Skip to main content

Three things to like about SAFe

I have written skeptically about SAFe and other approaches to scaling Agile. Some people have written even more skeptically (see Daniel GulloRon JeffriesDavid Anderson, Ken Schwaber and Dave Snowden for examples). Last weekend, I was able to take a closer look at SAFe through the eyes of its practitioners, and to my surprise, I found three things to like about it.

The Swiss Agile Coach Coach Camp in Kandersteg was an amazing opportunity for top practitioners to learn from each other. I asked Matthew Caine, who had been doing some SAFe implementations, if he would take half an hour or so to explain the key principles, to which he readily agreed.

I really appreciated Matthew's candor on SAFe's purpose and limitations. SAFe is not for corporate IT environments. It is for (parts of) companies that produce big software products. If your organization is already agile, it will slow you down. So if you are able to deliver functionality at least every two months, SAFe will not help you. (A coach from another company confirmed that they said no to SAFe for exactly that reason). But if your company is challenged to release once or twice a year, SAFe could be a good thing for you.

After listening to Matthew and other practitioners explain how SaFE works, both on paper and how they have actually gone about implementing it, I have found three things to like about SaFE:

  1. It has Scrum and Kanban inside. Yes, SAFe redefines both of them in ways that their respective communities are not happy about (see above links). But it legitimizes their presence, makes them part of the system, and leaves the door open to further improvements later.
  2. It defines work for all three levels of the organization: Top (Portfolio) Management, whose job it is to decide where to spend the company's money. Mid-level (Program Management), whose job it is to define the functional objectives of each quarterly release (the "release train" or "release choo-choo" as it is affectionately known), and the operational level, which creates stories, refines the backlog, and implements the functionality.
  3. SaFE can be implemented incrementally. It need not be a big bang migration. However, it is implemented in vertical slices of the company, from top to bottom, and can be applied to "thin slices" which simplifies the implementation tremendously. So you start with all levels of the organization associated with one particular product, implement SAFe in that slice, and assuming it is successful, expand to other slices of the organization incrementally. 
It was points two and three that really got my attention. 

When scaling Scrum, we often talk about feature teams (vertical slices from the front end to the back-end) vs. component teams (horizontal slices for each functional layer). Conway's law suggests that feature teams are more effective, and most coaches follow this approach. 

Scrum creates highly effective teams, but does not provide any guidance for the rest of the organization. This is both a strength, because it enables productivity without needing buy-in from the rest of the organization, but it is also a weakness. Since it doesn't need buy-in from the rest of the business, adoption is often challenged by the pre-existing organizational barriers between management and operational teams. Each agile coach has to find his formula to get buy-in from the organization.

So SAFe represents an approach to bring in Agility to the top of the organization and implement it at all levels. I have raised my likelihood to recommend score from a 4 to a 6.  I still have my reservations about it's lack of commitment to Agile values and I also have reservations about top-down change processes. But this does not prevent SAFe's practitioners from sharing the Agile values or applying good change leadership practices.

Jesper Boeg recently gave a talk "My Agile Journey: XP, Scrum, Kanban and Back Again" in which he said an agile transition was like mountain climbing. The summit is a high performance team. Scrum and Kanban represent base camps on the way. 

If we say our larger purpose is to create a high performance organization, then SAFe might represent a base camp along the way. Perhaps a better analogy would be that it represents the helicopter to get you to the base camp. So it looks like that helicopter will get you to 2000m, but not to 4000m. If you left some baggage behind, you could get higher. Does that make it a bad helicopter? 


Popular posts from this blog

Sample Definition of Done

Why does Scrum have a Definition of Done? Simple, everyone involved in the project needs to know and understand what Done means. Furthermore, Done should be really done, as in, 'there is nothing stopping us from earning value with this function, except maybe the go-ahead from the Product Owner. Consider the alternative:
Project Manager: Is this function done?
Developer: Yes
Project Manager: So we can ship it?
Developer: Well, No. It needs to be tested, and I need to write some documentation, but the code works, really. I tested it... (pause) ...on my machine. What's wrong with this exchange? To the developer and to the project manager, "done" means something rather different. To the developer in this case, done means: "I don't have to work on this piece of code any more (unless the tester tells me something is wrong)." The project leader is looking for a statement that the code is ready to ship.

At its most basic level, a definition of Done creates a sh…

Scaling Scrum: SAFe, DAD, or LeSS?

Participants in last week's Scrum MasterClass wanted to evaluate approaches to scaling Scrum and Agile for their large enterprise. So I set out to review the available frameworks. Which one is best for your situation?

Recently a number of approaches have started gaining attention, including the Scaled Agile Framework ("SAFe") by Dean Leffingwell, Disciplined Agile Development (DAD), by Scott Ambler, and Large Scale Scrum (LeSS), by Craig Larman and Bas Vodde. (Follow the links for white papers or overviews of each approach).

How to compare these approaches? My starting point is Scrum in the team. Scrum has proven very effective at helping teams perform, even though it does not directly address the issues surrounding larger organizations and teams. An approach to scaling Scrum should not be inconsistent with Scrum itself.

Scrum implements a small number of principles and constraints: Inspect and Adapt. An interdisciplinary Team solves the problem. Deliver something of va…

What is the role of a Business Analyst in Scrum?

When I teach a CSM class, my goal is that my participants go home delighted (and of course that they learn about Scrum, that they are motivated to do Scrum, and can pass the online CSM exam). So after every class, I ask for feedback, in particular what could I do to get a better score. And for the next class, I strive to implement or address two or three of the points raised by my participants.

One issue that was raised was unanswered questions. It is annoying to ask questions and not get answers! Time is limited, so it is not always possible to answer all questions, so I thought, why not answer them on my blog? So here goes, first question:
What is the role of a Business Analyst in Scrum? This question is a challenge because Scrum doesn't answer this question! Scrum is a simple, team-based framework for solving complex problems. The roles and ceremonies in Scrum are designed to ensure that inspect and adapt can occur regularly with complete and correct information. Scrum does not…