PI Planning Magic!
Intro
Earlier this month I was helping a software organization in an Israeli defense organization (that’s why there are no pictures) run their first PI Planning event. The day after I told my colleagues at Agilesparks that this is one event I will try to remember whenever I get into difficult times doing coaching, something that happens from time to time, coaching being what it is. I will try to remember that day because of the magic that happened somewhere around noon. And I want to tell you all about it.
If you aren’t familiar with it, PI Planning is an event where the entire (yes, entire) organization (or part of the organization, if it is big, up to around 125 people) convenes for 2 days to plan the next 4 to 6 iterations (sprints). Most people, hearing about it for the first time, respond in the exact way you did just now — incredulity. Yet, at the end of the event people are just talking about how will they make the next time even better. Having said that, the event we did this time was one day only — you need to choose your battles. As you will see, we needed that extra time.
Warm-up
The main purpose of the PI Planning event is to align and synchronize the organization and so the first day opens with overviews by various stakeholders, product managers and architects, all bringing concise messages and information — we don’t want all the people sitting there getting too bored, a challenging task. Immediately following this the teams break out for planning. Everyone stays in the same venue, huddling around tables, trying to come up with content for each of the PI’s iterations (leaving the last iteration for other things.) And here things start to warm up.
At the beginning the teams will usually stay together, calculating their capacity for each iteration and better understanding the required features to develop. However, after an hour or so it starts to be evident that there are dependencies on other teams, and this is exactly what happened at the mentioned event. One of the reasons the organization went into this in the first place is that coordination and alignment between teams did not fare so well. Yet, even though it was obvious the dependencies should be discussed, teams preferred to continue and look at their own plans, keeping to their tables, exactly like other teams in other organizations do.
Enter the program board
This is a good time to mention that another output of the event, in addition to the team’s plan, is the program board on which we clearly see dependencies between the teams. At this point of the event the board was empty. Seeing the situation for what it was, the RTE, a sort of a scrum master of the scrum teams, started going around the tables, prompting people to start placing dependencies on the board, assertively. And so they did. And then magic happened.
We asked teams that placed dependencies on the board to make sure they talk about it with the relevant teams (people and interactions over processes and tools ,right?) and this started an interaction across the teams. While at the beginning the noticeable huddle was around the program board, soon you started to see people from different teams at other teams’ tables. It was not just scrum master to scrum master but any representative with any other team members. People were thinking where should they move this story and whether they could split that feature to accommodate for the dependencies. Suddenly you saw how decision making went down to the ranks, how they took ownership of the big plan.
Self Organization Magic
That magic of self organization was happening right before our eyes. Instead of some managers making all the decisions and being the pipelines for messages, people were interacting directly. Later the RTE said that while she felt she was a bit losing control of the happenings, the volume of interactions and decisions was something that couldn’t be tracked by one person. She was happy.
At some point it seemed as though energy is starting to go down and that we can start to wrap up. The RTE called for a scrum of scrum meeting around the program and risk boards (the risk board is the last output of the event, except for the PI goals and confidence vote which I will discuss in a minute). She asked the scrum masters to look at the program board (which was quite crowded by that time) and see if anything was missed. And indeed there were several dependencies which were not handled. In addition they went over the risks and categorized them to Resolved, Owned, Accepted and Mitigated. We gave the teams another 45 minutes.
Bottom Up Objectives
In parallel to all this, a team of business owners went from table to table, asking the teams to present them with the PI objectives of the team. This is a bottom up process where the teams define their objectives according to the actual scope they plan to do (some of the objectives are stretch objectives). The objectives may be the features, or an aggregation of features, or part of features. The business owners asked the teams to explain their objectives and rated each with a business value, from 1–10. This will be used at the end of the PI to measure how much business value out of the plan the team actually did. The thing I liked about it is that at the beginning of the day the various stakeholders gave their view of what should be done and now this activity closed the loop. There was one place where the business owners did not understand why was something done, something to discuss either at the spot or later.
Convergence and Management Problem Solving
When the RTE gave the teams the additional 45 minutes she also asked them to run a short retrospective of the event and have a short confidence vote of the team members in their plan. Had this been a two days event we would ask the teams to present their plans and then have stakeholders, product and program leaders resolve issues and the following day have another round of planning. But as I wrote earlier it was decided to have only one day, so we fast forwarded to the end.
Instead of having a proper management problem solving session we assembled around tables where issues that needed attention surfaced. We call the relevant people and did quick consultations, deciding (not by managers, but mainly by POs and SMs) whether to split stories, whether to have one person from one team join another team for one sprint etc. We were able to handle some of the main issues but not all of them, as you’ll see in a minute.
The Confidence Vote
Once we had everyone’s attention — it was not an easy task — we asked the people to raise their hands in the air and indicate with the number of fingers what is their level of confidence in the plan. One means no confidence at all, five means excellent. As hands went up in the air we saw one One and a few Twos. Most were from one team. We asked the people what was the issue and the response we got was that everything got into the plan because this is what they were asked to do. Not good.
The main idea when teams make the plan (either at this kind of event or during regular scrum planning meeting) is that they pull only as much work as they can. If they have to do more than they can, the plan is irrelevant.
What the RTE did at this point was to allocate another 30 minutes for the teams to change their plans so they will believe in it. This is very important to do, to make people trust the process. The RTE asked the product manager and product owners to buckle down and make it happen. Stories were moved, features got a bit thinner and when we had the vote again, we had a few Threes and the rest were Fours and Fives. The number of Threes was small enough for us to decide to handle these issues during execution.
It should be mentioned that by this time of the day people were exhausted. Did they vote three because they actually believed in it or was it to just get it over with? Good question. This is one of the reasons to have two days. After the first hard day people go home to rest and the day after come with new vigour. We did believe our plan was good enough, though.
Retrospective
At the very end of the day we asked the teams to present the main findings of their retrospective. The feedback was good. Some comments were made on the order of the tables so next time teams that are more closely related will sit closer. There were some comments about scope not clear enough before the event. The main feedback was that what happened that day, teams agreeing between them when who will do what, teams coordinating their work, is something that so far they couldn’t manage to do. This fast loop coordination process is making things that would usually take weeks or months to happen in one day. And that’s magic!
Originally published at AgileSparks.
