Has SAFe Cracked the Large Agile Adoption Nut?
The Scaled Agile Framework (SAFe), created by Dean Leffingwell, seems to be gaining momentum in our community and is touted as the equivalent of Scrum at an organizational level. It is currently supported by several vendors including Rally, Net Objectives, and Valtech. There is also a scaled agile framework academy that provides training and certification. And, finally, you and your company can become a SAFe partner. All of this, tool support, big-named vendor support, a certification program and an official standard make executives at larger organizations feel safe. These people know what they are doing and the support system is there for large scale adoption. And there is also a beautiful diagram that shows it all known as the Big Picture:
However, not all in the community think SAFe is a good idea. In fact, many have a strong negative reaction. David J. Anderson and Ken Schwaber have both gone on record against SAFe. And there was definitely a buzz at this year's agile conference against SAFe as this reporter talked to several well-known and experienced agile practitioners and consultants.
So, let's start by examining the benefits of SAFe. First of all, SAFe is very concrete. It provides specific guidance at the team, program, and portfolio level - which makes it easier to understand because those are exactly the levels we have currently in our business structure. Rob Pinna at Rally blogged in 41 Things You Need To Know About the Scaled Agile Framework in detail about what this actually means.
The Scaled Agile Framework®, or SAFe, provides a recipe for adopting Agile at enterprise scale. It is illustrated in the big picture. As Scrum is to the Agile team, SAFe is to the Agile enterprise.
And, at Davisbase, Josh Fruit tells us 5 reasons why we might want to consider safe that include:
- If you have successfully experimented with Agile at the team level and you are now interested in implementing a consistent Agile approach across one or more programs or departments.
- If you have multiple teams running their own unique implementation of Agile but you regularly experience obstacles, delays, and failures anytime the teams are dependent on one another.
- If you are eager to scale Agile across the organization but are not sure what new roles may be needed and what existing roles (ie management) need to change and how.
- If you have attempted to scale Agile across your organization but you have struggled to achieve consistent strategy across business departments and consistent alignment from the portfolio level to the program and team levels.
- If you know your organization needs to improve its product development lead times and you’ve heard about the success that companies like John Deere have experienced scaling Agile with SAFe and you want to know how they did it.
And finally, in his article Josh sites the success at John Deere using SAFe as the poster child. InfoQ spoke to Chad Holdorf about the details of that effort in March of 2012 in Your Tractor Was Built With Agile, which seems to be a very big success.
So there seem to be some very good reasons to use SAFe and if you talk to one of the SAFe partners, it seems that large scale agile adoption is a done deal. Solved. We should all do SAFe if we are in a large organization. However, what makes this interesting, is that there is a strong negative reaction in the field against SAFe from both well known community leaders and on-the-ground practitioners.
Ken Schwaber, one of the two founders of Scrum, came out against SAFe like this:
The boys from RUP (Rational Unified Process) are back. Building on the profound failure of RUP, they are now pushing the Scaled Agile Framework (e) as a simple, one-size fits all approach to the agile organization. They have made their approach even more complicated by partnering with Rally, a tools vendor. Consultants are available to customize it for you, also just like RUP.
They are touting their processes and tools this week at Agile 2013 in Nashville. They would be at the RUP conference, but there are none. They would be at a waterfall conference, but they are no longer. So they are at our conference. Strange, but they had nowhere else to go. Try to be polite.
David J. Anderson, the founder of Kanban, admits that he is not a certified SAFe practitioner. However, based on conversations he's had with SAFe practitioners and reading the publicly available documents, writes:
It is assumed that the collected set of successful practices [which comprise SAFe] will also be successful in aggregate. I would compare this assumption to individually testing the 300,000 components in a modern passenger jet aircraft and then declaring that as all the components are tested the entire plane composed of those parts is _SAFE_! The very nature of process tailoring from a framework means that every implementation may be unique and the process design is therefore untested and unproven. The new process is implemented in a single change. It isn't implemented in an evolutionary fashion that allows each incremental step to be tested for fitness and selected based on its success. The risks from this are well established historically.
These are strong sentiments from well-respected leaders in the community. However, to be fair, neither Ken or David have practiced SAFe nor have they been trained in the technique. So let's talk about people who have a little more context and, at the same time, are not certified partners. Robert Galen wrote an article after attending a user group meeting with Dean Leffingwell on SAFe.
He (Dean Leffingwell) was referencing a 10 team instance of agile. The teams worked hard and scheduled ten sprint reviews at the end of their efforts. Stakeholders and managers dutifully attend the first round of ten meetings. Then they go away.
He asked – how many of them will return for the next of sprint reviews? The implication was that they clearly couldn’t spend their valuable time iteratively reviewing all ten teams work. He implied that in the “real world” these folks simply didn’t have the time for it and it wasn’t sustainable.
Rather, the teams needed to roll up their results into a singular demonstration event much closer to or right before the release. Call it a release review. This way, the time of the stakeholders and leaders would be effectively honored. And the team would get the benefit of demonstrating more mature software and gaining broader feedback and visibility. I say phooey to this notion or mentality that the leader’s time is most valuable; that the team inherently needs to “serve” the leader. If the team is working on the highest business priority work on the planet, the premise of all agile teams, then as a leader I need to get out of my chair and go engage with the teams. I should passionately care about what they’re doing, how they’re doing it, and what it looks like.
And finally, Valerie Santillo, who is a SAFe Certified Professional Consultant (SPC) and has experienced the implementation of the Scaled Agile Framework, has a mixed opinion of SAFe. She sees value in some of the practices, and worries that the focus on people is missing:
There’s a risk of any framework not working well and it’s not the framework that makes it risky. It’s people. People make frameworks and processes work. The buying of any framework is also risky because of people salespeople. The person selling SAFe has an obligation to represent more than just the framework. SAFe is Agile at scale which means there are cultural and tactical elements. To get the results organizations want they must pay attention to and work on both.
What is obvious is that SAFe is here. It is big. And there are many proponents and detractors. What is your experience with SAFe?
Solving the wrong problem
The other aspect of SAFe I dislike—along with all other scaling frameworks—is the inherent believe that bigger is better. I'd far prefer to see an approach that was about scaling an organization down to use Agile effectively than scaling Agile up (and risk losing its essence) to support bloated organizations.
And the finally, the one thing I /really/ disliked about SAFe was the directive that all teams need to use story points to estimate and predict, and that story points should have the same meaning across all teams. This approach was shown to be flawed some ten years ago.
PS Kudos to Valerie Santillo for speaking out against her own certification. We need more people like her in the Agile world :)
Oh, dear. Another brand.
Lean and Agile are great. Kanban the brand and Scrum the brand have pushed us from collaboration into a world of brands and interests, and that hasn't served the community well. Doing a high-level kanban of epics, and some portfolio management, can be good practice, too. Branding that with a registered trademark feels like a red flag to me.
Re: Solving the wrong problem
Kudos to Valerie Santillo for speaking out against her own certification. We need more people like her in the Agile world :)
SAFe is missing something....
Starting point (it claims no more)
Any self-respecting Lean-Agile practitioner should be disciplined enough to pick smart defaults, and continously improve from there - via the actual people involved. SAFe is new, and still growing and evolving - I too hope that more humanistic elements are made more prevalent going forward. Case in point, I too have a problem with the use of story points across teams; however, SAFe does not mandate their use.
The main issue is not whether "bigger is better"; rather Lean focusses on optimizing the whole system, and avoiding local optimizations that globally de-optimize.
SAFe is currently one of the only viable / recognizable frameworks for scaling Lean-Agile. DAD is another. And those folks taking point into uncharted territory usually take the brunt of the pushback.
I agree that the branding and land-grab is fracturing the Lean-Agile community at the very moment in history when we should be synergizing and rolling out beyond software to all industry.
"Software is eating the world." -- Marc Andreessen (WSJ)
"Agile is the best-kept management secret on the planet." -- Steve Denning (Forbes)
The problem is applying it!
To give some examples: Many organization had difficulties applying RUP. They weren't able to pick those activities and documents that served their purpose, and were afraid to leave out things. That made RUP too heavy, and it was perceived as bureaucratic and overhead by developers (and they were mostly right on that).
Organizations use the CMMI to improve the way they develop software. Most pick a CMMI maturity level as a goal, and start working on all the process areas for that level. Such a change is often too big, and again CMMI programs appear bureaucratic and people resist. Very few organization know and apply the continuous CMMI representation, which supports to set specific targets to improve the capabilities that help them to reach their business goals.
Practitioners should be able to pick what is needed from a framework, and apply that in an effective way. But how many are able to do that? And how many managers understand that that would be an affective way to use a framework, and will support such an approach?
I think this is where the real problem is: Deciding what to do (and use) and what not, and applying frameworks effectively to increase the business value.
Individual and interaction always come first
I can't imagine how large scale framework works while each individual team doesn't do Scrum or whatsoever Agile framework properly. And if individual team knows pretty well how to do things in Agile way, I guess the management mindset has already been changed in a certain level, therefore no matter SAFe or DAD or any other *Scaled Agile Framework* could be a good start point of discussing how tens and hundreds of teams collaborate together.
My concern is something in the middle: if individual team is in the very beginning of adopting Agile (very immature), and in the meanwhile the company wishes all the teams adopt Agile in the same time, is it possible?
Important opinion, after taking SPC course...
1) Daniel Gullo danielgullo.tumblr.com/post/80172140950/safe-sp...
2) Lyssa Adkins www.infoq.com/articles/agile-coaches-coach-view...