General

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.

Karaoke Agile

Have you ever gone out with your friends to a karaoke bar and watched someone, who did not speak English, sing the best Bon Jovi Livin on a Prayer you have ever heard, just short of seeing Bon Jovi live back in 1987?  I've seen both.  Have you ever worked with or for someone who follows a process or framework to the letter but does not have the first clue why they are doing what they are doing?  Again, I've seen it. The major difference is one is singing a song for personal entertainment and the other is potentially wasting time, money, and putting projects or product delivery at risk.

Cargo Cult

The name is derived from the belief among Melanesians in the late 19th and early 20th century that various ritualistic acts such as the building of an airplane runway will manifest in the appearance of material wealth, particularly cargo, via Western airplanes, though the meaning of the behavior is more complex than a simple misunderstanding. That mouthful is brought to you from Wikipedia.

I hear cargo cult referenced a lot in the Agile community.  I've been to half a dozen Project Management conferences and never heard the term once. I've been to an equal number of Agile conferences and heard it used every time.  We reference it all of the time, referring to the rituals of Scrum, SAFe, and other frameworks.  People memorize the frameworks but don't know why they are doing the rituals. They have little hope of improving upon a framework, if they follow rituals blindly.

Agile Translation

I recently wrote that the Agile community should consider using terms anyone understands.  If I said cargo cult, I would have to spend the next few minutes quoting what I wrote above, to explain it to a customer.  It could make you feel smart, needing to educate someone on a new term.  But, why not use a new term like karaoke agile?  First, I know the Agile community LOVES to use Japanese words.  With a Japanese word origin, from kara empty + ōke, short for ōkesutora orchestra, practitioners should be all over this!  For better or worse, I don't know anyone who doesn't know what karaoke is.  This includes anyone outside the Agile community.

Karaoke Agile

Combine words of Japanese origin and the word Agile.  Stop using the term cargo cult when describing people or organizations that follow processes or frameworks without understanding why they do it.  Win-Win.