27 October 2016

My Thoughts on SAFe and Leading it safely!

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

SAFe is providing you with a really nice mechanism to make decisions easy to be made. It helps you to determine which decisions to delegate and which ones to keep it at the leadership (or your own) level. You can read more about DDM here. It basically makes you think on Frequency, Urgency, and Economic at Scale. Then it will ask you to rank for each category from 0 to 2. If the sum of any decision is higher than 4, you decentralize the decision. 

Y=2, N=0

ROAMing (Risk Analysis)

At the end of Iteration Planning, Release Train Engineer (RTE) gathers all the risks defined for all the teams. He/She then ask the people in the IP to categorize it in 4 categories. It is a forum to talk about the whole program and its risk with the bigger audience. 

ROAMing

Weighted Shortest Job First

I really liked the idea have used it before in a different format. I used it as Business Value over Job Size (or estimations / story points). However, in SAFe it is suggested to use all the following category for weighing a job:
  • 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.

Value Stream

The introduction of Value Steams was a great idea. I am not sure if it was well thought of. It seemed to me as another layer, which is basically called Value Stream. It felt like more of a portfolio of portfolios to me rather than Value Streams. I am predicting that in next version of SAFe, we will see major changes in Value Stream.

Set Based Design

I looked at this as a way to have emergent architecture capability in SAFe, which I am all about. I am not sure how the implementation will go. It looked to me more of a Lean Startup approach formalized. I am not sure if that's a good idea.

Program Board

I really liked this visualization. It is basically after the PI planning session, all the features to be developed are mapped on a board. Then dependencies are mapped between then using strings. In the program time-frame, whenever there is a change, you can simply see what it is affecting, a great visual tool!

courtesy of https://mobile.twitter.com/michael_p_stump/status/721007389298663424/photo/1
An example of Program Board
Cadence has to do with predictability! I just liked this.

Thanks to Bertieg for making it happen in Canada, and kudos to Jerry Doucett for delivering content with a great attitude. You know you are challenged when your head is hurting from learning valuable materials and finally making you think in a different way. Jerry's delivery, the least it did, helped me to change my view on SAFe and scaling agile.

1 comment:

  1. Hi Shahin - Good post. Thanks for writing about your experience and learning. You've sort of untangled SAFe for me. As a communicator, a light bulb went on when you mentioned the value of the name, itself.

    What I've seen in big organizations (especially banks) is that the decision makers who claim they want to change actually have a vested interest (perhaps unconscious) in keeping things the way they are since the existing system rewards them. Branding around safety and risk reduction seeds the idea of lower threat. Then the processes and formulas add a greater illusion of control. If SAFe did nothing but give executives confidence that these new practices won't harm them, it's a good start. The art will be in helping the teams and individual contributors understand the value and rationale.

    Beyond process or forumulas, I believe something that will really help organizations change is for everyone to understand - and share the same understanding of - the organization's larger purpose and the business/financial implications of that. And, most importantly, how each of their jobs is part of that.
    Cheers - Sue

    ReplyDelete