A Real-World Roadmap for Rolling Out Agile Transformations

This case study describes an actual roll-out of an Agile Transformation across 7 product lines, and 18 scrum teams in a local commercial organization. It maps out 4 levels of industry best practices, and describes what techniques worked, why some techniques failed when they were introduced, and what other techniques had to be mastered before they could be re-introduced.

We will also talk about assessment models, and give examples on how to design good metrics for each level of performance. At Level 1 we have 6 core metrics that all teams must report. When the teams start Level 2 we ask them to design their own metrics, based on their products’ business models, to show how they impact income, overhead, strategy, and risk. When teams reach level 3 they are ready to start advising executives on corporate strategy, with a track record of proven performance.

To motivate teams we’ve mixed in several elements of gamification (rather accidentally, to be honest), that inspire teams to complete their assessments, “level up”, and engage in healthy competition. But it’s also not a winner-take-all culture. We leave room for multiple teams to receive rewards and appreciation for their unique achievements across 5 different performance categories.

The design of this Agile Transformation program is based on the principles of Teal Management, drawing on techniques from DevOps, Lean Startup (R), SAFe (R), and more, and combined with practical, real-world techniques, honed over years of practice. (You do not, however, have to be a “Teal” organization to use this model. Rather, this program is a map of “the road to Teal”. And while Teal Management will be referenced in this case study, it will not be talked about in depth.)

An Agile Transformation is very difficult. We found that each team needs to travel at its own speed, and one size does not fit all. This case study is how we make that happen, show appreciate for the uniqueness of each team, and ensure consistent, measurable, overall success.

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

Outline/Structure of the Case Study

This presentation will be a case study of an actual team rollout, involving 7 product lines and 18 scrum teams, in a scaled agile (though non-SAFe) environment. I’ll present the theory behind the design of the rollout (15 minutes), a walkthrough of how the rollout has gone to date (15 minutes), followed by audience questions.

The way I introduce Agile transformations to teams is the same way that I plan to introduce this case study. Imagine a new team member starting work, who not only has never worked at your company, but who has never lived or worked in that area. Would you ask them where to go for lunch, and say, “You’re driving”? Of course not. Typically, someone takes that person under their wing, invites them out to lunch, and shows them all the good places to eat. We don’t expect them to have instant knowledge. After some time, once they know their way around, they can now drive to lunch. And only after they’ve developed some expertise in the local cuisine will you ask them to pick a new restaurant to go to for lunch.

The same approach needs to be taken with an Agile Transformation. Teams need to first be introduced to new concepts and coached until they understand why we use those techniques. (It’s the same reason why the experienced person drives to lunch in stage one.) Once they understand why, then we can let them drive. We switch over to giving them goals, and letting them choose how to achieve those goals. (The equivalent of “Shall we get Thai food today? Do you want to drive?”) And only after a time period of successfully achieving business goals do we then allow them to suggest and alter what the goals of the organization look like. (This is akin to listening to them when they say, “I found this spectacular new Southern Indian restaurant that I think you’ll really like.”)

To achieve this progressive learning I have outlined 4 levels of Agile techniques for teams. Level 1 techniques must be mastered before Level 2 techniques can be rolled out. Level 2 mastered before Level 3, and so on. These techniques are a collection of industry best practices, organized into their levels by the principles of Spiral Dynamics. (Spiral Dynamics is the source material for “Teal Management” as defined in Frederick Laloux’s book, “Reinventing Organizations”.) It is based on 40 years of research by a gentleman named Claire Graves, a researcher who studied the interaction models of different societies throughout the world, and found that they always followed a consistent, progressive pattern. Agile teams also follow this same progressive pattern of understanding and cultural development. Each time I have seen a technique that has been introduced and failed, it is either because the technique was too far above the level of understanding of the team, or too far below it. Introducing the right techniques at the right time makes a huge difference!

Level 1 techniques are the basics of Scrum and Agile, like User Stories, Story Splitting, and Planning Poker. They are prescriptive, and in some ways yes, you kind of don’t have a choice on whether or not to do them. Once a team has done the technique I wait to see that moment of understanding, “Oh! I see! It’s not that we *have* to do Planning Poker, but we do *have* to discuss a story and seek input from our peers before we can call a story ready. When we don’t, we are surprised by unknowns in the middle of the sprint.” When I hear this I know they are now ready for Level 2 planning techniques, which may or may not include Planning Poker. Measurement for Level 1 is basic: Are you doing the techniques? What is your story count velocity? Do you deliver the story points you promise? How fast can you close impediments?

Level 2 techniques are goal-based techniques. We have our executives give the teams a goal, and they tell us how to get there. These include techniques like prototyping, MVPs, automations, and Roadmapping. Teams in Level 2 are also asked to design the metrics that show that they are achieving their assigned business goals. Executives then track the team against those metrics. Executives handle the “Why”. Teams decide how.

