Back to top

The Management Review - Part 1

Author(s) 

Management Review & Problem Solving

Navigating towards achievable objectives

The management review forms a key check-point mid-way through a PI Planning event that allows the stakeholders and facilitators of the event to offer sensible steering to the teams within the train. The guidance on how to facilitate this section of the PI Planning is simply:

The RTE facilitates and keeps the primary stakeholders together for as long as necessary to make the decisions needed to reach achievable objectives.


Whilst that gives plenty of scope for interpretation it also allows plenty of scope for mis-interpretation; which could very easily compromise the process and the underlying principles.

At IJI our consultants have been facilitating PI Planning events since the very beginning of the Scaled Agile Framework. Over that time, we have developed a simple strategy that helps focus and guide the conversations within The Management Review, without constraining those conversations. In this short set of blog posts we’ll share our approach to the management review and whilst it is impossible to predict what might happen in a planning event we can share some of our stories to highlight the sort of challenges that organisations might face.

Purpose

The goal of the Management Review and Problem Solving is to determine what advice needs to be given to the teams within the train on Day #2 of PI Planning in order for the teams to create a set of Objectives that they feel they can make a commitement and that deliver as much value to the business as can be sensibly expected.

Approach

The questions that the Management team really needs to ask themselves at the Management Review are:

The artefacts present in the PI Planning event can help to answer those questions and the approach that we have adopted over the years is a simple sequence of:

  1. Program Backlog to understand if we are doing the right work.
  2. Program Board to understand if the work is being done right.
  3. Team Spaces to understand if the risk in the plan can be reduced.

Preparation

The official attendees for the Management Review are the primary stakeholders which includes the Business Owners to the train and the Release Train facilitation roles of Product Owner, System Architect and Release Train Engineer. We also invite one representative from each of the Agile Teams to attend the management review as well; this needs to be someone that can explain details in their team’s plan if required and we might use them to relay back any team specific advice that doesn’t need to be broadcast to the Release Train as a whole.

The most important part of preparation is to pay attention during the Draft Plan review. Each team should be presenting:

  • Capacity and load for each Iteration
  • Draft PI Objectives
  • Program risks and impediments

There are some subtleties here that need to be explained; otherwise there is a tendency for people to interpret the information received wrongly. We need to know about capacity and load not to determine whether teams have loaded themselves up to their capacity, we trust them to be sensible about that, but to know: how much capacity is still available to be consumed by day 2 of PI Planning? This is a necessary input to the question “Are We Doing The Right Work?” We want early visibility of the risks to understand whether any of them can be addressed by the management overnight. Make them visible during the Draft Plan review but don’t try to address them there; save that for the Management Review.

It is also worth pointing out that the Draft Plan review is for the benefit of the train as a whole, and not just a report for management. Teams, and individuals within the teams, should be listening out to the presentations to ensure that they are getting from the other team’s what they need. If teams spot an issue, typically the presenting team hasn’t mentioned an inter-team collaboration that had been discussed earlier in the day, then they should make a note and pick up the conversation in Breakout #2 on Day 2. Such issues could be brought up at the Management Review, but it can be left as a decentralised issue to be resolved amongst the teams. The most important part is that teams pay attention to the other teams’ presentations, the presentations are as much for them as they are for the central roles. At the start of the Draft Presentations I always remind teams of their responsibilities, even on trains that are many increments into their agile journey.

Are We Doing The Right Work?

We start at the program backlog. The questioning here is exploring whether the right features have been taken

Why haven’t features been taken?

In a truly empowered train, the teams are allowed to tackle the features in any order they see fit; we advise them to take the highest priority available feature but they’re empowered to take any feature from the wall. Sometimes technical sequencing means that it might be better for teams to take features from further down the priority list in order to de-risk or assist the delivery of other features on the backlog.

My colleague Ian Spence was helping to facilitate a large (150+ engineering staff) planning event for a major electrical company in southern Sweden. At the end of Breakout #1, Feature #2 was still on the board; nobody had taken it. If you peered beneath the Post-It on the wall there was a team name; the team had taken the feature, carried it back to their table and tried to plan it. But the team could not make sense of the feature, they could not plan it, so they returned it back to the wall for another team to attempt. Indeed, there was a second team name underneath, but that team had not been able to make sense of the feature either and had also returned it to the wall.

In the management review the Product Manager was asked to explain the feature and after staring at the post-it for a minute or so; they also had to accept defeat. The next morning the Product Manager stood up before the room; they apologised to all the teams that wasted time attempting to plan the feature. They explained that they had been pressurised by a Customer to prioritise the Feature but the Product Management group hadn’t had time to do due diligence on the Feature to understand exactly what it was. They promised not to let it happen again. In a slightly flamboyant act they tore the post-it into little pieces and threw the confetti into the air; there is always a little bit of theatricality in Product Managers.

Anecdotal evidence is that it’s always Feature #2 that’s left; our hypothesis is that someone always takes the Feature #1 because it is the most important but after that they go for the features they’re interested in or have experience in. It’s happened on more than one occaison.

