Contact

The Management Review - Part 3

Management Review & Problem Solving

The third in a short blog series looking at the Management Review that occurs in the middle of a PI Planning event in SAFe. The first two posts have looked at an overall approach to structuring the Management Review and at some of the scenario’s that have been observed when posing the question “Are We Doing The Right Work?” at the ART Backlogand “Is the work being done right?” at the ART Planning Board. This post will look at “Can the risk in the plan be reduced?” and discuss the challenges that can occur if the decisions from the Management Review aren’t communicated back to the train in an appropriate manner.

History:
One of the major updates that occured in SAFe 6.0 was the deprecation of the “Program” phrase from the framework. Scaled Agile had always utilised the “Program” in it’s basest meaning: “a group of activities or things to be achieved.”, however there was a tendency for people to assume that this was a “program of projects” from project management and that was becoming problematic. Many items within SAFe that utilised the Program phrase were renamed: Program Board became ART Planning Board, Program Increment became Planning Interval. This article has been updated to the 6.0 terminology, but there may be historic references elsewhere that retain the Program phrase.

Can the risk in the plan be reduced?

The final step is to tour the Team Workspaces. The goal here is not to critique the team level plans, the goal is to get early visibility of the risks coming up and determining whether anything can be done about them before Breakout 2. If the central roles, Stakeholders and Business Owners, want team level detail then they should be participating in discussions with the teams as part of the Breakout sessions.

At this stage the risks can be broadly categorised three ways:

Missing information: Some risks are caused by missing information; missing information that central roles might know or be able to obtain overnight by making some phone calls. Once that information has been obtained it can be relayed back to the teams for incorporation into the team plans during Breakout 2.

Example:We don’t know who to talk to about this API?
Example:Where are the graphics designs for a component?

Team Level Risks : The risk is something that the team can own and should factor mitigation into their plan. These can be politely reflected back into the team and they can adjust their plan to deal with the risks. Typically, there is no need to broadcast this team specific advice to the train as a whole the reflection is conveyed back to the team by the team representative that is present at the Management Review.

Example:We need to know about this new technology.
Create stories to reserve time to learn.
Example:This is risky and we might need to do extra work to sort if out.
Plan for that, create stories to reserve time for that extra work. If those stories aren’t needed then other work can move forwards.

ART Level Risks: True program level risks that are beyond the abilities of the team to own and mitigate. These will need to be raised and ROAM‘d on Day 2 of PI Planning.

Example:We haven’t signed a contract with an external supplier to access their services.
Typically this is going to be organised by one of the Agile Train level roles, or above, rather than an individual Agile Team.
Example:We might not have enough infrastructure to handle volume of code changes.
Typically purchasing new infrastructure is beyond the remit of a single Agile Team so the Development Value Stream or Agile Release Train is going to need to own the risk



Unless a risk is arising repeatedly in multiple teams most advice on the risks is team specific and can be relayed directly to the team through the team representative that is present in the management review; there is no need to broadcast team specific advice to the wider train.

Communicating Back

The challenge with the Management Review is to stop the senior leaders reverting back to command and control. If there are things they don’t like or they want changed then they need to be posed as challenges; problems for the teams to solve, to factor into their plans, on Day 2.

A major concern of the management is that the teams won’t incorporate those challenge into the plans but it’s a fear that we’ve yet to see realized; most teams want to build a plan that works. If the management need convincing then remind them that The Final Plan Review on Day 2 closes the accountability loop; the Management are empowered to “not accept” the plan if the challenges from the Management Review haven’t been sufficiently met.

The Management Review is one of the few places where we as external coaches will tend to step in and run the activity instead of the RTE. It’s a lot easier for us, as externals, to face off to senior executives and say “Stop! Pose it as a challenge.”, than it is for the RTE since one of those executives is often the RTE’s manager. The Executives soon learn the process, at which point it’s a lot easier for the RTE to facilitate and push back on bad behaviours.

Who should present the challenges back at the beginning of Day 2?

Whoever is best placed to describe them.

If the challenge is work related then it would fall to the Product Manager to present. If the challenge is technical then the System Architect would present back. If it’s procedural then the RTE. Ultimately; it doesn’t matter who present the challenge back to the teams, it’s that the teams understand what challenges they have to incorporate into their plans during the Breakout session on Day 2.

Conclusions

In this series we’ve tried to show that some structure to the Management Review can help drive the discussions; without pre-empting what those discussions might be.

The structure utlisies the artefacts that are being created as part of the planning to bring focus to the discussions and to help steer them towards conclusions rather than letting them run endlessly.

Most importantly, don’t let the management revert to a Command & Control mentality; challenge the teams and let them solve those challenges in the planning event.

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.




More Great Content for Agile Teams

How many Features do you take to PO Planning? PI Planning Tips

On the Nature of Portfolios; WSJF Estimating Portfolio & WSJF

Program Level WSJF & Feature Slicing Program WSJF & Feature Slicing

All about Managing Dispersed Planning; WSJF Estimating Dispersed Planning Series

States of Epics The EPIC lifecycle






Subject: 

Contact Us