So you want your team to deliver software faster?
To demonstrate why this request is nonsensical first imagine a mature, high performing Agile team who delivers on average 10 stories of roughly the same size in every 2-week Sprint (i.e. 1 story per working day).
Now imagine we asked the team to take on just ONE story every Sprint. Their capacity is 10 stories, but we ask them to only deliver 1. What might happen?
Well, we can’t be sure but it is fairly safe to assume that the 1 story is guaranteed to be delivered. We can also be pretty sure that it will be of an extremely high quality, given that the team are working well under capacity and so have plenty of time to dedicate to ensuring a bug-free and pleasant user experience. They may also spend extra time on exploratory testing, ensuring that the whole product, of which this story is a small part, is not hiding some ugly buggy behaviour. If they do find some bugs, they may fix them and add some tests to their regression suite to ensure the bugs don’t recur, increasing the holistic quality and maintainability of the system.
Given that the team knows they are an awesome, high performing team and they have plenty of time to spare in the Sprint, they will likely spend a large portion of their time not working at all. Having fun. Slacking off a little. Giving their brains time to breathe, to reset. Enhancing their team culture and spirit.
From a planning point of view, we may not have speed but we sure have predictability. We know that the team delivers 1 story every Sprint so we can very easily figure out when our product will be delivered with close to (if not exactly) 100% confidence.
OK, now let’s instead imagine we ask the team to deliver 2 stories per Sprint. It’s not too much of a stretch to assume we would get a similar result to the above, except this time some (albeit small) sacrifices will be made. Perhaps some of the extra, luxury activities will be left out. Perhaps all of the aforementioned activities will be done but with less time spent on them. So a little less story and product quality. A little less fun and recuperation time. A little less team building. While it’s highly likely that the team will surely deliver the 2 stories, the probability is slightly less than when we asked them to deliver 1 story. So we have a little less predictability.
What about if we extend this scenario to 5 stories? Then 8? Now imagine we’re struggling to hit a contractual deadline so we feel the need to “speed up”. So we ask the team that predictably delivers 10 stories to deliver 12 (now we’re over capacity). Or even 14?
Hopefully you can see where I’m going with this. The more stories we ask the team to deliver, the less time they can spend on quality, the more likely shortcuts will be taken, the more likely technical debt will be incurred, the more likely team culture and effectiveness will suffer, the less fun will be had, the more fried the team’s brains will be and the less predictable we will become at delivering software.
Read that again – the “faster” we ask (or worse, tell) our teams to go, the less predictable at delivering software we become, and that software is more likely to be of a lower quality. Allowing our teams to deliver at a constant, sustainable pace ensures quality, predictable software delivery, a higher chance of happy teams and happy customers, which leads to higher business value (e.g. profit).
In short, by allowing the team to find the right balance and deliver high quality software at their capacity, a cycle of success is created.
So, managers, please think twice before asking your teams to speed up, i.e. deliver more stories (or story points) than usual in a Sprint or sequence of Sprints. It’s like asking a marathon runner to start running faster after 32k for the final 10k – you’re increasing the chances of long term failure (not completing the marathon at all due to fatigue) for a potential short term gain (running some quicker kilometers).