I have been working in agile ways for several years now and many things have become a mantra for every new engagement: we have teams of seven +/- two people, doing two week sprints and keep the teams persistent for the duration of the engagement. Sounds right, doesn’t it? But is it?

How do we know those things? Do we have science or do we just believe it based on the Agile books we have read and what people have told us? Over the last few weeks and months I have actively sought out differing opinions and research to challenge my thinking. I want to share some of this with you.

Team size

Agile teams are five to nine people. Full stop. Right? There is some research from Rally from a while back that shows that smaller teams are having higher productivity and throughput than larger teams. Larger teams, however, have higher quality. So far so non-controversial. If quality is really important, we want slightly larger teams and a higher percentage of quality focused people on the team. What really made me rethink this was an interview that I heard with an Agile coach, where he described how larger teams lead to better predictability of outcome. He made two arguments for that, one was quality as discussed above where lower quality leads to rework and in small teams that can really hurt predictability. The second one was the more obvious one; in small teams, sickness, holidays or other events have a much larger impact and/or people might feel less able to take time off and burn-out. With all this in mind, perhaps slightly larger teams are overall better. They might be less productive, but can provide higher quality, are more predictable and more sustainable. Perhaps those qualities are worth the trade-off?

Persistent teams

Teams should be long-lasting so that they only have to run through the Forming-Storming-Norming-Performing cycle once and then they are good to go. Every change to the team is a disruption that causes a performance dip. So far the common wisdom. I have heard arguments for a change in thinking – the real game changer is dedication to a team. Being 100% assigned to one team at a time is more important than having teams that work together for a long period of time. Rally in their research found that dedicated people have a 2x factor of performance while long-standing teams have only 1.5x. This model will also allow for more flexibility with scarce skillset – people with those can dedicate themselves to a new team each sprint. I feel there is something that speaks for this argument, but personally, there is a probably a balance to be found between full persistency and frequent change. But at least we don’t have to feel bad when the context requires us to change the team setup.

<<< Start >>>



<<< End >>>

Sprint/Iteration length

Shorter sprints are better. Two week sprints are the norm. I have said those sentences many, many times. When I looked at the rally research it showed similar to team size that shorter sprints are more productive but longer sprints have higher quality. So we need to consider this in designing the length of the sprints. We also need to consider the maturity of technology and our transaction cost to determine the right sprint length (less automation = longer sprints). And then I heard an interview with a German start-up. They run two week sprints most of the time, but then introduce longer four - six week sprints sometimes, and say this is because two weeks is too short for real innovation. Dang. Have we not all felt that the tyranny of the two week sprints makes it sometimes hard to achieve something bigger, when we forcefully broke up stories to fit into the two weeks or struggled to get software releasable in the two week sprint? I still think that the consistency of the two week sprints makes many things easier and more plan-able (or perhaps it’s my German sense for order 😉). But at least I will think more consciously about sprint length from now on.

There you have it, three things I took for granted have been challenged, and I am more open minded about these now. I will keep a much more open mind about these three dimensions of setting up teams and will consider alternative options going forward.

Mirco Hering

Global DevOps Practice Lead – IT Transformation & Delivery

Subscription Center
Subscribe to Software Engineering Blog Subscribe to Software Engineering Blog