The terms ‘long-lived team’, ‘stable team’ or to a lesser extent ‘capability’ can evoke an almost magical reaction. The problem with a magical reaction is that it switches off our ability to think about the consequences of the attributes and assumptions that need to be true for these types of the team to function effectively.  When any concept takes on a magical aura, conflict and disaster follow.  Long-lived teams sometimes don’t always make sense in every situation.

Human Safety or High-Security Scenarios Influenced by Confirmation Bias.  Airline crews are a perfect example.  Rotating crew members helps teams to avoid confirmation bias.  The high productivity and trust of a capability team are replaced by detailed embedded processes and checklists. The cockpit checklist is used to establish a common process, the lack of familiarity makes sure that the pilot and co-pilot do not get overly comfortable in each other’s pattern of behavior and fall prey to confirmation bias.  The checklist is augmented by a strict observation of hierarchy. In the airline industry, long-lived teams have been linked to accidents. Gate duty was continually rotated so that no one became overly comfortable and strays from the process.  TSA officers follow a very similar pattern at major airports. In each of these cases, efficiency and interpersonal trust are traded for ensuring the process is followed and that nothing falls through the cracks.  Most software development scenarios favor the most efficient and effective delivery process because human life and security are not at risk when writing and testing the software.

Highly Variable Work. If either the type of work or flow of work is highly variable, a fixed capability team makes little sense.  One of the requirements for a capability team to be effective is a backlog of work to draw from otherwise the team will either sit or be highly inefficient (potentially ineffective also).  I recently spoke with a firm that occasionally required software development.  Rather than forming their own capability team, it made more sense to outsource the work to a firm with a capability team.

Cultures That Believe In Highly Matrixed Approach. Organizations that believe (magical thinking) that organizing hierarchies based on functional roles and then forming teams to tackle specific projects will only have long-lived capability teams by accident.  There are only three ways for capability teams to form and prosper in these environments.  The first is purely by accident, in this situation prospering also has to occur by accident.  Don’t count on this strategy.  The second is for a portion of the organization to seal itself off from the other part of the organization and embrace a new management approach.  This approach is similar to icebergs calving from a glacier; it happens but how long the new entity lives is an open question. This is a useful approach for trying out capability teams. The final and only long-term approach is to change the management culture within the organization; unfortunately, this is the hardest route (risk and reward are often related). In the end, until the management culture is refocused, creating capability teams staffed from matrix managers will generate friction and management frustration when managers try to lean in and task individuals.

Capability teams generally represent the holy grail for effectiveness and efficiency in Agile and Lean organizations. However whether we use the term capability team or long-lived team, no one should fall prey to magical thinking.  Magical thinking can cause mistakes.  Alex Yakima in the Software Process and Measurement Cast 439 strongly advocates that an organization experiments with a concept first, reviews hard data on the impact of a change and then thinks carefully about making a change.  This approach is the opposite of magical thinking. While my observation is that capability teams will usually come out on top; usually is not the same thing as always.