I’ve been reading The Goal as well as The Phoenix Project. Whilst there are many important principals in these novels (and I highly recommend them) I wanted to highlight one in particular – The danger of too much Inventory or unfinished work.
Recently I was working on an Agile project. This team conformed to the scrum framework zealously, the application architecture was solid, the team were beyond excellent, we had fantastic and driven product owner. Yet despite all of this we consistently missed our sprint goal. Each retrospective we looked at the process, adjusted and tried again. We reduced sprint lengths, reduced the number of stories in a sprint, inflated our estimates for the stories, and quite a number of other adjustments. Nothing seemed to resolve the issue. We were confounded nothing seemed to resolve what was happening.
Finally Matt the Scrum Master suggest one last thing:
The entire team would only work on one story at a time.
Essentially we set a Work in Progress limit of 1, not for a given column (i.e. Test) but for the entire stream. As you can imagine there was a lot of resistance to this. In a team primarily made up of contract resource this seemed crazy. Can you imagine the burn rate? As with the old concept of a factory with contract resource in IT, you always aim to get your pound of flesh. This is expensive resource and you want to keep them busy. At least that is the common practice.
Despite the resistance the team committed to the restriction. Throughout the sprint only 1 story was allowed to be in progress at any one time. Amazingly the first story was signed off by the product owner within a day or two. I was astounded, the team were encouraged and it only got better from there. True throughput was achieved within the sprint, not by carrying stories over.
What caused this? What hadn’t we seen before?
I think for myself, despite all the rhetoric and the adherence to ceremony, my measure of productivity was fundamentally askew. Busy != Productive even if it is with prep for other items in the sprint. If it does not move the highest priority items from left to right then it’s probably not something that should be done.
For the team it forced the hive-mind to work as one, with only one item to work on, the team was forced to swarm on every problem. This helped to transfer knowledge and significantly improved resolution speed.
Responsible for the Technology strategy within IJYI, John is an evangelist for the adoption of DevOps, specifically how best to apply the tools we have at hand to improve delivery. Having worked within software development for the past 20 years, he brings a wealth of experience, technical expertise and passion both for technology and to see the next generation of developers flourish.
To further these goals he has recently undertaken taken PhD research at the University of Suffolk in to the field of Computer Science and Informatics, specifically looking at the further of application and testing within the enterprise.