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?