An Essential Update on Essential SAFe

An Essential Update on Essential SAFe

Essential SAFe SAFe Updates

Earlier this year, we published our first draft of the Essential SAFe® Big Picture via blog post. Since then, we have received lots of comments, from the blog, our classroom settings, direct customer and analyst feedback, and more. It’s compellingly obvious that this simpler, essential view is a clear aid to understanding the minimum roles and practices that are necessary to be successful with a SAFe implementation.

Simple is good. Feedback is good, too. To that end, we have now incorporated the input and present an updated version of the Essential SAFe® Big Picture:

Figure 1. Essential SAFe: the core of the framework, critical to every implementation.
Figure 1. Essential SAFe: the core of the framework, critical to every implementation.

Here are the nine key elements of Essential SAFe; without which, an implementation of the framework really isn’t “safe”:

  • SAFe Lean-Agile Principles. Lean-Agile principles provide the basis for every successful transformation and guide decision making as the process evolves and adapts.
  • Lean-Agile Leaders. Successful transformations are based on educating management to become “lean-thinking manager-teachers”. Thereafter, they lead, rather than follow, the transformation.
  • Agile Teams, Agile Release Trains, Value Streams. The Agile Release Train is a key building block of a SAFe enterprise. Trains are organized around Value Streams, and consist of Agile Teams. Teams use Scrum, Kanban and Built-in Quality practices to frequently produce integrated increments of value. DevOps practices close the loop on customer value delivery.
  • Cadence. A standardized PI and iteration cadence is the heartbeat of every ART and Value Stream. Periodic synchronization of all aspects limits variance to a single time interval.
  • Key Program Events. PI Planning, System Demo, and Inspect and Adapt assure that teams plan together, implement and demo together, and routinely improve their processes.
  • IP Iteration. The Innovation and Planning iteration is like extra oxygen in the tank: without it the train may start gasping under the pressure of the tyranny of the urgent, a plan that forgives no mistakes, nor provides dedicated time for innovation.
  • Critical Roles. Product Management, RTE, and System Arch/Eng— provide content and technical authority, and an effective development process. Product Owners and Scrum Masters help the teams meet their objectives. The Customer is part of the Value Stream, and is integrally engaged throughout development.
  • Vision and Backlog. Vision, backlogs and economic prioritization deliver business results by assuring that the teams are building the right thing.
  • Architectural Runway. Architectural runway provides “just enough” technical enablement to keep program velocities high, and avoid excessive redesign.

Of course, we are still open for feedback, so feel free to comment away. In addition, I think this is where we are headed next:

  1. Create a guidance article for Essential SAFe, so it can become a permanent part of the knowledge base
  2. Over time we will make the picture in the article clickable, allowing the viewer to navigate to a specific article from there
  3. Provide an Essential SAFe® poster PDF for download
  4. Incorporate this simpler thinking into some future version of SAFe (yes, @Chris, we really did say that …)

Also, Inbar is presenting Essential SAFe® at Agile Israel this week. We will share his presentation materials at some point soon. I’ll also be scheduling a webinar on the topic, probably in August. There I will discuss—not only what is essential in SAFe®—but also how other SAFe® constructs can be adapted to best fit your enterprise context. The link will be available soon, so stay tuned for that.

Please share your thoughts in the comments below. Without your input, there’s no “C” (and therefore, no “A”) in our PDCA cycle. Thank you and be safe, essentially speaking…

-Alex, and the Framework team: Dean, Inbar, Richard

Author Info

Dean Leffingwell

Recognized as the one of the world’s foremost authorities on Lean-Agile best practices, Dean Leffingwell is an author, entrepreneur, and software development methodologist.

