How a Backlog of Work is Like a Tank of Gas

Screen Shot 2019-08-30 at 3.12.18 PM.png

Work is decomposed into smaller units (stories) and retained, to create a sufficient level of healthy backlog for a team to deliver.  Poor/low backlog may result in a team being blocked by unidentified dependencies, stopping work to refine more backlog mid-sprint, or pulling in work that is not ready, just to keep moving forward.

Much like fueling up before a long trip, if you don’t have enough gas in the tank, get stuck in traffic or need to take a detour, you may find yourself stranded. Stopping for more gas often results in you reaching your destination later than originally thought.

How much backlog you’ll need will depend on the dependencies your team has, the complexity of your work, and the demands on your team to be predictable.


Stable Teams Should be Non-Negotiable

How can delivery vary so much in time and quality?

How can delivery vary so much in time and quality?

A few years ago, we had a house built in rural Maryland. Working through a builder, we designed the layout of our home and painlessly moved into our newly constructed home about 6 months later. After we took full ownership of the house, there were minimal construction issues (a few nail pops). Fast-forward a year. A family went through the same builder and purchased land next to ours. It took about 9 months for the builder to complete the house and for them to move it. After they moved into their house, they had major construction issues (plumbing, electrical, HVAC). We were surprised and delighted by the builder and our overall experience. Our new neighbors were not. Considering our houses had the same builder, we wanted to understand why their house took an additional 3 months to complete and had so many quality issues. After comparing notes, we had our answer.

The root cause? The builder foreman left the company after our house was completed and there was nearly a 100% turnover of the main construction team and the sub-contractors (electricians, plumbers, HVAC, cabinet makers…). All of the optimizations the team had accumulated from building homes together were gone. Instead of taking the usual 6 months to build the house, they had to train new people (which slowed the original team members down) and mistakes were made along the way (requiring rework).

STABLE TEAM DEFINED

A stable team is a team that stays together (no adds or drops) over a period of time, ideally for at least 3 months. The construction team for our neighbors’ house had drops and adds throughout the 9-month construction, most importantly the building foreman. We had none.

Stable Teams have a few characteristics:

  1. Individuals on the team only belong to one team.

  2. The team has one backlog or queue of work.

  3. The team has limited dependencies on other teams.

  4. The team stays together (unchanged) for at least 3 months.

CONTEXT

Stable teams can be applied to any organization and at any level, from delivery teams to program teams, to portfolio teams. If they meet the 4 criteria listed above, they are a stable team.

RESULTS

Plenty of surveys and studies have been done noting how stable teams are “better” than non-stable teams.

Particularly, I’m going to reference a 2014 research study by Larry Maccherone. With over 50,000 respondents, let’s note a few key points that it concluded:

  1. Teams that stay together are more productive.

  2. Teams that stay together are more predictable.

  3. Teams that stay together are more responsive.

3-things-stable-teams.png

If we modify teams regularly or staff teams with people who are merely temporary members, we will never allow ourselves the opportunity of high performance. If we consider Tuckman’s stages of group development (forming, storming, norming, and performing), we will continuously be forming and storming. We’ll never have the opportunity to norm and perform at the same level as a stable team.

STABLE TEAMS SHOULD BE NON-NEGOTIABLE

Having unstable teams hurts productivity, which makes sense. If we shift people around (think re-orgs), we have to train the new team members in the norms of the existing teams. While we are ramping up new teams or team members, we’re also not getting work done. The changes, though well-intended, will have negative impacts in the short-term.

When trying to improve an organization, some start with a practices-first approach, installing Scrum, SAFe, Kanban, or some other framework. But whatever your framework, stable teams should be non-negotiable, if you want a predictable system. Have a backlog of work, build and maintain a team, and then deliver value. As noted in the Maccherone research, stable teams resulted in throughput improvements (as much as 60%), increased predictability (variability of throughput effect improved as much as 40%) and quicker responsiveness (time in process improved as much as 60%).

Good organizational design should include stable teams. Leadership should be incentivized to keep teams together and incrementally improve them. Remember, if you make too many organizational changes too often, it will be at the expense of customers and the business.