The Management Review - Part 2 | Ivar Jacobson International

Navigating towards achievable objectives

Author(s):

Management Review & Problem Solving

The second in a short blog series looking at the Management Review that occurs in the middle of a PI Planning event in SAFe. The first post 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 Backlog. This post will look at “Is the work being done right?” and the final post will explore “Can the risk in the plan be reduced?”

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: Brogram Board became ART Planning Board, Brogram Backlog became ART Backlog. This article has been updated to the 6.0 terminology, but there may be historic references elsewhere that retain the Program phrasing.

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: Brogram Board became ART Planning Board, Brogram Backlog became ART Backlog. This article has been updated to the 6.0 terminology, but there may be historic references elsewhere that retain the Program phrasing.

Is the work being done right?

From the ART Backlog is it usually just a couple of steps to move across to the ART Planning Board. The questioning at the ART Planning Board explores sequencing issues, bottlenecks, and flow.

Are we hitting the milestones?

The ART Planning Board provides visibility into sequencing. There are Post-Its to represent when delivery of value, Features, can be expected and Post-Its and string (or their electronic equivalent) to represent the collaborations between teams. For value deliveries that contribute to a Milestone they can be connected to that Milestone with string and it becomes very easy to see whether the expected value deliveries are occurring at the right point in time.

Figure 1: Features Contributing To A Milestone

Perhaps one of the largest changes that we have ever witnessed was the first PI planning event of a major UK high-street retailer. This retailer has a very seasonal business and they needed to get a system released to the market in order to hit their seasonal peak. Deadlines has already been set twice before and had been missed; this PI planning covered the third deadline; the rule in baseball is “three strikes and you’re out!” if this deadline was missed then the opportunity would have passed and the Release Train was likely to be wound down and staff made redundant. One team, the team that had traditionally been working on this system, grabbed all the remaining work and started plotting it out. At the Management Review it was evident that the team couldn’t complete the work before the deadline; they probably wouldn’t even be able to complete the work until near the end of the next PI about 15 weeks beyond the deadline.

Understandably the Management were a little bit upset, if the train goes then they are redundant too! The next morning the challenge was posed to all the teams on the train; “What can you do to assist this team in delivering the system for the deadline?” The first hour of the breakout was dedicated to just that one task and the other teams started walking up to that one team’s workspace and grabbing fistfuls of Post-Its from the Iteration plans and carrying them back to their own workspace.

If teams are taking on another team’s stories then they do have to understand them and re-estimate them; which the teams duly did but the teams now faced a problem. They have already done a day’s worth of planning, Iterations 1, 2 and 3 were already full of work that had been planned. In order to make space for the work that had been grabbed all of the existing stories had to be slid down the plan by an iteration. It turned out that the easiest way to do this was not to move Post-It’s individually but to take the empty sheet of Flip-chart paper that was Iteration 4, move that to the front and just renumber the Iterations titles at the top. Iteration 1 was now empty and ready to be filled.

Despite this being one of the largest restructurings that we’ve seen in a PI Planning event, the event itself didn’t take any longer than normal. By the time the rework was complete the teams only had a little bit of space left in Iteration 4 to fill with a last few stories and planning was done. Confidence was high all-round and during execution the system actually went live 2 days ahead of the intended deadline.

Bottlenecks

Visualising the collaborations on the ART Planning Board allows the room to spot bottlenecks. It is not uncommon for one team to have to do some underlying architectural work that then allows a number of other teams to make progress; this would be visually represented by a pink ticket with a number of strings running out to features in other teams.

Figure 2: Potential Bottlenecks

Since the work that the pink ticket represents is vitally important to a number of other features and the train can see this; then the train can take steps to ensure that the Team has planned the work sensibly and has given itself space to give the critical piece of work the best chance of success.

Are There Structural Issues With The Teams?

The ART Planning Board can also be used to visualise structural issues within the teams. The more that the train is composed of stream aligned teams capable of delivering Features end-to-end, the fewer the collaborations that you’d expect to see. There will always be collaborations, even with stream aligned teams, because the features may overlap and the teams in planning will need to negotiate with each other who is doing the work in the overlap for the benefit of all the teams involved. Large numbers of pink collaboration tickets over and above those expected from overlaps in the work are often an indication of structural issues within a team.

Figure 3: Missing Skills within a team

At a PI planning event for a major pan-Scandinavian retail bank it was evident that one team had a problem; every feature they were trying to do had a piece of string linking out to work in other teams. Upon questioning the PO it turns out that the team had been hoping to recruit two Java programmers but hadn’t managed to do so before the planning event. With no Java programmers on the team coding up a Java based website is difficult, so they were repeatedly turning to the other teams for assistance.

Movement of people is one of the places where management will typically want to push; they have traditionally decided who’s in what team. Every time the composition of a team changes the team goes back around the Tuckman Cycle of Forming, Storming, Norming and Performing. The more that this change comes from within the team the easier and quicker it will be for them to go back around the loop and get back to performing; if its imposed externally by management then the acceptance of the change will be slower.

We got the management to pose it as a challenge the following morning “can anyone help this team that needs Java expertise?” One of the senior Java developers on another team stood up saying “There’s three of us here; the other two can easily cover the work we’ve got; I’ll join them.” and he walked over and joined the team for both the remainder of PI planning and the execution of the Planning Interval itself. That team’s row in the ART Planning Board and all its collaborations had been sensibly rationalised by the end of PI Planning.

Figure 4: Component Team

Platform and Sub-system teams will be visible on the ART Planning Board. They appear as a row of pink tickets since their work is often to provide support in their domain of expertise for the other teams within the train.

Working with a team in a major European Investment Bank, they had a team of database specialists who were the only people allowed to change the database. Every Feature in the plan was ending up with a pink collaboration ticket in the database team’s backlog. Their row on the ART Planning Board was solid pink. In execution this resulted in a lot of back-and-forth between the Stream Orientated Feature Teams and the Database Team to get Features done; the Database Team was a bottleneck and it was slowing the train down.

Eventually the database team was broken up and each Stream Orientated Feature Team gained a Database Engineer so that they had all the skills within. The Database Engineer was still the only person allowed to update the database but now the other team members could contribute by crafting the scripts that made the changes whilst the Database Engineer had to verify them. The result was that the velocity of the teams went up as the cross-team coordination was reduced, and the amount of value delivered increased correspondingly.

Next ..

In this post the some of the scenario’s that have been seen when posing the question “Are we doing the right work?” at the ART Backlog have been explored. The next post will look at “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.

The Management Review - Part 2