The Agile Tester, LLC
720-323-4652
  • Home
  • About
  • Services
  • Contact
  • Training
  • The Agile Tester Blog

Does SAFe Comply with the Agile Manifesto?

5/11/2017

3 Comments

 
The question: "Is SAFe Agile?" comes up with great regularity. There are myriad opinions on this subject. Some of these opinions are from people who have never worked in a SAFe environment who have never really studied or experienced it. Some are from experts in Lean and Agile practices. Some are even signatories of The Agile Manifesto itself. Others are the opinions of people with great experience in successful as well as unsuccessful SAFe implementations. 

So, does SAFe really comply with the Agile manifesto or is it, simply, more snake oil?

Let's take a look. 

SAFe (in its training and elsewhere) claims to be based on the Agile Manifesto, SAFe also calls out Lean principles with the goal of "the delivery of valuable software with the shortest sustainable lead time to the customer". As well, SAFe inherits from "Agile Software Requirements", which scales the concept of User Stories to the Enterprise. If that weren't enough SAFe is built on literally every principle in Donald Reinertsen's breakthrough research described in "The Principles of Product Development Flow". But, did it succeed in being "Agile". 

The Agile Manifesto is 4 values and 12 principles. Let's do some comparative analysis with SAFe. 
​
SAFe’s highest priority is to satisfy the customer through early and continuous delivery of valuable software? 

Check. Team Demos/Train Demos/Solution Demos/PO’s on team and attention to stakeholder management continuously create opportunities for fast-feedback so the best fit-for-purpose solution is delivered.   

Safe welcomes changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage?

Check. The use of Agile Software Requirements (the “Bible” of SAFe) as well as continuous planning across the enterprise, coupled with the XP practices of Test First/Refactoring/Collective Ownership/Pair Programming and Continuous integration provide best in breed agility at scale. 

SAFe delivers working software frequently, from a  couple of weeks to a couple of months, with a preference to the shorter timescale?

Check. SAFe promotes the concept of “Develop on Cadence, Deliver on Demand”. SAFe can deliver anytime the business deems it’s ready. Scrum delivers working software on a cadence and Kanban delivers in a continuous flow. SAFe is extraordinarily powerful to influence a true DevOps culture and calls this out directly.  

SAFe supports the principle that business people and developers must work together daily throughout the project?

Check. SAFe is, essentially, structured Scrum of Scrums with simple roles and clear alignment. Scrum/Kanban as core practices inherit this from XP with the presence of Product Owners, Lean/Agile Leaders and goes beyond this with the larger inclusion of stakeholder involvement at every level. 

SAFe knows to build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done? 

Check. This is essential to Agility and SAFe just inherits that directly from the manifesto. The SAFe training has done to advance the “Motivation of Knowledge Workers”, arguably, more than any other  single process or activity to date. 

SAFe believes the most efficient and effective method of conveying information to and within a development team is face-to-face conversation? 

Check. SAFe supports all of the ceremonies of Scrum of Scrum and Syncs on a regular basis.  

In SAFe, working software is the primary measure of progress. 

Check. Moreover an emphasis on the business value of the software delivered, just not the quantity of software developed, is a metric recommended by SAFe.  

SAFe Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely?

Check. SAFe is a pull system and is based in a value of respect for people. Teams only pull what they can reasonably accomplish. The IP sprint allows teams to recharge and innovate. 

SAFe recommends that continuous attention to technical excellence and good design enhances agility? 

Check. SAFe recognizes the ability to respond to change and support the rest of the manifesto hinges on exceptional SW practices and calls out the best of breed from XP as essential. Many teams try to “do Agile” and make the mistake of “cutting corners” “because we’re Agile”. Scrum makes no provision for XP. 

SAFe knows that simplicity--the art of maximizing the amount of work not done--is essential? 

Check. The alignment with the PI planning facilitates powerful big room planning and alignment which would otherwise result in myriad meetings, dependency planning issues, additional coordination and failed integrations and numerous other wastes. The absolute minimal number of people required to deliver in large enterprise are in place in the SAFe big Picture. Pretty hard to lean it down any more. A layer is 3 people and a backlog and only what else makes sense. Contrast that to thick layers of middle management in traditional project structures.  

SAFe allows for the best architectures, requirements, and designs to emerge from self-organizing teams? 

Check. Recognizing that it would be catastrophic to allow 400 scrum teams to architect a solution without some architectural guidance “unintentional architecture” is a certainty. SAFe aligns architecture and user experience across the portfolio. Teams are responsible for articulating their requirements. Designs emerge organically at the Train/Team level. 

In SAFe, at regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly?

Check. Team retrospectives, Train retrospectives, coupled with true root cause analysis and calling for improvement backlog items as mandatory to comply with the “relentless improvement” siren puts SAFe squarely in the requisite PDCA idioms of modern-age development. 

Summary: 

SAFe scores a perfect 12 out of 12 compliancy with the Agile manifesto. If there is any deviation whatsoever it would be in additional scaling acknowledgement and recognition of powerful flow concepts such as “there is more efficiency in overall alignment than with local optimization”, and powerful arguments about when it makes sense to decentralize control to the teams in the enterprise makes SAFe even better.

