The Scaled Agile Framework (SAFe) – A Review

safe-scaled-agile-framework-review

A SAFe Class Review for Agilists / Consultants

“When you become all things to everyone, you satisfy none.” – But maybe you’ll become a consultant.

“You strive to never compromise on your values or principles, when you do, you become nothing.” – But if you do, maybe you become a consultant.

“The difference between a methodologist and a terrorist is that you can negotiate with a terrorist.” – But methodologists can become rich consultants.

Preface

Like any method or framework one needs to be highly-contextual as to how facets of that method will work within your organization. Meaning, you have to pick and choose what works.

Being educated in a “new” idea of sorts is really (at least to me), and exercise in reflection, introspection, and self-awareness. I was, of sorts, doing reconnaissance. I was also looking for things I might be able to pull from the SAFe framework for my client and coaching work. In some deeper ways, I was looking to see whether my heart was ready for a codified framework on something I’ve been attempting to do for several years. This is an ego issue (hell, I’ve even published a book on Agile).

program-consultant

SAFe SPC Training

The first time I touched SAFe was a 2 day course held at my client 5-6 months ago (I got to participate for free because I was, after all, a coach on-site). I was aloof, un-attentive, and didn’t take it very seriously as I was also juggling other consulting duties (e.g. being pulled out of class). Now, after paying $3000+ out of my own pocket, I dug in. I got serious about learning this.

My company has rolled out Agile at scale at several places, and one of my favorite and most successful (probably why it’s my favorite) was a $22.7M program that I was the Agile Architect for, and presented a part of our results at Agile2012 in an IEEE paper. Our company has it’s own home-brewed version of scaling Agile, and we’ve been pretty successful in multiple places. We’ve also had our failures.

That being said, taking this class on the Scaled Agile Framework has allowed me to see many things. A couple here:

  1. What SAFe espouses is pretty in-line with what we’ve done, on many levels.
  2. What SAFe prescribes is thoughtful and well-intentioned. It just takes it a bit too far and defines everything… almost too much… but I can see why this is a great selling idea.

What SAFe is Far Better At Than Most

  • Marketing

“You have to get management on board with SAFe… You have to train everybody… You must get them on the Agile Release Train, they must get this.”

  • Did I say marketing? – I found several participants in my class ask me whether they had paid for a 4-day course to be marketed to. I didn’t feel like I was being fed cool-aid, but certainly, the trainers were passionate about their product. You really can’t down-vote that. There was 1 or 2 moments when I felt like the propaganda machine was in full effect though…  Many questions from the audience were answered the exact same way. For example: “How does SAFe handle change management?”

“Train everyone (in SAFe). Launch trains (Agile Release Trains).”

Slide on training us how to sell SAFe

Slide on training us how to sell SAFe

  • SAFe is Easier to Sell – Giving purchase-power leaders within companies a cheaper alternative solution to their scaling issues – Much easier to sell a cereal box of Wheaties than hire a nutritionist consultant to tell how you to eat healthy breakfast food.
  • Start Where Proof of Concept/Value Can Been Seen Easiest – SAFe suggests beginning at the Program Level (as opposed to starting at the Team Level or Portfolio Level). While it is far more easier to start anything at a team (local) level, the impact of change management is far greater at a Program Level. Obviously, we want to start at the Portfolio level… but this requires Lean-Thinking Leaders and large cultural understanding for full enterprise transformation efforts.
  • Focuses on Lean Thinking – Understanding flow of work/value. I’m a huge fan of Value Stream Mapping, so I readily embraced SAFe’s requirement to utilize mapping to understand the individuals work touches.
  • Cost of Delay – A heavy use of Don Reinertsen’s work – I’ve been a huge fan of Don’s writing and work. I use his stuff all the time. I especially like SAFe’s prescription to use the Cost of Delay as a metric… very powerful.
  • First to Market – Yes. They did it first. Congratulations! The clock is ticking now for all y’all. Where do you want to be on Geoffrey Moore’s Crossing the Chasm?

