Lean Up Scrum Teams and Save Money

Lean Up Scrum Teams and Save Money

Greg Mester Greg Mester

Greg Mester

More Value ??, Time ?, Experience ?? and Fun ??with Agile Cheerleader ??♀?, Full Stack Coach ??, and Keynote Speaker ??, ICP-ATF/ACC/BAF/ENT/CAT, CAL1/CSP/CSM/CSPO, PMI-PMP/ACP, SAFe SA/SPC, S@S, TKP, LeSS Basic

发布日期: 2018年2月18日
+ 关注

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!

brain full and lean interactions

number of stories to monitor in each time-box

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:

  1. Change the Length of the Sprint (Time or time-box)
  2. Change the Team Size (changing number of people and Velocity Capacity)
  3. 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, time-box story math, in 6 weeks all the time-boxes work the same number of stories:

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, 8 person team backlog various weeks:

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. time-box impact on brain, 8 person team and time-boxes 3 week, 2 week and 1 week:

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.

Table: communication channels 8 and 4 people

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: communication channels 8 people vs. 4 people

I wrote a blog post on team size previously https://www.gregmester.com/teams-growing-big/

Here is the chaos going on in the brain just based on communication channels between teammates, small lean channels:

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.

Sprint backlogs – 8 people 3 weeks (36), 4 people 3 weeks (18), 4 people 2 weeks (12) and 4 people 1 week (6)

Can you image only having to worry about 6 things during an entire week? Doing the math can the table below is created, lean 83% stories to track for 4 people in 1week time-box:

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, 8 vs 4 people team:


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.

  1. Increased Team or Group Quality Checks
  2. More Opportunity to work stories together in pairs or a team
  3. Less Rushed to push Code into QA
  4. Time in Meetings are of higher quality or more focused on work to be done.
  5. Feedback Cycle more frequent
  6. see blog post https://www.gregmester.com/teams-growing-big/
  7. Less Time spent figuring out what to do next
  8. 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 https://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, 10 percent increase in backlog:

How does a 10% increase in productivity translate into dollars and expenditures? The cost avoidance

cost avoidance table

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:

 This article is also found in my blog site and posting:

https://www.gregmester.com/lean-up-scrum-teams/

 Happy Scrumming,

Greg Mester

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

更多精彩文章

社区洞察

其他会员也浏览了