If you have no good arguments in favor of transition to SAFe – do not scale agile!
No matter what you will hear or read. transition to SAFe upgrading performance. If you decide to scale your agile processes you will increase complexity. As a result you will have to accommodate and follow more rules and policies. Introducing such a complex framework without reviewing possible pros and cons can result in chaos, lower productivity and agile trauma.
It’s not a joke, if you fail once your team will remember and following attempts will be even harder to execute.
Common myths when thinking about scaling Agile
- it will increase performance – teams will deliver more
- resources will be optimized
- introduce robust lean framework company-wise
To your surprise it’s possible to fail on all of the mentioned steps.
Introducing and then scaling Agile to gain performance is a common belief
It’s backed up with a feeling that teams acts faster, they deliver more.
In fact what you achieve is increased frequency of deliveries. You set a tighter cadence, deliver more efficiently – maybe even introduce devops culture. Your customers don’t need to wait months or years until your product will be mature enough to be released.
Your team will not start magically performing three times faster.
Optimized usage of resources
You think you will optimize your professionals workload. Consider the fact that you will need to split or double crucial resources where needed. Solve bottleneck challenges and synchronize flow efficiently.
Transition to SAFe equals adopting lean framework
Have you looked at the SAFe diagram ?
Now compare it to the waterfall V-Model
I think you will agree with me that SAFe is a beast.
Even simplified model called “Essential SAFe” will keep you busy for days spent on learning, training, coaching and implementing it. Moreover, used incorrectly it will bring you nothing else but frustration and disappointment.
And still I am a big fan of this methodology.
Decision points
In order to make a conscious choice you can try to look at the following table depicting dependency between team members and possible methodologies.
Decision point | Agile | Scaled Agile Framework (SAFe) |
Team < 10 members | Go with SCRUM / Kanaban | No place for SAFe |
Team < 30 members | Split teams to 3-4 groups and implement SCRUM / Kanban. You want to synchronize them with Scrum of Scrums or similar meetings. | You can enforce cadence and synchronization between teams by implementing Essential SAFe. |
Developing single product | Use feature team or teams with synchronization. | Essential SAFe with single Agile Release Train. |
Developing multiple products | Possibility to use components team or share load with feature teams. | Large Solution SAFe with Solution Train and multiple ARTs. |
Enterprise grade model | Clusters of Scrum Teams. | Portfolio or Full SAFe implementations. |
Implementation steps
It’s obvious it’s not a single dimension decision process. You take into account number of team members, number of developing products. How they are interconnected. What processes you could share.
I strongly recommend pilot projects where you can test potential aspects of transformation. Normally I recommend bootstrapping SCRUM in one of the teams. Aligning on the base processes and tools. Adjusting the model to specificity of your organization and business model.
In parallel you can introduce coaching session, evaluation and retrospectives. That should build up the confidence in the management and teams to move forward fully.