The Risks of SAFe

  • Scale – The primary risk of utilizing SAFe is the same issues we all have: When trying to do anything at scale, it is ridiculously hard. Whether you buy an “off-the-shelf” solution like SAFe or hire a fleet of consultants. Anything at scale is freaking hard.
  • All Hands Meetings – SAFe is a huge proponent of having all hands on deck for all program/portfolio discussions. While I agree with this, pragmatically this is highly unlikely to happen (we’re talking about 100-200+ people in a giant room). Organizational alignment and “being on-board” with such large-scale initiatives are… well… very difficult. A common quote from our trainer was: “Everybody must be there and nobody can leave.” – Hmmm…
  • Train Everybody – Training on anything complex and highly involved is near-impossible to do well. It’s time-tested. Doing anything well takes time, experience, and maybe a bit of insanity to keep doing it. Training alone is never enough. If you want to roll out anything at scale, you’ll need more than training.
  • 1 (one) Week Rollout of SAFe at Scale - This boggled my mind. The desired process to roll out SAFe is: Train everybody (100+ people). Then Release Plan (for a highly complex program). Then Go… I find this to assume a crap-ton of stuff within an organization… as well as assume that, well… the organization is smellin’ what your sellin’. While I understand this is the ideal, it will require a very bought-in management and the ability to shell out some $ to make it happen.
Train (everyone). Plan (everything). Go. - Do it in 1 week. Possible?

***THE IDEAL SALE*** – Train (everyone). Plan (everything). Go. – Do it in 1 week. Possible?

  • The SAFe Prescription – While the intention of SAFe may not be to “be prescriptive,” we have to understand the realities of management purchase-decision-making: They have little time, budget constraints, and need help yesterday. It’s far easier to buy a solution than have it hand-made. So, what will many do? They’ll buy it, not fully understanding how to implement it effectively. But wait… management does this all the time already… Therefore, SAFe also runs the risk of being blamed for poor program and portfolio execution (smell of agile-blaming anyone)?
  • Self-Organization vs. Command and Control – SAFe purports that self-organization is a huge part of it’s values, but the praxis of this beyond the team level is (as I went through this class) seems (or at least communicated to us) impossible. At scale, we must assent to the fact that program management does have a role, and often that will be “telling” people where they need to be in the Agile Release Train (ART). Therefore, self-organization at the program level… seems untenable and unfeasible. Now, (if) ALL of management is on-board with changing entire hierarchical structures and loss of team members from manager’s purview… then this would be possible. During our simulation, it played out perfectly… We HAD to move people to different teams. They were, of course, open to that, but in reality, I don’t see this playing out so well… At one point, our trainer told us that calls will have to be made on positions and roles, and per her example, those calls might come after work hours in the night (or at least in her example)! “Yes, George, it’s 10:40PM and we wanted to let you know that your role has been changed, and you’ll now be working on this team tomorrow morning…” – Ouch.
  • Re-Education/New Interpretation of Ideas – To the uninitiated, SAFe can be a breath of fresh air. For the experienced agilist or Scrum coach, SAFe takes words borrowed from Agile, Lean, and Scrum and redefines them (sort of). For many, I can see this being a barrier to entry… from an educational standpoint. Or give people heartburn as they truly might have “heart issues” (see last section at end).
  • SAFe is a New Codified Approach – It’s still within it’s infancy of sorts as an established framework. Therefore, there will be continual iterations as it changes. I saw many inconsistencies within the training itself… but was ‘ok’ with the fact that I paid to be part of a guinea pig group of people. The trainers were very open to ‘refactoring’ their slides and content and took advice/comments from the group as to how to improve their definitions/descriptions very well. I found this element refreshing as it showed humility of the trainers that, well, we’re still learning and uncovering better ways of scaling Agile!
A Team Exercise in SAFe Training

A Team Exercise in SAFe Training

