That’s right, I’ve said it. Your management doesn’t care about development speed.
Wait a minute! Didn’t they try to push our limits all these years? Trying to get us to do more work in less time?
True, but let’s take a look why they’re doing this.
Suppose you’re planning a next batch of work. After the estimation part, you typically get into a discussion about how much scope to commit to. Developers want to be careful and include some contingency. Management gets nervous and tries to sell more scope to the development team. A thing they often succeed in, thanks to their hierarchical power in the company.
So why do both party’s behave this way?
Because of the variety in delivery. Each person carries along a history of projects, iterations, batches of work. And a huge percentage of us have experienced many plannings that weren’t delivered according to commitment. So what do we do? We use that experience to improve our next planning meetings. Developers try to commit to less because in most cases they weren’t able to deliver the scope. Managers try to push the developers to commit to more because they believe they need to ask for more in order to get what they initially want. They build in contingency in the other direction.
Why? Because they really care for predictability. They want to leave the planning meeting feeling confident, feeling reassured that the team will deliver the scope in time, so they can commit to their stakeholders (customers, the board, …). They don’t want to team to work faster each and every time, they want them to deliver consistently.
Now, what’s an approach to deal with this? How can you reduce variability?
One approach can be found in the Kanban world, where collecting data is one of the key concepts to improvement. Not improvement in the sense of increasing development speed, but improvement by reducing variability.
We collect data to be able to monitor the delivery time of a feature. When a feature gets pulled in the Kanban flow, we can assign it a relative size by using t-shirt sizes for instance (XL, L, M, S). Then we monitor how long it takes to pass the flow. In a period of time, we get date on the delivery time of each feature size.
If we want to take care of the most important concern of management, consistent delivery, we need to remove the peaks and valleys in the previous graphs. Each feature should be delivered close to the average. If the default delivery time of an XL feature is 19 days, management is happy if a XL feature gets delivered in 20 days. But they won’t be smiling when it takes 30 days.
So collect the data, and focus your retrospectives on reducing that variability. You will be one step closer to a good relationship with your management.