Level 3 techniques are where we give teams a chance to influence the executives and corporate strategy. It introduces more-advanced Customer Discovery techniques from the Lean Startup movement designed to develop and validate new business models, plus Continuous Delivery techniques from the DevOps movement to ensure smooth, quick, tested deployments of micro-user-tests. At this stage, the teams again are asked to design their own metrics, but must decide what those metrics will be before they begin any new engagement.

(Level 4 techniques I will not talk about, because no one in this audience will be ready for them. And almost no one ever asks about them, or even remembers that there are 4 levels. It’s kind of like an Easter egg for those the one or two that do ask.)

One advantage of this system is that teams are allowed to evolve at their own pace. It doesn’t matter in which order they tackle techniques from Level 1. Some teams will master the Design and Development techniques first, and struggle at the Planning or People techniques. Other teams will excel at the People techniques, but struggle with the Development techniques. But once they’ve mastered about 75% of all of the techniques, the team is ready to start employing Level 2 techniques, building on their Level 1 knowledge.

The second advantage of the system is that it (non-intentionally) gamifies the Agile Transformation. Scrum teams see the levels, and see that management sees the levels, and are correspondingly naturally motivated to put a check mark in every box. It creates a “pull” system for the Agile coaches, as the teams reach out to learn how to earn a check mark in each box and “complete the set”. I have found that teams also like to “level up”. Low performing teams don’t want to be on the bottom, and high performing teams want to have more checks at the higher levels than other teams. We also get to reward Team A for being the leader in advanced Customer Discovery techniques, and Team B for being the leader in Automation. Every team evolves. Every team evolves at their own pace. Every team evolves according to their strengths, while also being held accountable for their weaknesses.

Learning Outcome

  • A practical method for deploying an Agile Transformation
  • A method for allowing teams to evolve at their own pace
  • A gamification method for inspiring teams to grow and reach out for help.
  • A detailed map of multiple possible techniques your teams could try.
  • An map of which techniques your teams may or may not be ready to use.
  • (What Teal management looks like in an organization that isn’t ready for Teal.)

Target Audience

Executives, internal coaches, and Agile Program Management Offices (Agile PMOs)

Prerequisites for Attendees

None

schedule Submitted 9 months ago

Public Feedback

comment Suggest improvements to the Speaker
  • George Dinwiddie
    By George Dinwiddie  ~  9 months ago
    reply Reply

    The abstract and outline/structure of this tell me little more than that it's a case study.

    The abstract is the place where you sell your session to the right prospective attendees. Help them recognize themselves and their situation, and tell them what benefits they'll get by attending. Give them enough information about the content to convince them that they'll get that benefit.

    The outline/structure is the place where you sell your session to the reviewers. Help them recognize that you'll deliver on your abstract. Give them details about the content and the way that you'll present it to convince them that you'll do a good job.

    See also https://threadreaderapp.com/thread/1028714041349263360.html for an independent description of submitting a successful proposal.

    - George, AgileDC Program Chair

    • Pete Oliver-Krueger
      By Pete Oliver-Krueger  ~  8 months ago
      reply Reply

      Updated this case study with a lot more information for both the attendees (in the Abstract) and the reviewers (in the Outline)! Let me know if you need me to provide any more clarification.

      Thanks!


  • Liked Roland Cuellar
    keyboard_arrow_down

    Roland Cuellar - Experience Report: Agile and Lean UX Techniques for Hardware Development

    45 Mins
    Case Study
    Advanced

    Experience Report: Applying Lean UX to New Hardware Development

    We often hear how Agile and Lean UX techniques are applied to software development, but there is much less information available on how to use these same ideas to develop new hardware solutions.

    In this experience report, Matthew Maddox, VP of Digital Strategy at Mirion Technologies and Roland Cuellar of Lithespeed will show how Lean UX techniques were successfully applied to the design of new and highly complex integrated hardware and software products.

    Mirion makes complex, highly regulated equipment that is focused on radiological safety for national security, first responders, and nuclear power. Mirion’s radiation detection equipment is used to protect people from radiation exposure, secure major events, and track down illicit radiological sources. Over the past year, Mirion has been experimenting with agile and lean UX techniques to design it's next generation radiation detection hardware and software.

    In this experience report, we will hear how Matthew utilized rapid, lightweight, lean UX techniques to quickly develop hardware prototypes, gather feedback from past and potential new customers, and quickly pivot initial designs based upon feedback from customers.

    As a result of this important process innovation, Mirion is now embracing more modern digital and agile techniques to more quickly bring innovations to market that are more closely aligned with customer desires.

    Matthew Madox is the VP of Marketing & Digital Strategy, and lead the field research, primary design and customer validation phases of the next generation Personal Radiation Detector (PRD).

    Topics Include: Agile Hardware Design, Lean UX, Hardware and Software Design Integration, New Product Development, Engineering Culture Change