Training workshops — from colleagues for colleagues
How to make the most of internal training?
We kept pondering that question quite some time. We know we have some very bright people amongst our colleagues. And we also have more than enough colleagues willing and able to learn. So how to combine these two factors?
Some background information
We were experimenting with this for years now. To understand why this is not an easy question you need to understand how we are operating — or better, how we are invoicing:
Bauer + Kirch started out with a product which was — and still is — sold to customers via licensing. But most of our revenue is made with individual development for our customers. That means that we are not selling a product or licenses but time and material.
So every minute not invested into a project is a minute not bringing in money.
Although this is somewhat true for product companies as well it is not that visible when your license fees keep coming in. If you stop investing time and effort into your products your customers will cancel their subscription at last — but it will take some time for them to become that annoyed.
We needed to find the balance between spending every minute on projects (and therefore stagnate in matters of technological expertise) and learning all the things we would like to improve ourselves in (but neglecting out projects and customers).
Discovering new ways
Things changed a few years ago when we restructured most of our teams using Scrum.
Our Sprint Planning is based on a mix of velocity and team capacity: We usually sum up the time of every team member spent at work during a sprint and the amount of work done, i.e. burned User Stories. For upcoming sprints we estimate how many hours we expect the team to work (subtract vacations, sickness and such) and — et voilà — we “know” how many User Stories we want to tackle this sprint.
But we wanted to talk about training and not our Sprint Planning, so let me get back to the main topic of this article.
Our first approach to enable more training for our teams was that every team may reduce their sprint capacity for training purposes. So let’s say, we have a team available for 20 days this sprint we reduce this amount to 18 or 19 days and use this value as a baseline for estimating the sprint scope. The subtracted one or two days could be spent freely on any topic the team considers important in this point in time.
Collecting ideas in a backlog
While this enabled the teams to invest time and resources into training it was without focus and — to be honest — scarcely used. So we enhanced this approach and built up a “Training Backlog” consisting of topics single developers or the whole team should improve in. Sometimes this were general topics like “improve understanding of testing techniques”, sometimes this included specific pieces of code crucial for products and sometimes the topics were various things like “check out this new library” or “let’s look for a tool that supports us with handling i18n translations”.
For about a year this worked pretty well. But then the advantages dimmed more and more. There were no specific problems and it wasn’t falling apart, but it didn’t feel like we were learning and improving enough anymore.
Introducing peer-level workshops
So we wanted to change things again. Our new idea is to hold training workshops on peer level. Any colleague wo thinks they know something well enough to teach others is invited to prepare some kind of workshop. It shouldn’t be a presentation where you are giving a long speech but something interactive. But otherwise there are no constraints but one simple rule: Start preparing the workshop only after a critical mass of colleagues confirmed interest in this topic. Depending on the topic, critical is quite variable. Usually you want at least four colleagues to make it worthwhile.
That’s the status quo at the moment. We have some workshops still waiting for participants to vote for this topic and some which are nearly ready. The topics include a wide variety like security for web development, Story Kickoffs (this may be another topic for our Blog in the near future), how to write good test case catalogues or even MS Excel basics. Currently there are about 20 different topics in our backlog.
Of course this does not (cannot and does not aim to) replace learning and training with real code and real problems. It has a much broader scope and seems like a good way to bring specific knowledge of our specialists to our motivated specialists-to-be.
There is just one minor problem… how to take enough time to prepare a workshop you are confident to call “teaching” or “training” and to include useful and realistic exercises while our customers keep calling with new work to do. We haven’t found the “Silver Bullet” for this issue yet…
