May 17, 2019
OK, you’re an RTE or an SPC in the IP iteration at the end of your Planning Interval (PI). You’re getting ready to run the Scaled Agile Framework (SAFe®) Inspect and Adapt (I&A) Workshop, and it seems a bit daunting. It’s big. It’s a bit complicated. It’s got lots of people. Maybe you’re wondering if it’s even worth it. Trust me, it is. And I promise that an I&A is easier than it seems.
The point of an I&A is to inspect both the product and process so you can make them better for the coming PI. The I&A breaks down into three parts:
1) PI System Demo – Inspect and Adapt the product
2) Quantitative Measurement – Inspect the process using metrics
3) Problem-Solving Workshop – Adapt the process
You might be asking, “Why all this rigor vs a regular retro?” Because…the bigger the groups of technology and people, the bigger and harder the problems. Imagine using a Start/Stop/Continue Retrospective to solve a complicated Delivery Pipeline issue affecting multiple teams. Your likely result would a hodgepodge of small ideas that don’t fix the harder problems.
In the spirit of Relentless Improvement, you need to take the plunge. How about a few I&A tips to put your mind at ease?
Watch On-Demand Webinar “Inspect & Adapt: A Coach’s Secrets For Optimizing Your Investment” Now
Tip #1: Make your PI System Demo exciting with a real-time simulation.
SAFe suggests a brief 45-60 minute timebox for a PI System Demo. In this time, it’s common for each development team to quickly demonstrate their portion of features, sit down, and allow for the next team’s presentation. While this style of demo allows each team to get direct credit for their work, I often find the overall presentation clunky and disjointed (not to mention…boring). So what does a better PI System Demo look like?
One of the best demos I saw was a skit put on by a Product Manager and Product Owners. In front of the entire Agile Release Train (ART) and VP Business Owners, they simulated a phone call and demonstrated the solution, just as if customers were actually using the product. When the PM/PO team finished, they credited the teams by asking them to stand up and take a bow. People clapped and cheered—even the VPs! It was an electric, ‘a-ha’ moment for everyone in the room. This type of demo became the standard for the rest of the company, and I recommend it becomes yours too.
A few things to note:
- This simulation was planned in only a few hours (not days).
- It was presented with working software, not PowerPoint.
- Because the demo focused on the solution and not the development teams, some of the component and data teams also felt appreciated.
Tip #2: Focus on the Big Picture.
You’re following SAFe Principle #4 – Build Incrementally with Fast, Integrated Learning Cycles. Every couple of weeks, you’re giving a System Demo of an integrated working solution to Product Management and Business Owners, who see and approve the individual features and explore the corner cases and error handling. They are aware of the details. So what value can you bring them in the PI System Demo? What don’t they already know?
How everything fits together! For the first part of the demo, focus on giving people the big picture and try not to get lost in specifics. Remember, you’re in a timebox! Big picture thinking allows you to solve problems quickly without dwelling on small potatoes. Thinking big will drive your success.
A few things to note:
- Make heavy use of the parking lot to keep people focused.
- Hold the Demo as close to the production environment as possible to ensure that the solution is tightly integrated and will go into production with fewer issues.
- If your environments are unstable, consider recording the Demo as a backup, then write a story or two to get your environments stable.
Tip #3: Use your metrics to tell the PI’s story.
Let’s move into the Quantitative Measurement section (Part 2) of the event, which is also suggested to be a 45-60 minute affair. The PI System Demo has given us a Product perspective. Now it’s time to take a Process perspective.
Typical questions after a PI include: “How did we do?” “Did we make our predictability?” “Is test automation on the rise?” Hint: the numbers alone don’t say anything meaningful. The key is to know the story that the metrics are telling and then using that story to provide context.
Saying “We only made 50% predictability” doesn’t mean much. Often, leaders avoid accountability and blame the teams for falling short of expectations instead of digging deeper for the real problem. If you want to find solutions that work, then you have to find the real story, or why you only made 50% predictability.
Being able to say: “We only made 50% predictability because we were working on too many things at once” is a powerful moment and gives you serious food for thought for the Problem-Solving Workshop (Part 3 of I&A). RTEs, this is a great place to serve and stand up for the train!
A few things to note:
- Sometimes people worry that Quantitative Measurement will be a big reveal of bad news. If you’ve been doing your SAFe events well and there is transparency, then this isn’t news. It’s just data.
- There is more power when the RTE, Product Management, and Architect “troika” present this section together.
- If you’re looking for what metrics to show, start with the Program Performance Metrics section of Scaled Agile, Inc’s Metrics article, or try ICON’s free ART Maturity Assessment tool.
Tip #4: Train Problem Solving Workshop facilitators ahead of time.
Let’s move on to the last part of the I&A, the Problem Solving Workshop. If this is your first time using the fishbone diagram and the ‘5 Whys,’ then you might feel some initial discomfort when using these tools. The best preparation is to practice using them beforehand and training your Scrum Masters as facilitators to help you.
Why not use the fishbone and ‘5 Whys’ for your last team retro of the PI? Your SMs learn to facilitate the retro, and the teams learn the tools. Typically, I get the SMs together for about an hour of training and level-setting. After that, I support each SM during the retros. Good preparation leads to less time churning around the tools and more excitement for solving problems.
A few things to note:
- Problem statements can be hard. Give the teams a few examples of good problem statements to model and bad problems statements to avoid.
- Problem statements shouldn’t suggest a solution.
- Focus on problems they can control or influence.
- Show the economic impact of a problem— this really inspires people to want to fix it. Most problems result in time wasted, so you can quantify that by asking management for the cost of a development team for a day, a sprint, etc.
For detailed suggestions and examples of how to have a better Problem Solving Workshop and examples of good/bad problem statements, download this helpful PDF.
Download 5 Additional Tips for Better I&A Problem Solving
Tip #5: The Inspect and Adapt Event Template is your friend!
You may not know it, but if you’re an SPC, then you have access to something called the SAFe Program Increment Toolkit from the Toolkits and Templates section of the Community site. The PI Toolkit has the Inspect and Adapt Event Template, which is a PowerPoint with all the steps needed to walk people through the entire I&A event. This is really, really useful!
The I&A Workshop is a complex event and there is a lot more to say, but these five tips should help you get started. Now go forth and make your train better!
View the Scaled Agile, Inc. partner profile for ICON Agility Services
Written by Randy Smith , SPCT
Randy is a Consultant, Trainer, Agile Transformation Coach, and SPCT. He believes that a transformation is about more than adopting a framework—it’s also about meeting people where they’re at to help them create an optimal human system that can happily and effectively deliver value to customers. Randy has more than 2 decades of experience in the industry and has worked in several sectors, including tech, manufacturing, shipping, financial, and medical firms, and he has served many roles like developer, test management, release management, support, etc. He started using Agile principles and values with a team in 1999, got his SPC in 2014, and completed his SPCT in May 2019.
