One week sprints or four?
Clive Beavis
Ex-Meta and 40 years of Software Development Management focused on Engineering Efficiency, now hands-on with compilers again.
And where do 2 week sprints factor?
Tldr; As with much of software engineering there is no one size fits all solution that is best. Both processes produced the same number of customer features in production.
Opportunity to experiment
Our startup had recently acquired a smaller company. The new team used a 1 week sprint process. Agile was something that their whole company had been trained on and they adhered to a strict Agile process. Our existing, somewhat larger team, used a looser 4 week iterative process.?
The new team was absolutely wedded to their process and were completely convinced it was the optimal, perhaps only, way to produce software. Our Kanban-style iterative process, I had introduced to the existing team, seemed to be working fine too.? Afterall we were the acquiring company ;)?
There was pressure from both teams to adopt their practice as the common process.
An opportunity to turn this into a bake off. Which process was best? Which should we adopt?
Metrics
First I needed a concrete metric to evaluate the results.??
?Accuracy of sprint burn-down, errors in production, sprint velocity etc were just means to an end and in terms of the processes were like comparing apples and oranges.
领英推荐
The only one that really mattered to the company was?
Customer features per engineer per month in production.?
No mention of this experiment was made to either group of engineers of course.
Hypothesis
My guess was that too much time spent defining precisely what would be done (1.5 days out of the 5 day sprint) was time taken away from building features and therefore, though the team believed they had velocity. The reality in terms of customer value would be less than the team that has more flexibility.
The results
Though customer features in production is a somewhat loose metric as feature sizes can vary in size, the results in this experiment were surprisingly too close to call.? The experiment was essentially a wash.??
Conclusion
It is not the process itself that makes the difference. It is having a process that the team buys into that makes the difference.
Learnings from years of iterative process
Long before Agile and other forms of iterative process became popular, and got cool names, my first start up we used an iterative process. For over 40 years I have always used an iterative process with all sizes of teams and all kinds of products and projects. The process has never been identical, even between teams in the same company. The process has to fit the team and the product. It does not work to force a process.
I have practiced 1,2, 4 iterations multiple times in various scenarios. In my experience 1 week sprints can be very effective with small teams (3-5 engineers), though it does not scale as well for larger teams or where a lot of cross functional communication is involved.