In response to Mike Beedle on LinkedIn. Mike is wrong about the SAFe of course. And not just because of his childish method of attack. Facts, evidence, experiments, my experience and dozens of business case studies back up the experiments of the SAFe. Mike sounds a lot like project managers that swear the PMBoK/waterfall works better than agile for large scale “projects” with high complexity, significant uncertainty, many dependencies and new knowledge to be obtained to deliver the product. Project management works in those scenarios (fantasy). But not as well as Agile (reality). Read the studies (Chaos Report, Standish Group; State of Agile, VersionOne; others). A sea change is in play — right now. Customers want predictability, results — and truth. Not endless “Change Requests” and contract modifications for more time, more money and more people. One truth about the Agile Manifesto is that it is great guidance as a value system and principles for software development. The big problem is that it [Agile Manifesto] is STATIC. Relentless improvement drives us to go beyond yesterday. Study the Scaled Agile Framework for the enterprise and come to your own conclusions. Evolve or join the museum with the other artifacts of the information age.

Responses below.

[Mike] I might have considered your arguments credible and worthy of debate if there were any truth to them. SAFe is not what you describe. You are attacking SAFe because you either lack understanding and/or it is part of your agenda. SAFe in 2016 had 27% of the market share and it is growing 150% per year… because the guidance (*framework) is producing great outcomes. All I read in your rant is “I’m jealous because I was too arrogant to be one of the over 100 thought leaders that built SAFe.”

Truth about SAFe #1. The first thing we teach in every SAFe course is The Manifesto for Agile Software Development. We teach it as a foundational value system and set of principles underlying the rest of the SAFe.

Truth about SAFe #2. The entire framework is designed to bring people together in the right context at the right time, on a cadence. SAFe is not a process. It is guidance. Follow Shu Ha Ri. Your point is ridiculous and so far from the truth. You can’t point out all the ceremonies in SAFe that drive the opposite of your claim because it defeats your argument.

Truth about SAFe #3. Wait did you say “require” to integrate and test everyday? I think your command and control project manager is showing. SAFe guidance decouples development from release. Develop on a cadence flow based system. Integrate often, DBT cycle occurs as oft as possible. Release any time. Automate testing at the unit through system levels, implement a CI loop. System demos are guidance for every iteration boundary and integration is a necessity for improving quality and part of the CI. EA and architects are part of the support structure of the ART building runway for teams consuming it at a regular pace of system development.

Truth about SAFe #4. The SAFe provides guidance for Lean-Agile development using both Kanban and/or Scrum. Scrum is taught essentially lock step with scrum guides.org. Agile teams in the SAFe are focused on value delivery in the form of working software/widgets with every iteration. ARTs are a team of teams usually with product and domain affinity and can be designed in many different ways to support value delivery. SAFe teaches us to focus on value delivery in the customer solution context. Managing risks and dependencies. Furthermore, the ceremonies and cadence actively encourages participation from all teams in an organization including the executive team. This is a big deal for staff typically detached from the elite strategic / portfolio levels.

Lastly , as anyone brave enough to look for more than five seconds would realize… Scrum is an integral part of the SAFe. In fact, much of the cadence and ceremonies are scaled versions of those found in Scrum. We change teams within boundaries all the time. It is just as painful in SAFe as it is in any framework, process or methodology. Inspect and Adapt, transparency are also part of the SAFe in the core values and principles. The SAFe is not Agile. It is Agile Evolved. The SAFe is not Scrum. It is Scrum Evolved. There may very well be better choices for any given organization. Any competent professional studies the challenges and chooses the right tool to fit the job. Leave the school yard antics to the fanboys who always recommend the same old “whine.” [Sic]

S_Fe is not Agile. S_Fe is not even Scrum.

We said “people and interactions”, “working software”, “customer collaboration” and “responding to change” were important; however, S_Fe does not put these things first, and violates the values of the Agile Manifesto.

S_Fe is not about people and interactions — it is a massive stiff process, you’ve seen the picture!, that does not put people and interactions first: it has NO cultural background, it has a process background with deep hierarchies.

S_Fe does not require to integrate and test every day — not even Sprint by Sprint; it is not a subsumption architecture; therefore, it encourages technical debt and it is prone to systemic problems like massive delays, building the “wrong thing” and lack of adaptability. S_Fe also does not offer structural or temporal choices for things like Enterprise Architectures, programs with or without software, or large products/services, to be delivered on a CDep, CDel, Sprint levels. It’s only choice is the “delegated _RT” — one size does not fit all!

S_Fe says that the _RT, is about “value streams” at the program or portfolio level, but we know that each Scrum team must deliver business value to be called Scrum.

Lastly, and probably most importantly, S_Fe does not have enough adaptation mechanisms — not even the basic ones in Scrum, to constantly “respond to change”. If business changes, technology changes, architectural changes, team changes come in the middle of an _RT, you will break your neck.

Don’t be fooled — S_Fe is not Agile. S_Fe is not even Scrum. There are many other better choices.

– Mike Beedle
co-author Agile Manifesto

Manifesto for Agile Software Development

We are uncovering better ways of developing software by doing it and helping others do it. These are our values and principles.