First Thing’s First: Essential SAFe?

First Thing’s First: Essential SAFe?

Essential SAFe SAFe Updates

In recent customer visits and SPC classes, we see and hear about various applications of SAFe, and we address many of the common questions that affect enterprises adoption everywhere. One of those questions (which might seem to be in even greater frequency with the launch of the expandable 4.0), is “but what do we have to do to assure the SAFe benefits. All of it? Some of it? And if some, which parts?”  And as we know, while the consultants answer of “that depends” is usually correct, it isn’t always helpful.

SAFe is a framework. That implies a degree of flexibility in applying the practices in a specific enterprise context. But it is also a system. In a system, the whole is the greater than the sum of its parts, and you can’t just grab a component practice, and hope you get all the benefits. So the question is:

What is the minimum subset of practices beyond which SAFe isn’t safe?

To address this, in the last SPC class we took some time to define specific practices that represent the “must have” for every SAFe implementation. We quickly realized that the best way to this is via a graphic (duh) that contains the essential aspects of elements. A few days later, we had the following graphic to test with the class. It was well received, so we offer it below:

Essential SAFe
Figure 1. Essential SAFe. If you don’t do this, you might not be.

Here is a summary:

1. The Foundation includes Lean-Agile Leaders, Core Values, a Lean-Agile Mindset and SAFe Principles. Any transformation is unlikely to be successful unless it is grounded on educating management and key stakeholders so they can lead, rather than follow, the transformation.

2. Teams apply Scrum and/or Kanban, and rely on Built-in Quality practices to frequently produce fully integrated increments of value. They power the train. There can be no Agile enterprise without Agile Teams.

3. Vision and Program Backlog provide alignment.

4.  Some Roles are critical. We rarely see successful ART execution without the minimum roles of Product Management, System Architect, RTE and Business Owners. Product Owners and Scrum Masters help the teams meet their objectives.

5. Cadence is the heartbeat of every SAFe enterprise. A PI and Iteration cadence (you pick yours) is mandatory.

6. Key program events are a “must”, too. There’s no SAFe without PI Planning that involves the entire train and results in team’s commitment reflected in their PI Objectives. The System Demo provides the ultimate measure of the train’s iterative and incremental progress. Inspect & Adapt provides a venue for comprehensive review of the PI outcomes and systematic improvements.

7. The IP Iteration is like extra oxygen in the tank: without it the train may start gasping under the pressure of a plan that forgives no mistakes, nor provides dedicated time for innovation, not to mention dedicated time for routine PI Planning and Inspect and Adapt.

8. Some Architectural runway provides “just enough” enablement to sustain development velocity over time.

This is the Essential set. Eight things (depending on how you count!). If you implement these, you are on the right track. Then you can further reason about the rest of the practices, roles and constructs, whether they are Team, Program, Value Stream, Portfolio or enterprise. Additional business and personal benefits are sure to follow.

We see this as a particularly important topic and we value your opinion. Please provide feedback in the comments to this post. Who knows, maybe this essential content will make it into some future version of SAFe.

Thanks and stay SAFe, at least essentially.

— Alex and Dean

Author Info

Alex Yakyma

SAFe Fellow and Principal Consultant Alex Yakyma is a methodologist, trainer, and consultant who has been applying Lean and Agile practices in the software industry for over a decade.

