How a Stable Team Grows in Capability

Resist the urge to move team members to the work.

In contrast to Agile leadership values, the basic belief of traditional management is to locally optimize a team to gain efficiency. For instance, optimal teams are believed to be functional teams who are homogeneous experts in architecture, requirements gathering, software design, front-end development, database development, back-end development, testing, deployment, or support. The premise is that these teams refine their skill and they are the best to perform a particular job. As this thinking propagates, silos are created and local optimization prevails. This is management thinking and not the Agile leadership that is desired.

Alternatively, systems thinking and Scrum suggest that we optimize through a stable, long-lived, cross-functional, and increasingly T-Shaped team, creating interactions and teamwork to produce an outcome that is much greater than the outcomes possible from the individual people on the team.

The Scenario

Consider this scenario. On a product team operating in the Scrum Framework, Team A is missing a skill to perform its work that Team B has. What should you do as a leader? Below are three common anti-patterns I have seen along with a better pattern to try.

Anti-pattern 1 – Move people to the work

A common management anti-pattern is to move people to the work. The muscle memory of traditional management practice is to temporarily move the skilled team member from Team B to Team A to perform the work for Team A. This is a temporary measure to get the work done. It does little to increase the skill set of Team A to perform that work in the future. It also increases the team size of Team A and disrupts the team dynamic. Disruption of Team B is also in play as they lose a critical member of the team until the work is complete.

Since the goal is not knowledge transfer, this team member movement becomes required in the future for the skill set in question and keeps the skill locally optimized in Team B. This approach does not focus on having two teams capable of the skill to optimize the system.

A variant of this anti-pattern is to make the team member movement permanent from Team B to Team A or to permanently swap team members between Team A and Team B. This also is not sustainable as it is disruptive to both teams and only focuses on moving skilled people around versus increasing the capability across the system.

Anti-pattern 2 – Keep work with the skilled team

A second common anti-pattern is to never allow Team A to perform work if they are missing a critical skillset that only Team B has, allowing only Team B to take work of that nature. This is similar to the first anti-pattern as it locally optimizes Team B and does not increase the capability of Team A for the future.

Managers typically gravitate to this method as it seems less disruptive to all teams involved and appears to be more efficient in delivery. Unfortunately, this method falls victim to focusing solely on keeping the team stable and locally optimized versus spreading knowledge across the system. It is short-term, tactical thinking.

Anti-pattern 3 – Move work between teams

In this third anti-pattern, management instructs Team A to do what it can and then pass the work to Team B to complete it. This creates an unnecessary dependency and greater waste potential:

• Partially done work as the work passes between teams
• Extra processing to hand off the work
• Task switching to transfer the work
• Waiting to complete the work after hand-off
• The motion of the work to a new team
• Defects resulting from a lack of shared context between teams.

On top of this, similar to the first two anti-patterns, this method keeps the skill locally optimized in Team B and does not improve the system.

We need a pattern that works both to keep the teams stable and to increase the capability of the teams over time as needed.

Desired Pattern – Team organically grows skills

In contrast to the three anti-patterns, the desired pattern supports the Genius of the “AND”¹ by having an intense focus on both preserving team stability AND solving a knowledge gap (see the prior post on Improvement vs. Delivery).

Managers must let go in this method and allow the team to self-organize around correcting the skill gap. Team A notices it has a skill gap in completing its work that Team B possesses. A member from Team B temporarily pairs with a member from Team A without leaving Team B to transfer the skill to Team A as Team A completes their work. The team member from Team B is focused on coaching Team A versus doing the work for them. The teams apply this mechanism on their own with no management intervention other than supporting the teams in slowing down to grow capability.

Team A now has this skill in the future and will not need help from Team B. The system is optimized, knowledge is spread, the teams are self-organizing and collaborating to optimize the whole, and team stability is retained.

---

Locally optimizing teams is a management anti-pattern that must be removed as we focus on stable, long-lived teams. Allowing teams to focus on growing their skills organically to gain control over their work applies all of the core leadership values in the prior post—Do We Need a Manifesto for Managers?

Team happiness will increase when teams self-organize around their skill set growth by helping each other versus management reallocating their members, preventing them from doing work not in their skillset, or creating unnecessary team handoff dependencies. A happy team is a high-performing team that sticks together, organically grows in capability, delivers ever-increasing value, and gains control over their work.

---

References

1. Built to Last, Jim C. Collins and Jerry I. Porras 1994, 1997, Genius of the AND concept