A Review on the Class

  • Death-by-Powerpoint – Make no mistake. You will be inundated by content. Every slide is chock-full of text. And, you gotta get through. It. All.
  • Lacks Engagement – A “great” training experience is full of simulations, exercises, and full engagement activities. Not here. I remembered my PMP-prep training class back in 2004. I shudder. – Now. Introspection time. Can I blame them? I’m not so sure. How the heck do you create simulations of complex system development across multiple teams at scale? I will say this: They tried.
  • Reading from Slides – I can’t do it man. Slides, in my honest opinion, are for review later to inform your thinking about what you’ve covered. If you read from them, line by line, you’ll be giving me a slow death all the way.
  • Context Please – A clear lack of section topics going to be covered would have helped. A type of “this is where we’re heading in this section” was absent.
  • Review Please – After each section, we didn’t really have time to review what we covered to ensure understanding. This could be much improved (see next bullet point).
  • Class Time-Management – Not good – Not being able to cover the material intended for the day… Coupled with the fact that each section was content-rich-in-yo-face… many slides were blown through with very little discussion or color commentary. For me, I cannot learn this way. Many important areas were, in my opinion, glazed over… and I wondered if anyone else felt “cheated” of a potential great conversation that could have happened. Also, some pretty tough questions were just waved at or given trite responses to, nobody really liked that.
  • Showing Us How to Train SAFe / Roll it Out – For a SAFe Program Consultant training class, I would expect (as from a ScrumMaster class), that the trainer would “model” and “train” you on how to “train the material” more. There was more information/knowledge transfer than modeling. I guess the same could be said for many certification classes, but follow my point: We’re here to learn how to teach the material well. Right? If we don’t have enough time, or enough discussion on WHAT the material is, how the heck are we going to be able to teach it? – I guess this is why the course requires several years doing Agile… … but then again, that makes the whole thing even more complex.
  • A 90 minute Proctored Exam with Public Shame – Cover tons of material in 3 days and then take an exam on it?… … well, cramming material in college worked for me so… … and yes. I passed. What was really interesting is the grade for the course is “on a curve” or so said our trainer. After everyone was finished,  she passed out little sheets of paper to each participant telling us whether we had passed or not… Man. Wanna talk about awkward? You knew exactly who had failed from some obvious non-verbal body language… I didn’t think this was a great method. At all.
  • No Hate Here for the Trainers – I do NOT envy our trainers. You have a room of over 20 educated agile professionals your trying to “train” (think facilitating a meeting of facilitators). Gawd. Need I explain how frustrating THAT could be? – I kept my mouth shut relatively consistently, but a few times I asked questions. I was here to learn. I had to, myself, remember the Art of Possibility and open my heart up to new learning.
  • Unique Experience (For Me) – I also had the pleasure of training with Ron Jeffries and Chet Hendrickson, Certified Scrum Trainer peers of mine and the inventors of Extreme Programming. A couple of dudes who are seasoned veterans in Agile and a hoot to be around. Can you imagine the color commentary in our class? Oh yes…

*Interlude – Helpful Links on Workshops and Training:

Look at this material. Bam. In yo face content slammin

Look at this material. Bam. In yo face content slammin. With section tabs too so you don’t get lost!

Summary:

  • I can give the trainers credit on all fronts…. and some grace too. Remember, this is new. The class is new. The content is new. The training system is new. It’s all new. I’m sure it’ll get better in the future (hope?).
  • This is complex stuff we’re talking about. 4-days? Try 6 months. Lean Management Leaders in Japan take 6 months as an apprentice to learn their craft. We got 4 stinkin’ days. Yeh. You try jamming it all in.
  • I LIKED THE COURSE – What?! With all the seemingly negative ideas previously? Yes, and yes. The reason I really liked the course is really one particular idea: The course validated what we have been trying to do for years, in a more codified way. It feels good to be validated at some point. I also really liked the fact that they incorporated many XP ideas (something that Scrum doesn’t touch) as well as a deeper dive into architectural considerations. Coming from a heavy development background, I greatly appreciated this as it has always been something that we’ve had to go heavy into with our clients. I also very much enjoyed the section on Lean Leadership. You can never hear this enough.
  • Now, did I enjoy content-heavy-death-by-powerpoint training? Absolutely not. But, I now have the content, which I can leverage and use, and with my own notes of comments/ideas from our trainers on how they’ve applied SAFe. The content itself was immensely helpful in sum total.
  • What SAFe does is walk a very fine line between practical application of agile at scale and “agile principles.” One of the tag lines continually marketed to us was: “Central control of strategy; decentralized control of execution.” – I get this. It makes sense. The issue is where these responsibilities bleed into each other. The context of the current system (company’s culture) plays a huge part in how this will be done (if it can be done at all), and I’m not sure trying to follow SAFe’s methodology is very feasible. We still have to use our brains (i.e. THINK) about how to solve problems at scale.

