Project Governance In An Agile World – Part 4

This week’s post looks at Chapter 4 – Governance or programs and portfolios. This chapter discusses how organizations can set the different types of governance for programs and portfolios. To focus on the differences with agile delivery, what could be changed during a transformation and why agile transformations fail when there is no change.

We will go through the following:

Four styles of governance

Governance of portfolios

Governance of programs

As we can see, Muller set up his book to go from a larger view of enterprise governance and drills down. In the last chapter, we discussed using a committee of leadership providing the direction and decisions on projects and programs. In an agile environment, you have more guidance given to the teams on product or service vision and not making a lot of “command and control” decisions. The reason is with agile teams, you have a constant feedback loop with all stakeholders on the direction of the deliverables.

Muller discusses ensuring effectiveness and efficiency, which are implicit in agile development. Teams want to provide the highest value possible and be efficient with continuous improvement. Where things start to separate when discussing efficiency is it discusses costs. Yes, the cost does play a part in any organization. It is here the way it is worked. It does not discuss improvements explicitly, while it does bring up resources. This can implicitly or explicitly stick around after a transformation as there would be trains of thought that if it is not working to what leadership thinks, faster delivery, they believe to be long enough then there is a tendency to start letting go of staff. This is something I have experienced in an agile organization. All the work to improve and provide value was all for not as it was all about headcount. I did work with the remaining teams to have the right behaviours to improve continuously, and they exceeded expectations. While talking with the leadership, they were happy with the turnaround, and I left them with this question “Imagine what it would be like if we didn’t let go of those teams a few months ago?”

This is why I love being an agilist and sharing my knowledge while helping teams succeed the best they can.

The four governance styles are as follows:

Portfolio of projects – where resources are shared and objectives unrelated

Hybrid organization – where resources are shared and objectives are related.

Multi-project organization – resource not shared and unrelated.

Program of projects – resources not shared and objectives related.

If we look from an agile organization’s, perspective Hybrid and Portfolio or projects wouldn’t be a good set of governance styles as self-managed teams don’t share resources.

The multi-project organization looks good at first, yet it focuses that all projects have no synergies. In an agile organization, although teams might be working on different things, there s still the synergy of everyone being agile in why and how they do things. The transparency needed to be agile in delivery requires synergy and synchronization.

The program of projects fits with the work and expectations in an agile organization with common objectives with all the teams. When I am talking about objectives here, I mean the organization’s agile values specific to them. These are the common objectives that drive the teams to success.

Next, they discussed measuring the productivity of the four governance styles. The projects were deemed less than 50%, while the Hybrid was close to 70%. The ability to make decisions to keep going or drop projects was why Hybrid was rated so high. This is odd because we all know that failing fast and dealing with risks early is a key benefit in agile delivery. There are also plenty of studies out there that show increased productivity when teams are being agile. This will be another topic for a future post to dig deeper into that study.

As we move on to governance for project portfolios, we can see that it continues the “command and control” way with PMO, middle management, portfolio management, project/program level reporting and the projects themselves. The model itself and the expectations are not dissimilar to an agile time; the difference is that most of the flow that is between each is actually done within the teams and that servant leadership takes care of the team’s needs, like getting the training they need)

There is an importance of Value Maximization, balancing and strategic alignment, all parts of being agile. Going through this chapter, Muller tends to keep a hierarchy involved in how projects and programs run and discuss little team involvement. There are some instances where we can see small changes needed to complete an agile transformation and avoid traditional management styles to creep in.

Using steering committees or board of directors adds an unwanted layer since the expectation is in an agile environment, the teams (including leadership) drive out the value. We see that steering committee use after an agile transformation is only focused on the teams where those teams are only doing agile frameworks and not being agile.

The next chapter is focusing on project governance. Maybe there will be some surprises. Stay tuned.