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…

Explaining Story Points to Management

During the February Scrum Breakfast in Zurich, the question arised, "How do I explain Story Points to Management?" A good question, and in all honesty, developers can be an even more critical audience than managers.

Traditional estimates attempt to answer the question, "how long will it take to develop X?" I could ask you a similar question, "How long does it take to get the nearest train station?

The answer, measured in time, depends on two things, the distance and the speed. Depending on whether I plan to go by car, by foot, by bicycle or (my personal favorite for short distances) trottinette, the answer can vary dramatically. So it is with software development. The productivity of a developer can vary dramatically, both as a function of innate ability and whether the task at hand plays to his strong points, so the time to produce a piece of software can vary dramatically. But the complexity of the problem doesn't depend on the person solving it, just …

Money for Nothing, Changes for Free

“Money for Nothing, Changes for Free” encourages both customers and suppliers to focus on value.

A key advantage of Scrum projects is that at least once per sprint you have something that could be shipped and no work in progress. You can change direction every sprint, and you can reevaluate whether the project is a good investment or if your money could be better spent elsewhere. Abrupt cancellation is risky for the supplier.

While the concept of an early-exit penalty is not new, Jeff Sutherland gave it a unique allure with his allusion to the Dire Straits hit.
Desired Benefit Incentivize both customers and suppliers to focus on functionality that provides genuine value.
Structure This works with Agile software projects because there is little or no work in progress. After each Sprint, functionality is either complete or not started. Work is basically on a Time and Materials basis with a cost target, often with the intention that the project should not use up the entire project budge…