Predictibility

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.

Getting Teams to Deliver Predictably

delaysAs recently as this week, I've been involved in conversations with customers about how we can help make their teams deliver more predictably.  How can they meet commitments on all levels of the organization, including project, program, and portfolio? Well, it's not easy.  There is no silver bullet that is going to allow you to align the organization overnight.  I do, however, have one recommendation:  Stop trying to maximize the utilization of your people.  I know some are going to find that hard to understand.  To maximize value throughput, you need to keep your people as busy as possible, right?  Didn't Henry Ford do it that way, when he had cars coming off the assembly line at three-minute intervals?  Actually, no, he did not.  What he had and what you need is a balanced system.

Henry Ford did not have everyone working at 100% utilization.  If everyone worked at 100%, the result would have been congestion -- bottlenecks within his (assembly) system and the production of excessive parts inventory.  Instead, one of the many things he did was focus on limiting lead times.  That's the time something waits before an activity happens.  By understanding his system, he was able to have the right amount of people, working at the right pace, in the right sequence, in order to maximize flow (delivery through the system).

When trying to get your teams to delivery predictably at your organization, let's look at this from a 100,000 foot view:

  • Understand Current and Potential Capability and Capacity
  • Understand the Delivery System and Establish Goals
  • Balance Capacity and Capability with delivery throughput
  • Monitor Performance

That is how you establish predictable outcomes.

No let's look at this with some detail.

Understand Current and Potential Capability and Capacity

You've probably heard the analogy of a freeway being a value delivery system.  If not, let me draw the parallels.  On a freeway, we don't care about utilization; we care about throughput. That is, we don't care how many vehicles can fit onto the freeway. We care how quickly we get from point A to point B.  Measuring the capacity of the freeway is not going to directly help us. Measuring the throughput will.  For those who follow Lean Startup, these are referred to as vanity metrics and actionable metrics.

Actionable metrics can lead to informed decisions and subsequent action.  Example, I know how fast the vehicles travel on a given freeway, therefore I can plan accordingly to arrive on time.  Vanity metrics show that you're measuring things, but they really aren't helping you. You need to measure the right things.  By measuring the capacity of a freeway and then trying to fully utilize it would be foolish.  Strangely enough, I see organizations do that with their people all the time.  They try to keep them as busy as possible.

Understand the Delivery System and Establish Goals

We don't build bigger freeways so they can hold more vehicles.  We build bigger freeways because we're not smart enough to figure out how to limit the size or amount of vehicles on them at the same time.  The fewer or smaller the vehicles on the highway at the same time, the faster everyone moves along.  To increase throughput (speed) on a freeway, you need to increase the ratio of space utilized by a vehicle relative to the total space of the freeway.  If we could increase the (distance) buffers between the vehicles, we'd have fewer start and stops along our commutes. Once we hit higher utilization rates, things dramatically slow down until we have traffic jams.

Balance Capacity and Capability with delivery throughput

It's the same thing with knowledge based systems!  Exceed a 70% utilization rate and you'll begin to see dramatic performance decreases.

One thing that I have seen that is bringing it together is enabling teams to make their own commitments.  Once they have a sequenced queue of work and all the people necessary to complete that work, allow them to commit to, start, and then finish it.  You should begin to see the flow of value start to emerge.  Don't pull people from the team to give them "busy" work.  Don't push extra work on the team to keep them busy.

Monitor Performance

You can tell if your people are over-utilized by measuring the lead times.  If their work is properly sequenced, and they limit the size and volume of work they agree to do at any given time, the result should be minimal delays.  If you want to go faster, you may have to change the system.  Measure how long it takes to get something through your system.  Reflect on that.  Were there any dependencies on other people or resources that slowed you down?  Did you have your people over-utilized?  Was the work you committed to too big?  Look for an area of possible improvement, address it, and run work through your system again.  Did the lead time get shorter?

Going back to the commuting analogy, for those doing the driving, understand the conditions and know the optimal start time to begin your commute in order to avoid delays and arrive at your destination without breaking any laws.  For those asking for arrival commitments, respect what the driver tells you.  If you don't, you'll find people doing things like driving on the shoulder or illegally speeding in the express lane, just to arrive on time.  Sooner or later, there's going to be an accident.

Originally published on the LeadingAgile blog