How to Overcome Inertia to Deliver Value Sooner
Five ways to deliver value quicker with Scrum.
Do you ever feel like the pace of feature development in your Scrum team is too slow? Or, more specifically, that you’re not delivering value at the pace your customers expect? Scrum, as a framework, was specifically established to “address complex adaptive problems, while productively and creatively delivering products of the highest possible value” (The Scrum Guide). However, for both new and established Scrum teams, it can be difficult to identify exactly which practices are slowing down value delivery. Here, I highlight five potential causes of inertia and consider how Scrum can help development teams to improve in each of these areas.
1. Technical Debt
Technical debt, in my view, has the rare ability to inspire fear for even the most seasoned Product Owners. The work needed to improve on historic technical issues and solution gaps can be difficult to estimate and difficult to gain visibility over. As such, it can seem almost impossible to prioritize technical debt effectively. That said, it can have serious implications for a Scrum team’s velocity.
When aiming to deliver value to customers, technical debt has the potential to make seemingly simple backlog items much more complex and difficult to test. As Agile consultants McGreal and Jocham highlight (from a more positive perspective), “the healthier your codebase is, the more test automation you have, the more capacity you have for innovative features” (2018, p.80).
They suggest that metrics can be used to measure and act on technical debt. One useful metric is the team’s innovation rate. Innovation rate refers to the amount of user value delivered in a given period, relative to the amount of maintenance work completed. To measure this, one could consider how many new features are delivered each Sprint, compared to the number of “planned maintenance items” such as upgrades and bug fixes. Alternatively, teams could measure the relative amount of time spent on these items (p.82).
By tracking innovation rate over time, Scrum teams can establish more transparency with stakeholders around the amount of technical debt addressed each sprint, and measure improvements in their ability to innovate.
2. Sprint Hangovers
The second potential cause of inertia for Scrum teams is what I like to call sprint hangovers. Sprint hangovers occur when teams fail to break down stories appropriately and allow them to carry across into subsequent sprints.
Identifying the “right” size for a Product Backlog item can be difficult, especially for newly formed Scrum teams. According to Roman Pichler, Product Backlog items should “fit into a sprint”, and teams should consider “decomposing” them a few sprints before work actually begins, especially where “large and complex” pieces of functionality are concerned (2010, p.61).
By breaking down items earlier, teams have the opportunity to gain feedback from stakeholders ahead of time. As such, issues and complexities can be uncovered before the item is even brought into the sprint.
3. External Dependencies
For Scrum teams working within larger organizations, external dependencies can prevent the delivery of value. Dependencies arise when a product relies on another product or system, or when multiple teams have to work alongside one another on the same feature or component (Pichler, 2010, p.92).
When a part (or all) of the product is dependent on the work of an external team, it can take more time to identify who is responsible for completing work and to ensure this work is done. Therefore, a sensible approach to reducing external dependencies is to look a few sprints ahead, to identify the items that the team is likely to work on. Then, it becomes possible to liaise with external teams in advance, to ensure that the necessary work is completed before the relevant sprint begins (Cohn, 2005, p.206). An important point to note when looking ahead is that by anticipating requirements, we are not committing to them. As Roman Pichler (2010, p.93) puts it:
“[T]here is no alternative. Not looking ahead is like running through the woods in the dark without a flashlight or headlamp. Chances are that we will bump against trees and hurt ourselves.”
Ouch.
4. Internal Dependencies
Just as inertia can be fuelled by dependencies on external teams, internal dependencies can be extremely problematic. In particular, when developers are deeply specialized in their specific domain, single points of failure can arise when a particular team member is suddenly unavailable.
Imagine a scenario in which your product is reliant on some lower-level functionality, which only one team member understands and is able to work on. What happens when the team member in question takes maternity leave or goes on sabbatical?
If our cross-functional teams are to be truly effective in delivering value, we must ensure that knowledge is shared in the team and that developers have sufficient learning opportunities. Moreover, these opportunities should not be limited to a single, specific field of knowledge. As Scrum.org CEO Dave West points out, the focus must be on delivering value, not on retaining traditional job titles:
“It cannot come as a surprise for anyone that agility encourages team members to do “stuff” outside of their skill base. To have a willingness to do work they are neither familiar with nor even have all the right skills. Agile teams balance size and skills to ensure they can deliver value.”
By encouraging team members to learn from one another, we can reduce dependencies on specific team members and potentially deliver more value to our users.
5. Excessive Governance
The final obstacle we’re going to consider is governance. It is well established in Agile that when a team has little agency in relation to its work and processes, the rate at which value is delivered could be unnecessarily slow. The Agile methodology, and by extension Scrum, recognizes that processes, contracts, and extensive documentation can get in the way of efficient software development.
However, it can be difficult to identify what an appropriate amount of external governance looks like. According to McGreal and Jocham, one useful approach could be to allow the development team to select the internal documents that serve to help them. These could include requirements, test cases, mock-ups, and style guides.
For external documentation, the Product Owner is best placed to decide what is most useful for the team’s stakeholders. For instance, user guides and legal compliance could be necessary. They note that problems may arise when organizations do not have trusting relationships with development teams, as this could lead to external pressures to produce internal documentation in a particular way (McGreal and Jochem, 2018, p. 295).
Trust can be built by delivering working increments each sprint, and arguably by engaging regularly with stakeholders in a transparent way (e.g. through the Sprint Review).
Summary
Inertia in Scrum teams can arise when there are internal or external barriers to delivering value. Such barriers could include having too much unaddressed technical debt, substantial dependencies, too much external governance, or not breaking down backlog items sufficiently. However, there are methods within Scrum that teams can use to reduce the impact of these problems. Building trust, communicating ahead of time, and reflecting on how your team’s processes can be improved are all useful ways of overcoming inertia to deliver features (and products) that improve your users’ lives.
Do you want to write for Serious Scrum or seriously discuss Scrum?
