We all agree that Agile teams should be self-organizing, right? Then prove it. Teams should choose their Agile approach!
Why do we pigeonhole teams into either Scrum or Kanban?
Instead, why don’t we TRUST the team to self-organize and come up with their own Agile approach that works for them? Instead of dictating a specific Agile method or framework for the team, we should provide a short list of high-level agility outcomes to the teams and trust them to figure out the best way to accomplish these outcomes.
Agile Team Outcomes
Let’s call this short list of team-level agility outcomes our Agile Team Outcomes (ATO). The ATO can be used to augment the Agile Manifesto and 12 Agile Principles with the added advantage of being context-specific to your organizational needs.
Each team can then use the ATO to create their own Agile approach. One team might settle on Scrum, another on Kanban. One team might use a hybrid mix like Scrumban, another a lightweight ScrumBut. Another team is XP, another a custom ecosystem of Agile practices. Another team simply uses Lean principles. When creating their own Agile approach, the team uses the ATO to ensure that their approach has a good chance of influencing towards the desired outcomes.
As teams improve over time and receive feedback from their business partners and organization leaders, they can adjust their Agile approach to accomplish more of the outcomes described in the ATO.
Example ATO
Our organization is made up of Agile teams that can accomplish the following desired outcomes:
- Direct and continuous interaction with the customer
- Ruthless prioritization of customer needs
- Continuously adjust the product based on ongoing customer feedback
- Deliver high-quality usable working solutions in short periods of time
- Accurately predict future releases
- Improve their flow of value over time
- Self-organize to address opportunities and challenges
We trust the Team to determine the best way to accomplish these outcomes!
Purpose
The purpose of the ATO is to provide guidance to the team on desired outcomes from a business and product perspective. It typically covers topics such as feedback, customer interaction, building incrementally, and how to ensure we are building the right product.
The ATO is a single artifact used by all teams in the organization. Since the ATO is outcome-oriented, it does not dictate “how” the team accomplishes the outcomes. That is left up to each team.
There is no default or fixed ATO – it is dependent on your organization. The ATO is created by organization leaders, business primes, product management, the Agile leadership team, the Lean-Agile Center of Excellence, a cohort of Lean-Agile thinkers, or any mix of these.
The ATO is intended to be a living artifact, and as such will be updated based on current learnings and business needs.
Need for Organizational Consistency
I often hear the argument, “We need organizational consistency. Therefore, all teams are now Scrum teams. That way if someone transfers into another team then there is no learning curve.” Seriously? You are going to dictate a specific Agile framework for all teams so that in the rare case when a talented highly paid professional transfers to another team he or she doesn’t have to learn a new way of working?
Doing this sacrifices self-organization and sends a mixed message to the teams: we trust you to figure out the “how” of coding and testing, but we don’t trust you to figure out the “how” of the work process.
Does any of this sound Agile to you?
Teams should choose their Agile approach. A big advantage of teams creating their own Agile approach is that learnings from each team can be shared in Communities of Practice. These learnings can spur teams to continuously experiment and improve their Agile approach.
A Personal Story
For many years I have championed the need for self-organizing teams, emphasizing that it is the “secret sauce” of agility. Then I would require the team to choose one of two options, either Scrum or Kanban. Sounds duplicitous, right? Guilty as charged. Perhaps you have done the same also…?
I once worked for an Agile transformation leader at a Fortune 500 company who stated, “All teams will use Scrum because it requires more discipline than Kanban. Once the team has proven their capability using Scrum, then and only then will we let them use Kanban.” Can you believe it? The service-oriented IT support teams working daily incoming tickets were forced to use Scrum and plan out 2-week iterations, even though it was impossible to plan their daily barrage of support tickets. They were clearly better suited for Kanban.
The Bottom Line
If you truly believe in the self-organization Agile principle, then prove it. Teams should choose their Agile approach. Let the team decide how to best address the outcome needs for business agility. An Agile Team Outcomes list can be useful in helping self-organizing Agile teams create their custom Agile approach that best fits their team while addressing the overall desired agility outcomes.
For more on Scrum, visit here. Thinking about an Agile transformation, visit here.