First planning event for a Pan-Scandinavian Retail Bank; Feature #2 had not been taken. Why hadn’t it been taken? We always advise teams to take the highest priority available Feature from the wall, but they are empowered to take any Feature from those available on the wall. Teams might not be able to take the highest priority available feature because it’s not their area of expertise and it might be better for a team with the relevant expertise to take the feature; they might not be able to take the highest priority available feature because they don’t have enough capacity left to complete the feature and it would be better to plan something that could be completed within the time available. In this case, Feature #2 was a bit of web-infrastructure that the site was going to need but all the teams had gone for the more exciting features further down the backlog that contained the fun, new functionality for the website.

The management of the Train wanted to send the feature to one of the web development teams; to push the work onto the team. We had to hold them back. One of the challenges with the Management Review is that it is very easy for the management, the business owners and central roles on the train, to go Command and Control on the teams; this needs to be avoided. If the management start telling the teams what to do then it will break the empowerment and self-organisation of the teams; instead the problems identified at the Management Review need to be reflected back to the teams as challenges for them to solve on Day #2 of the PI Planning event. After a little persuasion the management eventually conceded and let us present them as challenges; we reminded them that at the end of Day #2 as part of the final plan review we would ask them if they accept the plan and if the team’s hadn’t sensibly addressed the challenges from the Management Review then the teams would have to go around a re-planning loop until it the challenges had been addressed. Decentralisation, and empowerment, isn’t fire-and-forget always close the accountability loop to check that sensible decentralised decisions have been made.

The next morning, we present the challenge back to the teams and before we had even finished explaining why it was important a team had run up and grabbed Feature #2 from the wall. Was it one of the teams that The Management had wanted to push the feature onto? No. The team that grabbed the feature was not one of the Web Development teams but the team that were specialists in Security and Authentication. When asked later they replied, “We use this web infrastructure around our Security components all the time; it’s a no-brainer for us and there’s not that much Authentication work to do this Program Increment.”

Is that the right feature?

Working with the Marketing Infrastructure teams of the European arm of a major International brand; we were staring at the Program Backlog when the Product Manager mused “I wonder if that one Feature (he points to a large feature lower down the backlog) would fit where the team has taken these two? It might be more valuable.” PI Planning provides an opportunity for exploring scenarios, the Set Based Approach described in SAFe Principle #3. The challenge was posed to the team the next morning; could they quickly plan out the stories for the larger feature to see if it might fit instead of the existing two that had been planned. We coached the team to go light on the planning, just enough detail to get estimates and identify any potential collaborations and risks but not too much detail since any extra effort could become waste if the feature isn’t chosen. The team duly mapped out the feature and in collaboration with the Product Manager decided a course of action. In this instance the plan went with the original two features; the work on the larger feature wasn’t a complete waste; it came back in a subsequent PI Planning with some candidate stories ready to plan.

Are features still valid?

We were working with a UK Betting Firm and a release train that dealt with betting on Sporting events. The backlog included a large number of features that they wanted available for the Euro 2016 Football championship. After a day of planning it was obvious that not all of the desired features were going to make it in time for kick-off. There is no point delivering features for a sporting event when that event has happened. This led to what we call the parting of the backlog; all of the features that weren’t going to make kick-off were swept to one side and the next batch of features rose up in priority, Dubai Gold Cup horse-race, until that event had passed and yet another batch rose up.

Early warnings

Working with a Stockholm based Medical Equipment manufacturer; a surprisingly small train for such a large and complex piece of Medical Equipment; one software team, one electronics and firmware team, one mechanical team, one “team”1 of regulatory and compliance staff . The first feature for the Software team in this PI was to upgrade the Operating System on the device; to move off of Windows 7 required every library in the new Operating System that was used on the device to be re-certified for use in Medical Equipment; a slow and tedious piece of work. By the end of Day 1 most of the software Features were still on the wall and most of the software engineering capacity was gone. A quick interpolation from this point showed that the next release in about 7 months wasn’t going to have as many software features as they hoped or had promised. The Management took it fairly well; ultimately the engineering resources are Fixed Capacity Machine and it can only do so much. The OS update couldn’t be deferred any further as the support costs Microsoft were charging were going to start rising steeply. What the planning did achieve was giving The Management 7 months warning about the likely scope limitations so that they could prioritise the right functionality and start explaining to customers that the release would be the OS update rather than new stuff so that when the release did land the customers weren’t surprised by its content (or lack thereof).

PI Planning events provide lots of insight not just into the current Program Increment, but information that can be used to predict ahead and, combined with roadmaps, forecast whether future targets are sensible and achievable.

Conclusions

In this post the general approach to the Management Review has been described and some of the scenario’s that have been seen when posing the question “Are we doing the right work?” at the Program Backlog have been explored.

The next posts will move towards the Program Board and ask the question “Is the work being done right?” before touring the teams and asking “Can the risk in the plan be reduced?

Acknowledgments

A big thank you to SAFe Fellow Ian Spence and SPC-T Keith de Mendonca for providing stories and observations over the years that have contributed to this article.


#1 They weren’t a proper team like the three engineering teams; but encouraging them to act like a team in PI Planning made it easier to map out the collaborations between the compliance staff and the engineers.