The sixth installment of my blog series on “20 Controversial Topics of Debate in Agile” is for organizations that have multiple Scrum or Agile teams. In this blog, I tackle the question of whether all your Agile teams should be run in the “same” way?
I can see this debate from both sides, but I have a strong opinion on this one. That said, here are some arguments for and against requiring your Agile teams to do things in the same way:
Yay
- Organizations like consistency
- Enables teams with cross-functional members to move in/out of teams more easily
- Business partners know what to expect
- Terminology is the same
Nay
- This kind of goes against Agile principles
- The team should be able to inspect and adapt, which means changing and evolving to improve performance
- People with different experiences are going to do things differently
- Trying to fit Agile teams into cookie-cutter molds won’t be well-received
My Opinion
It’s impossible
In my opinion, trying to get multiple Agile teams to run “exactly the same” is simply not possible. Every team is unique. No two teams will have the same people with the same experience or knowledge.
Empiricism and Improvement
The power of empiricism in an Agile framework (inspection, adaptation, and transparency) is what enables teams to inspect and adapt on a regular basis. Through this process, it’s inevitable that every team will have some differences. Each team will discover better ways of doing things over time.
What works for one team may not work for another
Each team will come up with a unique way of working together on an Agile team. As they learn and grow, they will adopt practices that work best for them. But just because one team figures out something that works for them, it doesn’t mean you can just apply the same thing to other Agile teams and expect it to have the same effect.
The self-managed team
The Scrum Guide states that the Scrum Team should be “self-managed” (previously self-organized). This statement implies that no one should be telling the team what to do, or how to do it. Therefore, an organization should not attempt to impose some sort of prescribed format for how the team operates.
All elements of the framework should be used
Although individual teams will run things differently, that doesn’t mean the Agile framework is abandoned in the process. All the events, accountabilities, and artifacts are still required. It’s just that there is flexibility in how they are used.
It’s anti-Agile
Personally, I think that the idea of trying to create cookie-cutter Agile Scrum Teams is totally against the principles and values of Agile and Scrum. If you try to force teams to operate in the same way, how it is any different from other rigid methodologies out there?
What’s your opinion?
So, there you have it. I’m clearly not a fan of trying to rubber-stamp Scrum Teams. But if you disagree, let me know in the comments! I would love to hear your opinion.
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?