Simple Agile scaling – is it an impossible dream? As humans, we have a natural propensity to over-complicate things.
Growing up, I always enjoyed looking closely at Rube Goldberg cartoons to see the incredible convoluted solutions he would come up with to do the simplest of tasks. For example, this Goldberg invention for squeezing toothpaste onto a toothbrush requiring 16 convoluted steps from A to P:
SAFe can feel overly complex. Case in point – SAFe 5.1 currently has:
- 31 artifacts
- 17 events (meetings y’all)
- 16 roles
- 10 principles
- 7 competencies
- 4 configurations
- 3 levels
- 1000’s of pages of documentation
Brace for impact! SAFe 6.0 is coming out soon and will likely increase these numbers.
A Simpler Alternative
If you need to scale Agile from the Team level to a “team of teams”, here is a more pragmatic alternative developed across many years of leading scaled agile transformations (SAFe and home-grown).
Simple Scaling Approach:
- Form cross-functional Teams
- Determine which Teams need to work together
- Let the Teams decide how best to collaborate with the other Teams
- Establish system flow
It’s really that simple. Let’s explore each a bit more.
1. Form Cross-Functional Teams
Cross-functional means that we have every skill needed within the Team to create a small product increment within a short period of time (e.g., every 2 weeks). Cross-functionality is an absolute prerequisite for Agile teams. This means you may have to reorganize your current teams to achieve the right skill mix.
This is the crucial first step in scaling Agile. Don’t skip it. You’ll want to get Agile going well at the Team level first and then (and only then) scale it. We’ve all heard the mantra “Don’t scale crap”, and it’s true. If your teams are struggling with Agile, then scaling Agile will exacerbate their issues. Don’t inflict that kind of pain on your teams.
Skip this step at your own peril!
2. Determine Which Teams Need to Work Together
Step 2 is all about determining which teams make sense to work together. If you have multiple teams working on the same product, that’s a good starting point. You may also have teams that work on several products/services across a development value stream. More on development value streams here.
In either case, ask them to form a “team of teams” construct to focus on the flow of value to the customer. But then how do these teams collaborate effectively?
3. Let the Teams Decide How Best to Collaborate
To focus on flow of value to the customer, Teams on the “team of teams” plan, build, integrate, demo, and deploy solutions together. “Together” is the key! We want these teams to operate as a tight-knit “team of teams” with a common set of goals across all teams.
The teams operating in this “team of teams” construct are entirely capable of figuring out how best to do this. Some approaches they might consider are:
- Multi-team synchronization
- Dependency removal/coordination
- “Team of teams” optimization discussion
- Integration environment setup/coordination
- “Team of teams” feature planning
- Etc.
The idea is for the “team of teams” to come up with the minimum amount of overhead necessary for cohesive alignment. Instead of dictating this, trust the teams to figure it out! As leaders, we can (and should) give overall guidance on expected outcomes such as alignment, dependency reduction, and continuous flow – then trust the teams to figure out how without being prescriptive.
4. Establish System Flow
Because multiple teams are involved, we need to apply some systems thinking. We want the outcome of our teams working together to be a consistent flow of value to the end users.
To facilitate flow, it is a good idea to have a single prioritized backlog of Features/Capabilities across all teams operating in the “team of teams” construct. This helps to sequence the Features.
Additionally, a Program Kanban can provide transparency to the current state of all Features/Capabilities across the “team of teams” construct.
Wrap – Simple Agile Scaling
Start simple. Don’t install a Rube Goldberg 16-step framework for delivering toothpaste on your toothbrush. All you need is a simple place to start, so try these 4 steps. Then, grow it from there if needed.
Don’t install SAFe “as is”. That’s a common mistake many companies and organizations have made and regretted doing so. Read more about it here. Many parts of SAFe will not be needed initially, so look to SAFe (and other scaling frameworks) as reference material and general guidance.
Instead, start with these 4 steps. It’s really that simple.