I had the opportunity to learn more about SAFe by attending a Leading SAFe course. To be honest, I didn’t have a positive overview of SAFe and its implementation (despite the fact that I had a blog post about it some times ago). After learning more about SAFe, my perspective has changed and I want to share with you what I have learned, what helped changed my perspective and what I think is great in SAFe.
First of all SAFe is safe. This is by design. It is a great comfort for the leaders to hear it. The first thing they are hearing is SAFe when talking about transforming the organization. Don’t underestimate that! How many times have you seen or heard stories of the leaders buying into the Agile or Lean transformation ended up being confused about what they got into? They found themselves confused about what they bought into and then finally decide to abandon the transformation ship. Change is not easy and whatever you do to make them feel safe is well received, even by just calling it SAFe.
Second, SAFe is not confusing leaders with Agile / Lean mumbo jumbo at first sight. I am very sad to say that, but it is the way interpreted by the leaders. When you are talking about Agile Manifesto, you need to connect the dots for them, you need to tell them for example why less documentation help their organization deliver better value for their customers. On the other side, SAFe is talking their language. They came up with their own principles, 9 of them. And the first one is “take an economic view“. Don’t you agree, as a leader of an organization, you would relate to “take an economic view” more than “Individuals and interactions over processes and tools”?
If you look at SAFe as a start state, in which you introduce awareness for an organization transformation, it is an awesome approach. If you look at SAFe as an end goal, it might seem too immature. This is my perception and comparison of SAFe and LeSS.
|SAFe -> Cloudy -> Sunshine|
|LeSS -> Sunshine|
What did I like about specific SAFe practices? I am glad you asked. These are some techniques that I really liked and I am going to use them in my (and other’s) daily life.
Decentralized Decision Making
ROAMing (Risk Analysis)
Weighted Shortest Job First
- User-Business Value
- Time Criticality
- Risk Reduction
- Job Size
WSJF = User-Business Value + Time Criticality + Risk Reduction / Job Size
SAFe is suggesting to have at least a 1 in each category among all of your features. I am not sure if I like that. This means that the user business value has a similar scale to a job size. I like a weighted approach to that. Something like: (You can decide the parameters based on a discussion with leaders)
WWSJF = (.40)User-Business Value + (.30)Time Criticality + (.40)Risk Reduction / Job Size
You can read more about this feature in SAFe here.
Definition of Done
SAFe explicitly defines Definition of Done on 4 levels, Team, System, Solution and Release. By doing that, you are explicitly saying that a team is not responsible for an end to end delivery of value and the whole organization is. Again, if you look at as an introduction to transformation and your goal is to move from four levels of definitions of done to one level and only at the team level, it is a very great idea. Otherwise, it is a terrible idea to have four definitions of done.
*In LeSS you have Definition of Undone. And you are trying to make it fade away and include everything in Definition of Done.
Set Based Design
|An example of Program Board|