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:

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.

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.

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.

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?