comment (23)

  1. Shane Bowman

    03 Nov 2016 - 6:55 pm

    From little things big things grow.

  2. Lloyd Martin

    23 Mar 2016 - 8:55 am

    Excellent summary of an “MVP” for SAFe. This will prove to be a great tool as I transform teams to scaling.

  3. Richard Lindley

    03 Mar 2016 - 1:53 pm

    this is a very valuable definition of the guard rails for getting value from SAFe. it often makes me cringe when I read or hear people casually discarding parts of the framework because ‘it’s just a framework’; you can’t still call it a salad if all have is a bowl of dressing and bacon bits

    • Richard Knaster

      03 Mar 2016 - 2:10 pm

      Hi Richard:

      Thanks for your feedback and we’re glad that you find it useful. Good analogy, it’s visceral and easy to understand.

      Richard Knaster
      SAFe Fellow, Principal Consultant

  4. James Janisse

    29 Feb 2016 - 7:03 am

    I will try to use these as the basis of some form of Essential SAFe score card for our teams. Many ARTs say they follow SAFe, but if you scratch below the surface you sometimes see they follow the motions and the ceremonies but they still work “the old way”, dont trust teams, keep centralised control etc

    • Richard Knaster

      29 Feb 2016 - 9:29 am

      Hi James:

      Good point. The key is relentless improvement through team retrospectives and the inspect & adapt at the program level. Did everyone on the train go through training? Trains that have not trained everyone often experience the problem you mentioned.

      In addition or instead of a survey, perhaps these trains needs some additional coaching. Doing a “go and see” (gemba walk) it often is the best approach. For example: observe the trains during PI Planning, System Demo and Inspect & Adapt as a starting point. Visit the teams and ask them questions about the adoption of SAFe, problems they are having and ask how you can help. It also takes people a while to go from knowledge to understanding. A great and fun video that I like to play to illustrate the difference between knowledge and understanding is https://www.youtube.com/watch?v=MFzDaBzBlL0.

      On the SAFe website we provide several self-assessments at no charge: SAFe Team Assessment and Agile Release Train Self-Assessment. Please see the metrics article: http://www.scaledagileframework.com/metrics/

      Lastly, what is prompting your concerns? Are you not getting the results that you want, or is something else driving your concerns?

      Regards,
      Richard Knaster
      Principal Consultant, SAFe Fellow
      Scaled Agile, Inc.

  5. Jiten Kumar

    26 Feb 2016 - 9:34 pm

    Thanks Alex and Dean.
    Yes this is essential set of eight things. There are minimum number of acceptance criterias of SAFe to be safe.

  6. Pranay Chanda

    24 Feb 2016 - 8:16 am

    Appreciate the concise representation of what is the minimum viable change that needs to be incorporated to realize the benefits of SAFe.

    I constantly get this query from my clients around what is the minimum that we need to implement at Portfolio, Program and Team levels in SAFe.The program and team level seems to be clear to me.

    What do we preach to the client as minimum for Portfolio including the constructs and roles?

  7. Ramesh Nori

    19 Feb 2016 - 11:25 am

    This is great information – is there a way to download high res poster of the Essential SAFe version ?

    Thanks
    Ramesh

    • Dean Leffingwell

      Dean Leffingwell

      23 Feb 2016 - 8:53 pm

      Thanks Ramesh,
      Not at this time. This is just a spike for now, but we are considering just such an option.

  8. Arnaud LHOTE

    17 Feb 2016 - 8:50 am

    Thanks for the guidance.
    When I think of a Minimal Viable Product for SAFe in a traditional environment I try to reduce it further to focus on what I want to achieve.
    Is it Trust ?
    Is it Alignment ?
    Is it code Quality ?
    Is it Time to market ?
    Is the organisation ready for self organising Teams / Team of Teams ?
    Is the organisation prepared for a shift from project thinking to Value/Risk thinking ?
    Based on the answer to those question I would try to prove some assumptions first and gain traction in the organisations before moving towards adding the remaining points quicker or slower.

  9. Carl Vikman

    15 Feb 2016 - 12:46 pm

    Really good stuff Alex!

  10. Peter Pedross

    15 Feb 2016 - 9:43 am

    Addendum to my last comment, I miss the Enablers on the program level of Essential SAFe. In my understanding it is a must for having an Architectural Runway.

    • Dean Leffingwell

      Dean Leffingwell

      23 Feb 2016 - 8:57 pm

      Thanks Peter,
      Some things we just have to assume. For example, a Release, Shared Services, etc. We didn’t carry Enablers into Essential, because we they are not a simple, because we “assume” a smallish program would do those naturally. But it’s a good point and others have commented the same. And “the paint is not dry”.

  11. Peter Pedross

    15 Feb 2016 - 8:00 am

    This is great news and very much appreciated! … and a lot to think and consider.
    Essential SAFe eases the access to start with SAFe and we are actually about to design/ build it into Applied SAFe. On the program level most of the things seem to be straightforward. I would like to hear more about what, or what not, should happen on the portfolio level. The picture shows several Value Streams, i guess it implies that each value stream contains exactly one train.
    We are thinking about having an Essential (Program) SAFe even within larger organizations; where new to SAFe departments just start with Essential SAFe Program Level and other departments already work with a full blown 4-Level SAFe configuration. Do you have any thoughts on such a setup?

    Thanks for bringing this up!
    Peter

  12. Nick Clare

    12 Feb 2016 - 10:07 am

    As this is a question of what is the minimum common set of practices (etc) which are common to pretty well all SAFe adoptions, I think it’s worth bearing in mind that (almost) no SAFe implementation will adopt ONLY this set. I see an attendant risk that this will be seen as a “SAFe LITE”; do this and you’ll be okay, which I think will be an extremely dangerous assumption.
    I think its purpose is different: it is just to show what are the minimum characteristics that most/all SAFe adoptions will share. That helps understand the essence of SAFe, and could also help in targeting the most effective areas to start in. But is it all you’ll ever need, well probably not, not even from Day 1. But the bits you may need will differ according to the context of your organisation, business, technology, products, systems and solutions.
    Some specifics:
    • Would expect to see enablers still; unless it’s intended as a simplification that an enabler is just a special kind if feature;
    • Feels like it should mention Value Stream somewhere (maybe as tag on the train graphic?); as value streams are always present and ARTs are always based on them.
    • Not sure I’d include Business Owners in an essentials set – at leaset not as separate identity. Content Authority and Vision through program management can drive an ART pretty well (hence they implicitly carry the business ownership in them).
    • If Release Management aspects are all subsumed into the RTE essential (or into Product Management) then that’s okay but Release Management is a crucial aspect and it feels a bit uncomfortable without it..
    • A subset of metrics should probably appear to reinforce the central ideas of factual tracking and frequent feedback.

    • Dean Leffingwell

      Dean Leffingwell

      23 Feb 2016 - 9:04 pm

      Thanks Nick,
      Good points. Let me comment:
      – re Release Management. Many modest size ARTs can integrate that function, or we otherwise assume it is handled somehow.
      – we kept the BOs, because otherwise you can’t close the loop with business value and PI predictability.
      – we assumed the Customer, but I think we need to bring that back; the assumption that the customer is fully integrated in the value stream does not always appear to be true.
      – agree on the missing label for Value Streams; need to add that
      – Enablers, a good debate for sure. TBD
      – Metrics. again, can we assume an ART can mange that without our prompting? Not sure.

      I agree with the gist of all your comments. But we didn’t want toEssentials to just be the program level as is; we are trying to really boil it down to the “must haves”. The simplest possible effective starting point for an ART. But what you “must have” is a matter of option, not method or policy.

  13. Vikas Kapila

    11 Feb 2016 - 9:24 am

    Thanks Alex and Dean. This is a great summary and helps me have a more specific conversation rather than a custom conversation.

    I would say that the Foundation needs to include the Implementing 123 as most of the things called out in the article @ http://www.scaledagileframework.com/implementing/ is very helpful and needed for implementations following the above guideline. Please consider adding Implementing 123 to the Foundation of Essential SAFe as a guideline

  14. Jennifer Fawcett

    Jennifer Fawcett

    11 Feb 2016 - 7:09 am

    Just tested this in Tallinn, Estonia with some potential new Finnish, Dutch, and Belarusian SPC’s.

    Here is their feedback:
    –It’s missing the Customer
    –It’d be good to show at least the portfolio backlog for alignment and flow
    –Nice and simple
    –Definitely a need for the simplification
    –The Essential 8 helps! (Kinda like the Fab-4)
    –Helps with avoiding overwhelming folks
    –Allows for focus
    –Could add another “spanning” icon to show “Essential SAFe”
    –What about CI/System Team/DevOps?
    –Like Built-in Quality
    –Love the Arch Runway
    –Like PI and I&A called out
    –Maybe to add simplification, only show one team (we’re showing two, but that’s implied)
    –Enablers aren’t called out (both positive and negative around this)
    –In Implementing SAFe, when teams are creating their SAFe message and presentation, this could be a good visual to start with
    –Implies Train everyone/Launch Trains, but perhaps an icon to show that
    –Portfolio shows budgets, but does that imply that you have to implement lean-agile budgeting?
    –Maybe show the # of people in the train (dunbar’s).

    They LIKED IT! Thanks for this Dean and Alex!

  15. Mike Entzminger

    10 Feb 2016 - 1:11 pm

    This is a prefect depiction of this same conversation that I’ve also had with clients implementing SAFe. The strength of the framework allowing for interpretation and adaptation into any company/enterprise is also its weakness, in terms of misinterpretation by some folks. This leads to introducing some elements of the framework (e.g. RTE), while choosing to skip implementation of the most key/essential ones (e.g. ensuring all teams are truly agile/Kanban), and still claiming to have “implemented SAFe”.

    Thanks for bringing forward this reference as another guide!

  16. Wilbert Seele

    10 Feb 2016 - 3:35 am

    Thanks for the post Alex, this confirms a lot of things I thought.
    The one thing I see in the picture, but not in the text, is the explicit alignment of an ART to a value stream, and funding going directly into that value stream. A localized train is a pointless train.
    Yet local trains (so within a department) are still a very common antipattern, at least here in the Netherlands.

    • Dean Leffingwell

      Dean Leffingwell

      23 Feb 2016 - 9:08 pm

      Thanks Wilbert,
      We simple considered portfolio considerations, like funding, to be outside the scope of Essential. No matter how it’s funded, 50-100 cross functional people can deliver a lot of Value. It may be localized to the program level, but we’d guess they would mostly know what they are doing and why. That’s what makes it a Value Stream.

  17. Erik Schumann

    09 Feb 2016 - 1:14 pm

    Thanks Alex and Dean!
    Great summary and food for thought. This will be useful as a discussion starter with certain clients.

    What I am missing is what is happening prior to the ART. How is the content for the backlog picked? How can we adress the invisibility and bottom up approach to architecture and enablers? How can we include and track work that spans mre then one PI?Enters epics, enablers and epic kanban system. For me these are essential even in a reduced context, since they add so much on top of just a scaled scrum of scrums approach.
    Just my 2c. I am sure you have had that discussion or something in that direction, so I would love to hear your reasoning and understand why you decided to skip them.

    Thanks for sharing.
    /Erik

Leave a Reply