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 Gullo, Ron Jeffries, David 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.