Why Net Objectives Supports the Scaled Agile Framework (SAFe)

July 15, 2013 — Posted by Al Shalloway

The Scaled Agile Framework (SAFe tm) has been getting a lot of publicity.  And a lot of things have been said about it as one would expect. The positive has come from those who have used it and seen its benefits.  The negative I have seen has come mostly from those who have not taken the SAFe training and do not truly understand it.   And, as would be expected, much of the negative has been more mis-information than information.

Given the level of interest and given our high degree of involvement (we’re a Silver Gold partner), I thought it was time to state first, why we (Net Objectives) supports it so strongly and then discuss some of the negative comments we’ve heard about it that we don’t think are accurate.  Bottom line is, we think SAFe is great, albeit reasonably new.  What’s more exciting is that as good as it now is, I assure you it’ll get better.

Full disclosure: Net Objectives is both a silver partner with Scaled Agile Partners and the primary contributor for SAFe's Design-Build-Test pages.

Reasons We Support SAFe

SAFe is the only proven, documented approach to scaling Agile that includes detailed training materials available to properly trained consultants.   Let’s face it, there aren’t that many successful large scale (greater than 1000 folks) Agile adoptions.  We’ve done a few ourselves and we’ve seen some one-offs, but from a repeatability point of view, the only one whose methods are readily documented with training materials available to others outside the company that created them is the Scaled Agile Framework.  While there are some great books out there providing guidelines, they do not provide materials. SAFe does.

SAFe is based on Lean-Flow and Lean-Management. We have long maintained that Lean is an essential component of scaled Agile.  SAFe is built on Lean.   Lean-flow is used to set up a structure where business value can be delivered quickly.  Lean-management enables the continual improvement of the value stream intended to do this.  Proper involvement of management is essential at scale.  A bottom-up approach not including management has a track record of challenge (and that’s saying it nicely).

SAFe takes an holistic view. The focus on teams and scaling by coordinating teams is a myopic view.  One must come from the view of value delivered quickly across the entire value stream.  Part of this holistic view is using Kanban to manage the workload at the portfolio level.

SAFe creates a bigger picture that makes it easier for folks to work together. People in organizations often work at odds with each other because they are optimized for local improvements.  By creating a bigger picture, SAFe enables folks to work together and not simply do local optimizations.  It actually enables local decisions to be made while being aware of what will happen to the total value delivered – a necessary thing to achieve Agile at scale.

SAFe is non-method specific at the team level. One can use Scrum or Kanban (or anything else for that matter) at the team level as long as the team works within the context of the bigger picture SAFe creates.  No one method works everywhere.  SAFe acknowledges this and allows for teams, groups, etc., to work in the way they need to.  As long as they keep the big picture (entire value stream) in mind and stay in cadence with the two week sprints that SAFe requires.

Code quality is one of the four core values of SAFe. I have joked for years that "at the end of the day you're still writing code" because it seems, with the exception of XP, how you actually produce code has been ignored by Agile methods.  You have to address code quality directly.  Other than XP, SAFe is the only Lean-Agile method that says Test-First methods are important.  It also provides a structure for architectural consistency throughout the organization.  These and other required technical aspects of software development are not easy to handle but cannot be ignored.

SAFe is led by Dean Leffingwell. This is personal, but I’ve known Dean for years and hold him in the highest regard – both intellectually, professionally and personally. 

SAFe is based on a train the trainer model so large organizations do not have to be stuck paying consultants to get the job done.  Too many organizations promoting their framework/method/process have been focused on maintaining control of a few certified trainers.  SAFe is going just the opposite way with the Scaled Agile Academy and Scaled Agile Partners.  It’s trying to get as many people trained, both consultants and internal coaches, as possible. Most companies will likely still want to use outside consultants, but by providing options, organizations with limited budgets can still undertake and get great value from SAFe.  This approach is based on furthering value and not control.  It is further indication of the vision and integrity of SAFe's founder, Dean Leffingwell.

