I just registered for the Scaled Agile Framework, SAFe Program Consultant (SPC) class.

I’ll be taking the course April 22-25 in Boulder. One of the reasons I picked this class is that Dean Leffingwell, the creator and prime instigator of SAFe, is teaching it. Much as I did in 2004 when I took my CSM certification with Ken Schwaber, I want to get it “from the horses mouth” so to speak.

UPDATE, as of March 24, 2014

I changed my class. Instead of Boulder, I'll be staying home in Raleigh and attending a local class from June 10-13. It was just too good an opportunity "not" to travel. But I'll miss the interaction w/Dean.

I’ve been sitting around far too long observing it from the sidelines and feeling quite apprehensive about the implications that SAFe has across a variety of agile principles.

Another driver is that many of my coaching colleagues have taken this course and are recommending & leading SAFe initiatives. I respect them and their balanced judgment, so I want to approach the class with as few preconceptions as I can. I’ve long respected Dean for his work in RUP and software requirements, so I want to give it (and him) a fair shot.

Not entirely a “Newbie”

Now I’m not entirely a SAFe newbie as I’ve attended quite a few presentations that surround the core concepts. And in fact, I’ve been talking about and leveraging release trains for release tempo and Agile Release Planning since probably 2005-6. Starting around that same time, I’ve been a strong proponent of Hardening Sprints within these models. All of which are recommendations within the SAFe framework.

And I must say that I’ve gotten my share of “grief” from many in the agile community for leveraging and sharing on those ideas…mostly as being “terribly un-Agile”. So from that perspective, I’m truly trying to connect my own experience and to embrace the suite of SAFe ideas.

My Biggest Concern

That being said, and I’ve said this before; my biggest problem with SAFe is the emphasis or focus on leadership, management, and upper-tier project orchestration. While all of these are important considerations in scaling agility, I worry that SAFe is leaving the team (the people) behind.

And why worry about that?

Because the WOW from high-performance agile teams does not come from the C-level, PMO, or Portfolio Managers! It comes from the teams. It’s about creating a culture where the people are the success factor.

I was having a chat with a SPC not that long ago and we ended up with an interesting conclusion. We both thought that if you turned the SAFe diagram upside down, so that the “team” layer was on top, that it would make a huge difference in the interpretation and execution dynamics of SAFe. The imagery would imply that leadership was there to “serve the teams”. I know it might sound overly simplistic, but I felt that this simple change might allay much of concern about the interpretation of SAFe that I expressed in this previous blog post.

Following up on my ideas, here are two recent posts that amplify and explore my concerns:

  • First, Evan Campbell explores the Big Visible variant of agile scaling with SAFe within this blog post. In it he explores some of the indicators / dynamics of Deliver Team maturity. Acknowledging the importance of the team and its practices within the SAFe (or truly any) scaling initiative.
  • Second, Amr Elssamadisy explores the role that culture has in agile teams in this blog post, both in general and at scale. He correctly points out that SAFe is not an individual or team play in it’s primary focus, it’s also not a cultural change play either. Please read this post, including the wonderful quite by Jim Highsmith on the “mush stuff of values and culture” within the Agile Methodologies.

Wrapping up

Look for a future post right after the class where I share on my “learning’s and findings” from the class. I promise you that I’ll keep the agile principles in mind during my journey and give you a more in-depth and even-handed view to SAFe. And as is my habit, I’ll probably do a follow-up a month or two later as the ideas and concepts have further developed in my thinking. I’m also planning on gaining some “real world” experience with SAFe that I can report back on.

Anyway, stay agile my friends and stay SAFe until we discuss this topic again in early May.