An important, yet seldom discussed, topic is how do you govern agile software development 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 whether you are building 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 programming or database guidelines, or working towards a common technical or business roadmap, or inviting outsiders to attend your coordination meetings then you are being governed. In this blog posting we explore what is, and what isn’t, agile delivery governance
What Is Agile Delivery 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 delivery governance is the governance of agile delivery teams in a manner that reflects and supports the agile paradigm. We have identified the following principles for effective agile delivery governance:
- Collaboration with delivery teams is more effective than trying to force them to conform. IT professionals are 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 to do so. For example, if you want an agile delivery team to work towards a common technical strategy (perhaps captured by your organization’s technical roadmap) you are better off having people knowledgeable with that strategy to work directly with the team rather than forcing them to fill out specific documents that will be reviewed at some point. In this case the toolkit suggests the specific role of Architecture Owner who is responsible for this.
- 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 enable the teams to do those things, to make them easy to do. For example, say your organization wants developers to follow common coding conventions. One way to do this would be to hold code inspections, a time-consuming process, that validates whether the coding conventions are being followed. An easier approach would be to adopt a code analysis tool such as CheckStyle and include it in your continuous integration (CI) strategy. This automated approach requires no extra effort on the part of the developer and provides immediate feedback as to the quality of their code, providing them with a learning opportunity to help them improve their skills.
- 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 development 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 because the information displayed on the dashboards is automatically generated as a side effect of tool usage and therefore incredibly difficult to fake, whereas 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. In the original DAD book we referred to this strategy as development intelligence (DI).
- Transparency into teams is provides better insight than status reports. Through application of strategies such as information radiators, team dashboards and active stakeholder participation, the work of a disciplined agile delivery team is effectively transparent. 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 Delivery Governance?
Governance often has a bad name with developers, 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 delivery 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, as you will soon see, the milestones suggested by the DA toolkit are risk-driven, not documentation driven.
- Onerous. An onerous governance strategy will not be followed by delivery teams, at best they will do just enough work to make it appear that they are following the governance process, which implies that the process has utterly failed. As a result we’ve kept the governance strategies as light-weight as we possibly can, and when you do it right effective governance actually improves the productivity of delivery teams instead of detracting from it. These light-weight strategies are described below.
- 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. Our philosophy is that you deserve to be governed well, which is why we’ve taken the time to describe how to do so.
You are being governed. We believe that you deserve to be governed well. For more on this topic, we suggest reading the article Governing Agile Teams.
