One week sprints or four?

One week sprints or four?

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.

要查看或添加评论,请登录

Clive Beavis的更多文章

  • Sprint to Survive

    Sprint to Survive

    These product iterations were built on 3-? inch floppy disks and shipped to sales and customers on a weekly basis. 35…

  • Word Blind

    Word Blind

    The line of impatient customers was growing behind him. This was his fourth attempt to get the 4 letters of “cash” in…

    5 条评论
  • What does done mean?

    What does done mean?

    Software development is non-deterministic. Predicting time lines is difficult, even impossible.

  • Time is Money

    Time is Money

    Someone commented on my last post that much of what I said about measuring the efficiency of engineers was applicable…

    2 条评论
  • Concrete measure for eng efficiency

    Concrete measure for eng efficiency

    My last post “Clive’s Law” was a way to think about developer efficiency for a whole organization. As I mentioned in…

    1 条评论
  • Clive's Law - E = 1/D**2

    Clive's Law - E = 1/D**2

    Engineering efficiency = 1 / (distance between engineers)**2 Keep this simple equation in mind when looking to make…

    8 条评论
  • Priorities - Don’t get me started on P0

    Priorities - Don’t get me started on P0

    The planning progression Once upon a time there were 3 priorities, high, medium and low. These were not considered…

    4 条评论
  • Are two heads better than one?

    Are two heads better than one?

    Architect level engineers are hard to find. These are the engineers that stand above the rest and are go to person for…

    1 条评论
  • What KPIs should I use to measure my engineers

    What KPIs should I use to measure my engineers

    A number of people DM’ed up with me after my initial post which was great. I appreciate the feedback and will adjust my…

    5 条评论
  • Replacing 55 engineers with 4

    Replacing 55 engineers with 4

    A number of years ago I was hired at a public company as the VP of Engineering. The relatively new CEO had expertise in…

    5 条评论

社区洞察

其他会员也浏览了