comment (19)

  1. Tim Julian

    19 Dec 2016 - 6:25 am

    Originally, you had 10 components of essential SAFe, which included I&A. So, is I&A now not a part of essential SAFe? Also, the spanning palette has so many useful components. Shouldn’t the entire palette be included, and teams pick and choose the components from the palette as needed, like building blocks?

    • Inbar Oren

      19 Dec 2016 - 10:25 am

      Tim hi,
      Thanks for your comment. You are looking at an old blog post. The current version is at http://www.scaledagileframework.com/new-essential-safe-guidance-article/ and has the 10 elements and I&A. Regarding the palette, there are many items there which are important, but in creating essential SAFe we tried to limit it to the bare essentials, that is items without which a SAFe implementation will not succeed. Some of the choices were not easy but we tried to keep essential SAFe minimal.

      Thanks for your comment,
      Inbar

  2. Sebastien

    21 Nov 2016 - 1:32 am

    Great summary and I love the idea of the simple version of the big picture. When printing a copy and putting on the wall, most people do not have time to go through the details. A simpler version will increase the level of penetration for those who are hooked when looking at the picture. Counterintuitive but true. Good work!

  3. John Leon

    28 Oct 2016 - 9:40 am

    Having just learned of Essential SAFe, I was wondering about something. System Demos are on it, but the System Team is not. Are there words in the description that talk about how the System Demos are supposed to happen with no System Team to drive it?

  4. Jussi Järveläinen

    25 Sep 2016 - 10:42 pm

    Great article! I’m starving to get the actual essential SAFe material with a clickable map and also the background materials (that open by clicking) should be IMHO downscaled to the Essentials. This could be done in two dimensions:
    – downscale steps, requirements and details that are not necessary in essential safe
    – remove (or provide two versions) all unnecessary background text, motivation talk, “nice words” etc. but just list the facts and actual instructions

    Of course a very large task to do…

  5. STEFAN KUEFFER

    20 Jul 2016 - 8:19 am

    Hi Alex

    Essential SAFe is of great value even for large companies that start launching SAFe in smaller entities. Based on feedback from client contacts that realize hardware, embedded software and IT systems we suggest to include the following also on the Essential SAFe Big Picture and Program Spanning Palette:
    – Release Management
    – Roadmap
    – Metrics
    – Milestones
    – Release Any Time
    – Develop on Cadence
    – Goals
    – SW, FW, HW shall be showed on the Agile Team

    These are all practices that are anyway performed in complex product development even in an essential setup. Hence, guidance based on Essential SAFe for those practices is of help and will not add complexity.

    Looking forward to the first edition of the guidance article for Essential SAFe.

    Thank you and best regards, Stefan

  6. Rob Hoover

    07 Jul 2016 - 8:17 am

    Great post. By the way I agree with keeping this maintained. You should call it “The Little Picture” or “The Small Picture” 🙂

    • AlexYakyma

      08 Jul 2016 - 10:06 am

      Thanks Rob. Sounds great but one problem with that is that we used to have “Little Picture” for an extended view of the team process. But we took it down eventually, so it may be an interesting idea, for sure.

  7. Ann Konkler

    05 Jul 2016 - 4:04 pm

    Thanks for publishing this, Alex and team! It is going to make coaching and training so much easier to digest.

    Would really love to see this as the “back side” to the laminated Big Picture we handout in class. Perhaps it can replace or be featured beside a shrunk down representation of “Implementation in 1-2-3”?

    • AlexYakyma

      05 Jul 2016 - 5:16 pm

      Thanks Ann! One way or the other, it wouldn’t be bad if this picture appeared in the SA and SPC class, for sure. I would agree that it represents an easier way to digest…

      Our next series of tests will be around further use-cases like that.

  8. Ramesh Nori

    29 Jun 2016 - 12:16 pm

    Alex

    This is really the best way to get stakeholder participation based on the concept of “Aim small so you miss small” – My team picked it like fish to water due to it’s easy of understanding and also the way it is simple and not so over whelming for newbies.
    Thanks again for sharing

    Ramesh (Florida)

  9. Donna Reed

    27 Jun 2016 - 3:00 pm

    @Alex – thank you so much. I appreciate this discussion more than I can say – it validates what I’ve been doing for a few years – but wasn’t sure I could call it SAFe at those clients.

    When dealing with medium sized programs/projects with 2-3+ teams…it didn’t matter the size of the company. They could easily relate to and jump on board the Essentiatial-SAFe Train….adding the planning they needed across multiple teams.

    The PI, RTE, and Program Level were critical for success.

    A suggestion to consider is adding Scrumban Teams and maybe even their proprietary methodology teams (only if they can work with the cadence of the ART). I also agree with @Samir about adding Metrics and Milestones.

  10. AlexYakyma

    27 Jun 2016 - 11:07 am

    @Samir: thanks for your feedback. We did. We had quite a few things we wanted to keep there but decided against it and overall are trying to keep it as lightweight as possible. The lighter it is, the easier it is to articulate the main points, and that’s been the goal we pursued with Essential SAFe.

    As per other objects in particular… We see implementations without System Team which automatically makes it part of context-dependent constructs. Milestone – similar picture with those. In fact, most of the important learning milestones are already in the picture – those are the PI boundaries.

    Now, there are plenty of practices and different context suggest different configurations. That’s why it is critical to keep the “core” as slim as possible, a minimum viable set.

  11. Andrew Long

    27 Jun 2016 - 7:52 am

    Somewhere it should probably be articulated what are the essential preconditions to consider using SAFe (whether that be Essential SAFe, or 3 or 4 level SAFe)?

    I would argue that a key precondition is an organization has a value stream of sufficient size or scope that it requires a collaborative approach that combines the effort of, say, 4 or more Agile teams. Once you have that, there’s a coherent reason to adopt the ART concept and its associated Essential SAFe success practices.

    Still, I’ve also seen quite a few clients who have (or want to have) a large number of Agile teams, but the IT organization serves multiple small value streams (i.e. lots of different customer sets with different and emergent ad hoc needs) with few significant interdependencies (assuming they are set up as Feature teams). and which largely negates the need for things like Program Increments and PI Planning. Yet since there is a strong emphasis on gaining efficiencies from coherent architecture and tool/design reuse to lessen sustainment costs, there’s a lot to like about SAFe’s concepts for Architectural Runway, the System Architect Role, Capacity Allocation, Program Backlog, Epic Kanbans, Synchronized Cadence, etc.

    So, do we not call that approach a “safe” version of SAFe because we are foregoing PIs and PI Planning? In contrast, I would argue that is a “safe” approach that adopts much from SAFe, but is not SAFe because it’s technically not an ART operating on a PI cadence.

    At some point we need to explicitly define the sine qua non of SAFe and build from there, no?

    • AlexYakyma

      27 Jun 2016 - 11:53 am

      @Andrew, thanks.

      It’s a fair point. Discussing applicability criteria is important. Two agile teams do not need to use all ART practices, but rather a subset thereof. That’s right.

      Now, speaking of applicability, SAFe was built for value streams that are big enough and therefore require the notion of ART and a few other things. That’s our base. When we talk about SAFe implementations, we assume certain scale, including the implications for value streams. And yes, it assumes that the nine items in the blog post are the sine qua non of SAFe.

      Now, to be accurate, when we say that the value streams are big enough, it doesn’t mean that they must be as big as ART size suggests (50-125) to justify the use of the ART construct. The value stream article (http://www.scaledagileframework.com/value-streams/) describes the three key cases of realizing value streams with ARTs, one of which assumes smaller value streams. We’ve seen quite a few such implementations. And despite the fact that they may not have any physical dependencies on each other, they share important context, same stakeholders and have logical dependencies addressing which is required from the standpoint of content and architecture consistency across the board.

      BTW, nothing should prevent an organization from simply picking a construct, say Architectural Runway, and using it to their benefit while not using other practices. It can be very useful, however that is not to be called SAFe, per se. Just like a team of six people that does daily standups cannot be called a Scrum team, even though such a daily checkin will really add value to their way of working.

  12. Samir Penkar

    25 Jun 2016 - 6:42 am

    There have been a number of medium sized companies who have been interested in looking at SAFe. Many of them have been coming to the SAFe Agilist classes I have been teaching. For these companies who are typically product focused and have smaller – maybe 3 teams – Essential SAFe provides the focus and clarity they need. One suggestion is consider adding Sys Team, Roadmap, Metrics and Milestones to the palette.

  13. AlexYakyma

    24 Jun 2016 - 2:16 pm

    Thanks guys. That’s the intent, it’s a simple footprint that underlines the key practices that matter to a SAFe rollout. It’s really easy to use to articulate what matters the most and when we need more, we always know where to go.

  14. Dwayne Stroman

    24 Jun 2016 - 8:09 am

    Great guidance Alex. I’ve used similar to this ‘Essential’ footprint (calling it SAFe Lite), and have found that the lower overhead allows SAFe to be used successfully with smaller virtual organizations. 2-3 teams can benefit greatly from this Essential pattern.
    I especially appreciate the Principles being the first item on the list. Without these, the rest are just practices that can lead us the wrong direction.

  15. Daniel Miklusicak

    23 Jun 2016 - 9:41 pm

    Thanks Alex, and also to all who contributed. This will come in very handy at my current engagement with JCI in Milwaukee!
    Dan

Leave a Reply