Scaled Agile Framework (SAFe) – Is It Agile?

I have heard much discussion taking place over the “Agileness” of the Scaled Agile Framework (SAFe). You can find more information on the framework at their website. This post was motivated by a couple of David Snowden’s blog posts entitled “Deal with the system as a whole please” and “SAFe: the infantilism of management“. In these posts Dave challenges the assumptions of linear progression and fractal organization. I believe what Dave is challenging is the basic nature of the endeavor of software development assumed by SAFe. That is, software development is not a simple process that can be optimized by constructing a set of efficient constituent sub-processes. Also, people like Ken Schwaber in a blog post entitled “unSAFe at any speed” assert that SAFe violates Agile principles.

So, I could not resist this topic. Why? I do not have any original conceptual thinking. I have pointed you to some intellectual heavyweights that I respect. I’m sure you can find more ammunition if you want to continue the assault against SAFe. I would like to discuss what I learned from our implementation of SAFe. You see, I’m actually responsible for leading a transformation of our software engineering organization to SAFe.

Before I lose your confidence, allow me to explain myself. In the summer of 2011 I had taken over a new software engineering team. In the assignment I was leaving I left a relatively well functioning software development team with 6 Agile teams. As a director of the group I had software engineering managers reporting to me that had responsibility for the real work…that is I was mostly blissfully ignorant of what they were doing day to day. The only credit I can take for the adoption of Agile is that I exposed my team to an outside company that touted the virtues of Agile. The exposure motivated a manager that adopted Agile with his teams and the practice grew. Given Agile was forbidden within the company my second contribution was to give the methodology a name like “iterative development” to prevent the VP of Software development from killing the process.

So, while I was not a huge initial proponent of Agile, I was definitely informed by my previous Agile experience and my recent attendance at the 2011 Lean/Agile Conference in Long Beach. I will say I was highly supportive of the Agile principles and I was extremely impressed with Snowden’s presentation of Complex Adaptive Systems at the conference. I will say I was skeptical of some of the “Agile” practices. As Robert Rubin says, “Some people are more certain of everything than I am of anything.” I was very skeptical of the certainty people had with respect to many practices. My thoughts for creating a better organization were less focused on specific practices and more about emphasizing changing the way we thought about software to make better software. I had no idea where to start. I enlisted the support of a colleague that was in charge of an organization that was entitled something like Enterprise Software Engineering practices…cannot really remember the name. Anyway, he had contacts in the industry and I started to interview people that could help with the transformation process. Again, my goal was to think different to make better software. To my knowledge, there really isn’t a “think differently to make better software” help industry. Rather, there is a Lean industry, an Agile industry, etc. That is, industries are built around practices. I quickly settled on the closest thing that would meet my needs was an “Agile transformation”. During my interview process I made sure to emphasize that my objective was to think differently to create better software, not to be Agile. In the end, I chose Dean Leffingwell to help with our “Agile transformation”.

While I was shopping around there was also some movement across the company for a change. About the time I had decided to work with Dean the CTO of the company was also looking to help with a transformation. The whole movement caught momentum and the next thing you know we were visiting different companies that implemented SAFe. More accurately, we visited companies that implemented some of the practices some of which would eventually be codified as SAFe. To this day, I’m still not sure how and why it happened…but it did. All of the sudden I found myself in a 400+ engineering organization transformation. The point of this story is just to let you know that where we landed was a bit of an accident.

To be sure, we were relatively new adopters of SAFe. There were plenty of times during our 3 day training that sections were ignored, replaced on the fly, or adjusted. The point being that we are not necessarily representative of the current incarnation. Also, must to the consternation of our executives we have dumped a bunch of things we were trained to do by SAFe. So, if I had to write a list of what SAFe did and did not do for us here are the lists.

What SAFe helped us do:

  • SAFe feels “safe” to executives. It is a big bold program. They have big reference-able clients. It appears to preserve enough hierarchy.
  • Dean Leffingwell has executive appeal. I’m not sure how to describe it. But, after spending a half-day with our executives he had them convinced…something to consider.
  • The entire organization embraced time-boxed development cycles. Time-boxed development cycles were the catalyst we needed to adopt engineering practices that facilitate time-boxed development.
  • SAFe training challenged us to consider how we balance development efficiency and achieving customer value instead of just focusing on efficiency.
  • Developed an awareness of why it is important to continuously keep or software in a “shippable” state.

What SAFe did not help us do:

  • Our software is not continuously in a shippable state. We actually engaged another consulting company to help us with defining tactics and milestones for this endeavor. We launched the endeavor this year…multi-year effort so we’ll see where we land.
  • Our agile requirements (stories and features) are still of poor quality. Writing stories is difficult and requires expert practice in the team to reinforce and correct story after story until the ability to articulate stories well is achieved.
  • Our beliefs of what drives success are largely unchanged. Our behavior reflects a belief that Agile principles are kind of nice ideas. We don’t actually make hard choices using the principles. In fact, we often violate the principles.
  • Our teams are not self-organizing/managing. We see pockets of progress. But, the reality is that there are a lot of organizational contradictions that send mixed messages about self-organization/management. If you cannot choose the IDE you use because there is a standard IDE might that hint at some lack of autonomy?

Don’t get me wrong. I’m not arguing about what should be. I agree with the criticism of SAFe. In fact, the whole organization disagrees with some aspects of SAFE. That is why our organization is not a perfect reflection of what we were trained to do. What I’m saying is that some of the constraints that were added to our software system by the adoption of a SAFe program encouraged behavior that improved our software. For my organization, we can measure success in number of software releases, increased story production, decreased customer defect reporting rate, and improved employee morale. The SAFe methodology may be wrong for all the reasons given by Snowden, Schwaber, and others. I still encourage you to look at SAFe…it may be the Trojan horse your organization needs to drive the changes you need.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s