Looking Out To the Future of SAFe

I have no crystal ball. I can’t tell the future. One thing I can see happening is this: The SAFe model is the lowest barrier to entry for scaled agile work at the current moment. 

The struggle that SAFe will have will be the same struggle that Agile has had (and still dealing with)! – Poor understanding, insufficient education, and poor execution using SAFe (or Agile/Scrum) will happen. SAFe, just like Agile proponents do now, will have to defend their validity and viability as time goes on. This is an eternal struggle for any growing framework, philosophy, or idea. Many will rise, many will die out, some ideas will struggle and persevere. It will be interesting to see how SAFe survives the winter. It’s harvest time now, and pickings are good. The famine will come.

My Heart

Now, let’s get back to what I wrote at the very beginning: What I believe. My principles, my values, and how I apply them with our clients. No one wants to become a staunch methodologist, purist, or even dogmatic… but the risk to become one is there (over time). I’m sure you can agree with me here, that you have met many “experts” who have really shitty attitudes about things. They know it all, don’t they? Their way is far superior to yours because they’ve done it for more years than you’ve been alive. This is where the line between value creation and being ineffective come in to play.

I must, we must, continue to learn. I found myself trying to be as open to this new interpretation of Scrum, Agile, Scaling Agile, etc and the principles and values I have for so long embraced.

This. Is. OK. 

It is OK to be open to new ideas… even… change *gasp*! Isn’t that what the empirical process and the scientific method are all about? Being open to change based on new learning? What I enjoyed about our trainers is their humility about being in front of many other experienced agilists. They were open to comments, open to confrontation even. They were ready for conflict (if necessary). I learned a lot. I’ll be taking the booklet and sourcing it a lot I believe. I’ll contextualize a lot of it for my clients. I’ll even maybe change some things. I won’t use some things, and some things I just won’t (at this moment) use because I either disagree with it based on my personal philosophically/principle… or I’m just not mature enough to fully understand it yet. Regardless, I’m open to SAFe as a framework to help clients fulfill their needs at scale, and I’m excited to leverage facets of SAFe for our training and consulting. In that sense, thanks a bunch Dean.

Then. You must apply. Theory (memorization) is ok. Doing is better. Learn it. Do it. Practice it. That’s how you provide value. But go even farther. Learn more than just processes, methodologies, and frameworks. Understand how high-performance teams work. Understand how people work. That’s the essence of the Science behind Teams.

I believe we fight others when we have ourselves closed our minds to the unknown opportunities. We, therefore, have stopped learning. You might as well be dead.

-ps

Peter Saddington is a Certified Scrum Trainer who enjoys learning about new things and reviews them. AgileScout.com isn't a blog known for taking it "safe." ;) ]

