SAFe: Let’s Acknowledge It For What It Is… And Move On
A ton of SAFe related stuff made it across my desk this week. More than the usual amount. Some of it was positive, some of it was negative, some of it was old, and some of it was some new—but it was all asking the same fundamental questions. Has SAFe become the savior of all things software development? Is SAFe really Agile or merely the second coming of RUP? Will SAFe survive or be relegated to the ever growing list of failed approaches that have come and gone over the past 30 years.
Here is my take. It doesn’t matter.
A Brief History of Agile
Agile, as it was defined 14 years ago, is basically a lightweight framework for building software. Agile is predicated on the notion of small teams, colocation, onsite customers, lightweight documentation, and frequent opportunities for feedback. These teams need to be sufficient for solving the problem they are formed to solve. They need to have a clear backlog, and they need to be able to produce a working tested increment on some predetermined interval.
Now, if you go one level deeper, Agile teams need to work within a code base that is well architected, wrapped in tests, and safe to make changes. However, that code base needs to be supported by a team with autonomy to decide how best to solve the problems they are formed to solve. That team needs to be tightly aligned with the business objectives of the organization they are formed to support, and they must have some degree of independence from the rest of the organization.
Let me be clear. Most organizations can’t form teams like this. A lot of organizations have:
- Tightly coupled, non-autonomous teams
- Poor alignment to the business
- A lack of good tests
- Code bases that are not safe to make changes
- A matrixed staff
Shall I go on?
So, What is SAFe
Here’s the deal, you either create the conditions to do Agile well—Agile as it was defined 14 years ago—or you do something else. That something else is called SAFe.
It encapsulates a larger, more enterprise focused, value stream. A value stream that really does exist in most large organizations and can’t be ignored.
Again, I’ll say it one more time for emphasis—either you create the conditions to do Agile well, or you do something else, and SAFe is that something else.
What’s the Verdict?
We can say that SAFe is a cop out, that it isn’t really Agile, or that it’s the second coming of RUP but don’t underestimate the complexity, the risk, or the cost of totally refactoring an enterprise to be the kind of organization that can do Agile well at any kind of scale. However, some organizations simply can’t—or won’t—invest in this. At the end of the day, small batches are better than big batches. Iterative and incremental is better than Waterfall, even if it isn’t Agile.
Personally, I don’t think that SAFe is bad… or that SAFe undermines what we are trying to do with Agile in the larger scheme of things… However, I do believe that SAFe will be better for some companies, some of the time. SAFe isn’t the way that I’ve chosen to tackle the enterprise problem. I want to work with companies that do want to fundamentally decouple themselves and have a shot at doing Agile as it was originally envisioned.
But, I’m pragmatic enough to know that can be a long road.
So…where does that leave us?
Comments (23)
Steve Colasinski
Our company is in the process of trying to adopt SAFe. I was not part of that decision but was asked to come along for the ride. Surprisingly, the team is still trying to define an internal process based on SAFe with part time resources. That effort is going very slow. Outcome at this time is unpredictable. It appears that the company was looking for an in depth structure to follow.
Declan Whelan
Great post Mike. I think your pragmatism is right on the mark. I see SAFe as helping many organizations although I would not choose it for my own :).
Paul Boos
Great post, I’d add that few people seem to explore the issues and even more importantly the assumptions frameworks like SAFe are based on…
At the last ACCUS I facilitated a session on this topic with interesting results. We didn’t try to bash SAFe, but rather understand more of the underpinnings it rests on in order to determine if it applies. You can see the results here: session here: http://paulmboos.com/2014/10/05/acc-us-session-how-to-practice-agile-scaling-wo-a-condom-un-safe-agility/
Cherie
Your post makes me proud. Lets just do the right thing for who we are and where we are right now and keep our eyes on continuous improvement.
Derek Neighbors
SAFe is a path to mediocrity. Most large organizations are okay with mediocrity because they have enough cash to think it doesn’t matter. Until it does. The best reasons are the worst excuses.
If you are involved with an organization that wants to implement SAFe and you want to be anything more than mediocre run like hell.
Hey Derek, thanks for the comment. What do you do if a company is willing to make the changes required to do agile well, but is in a large complex systems architecture, doesn’t have the right alignment, doesn’t have good tests, etc.? Could SAFe be a viable intermediate state while they get their problems worked out? I’m not a SAFe apologist, and like I said, it’s not my desired end state and inclined to agree with your comment…. That said, can SAFe have any place at all in a transitioning organization?
Viktor Grgic
Hi Mike, There are much better “intermediate states”. I like your article very much, except that conclusion is a false dichotomy. There are many examples of traditional companies gradually becoming truly Agile with only Scrum. E.g. Large Scale Scrum (LeSS – http://less.works) helps further with many typical issues in such endeavour. So, there a better ways to deal with complex and large enterprises, although none of them promises a fast solution, since there isn’t one.
The only thing I would change in the blog post Viktor is where I said “SAFe is that intermediate state”. I wish I would have said “an” intermediate state or something like that. I still think the point of the post is valid. If you are using Scrum only, then the conditions to do agile well existed. Same goes for LeSS. If you are in transition and shooting toward those end states, then you have an organization that is creating the conditions for success, they are willing the make the investment. If you get stuck on SAFe as the intermediate state, by definition you are in a company that does not have the right conditions and isn’t willing to invest to create them.
Viktor Grgic
Agree.
Derek Neighbors
I think SAFe could potentially be an transition step. However, I have yet to meet an organization that has successfully used it as that. Most of them see it as a destination not a journey.
Kurt Jaeger
I am happy with that post, because it build pragmatic bridges. SAFe fits good for customers we talk with, like Deutsche Bahn, compuGroup Medical , aMADEUS, So even big enterprises are able to make wins out of agile and lean as John P. Kotter predict in his book and video XLR8 see also https://www.youtube.com/watch?v=Pc7EVXnF2aI
Martin van Langen
Well written. I experienced this also in my last two assignments. They feel it’s a shortcut to agility without taking the pain.
James
I think SAFe points to an important topic that was understated in agile: requirements engineering.
Extreme programming drove our attention towards quality practices such as test-driven-development, continuous integration, pair programming, etc.
Scrum placed the emphasis on project management with practices such as intensive planning meetings, regular review cycles, reporting with burn-down charts, etc.
What about user needs and requirements management? Will SAFe teach us the value of well analyzed and defined requirements? How will it integrate with other requirements engineering practices such as behavior-driven-development or specification-by-example?
How will tools such as FitNesse (http://fitnesse.org) and Concordion (http://concordion.org) support agile teams to specify collaboratively?
Rick Vance
I like this post. Very pragmatic in the challenges around SAFe. I believe that if we had agile teams, (co-located, autonomous teams who are using good technical practices) then we probably wouldn’t need SAFe. Good program management would probably suffice. Trying to implement the framework without agile teams will probably have little benefit. SAFe makes the assumption that we have agile teams… it’s the foundation that the whole framework is built on….. or just maybe, we can use the framework to sell the need for creating agile teams :-)
Luke Majewski
Although I agree with the premise that SAFe does not provide a magic bullet, I find it amusing when people talk about doing “agile really well and focusing on co-located, autonomous teams exercising good engineering practices”. If that worldview gives you coordination across 40 teams on the same value stream then that’s great. Agile is not a set of methodologies – it’s a set of principles. In my experience many principles begin to break down at scale. Whether it is SAFe or something else, it it too head in the clouds to just say otherwise. Every scaling effort requires additional coordination – SAFe is just one implementation. When Ken destroyed SAFe in his blog I noticed it wasn’t long after that he came up with his own scaling paradigm. I’m sure it sticks 100% to all elements of the manifesto.
Dennis Elenburg
I’m a newly certified SA, so maybe I need more experience so see SAFe through a non-agile lens, but I view SAFe as being highly dependent on good agile practice, Scrum in particular, at the team level. I work with large banking and telecom customers who span the spectrum from traditional waterfall to thinking they are agile (and not) to being highly sophisticated in their agile practices. The organizations that cannot do agile well at the team level struggle mightily in trying to use SAFe. The teams that are disciplined in team level agile, tend to excel with SAFe. That’s been my experience.
michael durrant
Testing in the next sprint for delayed feedback feels unagile to me
Pankaj C Pandit
Absolutely….
Martin Burns
Mike, this is a very worthwhile attempt to see the world from a different perspective, and to understand how the world works when you are at a very different starting point.
You’re right: SAFe is most effective where the Entire Product Organisation cannot simply be <10 people in a single room who can define all practises in a greenfield. And that's reality for many, many software-intensive products.
But I think there's a whole range of organisations where your criteria may be possible, but not today. The starting point is elsewhere, but with work, perhaps they can get there. Or at least: a hell of a lot closer than they are today.
Is SAFe used as a destination? Yes, in some organisations. If they have half-way effective coaches, by the time they arrive there, they will see that as no more than a staging post, even if it's taken 5 years to get there.
SAFe is highly effective (for example) at turning highly coupled delivery systems with little business alignment into strongly business aligned, loosely coupled "team of teams" systems. At teaching managers and executives to let go of control. At preaching engineering excellence practises to stakeholders who would have dismissed them previously.
You perfectly have the right to define that as 'Not Agile' however, I don't agree. I very much prefer Dan North's idea of Agility as a Centred Community, not a Bounded one. One where you are constantly 'heading towards'. To my thinking, the most important words in the Manifesto are about "uncovering better ways by doing and helping others" – which has to be a contextual question.
So is SAFe Agile, or Something Else? Well, it depends on where you start. Just like the Couch to 5k programme: is that endurance training? For a fatty like me, yes. To an existing marathon runner, not really.
So the question is: given the constraints you very effectively identified as starting conditions, what would you do first to reduce them and progress towards the ideal?
Sven Thiergen
Just had my first look at SAFe and now it’s 2017. This article was written in 2105 and SAFe may have been (a bit) different then so apologies if I miss on some points …
I think the article is right about that lot of companies can’t change enough to allow true agility. Which is why agile teams disfunction to some smaller or larger degree and you come to the point asking yourself “does it really make sense to do agile here or should we look for something else”?
“Something else” with less potential than Agile but fitting better thus getting better results in the end.
So far so good, but SAFe really isn’t just another “something else”. Definitely not defending SAFe here, but pointing out an important difference … SAFe is based upon true agility!
In SAFe there is everything you know from traditional Agile: Scrum Masters, Product Owners, Scrum Teams, even Scrum itself (or Kanban). Plannings, Demos, Retros etc.
SAFe in fact adds (at least) one additional organizational layer by introducing the team-of-team idea. Put simply, a bunch of scrum teams with 50-125 developers working on the same product with a common product backlog.
With additional roles that operate on the multiple team level like UX designers, architects or a Scrum master who acts as the “chief scrum master” for the team scrum masters.
Whether SAFe is good or bad in that is another discussion. I think most of their ideas are reasonable; I used to work for a company with this exact scenario and we applied many SAFe ideas just without calling it like this.
So that’s why I disagree with the statement “if you cannot do real Agile you need to do something else; SAFe just is another of this something else”.
SAFe e.g. does not seem to make any sense at all if you don’t have at least 20-30 people working on the same product. And this is the case for a lot of companies which struggle with Agile nonetheless and need “something else”.
Steve VanArsdale
Thanks, again, Mike. After two years, in 2017, this is still a relevant and articulate opinion on SAFe and all other approaches for Agile on a large scale. Growing agile practices to the size of the organization is an effort worthy of a defined process. The quote from Ron Jefferies is a focal point.
IMO: This is a scaffolding for the art of Agile, a three-dimensional framework, that allows / preserves / makes safe “bubbles” of agility in organizations that are dedicated to the systematic, predictable, and reliable supplying of people, materials, and capital to we enthusiasts… safely ensconced in our bubbles of agile development. For my money and career, a scaled agile framework is more than acceptable to Make Good, as fast as I can get there.
Eugene
IF SAFe is not Agile, it should not be marketed as Agile. SAFe, like RUP, should be called an Iterative Methodology. If it is marketed as that, then I have no problem with it. Mike, I don’t know if you have worked in an environment where SAFe was utilized, but if you haven’t I suggest you try. When I first learned Agile, while I liked it from the onset, I was turned off by how the instructor at the time, took down other methodologies. That was until I encountered SAFe for the first time. I have worked at 3 organization who implement SAFe, and I can promise you that people in all 3 organizations HATE Agile now – because of SAFe. I get why SAFe came about, but if you are going to be Agile, then be Agile. Do not violate all the principles, and think that is okay. SAFe is liked by management, but they are not the one doing the work, so by the time they realize the problem, the issues in their organizations have cascaded. SAFe should be marketed as another iterative methodology. It doesn’t have to be “Agile”. And sure, maybe it will work in some organizations. I haven’t seen it yet. 2 of those organizations decided to never do Agile again. The other one, as I have learned, is very close to doing the same. SAFe may be good for marketing, and some Agile folks may think that it helps Agile get visibility. I think in the long run, it will harm Agile. Agile, when practiced right, makes everyone love their work. Remember the teaching principal called, Shuhari. You must first “Protect” the basics, then you can “Detract”, and then “Transcend”. SAFe does not protect the principles and values of Agile, so you can never move to “Detract” and “Transcend” as an Agile Master.
S. L.
Eugene,
Like your comment. Which Agile values and principles did you find were not protected using SAFe?