Back to Shows

PI Planning Therapy

What you'll learn

  • Not everyone can make a decision
  • Decision making needs to be fast and be focused
  • Respect the authority 
  • The product manager decides in PI Planning what the scope is 
  • The architect is the one that must orchestrate the discussion around an architectural change
  • Teams decide how to implement, they get implementation design 
  • Business gets to decide about functional things for the customer 
  • All the teams and architecture should be aligned on things like databases or queuing systems but ultimately the decision makers need to be well known and well defined and careful for the arguments that are made
  • Getting quick decisions is key to agile


Welcome back to PI Planning Therapy. This is the last episode in this season of PI Planning Therapy. There may be more seasons to come. Who knows? The world is such an amazing place. And today we're going to talk about decision making.


(musical intro) PI Planning Therapy, where you come for all your help with PI planning! It's the best therapy you'll ever get. Better than drugs.


Decision making in an agile environment can be very complicated, because we want to live in an empowered organization where the teams get to decide things and, you know, it's almost like, if you look at the holacracy influences on agile, it's almost as if everything should be a democracy.


I have some bad news. Our customers don't care what's popular in our organization. They care about how well we solve the problems, or how well we enable them to solve their problems, which is probably more accurate. So, if the team agrees on something, and it's not the best solution for the client, the best solution for the customer, that's a bad thing. I know that sounds weird, but it is the truth. We are here for a reason. The reason is to get a result for our clients and for our customers. Yes, teams perform better when they have a say. The results are generally better when the teams are listened to. But the objective of solving the client's problem or enabling them to solve their own problem still remains the number one thing above all else, and lots of agile organizations forget that.


So I know we went down a little rabbit hole down there, this nice, deep, warm rabbit hole, but it's really important you keep that in mind. Because as we look at PI planning, one of the reasons we put everybody in that big, comfortable, warm room with a buzz, with lots of light, it’s just so alive and full of energy, and people talking about stuff and drawing on whiteboards, or they’re using an app like the PI planning app, or whatever other thing you can come up, trying to create a plan and create a vision for the product. 


We have to make lots of decisions. And that means we have to have a mechanism in place to do that. That means we need to be very clear around who gets to say what, so who gets to make what decision. So if we're talking about the simple elements of the product itself, who gets to decide, in PI planning, what the scope is: it's the product manager. They are the portrayals of the vision of the customer need. They're the ones who are passionately, madly speaking for the customers, for the problems that they need to solve, or the problems they need to solve for them.


So when there's a scope question, yes, there should be a lot of dialogue about it, and yes, people can share their opinions. But ultimately, if it's a scope question, do I do feature A or feature B? Or, do I have, can I drop function A or B from the feature because of a capacity issue?, yes, they get to decide. Their mission in life is to listen to everybody in that room who has a direct say in that, in terms of who is impacted by it, each team who will be impacted by it. They have to listen, but they have the decision-making authority. They are the deciders because their job and their future is based on how well they saw the clients.


Now, there are other products in this thing, right? There is the scope from the business functionality perspective, and there is the technical product, the architecture of the product: whether that's the functional architecture, how the business features are structured within the product you're building, and the technical architecture, elements of that. Who gets to make those decisions? Who is the one who must put straight the discussions around an architectural change? We're going to consolidate all these functions into this component. Or, we're going to separate the functions in this component into four or five other components and they're going to be spread across these teams. Who gets to decide that? That's the architect.


Now, the architect, just like the product manager, should be truly obsessed with taking in everybody's opinion. But the architect — or the architecture team, in some cases —, they are the deciders. They are the ones who are going to be judged on this. Their job is to be obsessed with providing the best technical solution that enables the business problems to be solved. 

