Thoughts On Adopting SAFe 4

Thoughts on Adopting SAFe 4

There’s much to appreciate in Scaled Agile Framework, version 4, but the framework’s at risk of losing it’s leanness, even as it embraces Lean.

Over the past few months, I’ve spent the better portion of my free time upgrading my brain from Scaled Agile Framework (SAFe) 3 to SAFe 4 by reading the SAFe 4.0 Reference Guide, attending presentations and workshops on SAFe 4, and taking six days of SAFe 4 training in advance of extensive work on an upcoming SAFe transformation.  As a long time agile practitioner with a SAFe 3 certification and exposure to scaled agile going back more than five years, this SAFe training certainly triggered some compelling thoughts, both positive and negative, about the Scaled Agile Framework, that I think are worth sharing. Here goes…The Positive:

  • Recognition of Product Management. After watching Product Owner after Product Owner struggle over the years, I came to the realization that the successful “all-in-one” Product Owner who controls and manages every aspect of a software product is the exception, not the rule. In addition, while the development team definitely needs one – and only one – person to make tradeoff decisions about the product, this does not mean that others cannot handle the market research and product strategy without breaking this principle. The fact that SAFe both recognizes the existence of product management as a business function and incorporates this into framework is a significant improvement.
  • Intentional Architecture, Emergent Design. One of the tenets of Scrum is that architecture emerges as teams develop the software, experiment and adjust over time. This works very well in a variety of circumstances — green field development on new platforms, small-to-midsize organizations with a few development teams, and development leveraging largely pre-existing architecture, among them.
    In my experience, when the software development organization exceeds a certain size — perhaps 75 individuals and five teams, including contractors — emergent architecture begins to become a liability and not an asset. Eventually, the lack of planning results in brittle software, non-cohesive tools, high technical debt and ultimately, high support and maintenance costs for the organization. In contrast with Scrum, SAFe draws a distinction between architecture (decisions that define structure at the enterprise and solution) and design (decisions that define structure for a single module or component), encouraging organizations to make long-lived, high-impact architectural decisions with greater care and coordination than short-lived, tactical design decisions.
  • Value Streams. If you’ve been in one of my Product Owner training sessions or sat through some of my portfolio management workshops in the past five years, you’ve heard me describe Michael Porter’s Value Chain and learned how to map out an organization’s value chain. Value streams, as implemented in SAFe, are fundamentally the same exercise as value chain mapping and serve the same purpose of ensuring business-IT alignment.
  • Business Strategy. I’ve spent much of the last ten years aligning business strategy with IT execution, in many cases leveraging my MBA to serve as the translator between strategy and IT. It’s what drove me to pursue Balanced Scorecard Professional certification 5+ years ago and compelled me to keep a firm foot in the world of business strategy and strategic planning as well as foot in technology.
    The incorporation of business strategy into SAFe — in the form of strategic themes, business objectives, product portfolio management and value streams — dramatically increases the likelihood that successful execution will yield successful business outcomes. It also confirms my quest to tie business strategy to IT execution in an agile world was not a futile one.

The Negative:

  • Awkward Acronyms/Lingo. Along with scaling, SAFe has brought forth some pretty awkward lingo and acronyms: VSE’s, MBSE’s, RTE’s, ARTs and architectural runways. The worst aspect of all this terminology is not that the terms are entirely new — some are — it’s that some terms are entirely re-defined in a way that contradicts the industry-standard definition. Metaphors are also mixed — release “trains” versus architectural “runways”; “Release Train Engineer” versus “ScrumMasters”; “Portfolio Epics” and “Program Epics”, as examples. Yes, some of this awkwardness has been around since the advent of SAFe, but the problem has worsened. In my opinion, this needs to be simplified and fixed.
  • Unnecessary Complexity. This is only speculation on my part, but I suspect that only 25% of organizations that practice agile also need SAFe. And, of those 25%, only 50% of those need look much further than essential SAFe for their implementation. Yet, much of the training time touched upon or incorporated four-level SAFe with the value stream level. This is sure to result in many organizations adopting far too much of the SAFe framework, increasing costs of software development AND increasing the risk of failure during adoption. I believe this can be remedied through a combination of changes to the training approach and changes to the website, but in the meantime organizations are left to struggle with the complexity.
  • Overly Prescriptive. If you’re working with a good agile coach s/he will provide sound advice, but ultimately tell you “…do what works best for you…” and encourage you to adopt the agile practices that are appropriate for your team and organization. Unfortunately, SAFe can be overly prescriptive in a number of areas that might force a coach steer a company the wrong direction. One example is use of Weighted Shortest Job First (WSJF) to prioritize work, as though this means of prioritization is somehow better than any other subjective means, like MoSCoW; another is the insistence that features can’t be swapped in our out during a program increment, forcing business stakeholders to wait as much as 6 months for a new feature to reach production. This is no better than well-managed waterfall.
    Fortunately, SAFe does encourage some degree of tailoring beyond essential SAFe. I hope the thought leaders behind SAFe keep this agile tradition of mixing, matching and optimizing practices within and across frameworks so that “best-of-breed” approaches can rise to the surface, while best-fit practices can be adopted by an organization when needed.
  • Culture Comes Last? I first heard this in presentation at Agile DC by Mike Cottmeyer from “Leading Agile” and I was so shocked that I peppered poor Mike with a few pointed questions before letting him move on. (Sorry, Mike, I still owe you a personal apology on this). According to SAFe teachings, cultural change comes last. Yet, experience has taught me that organizational culture must at least tolerate agile principles first before any agile framework can effectively take root. Consider, for example, an environment without trust among ART or even team members. This prevents transparency, which limits collaboration, innovation and empirical thinking, which in turn limits the ability to adapt, adjust and continuously improve. At this point, your organization may have multiple release trains going through the motions of SAFe, but you most definitely haven’t adopted agile. And it’s agility that brings the greatest successes to an organization, not any single framework or practice.

The Net

SAFe 4 has a number of improvements over SAFe 3 that make it more appealing than its predecessor and more likely to succeed in the largest organizations. I’m looking forward to injecting some of these into my coaching engagements where appropriate, as well as adjusting some of my existing practices so they are closer to (what is likely to become) industry standard. In short, SAFe is still the best framework for agile-in-the-large that I’ve seen.

Yet, for all but the largest of large organizations, four-level SAFe 4 at times feels over-thought and over-built. Because of this, we coaches must be judicious in how we advise our clients to implement SAFe to avoid over-complicating the implementation and putting success at significant risk.

In addition, leadership at Scaled Agile should seriously consider doing some pruning and patching to SAFe 4 before moving on to SAFe 5. Much like the Rational Unified Process (RUP) software methodology, a predecessor to SAFe that fell out of favor in the last five to ten years, SAFe is becoming extremely complicated, making it more difficult to learn, teach, implement and follow. Unless the framework remains fundamentally simple and straightforward, notable failures are sure to rise just as the fad of SAFe adoption starts to taper, relegating SAFe to the innovation junk heap along with RUP — and if it fails badly enough, agile itself.