“For Organizations to succeed today:
Only Agile product delivery isn’t enough. You need to be agile in terms of Business.”
Makes sense right?
Here’s the catch, making the teams agile requires flexibility in planning, customer centricity, and a continuous discovery process.
While Predictability is critical for Large System Development, teams need to be empiric as well.
Read on to know why SAFe is Not Agile, and how SAFe drives predictability while allowing teams to be empirical.
Does SAFe focus on Predictability over Empiricism? If so, how is it “Agile”?
Let’s take this into two parts
- Is SAFe Agile? Does SAFe follow agile Values & Principles?
- Does it focus on Predictability more than empiricism?
Is SAFe Agile?
No, and for a valid reason. Many of us still live only in the Agile world and consider that SAFe doesn’t work, because it’s not Agile. SAFe is NOT Agile, but a “Lean-Agile” framework. In specific contexts, Lean and Agile marry each other. Giving a solid power to product development.
This leads us to the next question.
Why should the SAFe program be Lean-Agile and NOT Agile?
Agile brings empiricism through values and principles. Is it required? Of course, Yes, it is. Empiricism is very powerful, and it keeps us dynamic—no doubt about it.
But is it enough?
Probably not, especially for complex systems development. Here’s why, the truth is that for complex systems development, Agile is required, but not enough. We also need Lean thinking.
Lean brings enough strength to the teams and leaders through a few principles like Eliminating waste, Systems thinking, Long-term visioning / Roadmapping, Value stream thinking, Organizing teams around value delivery, Limiting WIP to bring focus and deliver value faster.
It aligns multiple teams to a Common Vision, Roadmap, Cadence, Synchronization, Quality Alignment, Transparency across teams, etc. Hence, the answer to the first question is – SAFe is not only Agile but Lean-Agile.
Now, let’s look at the “Predictability” part of the question.
Does SAFe focus more on Predictability over empiricism?
SAFe focuses on “Predictability” for sure. For example: PI Planning, Confidence Vote, Committed PI Objectives, Roadmap, etc. Readiness focus during IP iteration for the next PI Planning is another example of “Predictability.”
Is it wrong to predict a longer-term, say a quarter?
It’s not when the context is about large system development. While building a larger system, we should have long-term thinking, just being “empiric” won’t help.
While an individual Scrum team forecasts an iteration, which is good enough, a large system development team cannot be unpredictable by focusing on a single iteration. It is critical that the entire program be more predictable for a slightly longer term, and we call it a “Program Increment.”
What is the definition of Predictability?
Let’s look at different perspectives of “Predictability.”
- Is Predictability an “ABSOLUTE” measure?
If you look at “PI Predictability Measure”, SAFe recommends having 80-100% predictability of the “Committed PI Objectives.” which shows that Predictability is not an “ABSOLUTE” measure.
- Is Predictability completing all the stories planned?
SAFe drives “Business Agility”, Hence, Predictability should also be aligned with “Business”, not just internal measure. Predictability is measured based on the “Business Value” delivered, not based on “Story Points” achieved.
With the above definition of “Predictability”, it’s good to be predictable.
Are we entirely away from being “Empiric” by being predictable?
No, SAFe doesn’t steer away from empiricism. Here are a few examples out of many that I can quote.
- Defining “80-100% predictable” of PI Objectives itself shows that there is empiricism. There is a space for us to be accommodative when business needs.
- Teams being Scrum Teams allows them to be empiric, where required. It allows teams to inspect and adapt as they move ahead.
- SAFe events like “System Demo” allow businesses to review the product and incrementally provide inputs for future changes. This brings in empiricism.
- SAFe drives “Continuous Delivery” thinking. This also means – when CI / CD practices bring issues on the product developed, it allows teams/leaders to step back, take the right decision in the middle of PI and adjust as required. This is another example of empiricism.
Now we know SAFe is not Agile, but a “Lean-Agile” framework. It drives predictability, which is critical for large system development, while it allows teams to be empiric as required for business.
Did you implement SAFe at work? Did you face a challenge? Leave a comment below…