Lean Up the Scrum Team, what? How many times have managers and organizations had to figure out a way to get more out of their production, because they are over budget somewhere or running behind schedule? The classic manager and anti-agile response is hire more resources, right? I say, No – Go the Opposite!
Go Even Smaller, Not Bigger !
Think less chaos in the development team person’s brain.
Less Chaos, Not More!
Do you think it is leaner to be on the left side brain or the right side? I know I would enjoy the right side more.
Think Lean in every way. In this blog post, I’ll examine an 8 person team of developers and testers in a 3 week Sprint. Just in this example, we will not worry about the Scrum Master or the Product Owner just to simplify the scenarios.
Do you shrink the number of people? No, you shrink the Sprint backlog. One might ask, “What do I mean by shrinking the backlog? How do I get all the work Done?” In actuality, what I’m proposing is not a shrinking of the existing Backlog, but a rearranging of the content of the Backlog into into different time boxes or velocity capacity. How do we arrange the content of the backlog?
There are 3 ways to rearrange the Sprint Backlog content:
- Change the Length of the Sprint (Time or time-box)
- Change the Team Size (changing number of people and Velocity Capacity)
- Combination of the above (Time-box and Capacity)
Change the Length of the Sprint (Time-box)
In our example, the 8 person team has 36 stories to complete in three weeks. As for the Sprint Time-box we can reduce the period into 2 weeks or 1 week. This does not mean change the story requirements or even now we need to complete 36 stories in less time. Just change the existing backlog size to fit the new time-boxes. Here is the math:
Here is what the backlog would look like on a scrum board based on the Sprint Time-box assuming the 8 person team and the same throughput:
One might say that nothing changed, but I would argue there is a difference. Any good scrum master know the extra work the team has to go through keep the priorities in mind, the status of stories and tasks and the work they did two weeks ago on something that just came back with a bug. All these small factors plus more add up, like compounding interest on your savings account.
The teammates brain at anyone time has to juggle all these stories as you never know what will come back for rework.
In a simple view each person on a team only has to monitor slightly more than 1 story per 1 week sprint.
Change the Team Size (changing number of people and Velocity Capacity)
So we looked at the variable of the Time-box, but some might say we need more time to code or test the code. I will touch on those agile-but statements later. For now, let’s just examine changing the team size. In our example team, we have 8 people which fits into the recommend team size of 7 plus or minus 2 people on a team. Typically this team size includes the Product Owner (PO) and the Scrum Master, but for our discussion we will ignore these two team members.
The number of people on a team impacts how well people can pay attention to what their teammates have done, are doing or when they need some help. The more people on a team the less they can see who needs help, because of all the communication networks in play at any one instant in time. The table to the right shows the number of communication channels.
By reducing the size of the team from 8 people to 4 people there is a 78% decrease in the number of communication lines that a teammate would be listening to (verbal) or monitoring (no verbal or environmental) .
78% Decrease in the number of Communication Channels
In a diagram the visual would look like this:
I wrote a blog post on team size previously http://www.gregmester.com/teams-growing-big/
Here is the chaos going on in the brain just based on communication channels between teammates
So here we are leaning up the communication channel chaos in the person’s brain.
Let’s Take it Even Leaner – Combination of the Changing the Time-box and Team Size
The graphic below show the various look of the backlogs. I know in the various scrum or agile tools 36 issues gets pretty long and that does not count the bugs that creep into the backlog.
Can you image only having to worry about 6 things during an entire week? Doing the math can the table below is created:
By reducing the team size in combination with the time-box there can be a reduction in clutter by 83%
83% Reduction in Brain Clutter
The resulting brains between someone on a eight person time in a 3 week time-box and someone on a four person team in a 1 week time-box
Result: Getting More Production Throughput
So we examined the impacts of smaller teams and smaller time boxes, but how this result in increased production throughput? I would offer up these areas of improvement will occur and they all contribute.
- Increased Team or Group Quality Checks
- More Opportunity to work stories together in pairs or a team
- Less Rushed to push Code into QA
- Time in Meetings are of higher quality or more focused on work to be done.
- Feedback Cycle more frequent
- see blog post http://www.gregmester.com/teams-growing-big/
- Less Time spent figuring out what to do next
- Less Bugs in the Code = Less Rework
Increased Team or Group Quality Checks
The smaller the team the more likely Teammates will check each other’s code. The reasoning behind this concept is the fact that with a smaller backlog teammates are not so concerned about staring on a new story so fast. In addition by having a smaller team getting code review requests is not that frequent and less chaotic. The result should be fewer bugs or maybe just just better code.
More Opportunity to work stories together in pairs or a team
Smaller backlogs mean people are not so quick to work a new story, they will naturally start to offer to pair program. Also such a small backlog will encourage teammates to work stories together, such as, splitting the tasks up that are needed to complete a story. The resulting teaming will result in stories being worked quicker and again with better code.
Less Rushed to push Code into QA
With a big backlog there is a natural tendency to move stories through the workflow sooner because there is so many stories to work. This encourages to lighten their junit test coverages.
Time in Meetings are of higher quality or more focused on work to be done
As I said in my blog post http://www.gregmester.com/teams-growing-big/
Now there is a 1 in 10 chance a developer will work a story vs a 1 in 20 chance
Smaller Teams mean less time needed to share concerns and next steps. Plus the conversation only happens for items that have the highest probability of being worked by all the teammates. Larger backlogs just mean more stuff that the developers will ignore because they don’t feel they will ever work on it. Developers don’t like to pay attention to things they won’t work on.
Feedback Cycle More Frequent
In a 3 week sprint there is only 1 demonstration or sprint review and only 1 retrospective. If the Sprints are 1 week then we will have 3 Demos and 3 Retros in comparison to a 3 week sprint.
1 Week Sprints = 3x the Feedback
Less Time spent figuring out what to do next
In our example of a 4 team with 1 week Sprint combination, there is not much deciding on what to do next. There is only maybe working one more story or helping your teammates in their efforts.
Less Bugs in the Code = Less Rework
Lastly but probably not the only other benefit from smaller teams with smaller time boxes and less backlog is the probability of less bugs in the code. As I stated in the item above “Less Time spent figuring out what to do next”, teammates will be encouraged to help more with code reviews and pair coding practices, which should result in better code going into testing.
Return on Investment
$ Cost Avoidance Gained $
So why do all this changing of team size or shrinking the Sprint time-box? I believe there is at least a 10% gain in productivity or throughput that can be gained from these simple changes.
Here is a graphic depicting what an increase might look like for the Sprint Backlog for various team sizes and time-boxes.
How does a 10% increase in productivity translate into dollars and expenditures? The cost avoidance
In general practice we could add person to the 8 person team, but most of the writings and studies indicate that the return is not a full person value in productivity. So I would argue the 0.8 FTE is equivalent to higher another person full time.
Looking at some advantages and disadvantages on steps to get an additional 10%:
Hire Another Developer
Advantage:
- Adds productivity
Disadvantage:
- Adds costs $120,000
- Start the Forming, Storming, Norming, Performing model again (by Bruce Tuckman in 1965)
- Training new employee and other HR and on-boarding issues
- Need more real estate in the office for the additional person
- 4 to 6 sprints to reestablish velocity standards
Change Time-box or Team Size
Advantage:
- Adds Producivity
- No additional real estate needed
- No additional costs avoid $120,000
- No additional training as all the scrum practices remain the same
- Corporate operational practices don’t need to be introduced to new teammate
Disadvantages:
- Limited Start the Forming, Storming, Norming, Performing model
- probably only 2 or 3 sprints to re-establish velocity standard, as you can just use a proper fraction of the existing 8 person team velocity.
Summary:
I hope this article encourages leaders, scrum masters and managers to try the smaller team approach. I do believe you can get at minimum a 10% increase in productivity. Who would not want to deliver 10% more product or finish 10% early to cover all the unknowns that creep in.
Additional Research:
I browsed Google and found some addition articles that one might want to review:
- Why Individuals in Larger Teams Perform Worse
Organizational Behavior and Human Decision Processes; 117(1), 111-124
By Mueller, J. S. (2012) http://jennifersmueller.com/about/publications/ - Jeff Bezos’ 2 Pizza Rule..
Bigger doesn’t mean better when it comes to work. Jeff Bezos, the CEO of Amazon famously coined this with the 2 Pizza rule
Written by Janet Choi , Jul 29, 2013
https://blog.bufferapp.com/small-teams-why-startups-often-win-against-google-and-facebook-the-science-behind-why-smaller-teams-get-more-done - Is Your Team Too Big? Too Small? What’s the Right Number?
Jun 14, 2006
http://knowledge.wharton.upenn.edu/article/is-your-team-too-big-too-small-whats-the-right-number-2/ - Why Less Is More in Teams
by Mark de Rond, AUGUST 06, 2012, Harvard Business Review
https://hbr.org/2012/08/why-less-is-more-in-teams - The Hidden Benefits of Keeping Teams Intact
by Robert S. Huckman and Bradley Staats 12/2013, Harvard Business Review
https://hbr.org/2013/12/the-hidden-benefits-of-keeping-teams-intact
Happy Scrumming,
Greg Mester
