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.
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).
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:
- What SAFe espouses is pretty in-line with what we’ve done, on many levels.
- 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
“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).”
- 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.
- 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 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:
- Effective Communication Techniques as a Presenter
- 5 Tips for Agile Workshops
- The Best Audio/Visual Tool for a Workshop
- A Full List of Helpful Tools for ScrumMasters, Product Owners, and Agile Coaches (scroll down the page a bit)
- 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.
- The course was… OK. – What?! With all the seemingly negative ideas previously? Yes, and yes. The reason I felt like I didn’t waste my money on 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.
Worth noting… Dave Snowden’s view of SAFe:
“Put brutally SAFe seemed to be PRINCE II camouflaged in Agile language. SCRUM as an approach was emasculated in a small box to the bottom right of a hugely overcomplicated linear model. The grandiose name of a dependency map was applied to something which is no different from a PERT chart and in general what we had is an old stale wine forced into shiny new wineskins…
My strong and increasingly passionate argument was that SAFe is not only a betrayal of the promise offered by AGILE but is a massive retrograde step giving the managerial class an excuse to avoid any significant change. OK its a obey making machine but the same applies to snake oil salesmen and the South Sea Bubble. People will get damaged by this nonsense and it needs to be hamstrung at least, garrotted at best.
Such excuses abound and allowing these false linear models to perpetuate themselves is a form of infantilism, a failure to carry through on the need for change. In particular the failure to realise that software development needs to be seen as a service and as an ecology not as a manufacturing process.”
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.
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.