The Scaled Agile Framework for the Enterprise (SAFe) is a framework designed to bridge the gap between agile at the team level and business objectives and initiatives. There are times when this linkage works well and other times when, well, not so much. In this case study, we'll talk about the experience I've had coaching different teams in the enterprise on an Agile Release Train with multiple planning events. I'll talk about the challenges my teams experienced during the PI Planning event. Sometimes things don't work quite a easily as they've been advertised, but sometimes they work even better than expected. We'll also discuss some "do's and don'ts" about running an Agile Release Train, including a review of the SAFe assessment tool, and what to expect.

 
2 favorite thumb_down thumb_up 3 comments visibility_off  Remove from Watchlist visibility  Add to Watchlist
 

Outline/structure of the Session

  • Introduction (2 mins)
  • Overview of the SAFe Framework (5 mins)
    • What is SAFe?
    • What's an Agile Release Train?
  • Case Study (20-25 mins)
    • Overview of the Agile Release Train teams
    • PI Planning summaries
      • What worked
      • What didn't work
  • SAFe's ScrumXP Assessment Tool (3 mins)
  • Do's and Don'ts (5 mins)
  • Close-out (5 mins)

Learning Outcome

  • Understanding of SAFe and the Agile Release Train
  • Things to watch out for when adopting SAFe
  • Tips for running a successful ART

Target Audience

Executive, manager, developer, tester, product manager, business analyst, system analyst, architect

schedule Submitted 1 year ago

Comments Subscribe to Comments

comment Comment on this Proposal
  • Prasad
    By Prasad  ~  1 year ago
    reply Reply

    Hi Bill,

    thanks for the proposal, there is lot of awarness of SAfe genraly in the community, it will be apt if we can cover more experinitial oriented details of few areas.

    ~pras

    • Bill DeVoe
      By Bill DeVoe  ~  1 year ago
      reply Reply

      I did update the proposal overview above to clarify that I'm specifically talking about the challenges the teams experienced. Thanks!

    • Bill DeVoe
      By Bill DeVoe  ~  1 year ago
      reply Reply

      This is definitely experiential - it's a case study of the group that I'm working with right now. I didn't file it under Experience Reports but did plan to cover a particular engagement and what's worked/not worked, especially during the PI Planning process. The overview/background material is at most 5 minutes reviewing the framework to provide context on what I was going to cover. Hope that clarifies a bit of the intent here.


  • 90 mins
    Workshop
    Beginner

    Getting good information about how your teams are doing can be challenging. There are some very traditional metrics that we use in Scrum to see team progress, but are you getting the entire picture? Are your teams actually doing badly but you can't tell? Where can they make some improvements? Your metrics should be able to tell you - at a glance - what's going well and what's going badly.

    In this workshop, we'll review, discuss, and create several different metrics you can use to track your team's progress. Are they on track? Are they lost in the weeds? What kinds of metrics are most useful for the kind of agile methodology your teams are using? For instance, Kanban requires a whole different way of measuring team accomplishments than Scrum. After taking this workshop, you should understand the different kinds of metrics, which metrics are most useful for which methodologies, which metrics you aren't using will help identify anti-patterns, and how to identify teams that are on track or off the rails.