There is a favorite answer to this question, and it is: yes, Agile teams should be stable. And that is in a big part because most of the research done on team performance favors stability of team composition. That is to say, teams where the membership of individuals remain stable over time tend to perform better. And by perform better we mean they achieve great results in faster time, with less conflict than teams with high turnover.
In my opinion, all these questions with “should” are a matter of assessing a pros and cons list. So, to answer the question “Should Agile teams be stable?” we will go over the definition of the stable team with you, you’ll understand what it opposes to, and look into the advantages and disadvantages of it.
The definition of a stable Agile team
Have you ever worked on a team where you are waiting for someone else to become available to help your team? Maybe it was Abilash, the DBA, to be free from his other duties and come and support you in the development of your application. Maybe it was Nora, the business analyst that knows so much about the business that she’s given literally just four hours with your team to help you in whatever way possible? And remember how things stayed stuck, tasks in waiting, because you did not have access to these people?
That’s the world full of specialists and silos. It had a purpose alright, but in the world of Agile, where we are talking frequent delivery, collaboration among teams and the customer, and not starting new work if you did not finish old work, you can see how this hurts the flow of work and creates a lot of hard dependencies.
A stable team requires cross-functionality. While we don’t ask people to abandon their specialties, the reality is that an Agile team, to be successful, needs to have in its composition all or most of the knowledge required to deliver their work. So, in light of that, here’s my definition of the stable Agile team:
A team where you bring the work to them. You don’t assign people partially here and there and you do not disband and reform the team all the time.
Here’s a simple way to understand all this.
This is a stable agile team: bring the work to the team.
This is a resources team: where you bring the people to the work.
Resource allocation is detrimental to high performance
Stable team is a concept that fights the mindset of partial allocation. Partial allocation is PMO sorcery to make budgets close in the world of projects. Get 35.7 hours of Jennifer plus 13.3 hours with Matt.
While I acknowledge I am simplifying the issue in that sentence, one thing is clear: people are put together as a team to solve a problem. Well, then, they need to be given a fair chance to solve the problem. Having management folks playing chess and moving people around as players on a board interferes with the team member’s ability to do their best work. Not to mention it hurts their autonomy and motivation. Wait a minute… didn’t agile talk about motivated individuals?
I worked with many teams where they could not have a team member allocated for the full week. They were a “resource” partially allocated. Like bolts in machines. Someone was splitting their time as if all that mattered was the math of it all. They can only come in on Mondays. Then they do their part of the work. And what cannot be finished… will wait till next Monday!
This is the damaging mindset of treating people as resources. When you think resource, you think of something that can be swapped without any performance loss, interchangeably, like a hard drive in a server. That’s not the same with people. People need to get used to each other to perform at their best. In knowledge work especially people can’t just come in and fix something. They are all usually figuring out the simplest solution to a complex problem. There is a lot to be discovered when complexity is involved. So, Ahmed cannot come in for 2 hours and solve for it. That’s a fantasy, unfortunately.
One final word on why sometimes managers keep this practice of partial allocation is because they start way too many projects or initiatives at once. And they have only two specialists on the topic for the whole organization. So, what’s required here is a good hard look on prioritization and focus on value delivery, instead giving in to the shiny object syndrome.
If your organization seems still stuck in the mindset of resource allocation and find all those financial and mathematical reasons, guide them into the world of Beyond Budgeting. Enabling their Business Agility has a much better payoff than micromanaging teams.
The advantages of stable Agile teams
Agile is about addressing constant change and complexity. So, if you somehow have projects or products that contain neither, you don’t necessarily gain anything extra from working in Agile ways. But if you do work with complexity and change, what if you could have one less change to deal with? What if you could simplify one thing? And that is keeping the team together. Would you take it? I’d do it in a heartbeat!
Here are some of the advantages of bringing the work to the teams, aka, keeping stable Agile teams.
Progressive team development
Many team development models exist and the most famous is probably the Tuckman model, which states that the team dynamics shifts several times from Forming to Performing. They go from a period of lack of trust and too much politeness interacting with each other, to clashes and adjustments, all the way to trust and effective teamwork.
As you can imagine, if you keep adding or removing people to your team… you are constantly getting back into the initial phase of development and doing the cycle all over again. So instead of focusing on the work, we are back to the drawing board with team agreements, ways of working and other much needed team boundaries’ definition.
Once the personal quirks and adjustment get out of the way, it is then possible for the team to focus on their ways of working, their process, how they show up as individuals. If team membership changes constantly the team might feel like every day is Groundhog Day, where problems you have of miscommunication, individuals liking to do things differently, and mistakes all keep repeating themselves and you need to apply old solutions to old problems. It’s unfulfilling to say the least.
Stable Agile teams improve their interpersonal dynamics and gel progressively over time.
Increased trust
I know you, you know me. You don’t trust who you don’t know, and trust takes time to be developed. If by the time I trust you, you leave the team, then it was mostly time spent instead of invested. Yes, it is amazing to get to know different people, but teams are formed to fulfill focused missions (or they should). The focus is not on team development per se. Team development is the vehicle for performance.
Diversity of ideas and several perspectives is what you can get when a whole team pitches their points of view. That is at the heart of collaboration. Collaboration is required in Agile ways of working. You don’t collaborate with whom you don’t trust. How can you do pairing with someone, let them dissect your idea, critique it, and eventually refuse it? Only when you are sure you are not being personally judged. That’s very exposing. And exposure requires trust. And trust takes time to be developed.
Stable Agile teams are a group of people who can trust each other to do their best and not be judged.
No surprises in budget allocation
Stable teams, stable cost. It’s that straightforward as an advantage.
Literally, as you keep your team together, you know how much your team costs, come rain or shine. Shorter lived projects inject people here and there and that makes for an initial budget to explode once the management team decides that they have to “push through” by the final third of the project.
In the spirit of bringing work to the people, you assign work that is aligned with the team’s abilities and desires. It literally makes budget an exercise of simple, not complex math: your team has an annual cost and that’s it.
Stable Agile teams are a fixed cost on your budget.
More work done, with better quality
People like to call this throughput. I don’t like that nomenclature so much as it implies a team delivers more stuff as in units of work. And you know better! You know that more units of work don’t necessarily mean better quality or more value delivered.
What I prefer to mention here is that stable teams tend to deliver better work with less effort overtime. Tools, process, and team dynamics having been mastered, all that is left for the team is focusing on the work to be done and improving ways of doing it.
The famous continuous improvement can only happen when there is… continuity! If the team gets disbanded, whatever they improve happens individually, for whenever they form other teams somewhere else. Projects want to end. It is their destiny. And whatever happens after is no longer a worry of the team that originally produced the goods.
It might sound uncomfortable, but the reality is that we do pay more attention, give more love and care to products and very long-lived projects because we are the ones who will have to fix the mess if months later things stop working. And because we have the time, we can incrementally improve the quality of our work. And become faster as we master our craft. It’s a virtuous circle.
Stable Agile teams can sow and reap the benefits of continuous improvement towards high performance.
Disadvantages of stable teams
If you look closer anything in life has downsides. In the case of stable Agile teams, here are some disadvantages or challenges to pay attention to.
Comfort and dysfunctions
Most short-lived teams have no time to develop interpersonal dysfunctions. While they can still deliver good quality work, they don’t have time to achieve high performance. You need time together with your team members to go on that path of performance. You need to develop a rhythm first before you can improve on it.
Now, be aware that a rhythm that once was good can become too much of a comfort zone. While it does not happen to all teams, it is possible that the team can improve up to certain levels and then settle in a groove where they don’t want to push through the next level of discomfort.
While they can lead to it, stable teams do not mean high performing teams, at least not automatically. Stable teams are a pre-condition, but not a guarantee of high performance. Work needs some doing. If no effort is made to deal with team dysfunctions and address whatever is underneath the surface, stable teams can become a hindrance. It’s a space where everybody is comfortable even with what does not work and hide and shield themselves from further development.
Slower on specialization needs
Depending on the needs of the product or project it is faster to bring a specialist in to deal with the specialized items of work. It will, however, disturb the team dynamics, so it is a trade-off on speed of certain items for an unbalance on future team development and performance. But it is done, and it can be justified.
The time for upskilling when the work is beyond team’s current abilities is longer than just getting that knowledge directly from a specialist. Not to mention that people learn at different paces and any knowledge takes time to master. So, if the market, business, or technology shifts significantly, the stable team will simply take longer to respond.
Some people like to cast experts as a permanent fixture in a team thinking of these types of issues. While the specialists remain on the team for those specialized tasks, if they have no other capabilities or interests after they perform the specialized duties, they basically remain idle, bored, or disconnected.
Stable teams are not the only way
You can google some more after reading this post. And from research to anecdotal evidence, stable teams are a better configuration for Agile teams. Or at least that’s what we know today.
But I wanted you to leave with something extra to think about. Keep in mind that bringing people to the work, aka project team, where you gather the specialists and put them together, some for just a short period of time, can still be done in Agile.
Project + Agile is not incompatible. Not having stable teams does not mean not doing Agile. Similarly, having stable teams does not mean doing Agile. Careful with the subtlety behind this logic.
While stable teams are a natural fit for high performance and continuous improvement, not having stable teams does not mean the project will not be a success and that the project team itself cannot work in the best environment and state of mind possible.
Stable Agile teams having tons to do with cross-functionality, you might want to take a look at this blog post.
What is your reality with your Agile teams? Are they stable? Stable enough? What has been possible and what has been challenging in your current team configuration?
