Governing Agile Teams: Part 1 of 2

An important, yet seldom discussed topic is: How to govern agile teams? This is rather strange considering that agile teams are in fact being governed, whether you choose to recognize this or not. If someone is keeping an eye on the budget, or the level of quality being produced, or if you are producing something of value for your stakeholders then you are being governed. If there are defined roles and responsibilities for team members, then you’re being governed. If you are following common security or data guidelines, or working towards a common roadmap or strategic outcomes, or providing visibility people outside of your team, then you are being governed. The real question is: Are you being governed well?

The following diagram overviews how the Disciplined Agile (DA) tool kit enables agile team governance. The DA tool kit is one of the few agile places where governance strategies are an explicit aspect of the overall approach. This includes governance of individual teams as well as governance at the organizational level. 

Click on image to see larger.

This article, the first in a two-part series, focuses on the following topics:

  1. What is Agile team governance?
  2. What isn’t Agile team governance?
  3. Why is Agile team governance important?

What Is Agile Team Governance?

Governance establishes chains of responsibility, authority and communication in support of the overall enterprise’s goals and strategy. It also establishes measurements, policies, standards and control mechanisms to enable people to carry out their roles and responsibilities effectively. You do this by balancing risk versus return on investment (ROI), setting in place effective processes and practices, defining the direction and goals for a team, and defining the roles that people play within a team.

Agile team governance is the governance of agile or lean teams in a manner that reflects and supports agile and lean ways of working. We have identified the following principles for effective agile governance:

  1. Collaboration with teams is more effective than trying to force them to conform. Most agile teams are composed of intellectual workers, the type of people whom are more likely to do what you want when you work with them to do so, rather than tell them what to do. For example, assume you want an agile team to work towards a common strategy, in this case one that is captured by your organization’s architectural roadmap. You are better to have people knowledgeable with that strategy to work directly with the tea, rather than forcing them to fill out specific documents that will then be reviewed for conformance.
  2. Enabling teams to do the “right thing” is more effective than trying to inspect it in. Agile team members are human, and being human their natural tendency is to do the easiest thing possible. The implication is that for things that you want to have happen you should make them as easy as possible to do so. For example, say your organization wants developers to follow common security conventions. One way to do this would be to hold code inspections, a time-consuming process, that validates whether the conventions are being followed. An easier approach would be to adopt one or more security analysis tools and include it in your continuous integration (CI) strategy. This automated approach requires very little effort on the part of the developer and provides immediate feedback as to the secureness of their code, providing them with a learning opportunity to help them improve their skills.
  3. Continuous monitoring provides more timely insight than quality gate reviews. Team dashboards that use business intelligence (BI) technology to display real-time measures generated by the use of your work tools have become very common in the past few years. This enables both the team and their stakeholders to monitor the team’s progress in a continuous real-time manner. This is orders of magnitude more effective than traditional “quality gate” reviews of artifacts. The information displayed on the dashboards is automatically generated as a side effect of tool usage and therefore incredibly difficult to fake. Conversely, team artifacts (status reports, specifications, plans, and so on) are hand-crafted and thus contain whatever information the creator(s) decide to capture. Furthermore, after the initial cost of the dashboard technology this approach is effectively free.
  4. Transparency enables governance. The work of a Disciplined Agile team is effectively transparent through application of strategies such as information radiators, team dashboards and active stakeholder participation. All of these strategies are described below. As a result, your stakeholders can discover what the current status of your team is simply by looking whenever they want, they don’t need to rely on status reports crafted by the team that may be little more than works of fiction.

What Isn’t Agile Team Governance?

Governance often has a bad name with agilists, typically because they have had ineffective traditional strategies inflicted upon them for years. These traditional strategies often prove to be little more than a layer of additional bureaucracy that offers little or no value to your organization. To put your mind at ease on this issue, we’d like to point out that agile team governance isn’t:

  • Documentation driven. The greater levels of collaboration promoted by agile, in combination with the strategy of team dashboards, alleviates the need for many of the artifacts that traditional governance strategies dictate. Furthermore, the milestones suggested by the DA tool kit are risk-driven, not documentation driven.
  • Onerous. An onerous governance strategy will not be followed by teams, at best they will do just enough work to make it appear that they are following the governance process, which implies that the governance process has failed. In DA, we’ve kept the governance strategies as streamlined as we possibly can, and when you do it right, effective governance actually improves the productivity of agile teams instead of detracting from it.
  • Management. Governance and management are two different things. Governance looks at a team from the outside, treating it as a system that needs to have the appropriate structure and processes in place to provide a stream of value. Management, on the other hand, occurs inside the team and ensures that the structure and processes are implemented effectively.
  • Optional. Your teams are being governed, like it or not. In DA, our philosophy is that you deserve to be governed well, which is why we’ve taken the time to describe how to do so.

Why Agile Team Governance?

There are several important benefits to effective team governance. Your agile governance strategy will enable and motivate agile/lean teams to:

  • Fulfill your organization’s strategies and objectives;
  • Sustain and extend your strategies and objectives;
  • Regularly and consistently create real business value;
  • Provide appropriate return on investment (ROI);
  • Deliver consumable solutions in a timely and relevant manner;
  • Work effectively with their colleagues and stakeholders;
  • Adopt processes and organizational structure that encourage successful ways of working (WoW);
  • Present accurate and timely information to their stakeholders;
  • Mitigate the risks they face.

Next Steps

In the second part of this two-part series, we will explore a collection of strategies that Disciplined Agile teams adopt that support effective governance. We also explore how the rest of your organization acts that supports agile team governance. Stay tuned!

This article has been adapted from Governing Agile Teams.

Share this post

Scott Ambler

Scott Ambler

Scott is the Vice President, Chief Scientist of Disciplined Agile at Project Management Institute. Scott leads the evolution of the Disciplined Agile (DA) tool kit and is an international keynote speaker. Scott is the (co)-creator of the Disciplined Agile (DA) tool kit as well as the Agile Modeling (AM) and Agile Data (AD) methodologies. He is the (co-)author of several books, including Choose Your WoW!, Refactoring Databases, Agile Modeling, Agile Database Techniques, and The Object Primer 3rd Edition. Scott blogs regularly at ProjectManagement.com and he can be contacted via PMI.org.

scroll to top
We use technologies such as cookies to understand how you use our site and to provide a better user experience. This includes personalizing content, using analytics and improving site operations. We may share your information about your use of our site with third parties in accordance with our Privacy Policy. You can change your cookie settings as described here at any time, but parts of our site may not function correctly without them. By continuing to use our site, you agree that we can save cookies on your device, unless you have disabled cookies.
I Accept