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.
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.
RSS Feed