16 Responses to “The Scaled Agile Framework (SAFe) – A Review”

  1. Mike Cottmeyer
    February 25, 2014 at 10:13 am #

    I have not been throught the SAFe training and have no plans to go, or to get my team to go. I like SAFe and have tremendous respect for Dean, but some of the points you’ve raised are fundamental flaws that need to be worked out. Why a 1 week implementation? Because when you are scaling a consulting practice, it’s hard to spread yourself and your team any other way. Why everyone in the same room? Too much pandering to agilists that don’t want to be told what to do. Why so much detail and not enough context? ‘Cuase it will sell.

    Like you Peter, we use many of the concepts built into SAFe and I do believe the fundamental model is sound. The challenge is that it has to be packaged into somethign that will sell. The stuff that SAFe does not address: the underlying team-based organizational structures that must be formed, how to effectively deal with upstream and downstream process elements and governance, how to safely and pragmatically introduce SAFe into an organization, or to adapt it, or to tailor it are going to kill it.

    We are already starting to see evidence of people that won’t even consider SAFe due to some of these concerns. Others have bought the marketing, but have failed in the implementation of it’s ideas. Frankly, it’s not the fault of these organizations that they couldn’t apply SAFe out of the box. It’s a process that won’t work for them as they are currently configured. I hope Dean figures out how to incorporate some of this guidance into the framework so that more people can take advantage of it.

    I bend over backwards to be resepectful of SAFe becauase I respect Dean and I do believe SAFe has many elements that are dead on accurate. I think it is more pragmatic at scale than pure-play Scrum. I also think that Dean has some runway to include some of this guidance in the framework. I hope they get to it before enough failed SAFe implementation go public and diminish his ability to advance the cause. We are all trying to figure this stuff out, and Dean has given the industry a good starting place.

    My take is that implementing agile in an organization requires some up front design, some intentionality about how to form teams and what to form them around, an understanding of the existing governance and the upstream and downstream impacts when product development changes what it does. I think it requires iterative and incremental implementation and a solid change management strategy to help people through the transformation. It’s hard work in most organziations and it takes time.

    The hard part is that kind of stuff is hard to sell. It’s hard to convince people to fund that kind of a transformation. It’s easier to get people to buy Scaled Agile in a Box, send everyone to class, and tell them you’ll be done in a week. IMO.. that is not sticky. I’m sure folks will disagree… I am sure the proponents of SAFe have some case studies somewhere where the approach has worked. If so… I’d love to see them and have a few minutes to ask some tough questions. We must be working with way different kinds of companies.

    Good review Peter, IMO by far your best, most insightful post yet ;-)

  2. Olaf Lewitz
    February 25, 2014 at 3:11 pm #

    Peter,
    thank you for your comprehensive and balanced summary, and the appreciative tone of the whole review.

    And:
    “Central control of strategy; decentralized control of execution.”
    This summarises my concern.
    Getting some benefits from “Agile” without losing control is certainly a SAFe thing to do.
    It might make some things better, especially for a few (those who control the strategy, at the top).

    It also seriously limits the options that can be available to a wholehearted, decentralised organisation that fully leverages the potential of all people. It values some people more than other people, which in my opinion is not Agile.
    Our manifesto does not say “we value some people and their interactions more than some other people [...]”

    Scaling agile is a broken concept…

    descale (ˌdiːˈskeɪl)
    vb (tr)
    1. (Chemistry) to remove the hard deposit formed by chemicals in water from (a kettle, pipe, etc)

    Centralised Control is the hard deposit. Agile in all its flavours is one way to remove it.
    Agile is a means to descale an organisation.
    Scaling it makes no sense.

    Thank you.
    Olaf

    • peter
      February 25, 2014 at 3:23 pm #

      Olaf. Can I have a virtual hug? < (^.^<)
      Man. I'm 110% on board with what you're saying. I know of several consultants who are doing an awesome job at actually de-scaling organizations (at scale) and decomposing PMOs. ... ... and, it's working. Companies are also moving to #nomanagers and other ideas as well... novel, but powerful. See http://ryancarson.com/tagged/NoManagers for an example of how one company is doing this!

    • Phillip Cave
      April 12, 2014 at 11:33 am #

      I love this word play. I too went through the SPC certification and now I have “lectured” two class for SA training. SAFe is a framework like I have always thought of Scrum as a framework. The “work” part of a framework is “framing” it to the context of the organization. I don’t care if it is Scrum or SAFe … the work is in helping people see the value of it and how to apply it in the context of their world. Some orgs are tiny, some are crazy big. My consulting work has always been around helping people help themselves to deliver products and services with lean thinking as a guide…to make sense of the scaling problem and “descale” the impediments. Thanks Olaf for some insightful words :-)

  3. Allison
    February 26, 2014 at 10:53 pm #

    Wow, I am really glad you shared your thoughts. I know some folks who attended a SAFe presentation recently and were excited about it; with your comments about the training, I think I have a better idea of what they heard about SAFe vs. my understanding of it. I’m a little shocked by the one-week training to start SAFe given that one person I’ve heard a success story from talked about the ongoing efforts related to culture to help the organization be agile — http://www.prettyagile.com/search/label/SAFE

    And I love Olaf’s comment on scaling/descaling and hard deposits!

    • peter
      February 26, 2014 at 11:25 pm #

      The road is paved with good intentions. :)

  4. Jason Tanner
    March 25, 2014 at 12:22 pm #

    Peter,
    Fantastic review and it feels like you read my mind. I just renewed my SPC…tough decision. After a year of SAFe coaching, I was torn – primarily due to the training problems you described.
    Last year I coached a release train through 5 PSIs. They’re still going and continue to make adjustments based on what they’ve learned. I’m currently coaching a very interesting conglomeration of teams on a release train. There are at least a dozen more trains running here. We are all learning so much.
    @Mike’s comments…I know the feeling. We should talk.
    @Olaf’s comments…I really struggle how to descale some really big initiatives. For example, a brand new technology with petabytes of space for five business units to leverage in support of complex NPI analytics. It takes more than a couple of teams of 5-9 people. Basic Scurm of Scrums probably won’t work. Perhaps a group of 5-9 teams could figure out their own scaling/planning/integration pattern. SAFe provides a starting point. Is it perfect? No. Does it provide value on the way to inspect and adapt? IMO, yes.
    I need to reflect some more as we wrap up the first PSI…then I can write my review – reflections on SPC training after a year of experience.
    Thanks for such a detailed, thoughtful, introspective review, Peter.
    All the best,
    Jason

    • peter
      March 26, 2014 at 8:51 pm #

      Thanks for the feedback man! It’s tough. While I believe it (could) be a starting point, it certainly has to be contextualized to the greater organization.

      Hope all is well, friend!
      -ps

  5. Daniel Gullo
    March 28, 2014 at 3:08 pm #

    Funny, I guess we missed each other in the class all 4 days… ;)

    Great stuff and totally in line with what I saw when I took the class.

    Thanks for taking the time to capture this, brother.

    IHS-

    Daniel

    • peter
      April 1, 2014 at 8:54 am #

      Is it just me… … but when I find material chock full of “A proven method for _____” …. does it make me feel like it’s just hogwash?

      If I have to say it’s “proven” does that dilute the truth?

Trackbacks/Pingbacks

  1. The Scaled Agile Framework (SAFe) – A Review - The Agile Product Report - February 25, 2014

    […] The Scaled Agile Framework (SAFe) – A Review […]

  2. New PM Articles for the Week of February 24 – March 2 | The Practicing IT Project ManagerThe Practicing IT Project Manager - March 3, 2014

    […] Peter Saddington gives us his thoughts on SAFe, the Structured Agile Framework, after attending the training. […]

  3. SAFe - Scaled Agile Framework - My Study Notes | Agile ScoutAgile Scout - March 8, 2014

    […] are the notes I had to study from to pass the Scaled Agile Framework SPC exam. Yes, there is a lot of memorization. Welcome to college […]

  4. Updated: Reviews of SAFe (Scaled Agile Framework) | Agile Advice - October 9, 2014

    […] Peter wrote a review on the Scaled Agile Framework back in February 2014.  Please check out “The Scaled Agile Framework (SAFe) – A Review“.  It is interesting and insightful.  Great […]

Leave a Reply