This is the 17th episode of my blog series, “20 Controversial Topics of Debate in Agile”. In this blog, the topic of debate is whether Agile teams should be kept together.
One of the key aspects of Agile is a shift away from the idea of “projects” in favor of “products.” By nature, projects have a distinct beginning and end, whereas “products” are continuously developed and supported until they are no longer relevant or valuable. This requires a significant change in mindset regarding how teams are formed and whether they should stay together.
Another concept that is important when thinking about this topic is the idea of creating high-performing teams. These types of teams don’t happen accidentally – they are cultivated and developed over time. If you have ever been on a team like this, it’s magical; you never want to leave your team.
On the other hand, if you have a low-performing team that can’t get past the early stages of team formation (forming, storming, norming), then there’s no way you’ll become high-performing (performing). This blog isn’t about these low-performing teams. In situations like this, the team will naturally fall apart, and it probably makes sense to re-shuffle the deck when things aren’t working.
Instead, my focus here is whether it makes sense to split up a Scrum Team when the bulk of the work on a product is done, and less development and support is required. When this happens, people may want or need to move on to other things. But… think about this team as a Superbowl-winning football team. Why would you want to break up a team that achieved such a great accomplishment together? Does it really make sense, or should you keep a team intact when it has run its course?
Let’s debate…!
Why you should keep your Scrum Team together
Why spoil a good thing?
High-performing Agile teams are hard to come by. These teams are highly successful and operate like well-oiled machines. So why mess with a good thing? If you no longer need to grow or support your product, the whole team could go on to build the next product. In the perfect world, you would want to keep the high-performing teams together indefinitely.
It takes time to become a high-performing team
Teams don’t become high-performing without spending a lot of time working together. It takes time to establish relationships and rapport, build trust, understand each other’s strengths and weaknesses, etc.
It often takes going through some trauma or failure that forces the team to bind together to solve a problem. These experiences bring the team closer together. The only way to create high-performing teams is to keep them together.
The longer a team is together, the faster their velocity becomes
It makes sense that high-performing teams create valuable outcomes. The more a team works together, the more efficiently they will be able to deliver. Mature teams with good Agile practices will increase their velocity the longer they stay together, improving their ability to accurately forecast the amount of work they can complete within a Sprint.
Whenever team members change, team formation re-starts
If you add or remove someone from a Scrum Team, the process of storming, forming, norming, and performing starts all over again. The team will need to learn how to adapt to the new or lost person. It’s always risky when changes like this happen because it could totally change the team dynamics.
If you split a team up, productivity will decline
Any time you change the composition of a team, their productivity will decline. This is a natural consequence of having to spend the time to bring the new person up to speed or identifying the team’s new velocity when someone leaves the team.
Eventually, you can correct this productivity loss, but it will dip for a period whenever a team is changed.
Being on a high-performing team is magical
People love being on high-performing teams. It’s a fantastic feeling to enjoy your work and the people you do it with. You don’t find this every day. When you feel like a part of something, you are more likely to want to stay and drop everything to help the team succeed. It’s hard to walk away from something like this.
Why you might not want to keep your Agile team together
It’s impractical
When you have many business demands being made of your organization, it may not be practical to keep a Scrum Team together forever. As strategy changes and market opportunities arise, your company may need resources to work on other things. When this happens, the first place your leadership will look is at existing people. And successful teams usually have successful people who are likely candidates to get picked for new projects or products.
It could get boring
I don’t know about you, but I don’t particularly appreciate getting stuck working on the same thing all the time. It’s boring! That’s why I love being a consultant – it’s never boring! But, if you spend many years of your life working on one product, it could get old. And once that product reaches its own level of maturity, the work will become more rote and less exciting than when you first built it. You don’t want your best team members to get bored, or they might go somewhere else!
It’s expensive
Keeping a full Scrum Team intact is expensive. If there’s not enough work to keep the team fed with high-value items, it might not make sense to continue to spend money on resources that don’t have their plates full. And we all know that money talks.
People might want to move on to other things
Most professional people I know are on a growth path. If being a Scrum Team member is not your life’s goal but just a step stone in your career, you might spend a few years on a team and then be ready to move up the corporate ladder. In this case, you certainly don’t want to hold someone captive on a team against their will.
The product has slowed down, but still needs some support and development
Once a product reaches maturity, it won’t need as much care and feeding. It might need a minimal amount, but it certainly won’t require an entire team. At some point in every product’s life, this will happen. When it does, it might make sense to split the team up and let everyone go their separate ways.
Final Thoughts
I could go either way on this one, especially since I’m a consultant, and I don’t get to stay with a Scrum Team when I leave a client (which is sad indeed). New things excite and energize me, so I think I might grow bored after spending too much time working on one thing. But that’s just me. Now I’m dying to know what you think. Let me know below!
Next up in this blog series:
- Can you use a Sprint 0 in Agile?
- Do you need Documentation in Agile?
- Is there a “right” way to write User Stories?
- What’s the best way to write Acceptance Criteria?
- How long should your Agile sprints be?
- Should all your Agile teams be run the “same” way?
- Which “flavor” of Agile is best?
- Can Agile co-exist with Waterfall?
- Story Size – What’s an Epic, Theme, Feature…?
- Can the Scrum Master be a team member, too?
- Can distributed Agile teams work?
- How should you estimate in Scrum & Agile?
- Is it OK to add items to the current Sprint?
- How should you manage your Agile backlog?
- Can an Agile team have more than one Product?
- What is the optimal size for Agile teams?
- Should Agile teams stay together?
- How should you handle defects in Agile?
- Can a hybrid of Waterfall and Agile succeed?
- What are the official roles on an Agile Team?