SAFe is improving as time goes on.  At the end of each SAFe SPC training, time is taken to talk to folks about how to improve it.  I’ve seen SAFe improve in the last 12 months at a faster pace than any other Lean or Agile organization I’ve been involved in.  Dean and his associates are pioneering this change not changing reluctantly as other methods provide competition.

SAFe provides a framework for learning. SAFe is not an end point.  It is a point to work together across an organization to learn how to improve one’s methods.  At scale, there are many things that must happen: architectural framework, synchronization across projects, prioritize value across the portfolio, build incrementally, amongst others.  SAFe provides a method to accomplish all of these things.  Because it is based on Lean principles, the intent of the SAFe practices are clear and can be modified with understanding.

SAFe is consistent with approaches we’ve used ourselves for almost a decade. SAFe’s track record alone should be enough to inspire this confidence.   But because it is based on proven principles, this gives us confidence it works in situations other than where it has already proven to be successful.  But we’ve always liked it when we can understand why something works.  SAFe is based on solid Lean and Agile principles that work.

Arguments against it

Most of the comments we’ve heard against SAFe are by Agile consultants who haven’t tried it.  But, misunderstandings lend opportunity for greater clarity.  So here are the three most common things I’ve heard people don’t like about SAFe.  Feel free to add more and I’ll extend the blog.

It’s prescriptive.  Actually, it’s more prescriptive about what needs to be accomplished.  It does provide a method of solving things in a particular way.  But this is necessary to avoid SAFe being too abstract.  SAFe could tell you the different issues you need to solve and the principles that would be useful in solving them and then let you figure things out.  However, that would take a lot longer than starting with the SAFe solution and then modify it as you went along as needed.  Even at the beginning, however, SAFe suggests using team methods (Scrum or Kanban) as best fit.

It is heavy-weight.  This typically refers to the optional hardening activites identified in the "HIP" (Hardening, Innovation, and Planning) Sprints. SAFe only suggests using things that are needed.  Most large companies need hardening sprints.  Maybe they shouldn’t have to, but reality is what matters.  SAFe is pragmatic.  It’s not saying the goal is to have hardening sprints but it is almost certain that if you are doing Agile at scale for the first time, you will need them. If you need hardening sprints and don’t do them you will have serious problems.  Underweight can be just as bad as heavy weight.  And in most cases, this isn’t heavy weight at all.

It involves certification. Certification is not bad when what is being certified makes sense.  SPCs are certified that they know what SAFe is.  You must pass a rigorous test to get certified.  No one claims having passed the test makes you able to implement SAFe.  But let’s face it, some folks won’t like certification no matter what its value.   I see value in the SAFe certification.  It strikes the right balance between being readily available but still be meaningful.

In Summation

We at Net Objectives think SAFe is the first viable approach to large scale Agile that is readily available.  We think it’s the next big thing.  And yes, we’re biased.  But our track record of being in the XP, Scrum, Lean and Kanban camps should prove that we are attached to results, not organizations.  If you are struggling with expanding your Agile methods you should consider SAFe.  Even if you don't use it, taking a Leading SAFe course or the full four day SAFe Program Consultant course will be well worth your time.  If you are considering SAFe, or are skeptical about it, please drop me a note.  Always happy to help.

To learn more about SAFe, see our SAFe Resources page..

Al Shalloway
CEO, Net Objectives

 

Author: 

Share this:

About the author | Al Shalloway

Al Shalloway is the founder and CEO of Net Objectives. With over 40 years of experience, Alan is an industry thought leader in Lean, Kanban, product portfolio management, SAFe, Scrum and agile design.


Comments

Do you do certifications? If not, whom would you recommend?

Yes we do.  We have two courses coming up - one in Seattle in January and one in Atlanta in February.

We can also do in-house SAFe training any time you like. :)

Al

Free Email Updates!

Sign up for free email updates from
Net Objectives Thoughts Blog

Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean-Agile, Kanban, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, Kanban
Ken Pugh
Software Design, Design Patterns, Technical Writing, TDD, ATDD, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile