The only thing you need to keep track of in your team
"When will it be done?" You’ve definitely heard that question before. And it’s a hard nut to crack, especially when delivering software. Over the last few months, our Team Lead Thijs started looking for answers in the books of Daniel Vacanti. An expert in the field of agile and lean practices. And he found them. It’s time to talk about predictability and forecasting, people.
You know how to think probabilistically
Probabilistic thinking stands front and centre in Vacanti's books. And it’s no stranger to us too. When we introduced probabilistic thinking in our way of working, a colleague noted that it would be nearly impossible to use this method with our clients. According to him, people don’t think in a probabilistic way. But let's look at real-life to illustrate the contrary.
Everyone who ever commuted to work already knows how to think probabilistically. Let’s say you have an important meeting with your boss the next day. You can’t miss it. You need to arrive on time. Naturally, you already have a ‘kind of notion’ of how long it takes to arrive at work. Whether you use public transport, go on foot or by car. But you want to avoid being late at all costs. What do you do?
You add extra time to your commute. How much depends on how confident you want to feel that you’ll arrive on time. If you use public transport, you might take a train earlier. If you go by car, you may leave your house half an hour earlier. You add a buffer, just to make sure you don’t arrive late at that meeting. And there you have it. You forecasted something in a probabilistic way.
Apply the same tactic to your work
Let’s extrapolate this to knowledge work. The ‘kind of notion’ in the example above requires a definition of ‘commute’. It’s simple. Your commute equals the difference between the moment you leave your house and the moment you enter your office. After a little while, you develop a feeling of how long it takes. Simply by commuting regularly. Based on that information, you take your chances.
Notice how your internal forecast exists out of two parts? First, you have a range. In this case, a commuting time. Second, you have a probability. The more time you foresee, the higher the chances you’ll arrive on time. The same goes for software development. To apply this in software delivery, you only need a starting point and an endpoint for your work items. Decide what these work items are in your team and start measuring the time for a single work item to complete. That’s your cycle time.
Stop guessing, start forecasting
Soon, you’ll have tracked the cycle time of enough work items. Trends will emerge and you will start forecasting items in a probabilistic way. You’ll develop the same notion you develop when commuting. Based on historical cycle time data, you can generate forecasts. Only this time it won’t be a mere guess, the data will speak for itself.
