How much team stability is good?
As a leader, your choices about how you set up teams impacts how you can manage work.
By making decisions on how teams are structured and managed, we create inevitable consequences for how work is performed.
There is no “right answer” here. Each option gives some strengths and weaknesses. It is however important that you understand how team approach impacts the business. Some approaches align well with more structured, projectized organisations while others are a better fit for fast-changing organisations in a VUCA (Volatile, Uncertain, Complex, Ambiguous) environment.
In this article I will look at three different approaches to teams:
- Transient teams – building a new team for each piece of work. This is the default approach for projectized organisations. This approach can make it easy to impose control and can be an efficient use of people, but can cause inflexibility and siloing.
- Stable teams – making the teams the focus and assigning them the work. This is the default approach for Agile development. This allows much more flexibility and faster pivoting, but there’s some risks to watch out for.
- Dynamic teaming – combining these ideas to build teams with enough stability to self-manage, but enough flexibility to respond to changing circumstances and avoid stagnation. Requires a willingness to delegate more completely.
Transient Teams – the “project” approach
Let’s look initially at the “projectized” approach to teams and the implications of taking this approach. A “project” is defined by the Project Management Institute (PMI) as:
A temporary undertaking to create a unique product, service, or result.
Project Management Institute
The project sets a goal (the product, service of result). Initial planning then looks at what is required to achieve that goal. Teams are planned and created along with the rest of the project as part of initiating the project.
The project exists first and the team arrives later, an approach sometimes characterised by the phrase:
Bring the team to the work.
Project teams are transient. They are created for a specific project, exist for the duration of the project and are then disbanded at the end. Having transient teams implies some consequences for the organisation which are largely unavoidable if a project approach is taken.
Benefit: More business control
The main benefit of this approach is managing cost. A new project is approved based on a business case which investigates the benefits and costs of the project. As part of this, the needs of the project are defined and costed. This ensures that the people needed for the project are identified and agreed.
This “up front” approach to costing means that the project can be confident that the team cost is approved. It means that the exact needs of the project will be supplied and the exact skills are budgeted for. The team should be a good fit for the required skills. If the required skills vary with time over the project, the team can similarly vary with time.
Risk: Reduced business agility
To form project teams, we need to have availability of skilled staff to be formed into teams as projects are created. People do not appear from nowhere. We can recruit for each project. We can also remove staff after each project by having staff on contracts employed only for the project duration. However, it will typically take months to find skilled staff and departures mean a loss of key knowledge, which is a severe problem in knowledge industries.
However the people are found, transient teams need to be created and to develop a level of stability and sufficient knowledge to work effectively. Tuckman’s work suggests that any new team will take some time to become a high performing team. Although Tuckman’s methodology has been questioned, it seems clear that creating teams doesn’t come for free. Time and effort are needed in order to get the team to be effective.
Risk: Increased functional silos
As an alternative to recruiting for each project (which in most cases is unrealistic), most project organizations keep a pool of people available for project work. But this has its own consequences. This pushes the organisation down a “functional” path, with functional leaders controlling and assigning a specific skillset. In many cases it leads to intense siloing in functional groups.
The existence of functional groups sets up a tension in organisations. Ideally the project teams would be independent. However the functional owners typically control performance management and career progression. This leads to a likelihood that they will aim to influence the projects, rather than delegate. Since only functional heads can supply the people which projects need, they can end up with disproportionate power.
Risk: Resource management challenges
Every project needs to be resourced with the correct mix of people. Unfortunately the available numbers will not exactly match the desired projects. Resource management therefore becomes complicated and often generates conflict. Managers compete for the resources which they need.
There can be a conflict in objectives. Functional owners are rewarded for high levels of utilisation – making sure everyone is busy. Project teams are rewarded for delivering objectives. Shifting people between projects and under-resourcing often becomes a functional owner’s best interests.
Summary
Transient teams are a proven approach used widely in projects. They will be most effective in projects with longer lifecycles and low change environments and may struggle to manage change well. Transient teams will also tend to promote traditional management structures with lower team autonomy and hierarchical management approaches. This can risk the development of organisational silos.
Stable Teams – the “Agile” approach
Agile development was created to address some of the perceived limitations in the projectized approach which had dominated up until the start of the millennium. The Agile Manifesto itself gives very little detail of how teams should be built. There is a clear reference to self-organizing teams, and also to business people working with developers, suggesting cross-functionality.
The best architectures, requirements, and designs emerge from self-organizing teams.
Principles behind the Agile Manifesto
Although it is not explicit in the Manifesto, Agile development is typically built around team stability. Rather than being pulled together for one piece of work, the team is stable for a long time. The team comes first and is stable and the work flows through the team. This approach is often characterised as below.
Bring the work to the team.
Benefit: Higher responsiveness
The main benefit that a stable team brings is that it can respond more rapidly to changing circumstances. Business agility is a key focus of Agile development, so it is unsurprising that stable teams are a popular Agile approach. There is no “ramp up time” for the team, so new work can be started immediately, or at least as soon as current work is finished. If work in progress is minimised, an Agile team can rapidly be pivoted onto new work.
Stable teams combined with the use of prioritised Backlogs is a typical approach to allow the team quickly to reprioritise work and to keep team priorities aligned with business priorities.
Benefit: Self-management
Team stability is a requirement for self-managing teams (or “self-organizing” in the Manifesto terminology). If the team keeps changing and needing to rebuild, it will spend much of its time below peak performance. Long term stability gives the opportunity for clarity about decision making processes and lowest viable level decision making, allowing teams to self-manage.
Self-managing teams increase responsiveness through more efficient decision making and can be a powerful tool to help organisational scaling.
Benefit: Resource management
Since the teams are stable, the resource management challenges disappear. Resources are assigned long term, perhaps on a value stream basis, and at a team level. The resource management problem shifts to being a work management problem, as the teams are fixed, and prioritising the work for those teams is the equivalent challenge.
Risk: Limited flexibility
Although stable teams are widely used, they do bring their own challenges. While transient teams allow the needed skills to be assigned, stable teams are limited to the skills available to the team. Cross-functional teams give as much independence as possible, but combined with small “two pizza size” teams, flexibility is limited.
At any point the team skillset may not be a perfect match to the skills needed for the work. One frequent challenge is the inclusion of supporting functions such as architecture which may be needed periodically but not as a full time team member. Compromises on cross-functionality are often made when individuals need to be shared between teams, which can build dependencies and delay, impacting flow.
By bringing the work to the team, we necessarily modify the work to fit the capacity of the team. This is where we see teams becoming “feature factories” because it is easier to create based on the balance of team skills than on the business need.
Summary
Stable teams have been a popular approach for Agile development (although not specifically described in the Manifesto). They are effective at responding to changing business need and combined with a good backlog approach and management of Work in Progress can give a fast and flexible resource for product (rather than project) development. They can develop into true self-managing teams, bringing further advantages for speed and flexibility. However, small, stable teams may have dependency issues and be limited in the range of work they can perform. Long term stability could lead to stagnation.
Dynamic teaming
More recently we see organisations exploring approaches which seek to exploit advantages from both Transient and Stable teams, while minimising the penalties.
A weakness of Stable teams is the limited availability of skills in a small team. Transient teams by contrast have large functional pools but these can cause siloing and inflexibility. What if we had an intermediate position?
Dynamic teaming can take a range of approaches. Building stable teams but ensuring some exchange of individuals over time is one option. However, a promising technique is to build a group which is stable and cross-functional, but several times larger than a single Agile team.
There are a range of approaches in this space, from micro-enterprises to Agile Release Teams. The outcomes may vary somewhat but all are looking to build self-management at a larger scale. This scaling gives stronger ownership over a business area, typically a product.
Benefit: Higher ownership
Many organisations have found that a single “two pizza” team is too small to own a product. Multiple teams are assigned to a product, but without ownership they can become focussed on short term feature development. A larger independent group can take ownership.
This is the basis of a “microenterprises” model. This is close to the “rugby game” originally proposed by Takeuchi and Nonaka. It is probably best demonstrated today by Haier. Under the approach which they call RenDanHeYi (https://www.rendanheyi.com/), employees form microenterprises. These are flat-structured cross-functional teams of typically 10-20 people addressing a specific business opportunity. They take full ownership of the problem and its solution. The meaning of the name “RenDanHeYi” is that each employee should directly face users, create user value, and realize their own shared value.
RenDanHeYi refers to the opportunity of this model as “carp jumping over the Dragon Gate”. While a traditional approach to teams sees individuals as fish constrained to a pond, this model gives the team freedom to step outside the constraints to allow the team or individual to transform into a dragon.
Benefit: Higher flexibility
Specific teams can be formed from the wider group on a dynamic basis as needed. This gives the advantages of Transient teaming, but at a far faster cadence. Since the overall group is stable, team members know each other and can ramp up faster on work. But since individual teams working on a problem are dynamic, they can better be targeted on a specific problem.
How teams are formed may vary. They can be relatively stable, with some migration of individuals over a long time period. They can include “shared” individuals which do not fit naturally into a single team, such as architects or designers. Or they can use a swarming approach. The problems are reassessed periodically, perhaps each iteration, and the group agrees who to assign where. Teams of varying sizes, or even individuals, branch off to address individual problems, and then come back to the central group for the next problem.
Risk: Organisational integration
Delegating authority to teams can be a challenge to any organisation. With stable teams, the organisation delegates the management of work, but retains control of resourcing. Dynamic teaming gives increasing authority over not only how the work is done but who does the work. The larger teams may also gain more control over what work is done.
This greater level of authority can be a challenge for organizations. Projectized approaches often keep tight control of work, tracking hours against budgets. Stable teams usually use a value stream approach, accounting for the team costs. Dynamic teaming can lead to far lower levels of visibility of who is working on what at any time.
If a group is continuously readjusting to swarm around problems, how can the organisation best see that the work aligns with strategy?
Top-down control is unlikely to work with dynamic teaming. As with the microenterprise approach, a higher level of delegation is needed and measurement of outcomes will replace accounting work done.
Summary
Dynamic teams aim to combine cross-functionality with increased flexibility and avoiding stagnation in the teams. The micro-enterprise approach has been used very successfully. However, dynamic teams require a higher level of delegation from the business to be effective. This can be a challenge as the organisation can feel a loss of control.
Good Practices
How should you as an Agile Leader navigate this complex environment?
You should make sure you understand the options in team structure and the consequences of those options. If you have low margins and need to optimise utilisation and track and assign cost, transient teams are probably your best option. If you are developing product and need to be able to respond to customer feedback and pivot rapidly, transient teams will be a poor fit.
Takeuchi and Nonaka refer to the role of management as “subtle control”. This includes the shaping of teams to support the objectives of the business.
Enough checkpoints to prevent instability, ambiguity and tension from turning into chaos
“The New New Product Development Game” – Takeuchi and Nonaka
Slow adjustment of team members helps ensure effective cross-functional skills and diverse viewpoints while avoiding stagnation. Building the right culture helps the team build the skills and confidence to self manage. Supplying the support functions needed by the team allows them to focus on the areas in their control.
Leave a Reply