[05:12] And you're going, but where are the teams in all of this? Are they empowered, do they get to decide everything? Well, they don't get to decide everything. They get to decide how to implement these components. Of course, they're following the guidelines that have been agreed with everybody. They agreed to guidelines, with architecture, they agreed guidelines with each other. But they get implementation design. So if you think about intentional architecture, you have intentional business architecture, you have intentional technical architecture, and then you have an emergent design, and the teams come in when it's emergent design.


So how do we meet this architectural and business function requirement within the guidelines and agreements and the scope of this product? Often I see, and you may be experiencing these blockages, where you have architecture and the teams fighting over something. Be very clear about who has the main authority here. And don't let those discussions go on for too long. The longer they go on, the more entrenched people's views become, the harder it is to move forward. If you get stuck in an argument, you have to climb out of that trench, so don't get the trench get too deep.


So the business gets to decide about functional things for the customer. They get the ultimate say, right? It could be product manager, it could be the product owner at the team level, they get the ultimate say, the architects on the technical product itself, and the teams on the implementation design and their plan to implement the business vision and the technical vision of the product. Make sure that you're rotating, you're keeping an eye and you're watching for these arguments going on.


Now, I can promise you, people will get deeply upset. Now say, you're not empowering me. I don't get to decide things that are in somebody else's domain. They won't quite say it that way, but if I'm empowered, I get to decide which database we use. My answer to that one, and I get this one a lot, is: let’s say the smallest solution I've ever run is 18 teams. Let's say 18 teams make 18 different decisions about which database we've got to use. How expensive and complicated is that? All that time and effort to support 18 or 16 or 14 different databases. That's time and effort taken away from serving our clients, solving clients’ problems, enabling our customers to solve their problems. 


All of that time is taken away. And that means we are not on mission. So all the teams and architecture should align on things like databases or queueing systems. But ultimately the deciders are well known and well defined in SAFe. And watch out for those arguments, because getting quick decisions is key to Agile, and empowerment doesn't mean I get to ignore the people with the main authority.


So that's it. It's a bit of a heavy one, a bit of a long one, maybe. But that's it for PI Planning Therapy. I'm sorry, I'm gonna have to cut you off. No more prescriptions from now on unless we do another season and at some place… But really, decision making needs to be fast and needs to be really focused. Thank you, really, a lot for your time. Have a great day. See you in the future on another show. Let's see… maybe a show about business agility, wouldn't that be fun? Or leadership topics, like delegation and empowerment and Jewel operating systems for your organization and how much fun that is to do. And it is fun and it is enormously valuable. So, bye bye for now. We'll be back soon with a new show. Signing off.

About the course

Shane Harrison has been working with Rentouch to create a new format "PI Planning Therapy". Shane is the therapist and he will give tips on various problems that have been sent to us by the SAFe community.






1h 22min

Last Updated


Meet your Expert

Peter Pedross

CEO & Founder PEDCO AG, Chief Methodologist Applied SAFe

Creator of the product Applied SAFe. Started to program for money at the age of 14. Ex-professional sportsman with a passion for software and a knack in engineering. 30+ years working experience with 50+ publications. SAFe SPC since 2011, Agile (XP) since 1999. Happy father and married to a wonderful woman.

Meet your Expert

Silvio Wandfluh

Head of Product, SPC5

Silvio is a certified SAFe® Program Consultant and as Head of Product at Rentouch responsible for the innovation of

Meet your Expert

Shane Harrison

Business and Agile Leadership Coach

Shane is a business focused change agent, specialising in enterprise level digital Lean/Agile transformations. More than 17 years consulting experience across a variety of industries from pharma to banking Shane is a specialist when it comes to context and culture-specific transformations.

Meet your Expert

Ian J Franks

SAFe® 5 Program Consultant & RTE

Ian has a deep knowledge of Scrum, Kanban and Scaled Agile, and 30 years’ experience in international IT Transformation Programs. He is a successful PO, SM & RTE and as a Consultant/Trainer he coaches his clients develop a strong Agile Mindset that delivers real change and measurable improvements.


Sign up for a free 14 days trial today

Sign up