The End Of Agile Estimation: Flying Without Estimates
In the past twelve months I have had the privilege of working across more than a half-dozen teams building digital services. It was interesting that only one of them was attempting to do estimates and it wasn’t clear to anyone, let alone them, exactly why they were attempting it. In this post I will sketch out how a successful large scale team abandoned estimations entirely.
You must have been hiding under a rock the past decade if you haven’t seen a burndown chart or witnessed a game of planning poker. It may seem a bit odd that I am brushing off the idea of estimates given that “Agile estimation” is a thing. Heck, I even wrote an opensource planning poker webapp. Rather than get into why I believe burndown charts might be asking the wrong questions let me present a case study of a successful “no estimations” team.
For about a year and a half through to the end of 2015, I was working on a very large platform. When I left it had thirty folks working on it in a globally distributed team. When I arrived the platform was live and in the process of scaling up. Attempts to do scrum were failing. It was back-end heavy work and a highly technical platform. Everything that was being built was new, only built once, and had complex dependencies. The core engineers simply stopped engaging with ceremonies and just doubled-down on shipping working code.
The users of the platform were a large number of teams building business services. Their execs started to get really annoyed that features (platform technical capabilities) were late or stalled. They were being charged for the platform build and felt little control. This seems like a job for a certified scrum master to get in there and crack the whip on Agile estimations, right? Nope.
So how did the situation go from angry internal customers to high fives all round? The bloke in charge of the platform (who was also the platform chief architect) read The Pheonix Project and the team switched over to Kanban without estimations. Team ceremonies for Kanban got down to as low as 3 minutes a day. That was how quickly we could identify the tickets that needed collective focus or intervention. Anyone idle (due to Kanban board work limits) could stay on the line to swarm blocked, starved or urgent production support issues. Everyone else hung up and got on with their work.
As most of the time developers only had meetings totalling 15 minutes a week they were happy. Happy developers with less work in progress, and with better coordination due to fewer fires, gives high productivity. Better yet it was agile in the sense of responding and adapting quickly when things weren’t working. Rather than platitudes to “being bold” and “failing fast” the team was living the dream.
As blocking issues were dealt with pro-actively fewer things burst into flames. That freed up management time to do more proactive work. More often than not when the situation was more complex than had been anticipated the customers themselves were engaged. Usually, quick and practical steps (aka compromises) were found so that their business features were delivered on time.
After some months the team of thirty had many man years of statistical data. The data showed that the team was very good and breaking down the prioritised features into chunks that they could ship inside a couple of weeks. Inevitably there were some outliers of tickets that ran over spectacularly; but since we had been proactive about managing issues the few big outliers were all genuine knotty issues. Only with hindsight were the knots unpicked.
Given that a big agile team can be very successful, and very productive, without estimates why exactly do we feel we need estimations again? More on that in the next post.