Continuous Improvement and the Aggregation of Marginal Gains

Much has been written about the concept of the Aggregation of Marginal Gains as it applies to cycling, such as this HBR article or this excerpt from James Clear’s book “Atomic Habits”. As a cyclist, cycling fan, and Agile coach, I have been looking at how this concept can be applied to Agile teams. Could an Agile team see significant improvements by making small improvements in everything they do?

In brief, the Aggregation of Marginal Gains is focusing on making small improvements in different areas that, over time and in aggregation, will result in much bigger gains.

Any team that has been through Agile training knows that they need to run a retrospective at the end of each iteration. My observations have been that while almost all teams do this, many are just going through the motions, a cargo cult approach. Once every two weeks they identify a couple items which may or may not actually get changed, a far cry from a kaizen mindset. When I’ve approached teams with the concept of aggregation of marginal gains, I challenge them to look at everything they do as they do it, not just at the end of each iteration.

In this article, I provide some examples and stories about “marginal gains” that in aggregation could help you and your teams make big strides. Agilists may feel like it is a combination of continuous improvement and weighted-shorted job first – wsjf pronounced “whiz-jiff”.

Continuous improvement is one of the three key predictive indicators of organizations who are seeing better outcomes with business agility. The 2019 Business Agility Report – released in partnership with the Business Agility Institute and AgilityHealth – highlights these three key predictive indicators and sheds light on the state of business agility today.

Read Now

As a simple example, the team finishes their stand-up one morning. I have them take a moment and de-brief the stand up. Did it provide value? Should they be asking other questions? Do they need to change the time, location, or participants?

Another standup tweak I have done with teams was the introduction of the parking lot. If the discussion during standup starts to go off on a tangent, someone says, “Let’s parking lot that” or “Let’s put it on the parking lot” and standup continues. Afterward, everyone that needs to take part in the extended discussion can stay on, while everyone else gets back to work.

Another example is how a team I was working with improved how they were using velocity for sprint planning. The approach they were using was to take the amount of points from the last sprint and use that as their capacity for planning the next sprint. The issue they were running into was that they weren’t getting all the work done each sprint. I introduced a simple approach to help. I helped them calculate “yesterday’s weather” for them taking into account the capacity for the each of the past three sprints. The capacity is a simple percentage based on how much of the team was available for the sprint. For example, if a team has four developers and runs a one-week sprint, if one of the developers is taking the whole week off, the capacity is 75%. If yesterday’s weather reveals that the team’s average capacity for the past three sprints was 20 points, they would only pull in 75% of that capacity in Sprint Planning = 15 points. This took the guessing out of sprint planning and the team started seeing less unfinished work each sprint.

This same team was having trouble with their retrospectives: they weren’t coming up with any real improvements. The team was geographically dispersed, and the retrospective was a discussion via a conference call. The introduction of a retrospective tool helped here. The tool allowed everyone to provide input, but it wasn’t visible until everyone was done and the facilitator clicked a button to share the comments. This approach eliminated group think and gave everyone on the team an equal voice.

The team was not writing sprint goals each sprint. I explained why they were important and helped them write goals for a couple sprints until they got a hang of it. The sprint goal became something they reviewed at the end of the sprint (did we accomplish our goal?) in both the sprint review and retrospective. Then the team started running with it. They looked for opportunities to relentlessly improve everywhere they went. They ran a debrief after finishing mob programming. They started using the burndown chart as a review tool in retrospectives. They did a “fist of five” vote at the end of sprint planning to identify and remediate risks. Each improvement was very small but part of the aggregation.

In Aggregate

Two months after starting with the team, they began to see the impact. In the words of one team member, they were “Crushing it!” The concept of the aggregation of marginal gains had taken hold. More importantly, the approach had instilled a relentless improvement mindset in the team. They no longer waited until the retrospective to discuss improvement ideas; they had those discussion every day.

There are a couple critical success factors that are required to make this approach work. First, everyone on the team has to be a part of the approach. It really has to be part of the culture and then it becomes contagious. However, if team members don’t feel their voice is heard or ideas aren’t being acted on, the whole approach won’t work.

Second, the goal is not perfection, but marginal improvements. The focus should be on small changes that are easily implemented, not big, difficult changes. The team may not see the impact of any single change, but as my examples show, after a while the impact will become visible.

In what ways do you and your team make small improvements?