The best Agile governance framework to keep your Scrum Teams in line
Hint: Governance and Scrum don’t mix.
“Do you know of any good Agile governance mechanisms?”
As an Agile Coach, I get a chill down my spine when I hear statements such as this. And I’ve been quite chilled over the past couple of years. Governance is popping up more and more as a desired element of an Agile organization.
Should we even place the words “Agile” and “governance” next to each other? The words have opposite meanings. To be agile is marked by the ability to move with quick, easy grace. Governance means to rule and control according to standards—not an enabler of quick and easy movement in my experience.
The Agile governance oxymoron fits right in with others popular among the Agile quick-fix tribe, such as:
- Agile management
- Agile project management
- Agile program management
- Agile program management office
- Agile standardization
“They (Scrum Teams) are also self-managing, meaning they internally decide who does what, when, and how.”
Do Scrum Teams stand a chance in the presence of governance? Can self-management take root? Is our goal for all teams to operate the same?
The answer to each of these questions is, “No.”
But this does not stop the mad rush to put governance mechanisms in place. Let’s explore why many are in love with governance and what to do instead to enable thriving Scrum Teams.
Why organizations fall in love with governance
Is it more important for your system of work to be correct or for it to be useful? Governance is more concerned with the former than the latter.
I’ve seen companies slow to a crawl due to a love for governance. Some would rather wait months to form a governance team than start a product effort. Others hold up features to await central approval from a governing body or review board. And many try to design the perfect process and standardize all teams before starting anything.
Believers of a central source of truth and centralized governance see one true way to do things. And they believe there is no way anything could be useful unless it adheres to the standard. All must follow the rules.
To govern is to rule according to a set of standards. These standards create the status quo. Organizations arrive at their current condition through their existing mechanisms.
What they know is safe. So they wrap themselves in the comfort of this safety net like a warm blanket. Preserving the rules becomes the ultimate goal.
But holding on to “the way we have always done things” provides an illusory sense of comfort. In today’s competitive, hyper-changing environment, organizations must adapt — or perish.
Governance will keep you standing still while your competition moves on. You become stagnant, your products will atrophy, and your customers will go elsewhere. Where is the comfort now?
Why Agile and governance don’t mix
I have seen Scrum Teams scared to make a move when shackled by governance and its many guardrails. Brains turn off. It’s easier to follow orders than buck the system.
And transparency plummets. Governance expects compliance or you face the music with the governance committee. When under a microscope, most teams opt to create an illusion of being in the guardrails. The true situation remains cloaked by optics.
I’ve seen a form of “success theater” take root when teams have a fear of non-compliance. These teams will go out of their way to ensure there is no “whiff” of problems. One signal you are watching success theater is what I refer to as the “watermelon syndrome.” Everything is “green” on the surface but “red” on the inside.
The Hawthorne Effect shows people, when being watched, choose to increase their performance. Many, in error, interpret this to mean more transparency means more productivity. But the increased performance often turns out to be Oscar-worthy acting to appear to be in the rails.
“Scrum is founded on empiricism and lean thinking. Empiricism asserts that knowledge comes from experience and making decisions based on what is observed. Lean thinking reduces waste and focuses on the essentials.”
— The 2020 Scrum Guide
When transparency fails, empiricism can’t take flight. If you don’t know there is a problem, you can’t solve it. And when teams also don’t feel the safety to solve it on their own, you get into a downward spiral toward stagnation.
Problems fester and become thornier the longer they go ignored. It’s messy and not good for anyone involved — teams, companies, or customers. When your goal is to be Agile, rules get in the way and slow you down or stop you altogether.
If Agile is about embracing change, governance is not a helpful mechanism.
If not governance, what are the alternatives?
I’ve found in most cases, the cry for governance is a plea for involvement. Stakeholders want comfort and confidence in the team’s ability to self-manage. But the answer lies not in centralized control.
Instead, we need decentralized collaboration, adapting to unique contexts, and supportive communities.
Collaborate Often. Being Agile is working small, collaborating often, and making people’s lives better. When teams review Product Increments often with stakeholders, governance is unnecessary. When those who have a stake in the product partner with the teams, the desire for governance fades away.
When teams work small and engage often with their community, risk reduces. All involved realize the beauty of frequent inspection. They can make easy, low-risk pivots together to chart the best course based on learning.
Embrace unique team behavior. When teams work in a model of decentralized collaboration, each team operates uniquely. Each team has different team members, different stakeholders, and different users. As such, its system of behaving will adapt to its situation.
Scrum is meant to work this way as it is based on empiricism. The only guardrails a Scrum Team needs are the values and principles of Agile and the values of Scrum. The rest is up to context.
Build Strong Communities. Communities fulfill many of the well-meaning intentions of governance without oppressive control. Communities of practice cross-pollinate knowledge, build relationships, and share practices.
Communities of practice can take on many flavors. Here are a few:
- To focus on an area of improvement
- To share practices across teams
- To generate product ideas to solve a customer need
- To build domain or functional excellence across teams
- To improve quality
- To retrospect across teams or organizational units
- To demonstrate product achievements
- To assess product strategy and direction
- To solve problems collaboratively
- To celebrate success or share learning from failure
- To promote unstructured sharing of any topic
Every Scrum Team has a mechanism for embracing community built into the Sprint Events. A team may invite its community to any Event as necessary. But in particular, the Sprint Review is a forum to invite broad community involvement.
But you often need to share in broader communities across the organization. So you must go outside of the normal Sprint cadence. Often cross-team communities of practice flow on a monthly or quarterly rhythm.
Communities provide a conduit to step back from work and reflect. They are often energizing events for teams, stakeholders, and customers. When compared to engaging with a governance review board, there is no contest.
Taking it forward
Governance is too often turned to by organizations. They are seeking control in the uncertain, complex world of product development. They want rules and guidelines for familiar patterns and a means of enforcing them. But this control is an illusion.
And all this control makes Scrum Teams hesitant to act in the face of new knowledge. They don’t move fast to reveal problems or make a move on their own outside of the guidelines. It is too risky to be seen as drawing outside of the governance lines.
But this is exactly what you need self-managing Scrum Teams to do. You need them to turn on their brains to solve problems. Or if they can’t solve it on their own, you need them to ask for help fast without concern of criticism.
Instead of governance, you can enable powerful, adaptive, self-managing teams by:
- Engaging and collaborating with teams on small, rapid feedback cycles
- Allowing teams to operate in a manner unique to their context
- Embracing the multiplying-effect of strong communities of practice
“You are remembered for the rules you break.” ― Douglas MacArthur
Avoid building robot Scrum Teams, awaiting their next order. Instead, allow teams to break the rules to improve their situation.
Embracing centralized governance won’t make a mark to remember. But embracing distributed learning and change just might set you apart from the rest of the rule-following pack.
For more content like this on my pursuit of Lean Leverage, delivered to your inbox, you can just join my email list. Or see my other related posts below to dive even deeper.
Related Posts
For more posts like this one from the author, see below.
