Balancing Governance and Empowerment

Avatar of author
Ole Jepsen
ole@goagile.dk

Are your Agile teams and programs succeeding because of or in spite of your governance structures?

In most governance setups I have experienced (traditional or “so-called Agile”), artifacts/documents seem to play a major role: RACI matrices, one-pager templates for initiatives and epics, status reports, cost-benefit calculations.

You get the picture.

Contrast this with most Agile teams I’ve met where the driving force for the governance setup is a series of conversations between team members and their stakeholders. The more the team members involve their stakeholders in the conversations, the better chance the team has to succeed and deliver actual business value.

Before we dig deeper into how this relates to governance and empowerment, allow me a little side-comment on processes:

Any process covers these three elements:

  • Roles
  • Interactions
  • Artifacts

So:

  • Roles: Who’s doing it?
  • Interactions: How are they doing it?
  • Artifacts: What is the documentation around what they are doing?

Here’s how the three process elements seem to be prioritized at the organization’s governance level and at the team level:

Governance Agile teams
1. Artifacts 1. Interactions
2. Roles 2. Roles
3. Interactions 3. Artifacts

Agile and the focus on value over processes

Over the last couple of decades, Agile has inspired development organizations to focus more and more on customer value and less on formal processes. This change started at the team level with XP and Scrum, and has (for the most part) been overwhelmingly successful.

About a decade ago, as Agile teams and programs became the majority of many portfolios, we could no longer hide them away in a corner in the organization giving them the “you-don’t-need-to-follow-the-governance-rules pass.”

We needed to start catering for agility in our PMOs and our governance. Frameworks like LeSS and SAFe® saw the light of day and gave us some ideas about how to handle Agile at the management levels in our organizations.

It does not help to simply add the magic Agile “A”

If the main focus is still on artifacts and checklists and following up on the original plans and business cases, adding A (for Agile) to the PMO so that it becomes APMO, or renaming your cumbersome budgeting processes to Lean Portfolio Management will not help. If that is still the mindset, it doesn’t matter how many acronyms you have that start with A. 

What we need to do instead in our PMOs and Governance structures is to:

  • Welcome changes when there’s an option to change direction and optimize the business value we’re creating, rather than to stop or limit changes with (for the most part) cumbersome Change Management processes.
  • Help our Agile programs and teams with ways to demonstrate that they are in control. By setting up structures that support planning and replanning at some agreed upon frequency, in a manner that makes it feel more natural to replan frequently rather than to not revisit the plans at all.
  • Support and help facilitate frequent interactions across teams and programs and stakeholders inside and outside of the company to actively pursue synergies – to foster an environment where it’s expected to challenge the original plans, the status quo and the traditional lines of command, if and when that can lead to optimizing business value.
  • Rethink which competencies we need in our PMOs in order for our governance to shift from a control mechanism to a system that supports the Agile teams and programs. Some structure and budgeting focus are still needed in most PMOs, but I predict that future PMOs will have more innovators and facilitators than controllers and managers.

By doing these things, we can balance governance and empowerment so that PMOs will not primarily have focus on structure and checklists, but also shape the path for innovation and chasing business value.

And, we can enable Agile teams and programs to not primarily focus on changing course, but also pay attention to their spending and communicate and coordinate their changed plans to the rest of the organization, including the PMO.

That being said, I want to make this crystal clear:

While some Agile teams need to pay a little more attention to the organization’s need for control, PMOs and governance have much more to learn from Agile teams and programs than the other way around.

My advice to all PMOs is make more room for empowerment and optimizing business value by adjusting your governance processes and mindset to welcome change. Support re-planning; encourage frequent interactions and facilitate those interactions. 

BALANCING GOVERNANCE & EMPOWERMENT

Governance mindset “wins” over empowerment mindset

WHAT TO DO:
Empowerment mindset “wins” over governance mindset

WHAT TO DO:
  • Stand back and let teams make decisions (give control, increase clarity & competency)
  • Reporting should mainly rely on what is seen in the demos (not just the planned vs. actual velocity)
  • Use burn-up charts based on high level master planning for the program management view
  • Facilitate that people hold each other accountable
  • Delay decisions only to last responsible moment – facilitate the decision-making process and gaining acceptance of the decisions
  • Use master plan to drive decisions and deliveries

Product

Making agile work

Pragmatic Agile support aligning purpose and ways of working to anchor change.