Can you be safe with SAFe?

Can organizations implement SAFe safely? There are many organizations attempting to scale agile practices to a large number of teams and teams of teams. As I'm sure you know, there are many competing frameworks that are available to help in this regard (SAFe, Disciplined Agile, Nexus, LeSS, S@S, etc.). If you read the blogs, you've seen lots of folks talk about concerns they have with SAFe being too big or prescriptive or . Rather than survey all frameworks, this session will focus on the Scaled Agile Framework (SAFe) and provide practical tips and tricks for how organizations have successfully implemented it minimally, incrementally, and pragmatically without experiencing the potential risks you might have read about.

The session will cover practical tips, tricks, examples, and approaches to implementing SAFe in a way that helps ensure the success of your agile transformation.


Outline/Structure of the Talk

1. Bio

2. Industry concerns relative to SAFe

3. Responses to industry concerns

- With examples, tips, suggestions on how to mitigate/avoid the concern

4. SAFe success stories

- Short case study-like summaries of successful implementations

5. Summary

Learning Outcome

1. Appreciation for the concerns expressed by the industry relative to SAFe and how to mitigate them

2. Practical, pragmatic tips and tricks for successfully implementing SAFe

3. Results you might expect if you follow the advice

Target Audience

This session is for people who have heard about or have been using SAFe to drive large-scale agile transformation and feel its too big, too complicated, too much, or too whatever. Everyone from practitioners on teams to executives will benefit.

Prerequisites for Attendees

Participants should have some working knowledge of SAFe as a foundation to understand some of the examples that I'll discuss. I don't plan to cover the basics of what SAFe is given the time box.

schedule Submitted 1 year ago

Public Feedback

comment Suggest improvements to the Speaker
  • George Dinwiddie
    By George Dinwiddie  ~  1 year ago
    reply Reply

    Ken, it would be helpful for the reviewers if you would share with us the examples, tips and suggestions you recommend to make SAFe safe. C.f.,

    • Ken France
      By Ken France  ~  1 year ago
      reply Reply

      Thanks George.  Some content I plan to include (can't provide slides yet):

      1. Overall message: remember it's a framework not a prescriptive process despite what you might read.  Relay on the 9 principles that drive SAFe as opposed to blindly focusing on the practices.  "Conformance" to SAFe is NOT the goal. 

      2. Understand the particular mechanism in SAFe and apply it when you're having the problem the mechanism is intended to address (e.g. Program Increment, System Team, Large Solution level components like the solution manager, capability, solution intent). 

      3. It's not an "all or nothing" at each level of the framework.  This is a variation of #2 but you don't have to use all the mechanisms at each level if you don't need them.

      4. I'll give examples of 1-3 from various clients like Capital One, T Rowe Price, and Travelers.

      5. Strive for "better than yesterday" vs. perfection.  You don't need to be doing SAFe "perfectly" to get the value from it.   Incremental improvement is key.

      6. The SAFe implementation roadmap is a theoretical ideal path.  I've found that often the best place to start is go right to getting the first ART up and running and then later circle back to value stream identification and mapping once there's some appreciation for the framework and the benefit in organizing around value.

      7. You don't need to fund value streams instead of projects (epics) to use SAFe.  You can still organize teams around value and establish them a long-standing teams/trains without fully changing your funding model.  Instead, you can continue to fund the work in the form of epics and then keep the standing teams/trains funded by flowing sufficient work to them to keep them funded.  They can still charge the appropriate charge code based on what they are working on and thus giving the full closed loop tracking process they have for projects without having to continually go through he Tuckman stages for the team.

      8. Demos: there are team, system, PI, large solution system, large solution PI demos in the framework.  You don't have to do every single demo at every single level.  Go back to the principle of why all the demos exist: to show concrete integration and progress at multiple levels.  You can achieve that by combing demos or maybe doing them less frequently initially until you get more mature.  

      9.  Timebox enabler work: some feel all discovery/analysis/design can happen inside the sprint, that doesn't really scale but there's risk that we fall back too close to waterfall as well if we do too much up front.  Use clear definition of ready and time boxed enabler sprints just ahead of when you'll be implementing the associated work coming out of the enabler work to ensure you are not getting too far ahead and then you are asking those up front people to produce PI ready features or sprint ready stories on a regular cadence and at a pace where teams/trains can consume them quickly thereafter.

      That should give you a feel for what I'm going after in the session.  Basically looking to help make it more lightweight and consumable.

  • Steve Moubray
    Steve Moubray
    Agile Coach
    cPrime, Inc.
    schedule 1 year ago
    Sold Out!
    45 Mins

    How do you promote mastery of practice areas? Danial H. Pink tells us people are motivated by autonomy, mastery and purpose. Small Agile teams promote autonomy while value streams and corporate missions promote purpose. Communities of Practice can be a great way to promote mastery, if formed correctly.

    Communities of Practice are more important today then they’ve ever been before. We’ve learned cross-functional teams are the best way to produce customer focused products but as we put people into value streams and product teams, are we creating silos where practice domains don’t communicate as often and knowledge gaps are widening? There’s a reason why most Agile Frameworks recommend forming Communities of Practice.

    In this workshop we’ll talk about forming masterful communities and you’ll create a handy pocket guide to take with you.

    Come learn how to form Masterful Communities of Practice and lead your organization going forward.

  • Liked Daniel Weikart

    Daniel Weikart - Lean-Agile Leaders: A mix of action and style!

    Daniel Weikart
    Daniel Weikart
    Enterprise Coach
    schedule 1 year ago
    Sold Out!
    45 Mins

    Studies ubiquitously show that Leadership and Culture are among the top factors for a successful Lean Agile transformation. What specific actions should leaders take to structure Lean Agile transformations? How does leader style enable cultural change? This session provides 1) a practical set of actions to start or improve your transformation and 2) a specific list of behaviors to do and NOT to do in setting the right culture as a leader.