ScrumHow Can We Speed Up Our Low Velocity Scrum Team?

Our organization has a number of Scrum teams working on various projects.  Some exhibit much higher velocity than others.   Unfortunately, some of the teams with low velocity run the risk of not being able to complete high priority work items in the product backlog.  Management is considering whether to replace team members with more experienced and/or skilled members.  For example, replacing a mid-level developer with a more senior developer.  However, some believe the team is understaffed and that we should add more team members. As consultant coaches, what are some things we should consider?  How should we advise our client?

How can we increase the velocity for our Scrum team?  First, and most importantly is to make sure we understand the problem.  Although ostensibly the problem is low velocity, we should first review the way velocity is being measured, and then compare that to other throughput measurements for this team and other teams.   If Story Points are being used, compare the number of Story Points delivered (velocity) versus the number of items delivered (throughput), and compare both numbers to those of other teams.  Also, are Story Point estimates updated at any time after initial estimates are recorded?  We have observed situations (especially for a new team) where an item was estimated very high but was delivered much faster and easier than expected.  This “mis-estimation” would skew the velocity upwards.   Of course, the same thing happens in reverse even more frequently, due to “optimism bias” (see Thinking, Fast and Slow by Daniel Kahneman).  Due to these factors, it is entirely possible that what we have is a mismatch of expectations rather than an actual case of low velocity.  Expectation management is a critical piece that many IT workers miss.  Even accomplishing the remarkable feat of landing on the Moon may be viewed as an abject failure if management expected a Mars landing.

Assuming we have done our due diligence and are convinced that there truly is a need to improve velocity, there are several options available to increase the velocity of a Scrum team, including process improvements, tooling improvements, scoping changes, and staffing adjustments.  In order to determine the most appropriate thing(s) to change, we should first consider our circumstances and ensure we are addressing the underlying reasons behind the current level of throughput.   Even if we are extremely confident in our analysis and recommendations, we should still proceed scientifically, ensuring we have accurate baseline measurements and performing “safe to fail” experiments that are quantitatively measured to prove their effectiveness.  We should also be aware that some changes take time, so the results may not be immediately visible.

Since we are talking about a Scrum team, an optimum size all else being equal is generally agreed as being between 3 and 9 team members (depending on many factors outside the scope of this article).   We should consider:

• Team Size: If the team only has three team members, for example, it’s more likely that adding another team member is a good idea than if the team already has 8 or 9 members.
• Bottlenecks: Are there bottlenecks that indicate where the work gets stuck? Perhaps backlog items are not well-analyzed, so developers need to make many assumptions that turn out to be wrong and lead to rework.  Are there a lot of items stacking up waiting for manual testers to become available?  If there are regularly occurring bottlenecks that are outside the control of the team, then systems thinking tells us that adding additional team members could actually make matters worse.  On the other hand, if the bottlenecks are occurring due to the team lacking some specific skill or authority, then bringing someone with that skill or authority into the team may make a huge difference (e.g. DBA, Operations, compliance expert, tech writer, etc.)
• Release Cycle: Even under the best possible conditions, adding team members decreases team productivity in the short term and the level of disruption may be greater still in the case of replacements.  Therefore, if we are trying to hit a target that is less than a few months away, adding team members may well only serve to delay the team further.  Fred Brooks made this observation in his seminal 1975 classic “The Mythical Man-Month.”
• Team History: Has this team been working together for a long time, and likely suffer loss of morale if a team member was replaced?  Are they all recently hired consultants who have never worked together before?
• Application Criticality: More critical leads to a tighter Definition of Done; items likely take longer to complete.
• Definition of Done: Is the Definition of Done more rigorous than that of other teams? We need to make sure we are comparing apples to apples.   For example, perhaps this team is updating end-user training, design documentation, and compliance items that simply don’t apply to the other “higher velocity” teams.  Taking those into account, it is possible this team is actually higher performing than the others.
• Software type: Enterprise COTS (e.g. SAP, Salesforce) or Legacy software teams often have a lower velocity than greenfield teams. Any large and complex pre-built system has constraints, standards, and guidelines that must be learned, making the task of adding complex new functionality tricky.
• Team Morale: Are people generally enthusiastic about their work or has everyone determined the deadline is hopeless and they have emotionally “checked out?”
• Teamwork Style: Do team members regularly review each other’s work and collaborate as appropriate? Or does everyone hunker down in their cubical and speak only during the daily standup?
• Scrum Process: Is the Scrum meeting held daily? Are sprint planning and review being done, and are retrospectives being held regularly?  There is a big difference between a mature Scrum team that is starting to experiment with some Lean or Scrumban / Kanban processes versus a team that “can’t be bothered” to follow the basic practices (see Shu-Ha-Ri)
• Quality Issues: Is the team experiencing a lot of quality issues? Perhaps more items are not getting completed because they need rework.
• DevOps Tooling: Does the team have CI/CD in place? Are automated tests relatively easy to build or very difficult?

Assuming none of the above issues sticks out as a root cause of slower performance, there is ample time left in the cycle, and the team is amenable and not already full, adding a senior team member or two could indeed be helpful.  In our experience it is best if the team participates in the interviewing process.   We do not recommend replacing a team member except in the case where a team member is widely recognized as a problem by the other team members.   On a Scrum team, incompetence or apathy is immediately noticed by all team members and should be addressed quickly.  Assuming proper HR procedures are followed, replacing such a team member with a more senior and committed person is usually welcomed by the team.

In summary, when looking into how to increase velocity for a Scrum team, we should keep in mind that there are many different possible root causes for “low velocity” on a Scrum team, and adding or replacing team members is disruptive and may even be counter productive.   We should first consult with the team: perform our due diligence and root cause analysis.  We may need to make some small experiments to validate our hypotheses.  Finally assuming the team is amenable, we may add or even replace team members if it makes sense.