Case study after case study not only make it clear that SAFe does indeed comply with the Agile manifesto but takes the Agile manifesto in to the enterprise with style, aplomb and lean based flow. The only way SAFe can not conform to the Agile Manifesto is if it's poorly implemented. "Agile", being absolutely nothing more than a set of "Values and Principles" it is the practitioners, not the SAFe framework, which determines if SAFe complies. It can be no other way.   

3 Comments
Peter Merel link
5/12/2017 02:47:36 pm

Hi Tim, I felt bad about leaving you hanging. Here's a quick response. I'll add it to your post too.

1) POs and PMs aren't the customer.
2) Quarterly planning cycles aren't continuous.
3) Agreed, though you're abusing the word DevOps - see The Phoenix Project.
4) Agreed, but XP has no POs or Agile/Lean leaders. (http://wiki.c2.com/?ExtremeRoles)
5) Except for the Big Rooms.
6) Scrum of Scrums is communication by representatives, not face to face. Try Chapters/Councils.
7) ARTs defer obligation to ship working software till it's "ready". WSJF statistically smears the business value of software.
8) SAFe compromises sprint planning by calling it commitment rather than forecast, and story points by equating them with budget in PI plans. Both compromises oppose sustainable pace.
9) Agreed - though when this article was written SAFe still had the concept of hardening. Better now.
10) SAFe is more complex than competing methods. No other method requires its big room overhead.
11) SAFe compromises autonomy of self-organising teams. It's straightforward to align them without hierarchies and big rooms.
12) Where are the case studies about SAFe failures? Can't reflect and improve if you're not open to negative feedback.

Reply
Tim link
6/8/2017 06:43:16 am

Hi Peter,

1. No, they're not the customer. They are the proxy for the customer. The customer and other stakeholders, however, are an integral part of the process. This is true extension of scaling the manifesto. The Customer simply can not be in all these places but this allows a constancy by a delegate.
2. It is continuous. The plans can *clearly* change during the PI. It's simply alignment and an extension to the cadence. There's a lot more in play than meets the eye on this one. The simple fact that an organization can use PI->Iteration as a "point in time" allows very effective understanding of dates, goals, milestones, etc.
3. I am very, very aware of DevOps having been part of many very successful initiatives including DevOps at the IRS which was extremely challenging. The Phoenix Project is an excellent book. One we studied in a book club.
4. You're mincing words. Everyone in XP is a Lean-Agile leader.
5. What about the big rooms? These are bad why? Conferences are big rooms. The information shared and energy garnered are palpable. Same with the PI events which are truly energizing and a great opportunity to meet other people in the enterprise to begin tearing down barriers.
6. Not sure I understand your point but the SoS is Face-face-face. Chapters and Councils are simply manifestation of the same concept with less accountability structure. We're learning more and more about the dangers of "the Spotify Model". Spotify still is not profitable. Though it has a single value stream which is unlike most real enterprise initiatives.
7. Please see "SAFe from the Perspective of a Fish". We need a way to prioritize. There are many. WSJF is but one approach. In the dozens of WSJF sessions I've facilitated and been a part of the most useful aspect was the discussion forced by understanding the business value of an object. This is simply common sense and is well covered in principles F15, F16 and F17 of Reinertsen's breakthru work. Software can be released 1,000 times a day in SAFe, if necessary. What's your point?
8. I was a big part of the conversation around the word "commitment" in SAFe and the reason it is expressed in two parts: a) we commit to do what is sustainable and our best effort and b) we commit to raising an impediment if we can not meet our planned objectives. Commitment is an "emotive" word and also seeped in controversy and our own value systems. When we ask people to commit to an unknown, to commit to one thing (work) over another (family) we are asking them, basically, to lie. Thus the two-parts.
9. You're pointing out the most Agile aspect of all: That SAFe is versioned and responsive to changes. If that's not "meta proof" enough for this comparison, I'm not sure what would be.
10. It's incredibly simple. I suggest it is the minimum hierarchy for doing the job. It is, at its core, an agile requirements methodology with a focus on getting on with the work. Not sure where you're seeing the complexity. Now, I've studied the competing methods as well and have colleagues I meet regularly who are certified in those methods. In some cases, after years, I still don't understand what they propose as they're vague, or incomplete, or think we can align 4,000 engineers launching satellites simply by adopting Scrum.
11. Again, we will see much greater efficiency with overall alignment than with local optimizations (this is a principle of lean flow). Couple that with clear decision making framework and a bias for decentralization and you achieve the best of both worlds. Trust me we on this: We teach *strongly* that the team should be empowered to make decisions locally and that they should self-select where possible.
12. Maybe there are no case studies of failures simply because it is a framework for *learning* from failure and relentless improvements. When I see SAFe failing it has always been for political reasons and not acknowledging the time it takes (2-4 PIs of constancy) to form our teams.

Reply
QA Guru link
6/8/2017 12:53:17 am

Well, here are sharing such a great and helpful information regarding Agile Testing. Thanks for the publish great ideas in this blog!

Reply



Leave a Reply.

    Click to set custom HTML

    Tim Walker

    Tim is the founder of The Agile Tester, LLC and is passionate and dedicated to the advancement of technical practices for agile teams. 

    Archives

    February 2017
    October 2015
    September 2015

    Categories

    All

    RSS Feed

Contact Us
Jobs

Services
Training