Lessons from a year in SAFe: Use the ART Planning Board to highlight the problems you’re trying to solve

This is my second post about some of the lessons I learned while working within SAFe. In my previous post you can read about how I think you should look at teams’ maturity rather than fixating on having specific roles in each team.

Lesson #2: Use the ART Planning board to highlight the problems you’re trying to solve

I’m a big fan of defining specific outcomes rather than having a sole emphasis on shipping features. The ART Planning Board in SAFe serves multiple purposes but one of the main things is to showcase the features we’re working on. It’s a setup that rewards attention to detail; clear descriptions, acceptance criteria and much more but at least from my experience, we rarely take the time to define which problem the feature is intended to solve, what data we have to prove that it’s actually a problem and how we will know if it has been solved.

A radical way to change this way of working, and in the process empower your teams, is to move the discussion from the solution space to the problem space. Imagine if we had a board for each train with the most prioritized problems we had to solve. It could look like this:

Instead of: We want to offer our customers an AI-chatbot in the mobile app

We say: We’re seeing data that shows that our customers are increasingly interested in contacting us through other ways than over the phone and we need to find ways to meet this demand.

Instead of: We want to add a button to the home screen for our advisors so that they can quickly access the customer overview

We say: We need to explore which information our advisors need at the start of an interaction to give our customers the best possible service.

By doing this we achieve a few things:

  1. Everyone within and outside the train will have to shift how they think. Instead of jumping into discussions regarding solutions, they will need to bring data to strengthen their arguments and prove why their problem is worth solving.

  2. Teams will become more empowered to design and implement the solution they feel will solve the problem, instead of receiving a detailed specification of what to build.

  3. The train will have an easier time proving their value and right to exist by being more data-driven in how they prioritize. If we confidently can say that we saved x amount of minutes or increased the conversion with y with the problems we solve, you won’t end up having to fight for more resources. Instead you’ll probably be asked what you need to continue doing what you’re doing.

  4. You’ll most likely increase your focus. Solving specific problems requires teams to work on both discovery and delivery. This can be time consuming to some extent and force you to work on “less things” but it will probably be worth it in the end since you’ll create more value for your business and customers.

All companies aren’t interested in going full Marty Cagan but even within SAFe, you can come a long way by shifting your mindset and using the structure you’ve set up to highlight and work on the right things.

Föregående
Föregående

Lessons from a year in SAFe: If you talk about risks and dependencies long enough, eventually every team will have them

Nästa
Nästa

Lessons from a year in SAFe: Don’t fixate on roles, look at teams’ maturity