SAFe PI Planning: The Confidence Vote
Imagine…
You’ve almost made it through your first PI Planning event and you, as the coach, the RTE or maybe an engaged business owner, can visualize the entire ART raising their hands with five fingers extended to the sky to show their confidence in the plan they have created. You can imagine the buzz in the air as so many people align to a shared purpose.
A hush descends as the RTE gathers the room to attention.
They look to the posters with PI objectives and business objective scores displayed…
They look to the ROAM board where risks to the plan have been cared for…
The energy is palpable.
The RTE says, “Will we meet these objectives? Give me a Fist of Five!!!”
Hands shoot up across the room.
Fives!
A few fours!
There’s a three (that’s Mr. Three – he’ll never have a four).
No twos…
No ones…
Yes!
There is a pause, the RTE turns to the Business Owners and management and asks, “Do you accept this plan?”
“Yes!”
Applause! Excellent… on to the Retrospective…
The energy generated when a large group of people have aligned to a shared purpose is something that one remembers well.
However; the scenario above was missing a key element that could prevent this ART from meeting their PI objectives.
The commitment has two parts.
Really?
Yup.
With the Fist of Five confidence vote, the teams commit to doing everything in their power to meet those committed objectives; however, they also are showing their commitment to immediately escalate if they learn of something that will prevent the objectives from being met.
As I mentioned, the vote has two parts. Unfortunately, the second part is often forgotten during the excitement of the moment.
Does it matter?
I believe it does.
One of the advantages of a commitment to PI objectives as opposed to committing to features and stories is that it compensates for the potential changes that will occur as the teams deliver value each iteration, within their small build-measure-learn cycles. As the teams are continuously exploring, integrating and deploying, new insights and learnings are flowing into the system. These learnings fuel relentless improvement efforts and help improve the speed and quality in which teams can deliver value. However; there are times when the insight or information gained arrives like a punch to the gut.
What? Why didn’t we know about that? Why didn’t someone see this coming? What does it mean?
Unexpected incompatibilities. Unexplored risks. Unanticipated delays. These things happen.
Imagine…
A team member encounters a major issue that could prevent the solution from working and they share the insight with their team. It is discussed. Perhaps the Scrum Master mentions it on the scrum of scrums, perhaps not. Will it prevent us from meeting our team’s goals?
No?
Whew.
Crisis averted.The iteration ends and another begins…
The issue is still out there but the team is focused on getting the stories accepted for the iteration. This is not like PI planning where we are all working together. This is the grind. We are in it. We have to do our part.
Another iteration passes and we are more than half-way through the PI…
Now, the issue pops up as a major impediment when the system team prepares for the system demo.
This is a systemic issue.
This could prevent us from meeting several of our PI objectives. The business is going to freak out!
Wait. We can figure something out. Let’s get the architects, dev managers and some of the best developers together to come up with something.
Don’t tell the business yet. We got this. We have to meet our commitment!
System demo? Just demo it from dev this time. We are working on a fix.
Another iteration passes.
The business is feeling great about this new way of working. They were skeptical at first but they are seeing demos every couple of weeks. They are preparing their go to market activities in anticipation of the release of these new features.
The group focused on solving the issue stays late, tries different solutions. However; people are starting to worry. Maybe the business won’t be able to release this but we should still be able to meet the feature acceptance criteria. We will still meet the date. The business will understand.
The PI is wrapping up. It is time for the PI System Demo.
Great demo! Let’s release immediately!
What? Can’t? I don’t understand.
Stability issue? Not working in production?
Will it?You think so.
You think so?!?
Let’s pause here.
I have seen similar scenarios play out time and time again. In these situations, people are working their hardest. They often believe that they can come up with a fix or solution without having to “bother” the business. They take ownership. They did everything to meet the objectives.
What was missing?
The second part of the commitment.
If you learn that something will prevent the objectives from being achieved, immediately escalate to management.
What does the term “escalate” mean within your organization? Does it bring to mind a formal process? Are there political ramifications? Is there a formal chain of command that must be followed?
I believe that the reason for the second part of the commitment is to remind everyone that, in this new way of working, unanticipated issues are expected and that both business and IT leadership understands and accepted this.
Management is planning for variability and the earlier the learning, the more options exist to respond.
I’ve yet to see a situation where a business owner or stakeholder preferred to learn “after the fact” about something that would prevent commitments from being met. Once the issue is known, action can be taken and it is not always technical in nature. Sometimes, priorities may shift or there may be an option that can be seen from an alternate perspective.
While it may be uncomfortable to speak up, each day that passes may eliminate options. What can you do to embrace those values, such as transparency, that will ensure sustainable change?
Remember: The commitment has two parts.
great post – thank you