Recently, Ken Schwaber--an Agile thought leader, co-creator of Scrum and someone I think very highly of--posted a controversial blog entry "unSAFe at Any Speed" during Agile2013. During my career as an agile transformation consultant, I have had the opportunity to work with Ken, Dean Leffingwell of SAFe and both Scott Ambler and Mark Lines of Disciplined Agile Delivery. I have studied their histories, intensely reviewed their current approaches beginning in 2007 and analyzed the approaches against lessons learned with hundreds of diverse enterprise teams over time. From that perspective, I offer the following thoughts.
 

     SAFe *is* a prescriptive framework and done without consideration for underlying principles and values of agile is a serious problem for an enterprise, just as implementing Scrum without the principles and values would be problematic for a small agile team. It is a framework that works for many teams. SAFe has been empirically derived from addressing problems as teams scale--lessons learned over time--and it continues to evolve.
 

     Examples of how SAFe is empirically derived include two teams realizing they can be more productive together as a team if they organize on the same Sprint lengths and same Sprint boundaries and two teams realizing that they need an architectural runway in order to communicate and collaborate more effectively as *one* team. We have many other examples of aspects of SAFe empirically derived as the teams, their organization and the enterprise work to "optimize the whole" to deliver value with lean thinking, rather than viewing the individual teams in tiny silos, sub-optimizing. Within IBM, we know that this is empirically derived because some of our larger, more successful teams and client teams have been evolving through experimentation and working with "SAFe-ish" elements since the early 2007 days when SAFe was little more than the Agile Release Trains part of today's SAFe approach. We also see that SAFe is continuing to logically evolve as indicated by the DevOps approach that's recently been announced.

     Disciplined Agile Delivery (DAD) is more important than ever because it is a decision framework. DAD covers the "whys" of enterprise agile methods and approaches. It captures the experiences of working with many diverse enterprise teams and respects the complexities of the starting points of those enterprises. It describes different approaches that have been taken in different situations and explains the empirically observed results. There are options. One size does not fit all. Approaches to requirements, approaches to coordinating, approaches to validating an integrated solution, approaches to metrics, etc etc... are provided within DAD and are important for helping teams to continuously improve.

     Many teams will evolve to something that looks a lot like SAFe, if not SAFe. But, to be agile, organizations need to be able to learn and continuously adapt to become their personal best. DAD addresses the scaling factors and realities including aspects of working with the enterprise to start up an agile effort. Notice that I didn't say "project" here... I've heard several perspectives criticizing DAD for inception and transition "phases" in our new world where continuous delivery is the goal. Unless there is a magical wand that *poof* creates an agile organization, there most definitely is a need for organizations to address inception at least once.


     Ken is moving forward with "Enterprise Scrum"...his own approach. My interpretation of Ken's controversial blog posting is that he is highly concerned that a "safe" approach alone won't create a true agile transformation...a culture change. Anyone working with enterprise teams knows that the cultural transformation is the challenge. There is nothing controversial in that statement.

 

Elizabeth Woodward
Agile Community Co-Leader

Tags:  scaled-agile-framework scrum agile-development agile-planning agile disciplined-agile-deliver... safe