Governing Agile Teams – Part 2 of 2

Agile teams are being governed, and often not governed well. That is because agile teams work in a much different manner than teams working in a traditional manner. All teams, regardless of their approach, deserve to be governed well. The implication is that agile teams must be governed in an agile manner. In Part 1 of Governing Agile Teams, we worked through what is agile team governance is, perhaps more importantly what it isn’t, and why it is an important success factor for your organization’s agile strategy. In this second part of the two part series, I explore the strategies that enable governance within an agile team and how the rest of your organization supports agile team governance.

I use the term Disciplined Agile (DA) team to refer to a team that is following an agile, lean, or hybrid approach. An important aspect of a DA team is that they realize that they are being governed, they hope to be governed well, and they work with the rest of their organization to support their governance efforts. There are, of course, more aspects to a DA team than this, but that is beyond the scope of this article. I suspect one of the reasons why many organizations are struggling with the governance of agile teams is because many agile frameworks downplay or ignore governance issues. DA doesn’t take that approach.

Figure 1 gives an overview of how the DA tool kit enables agile team governance. There are two aspects to this diagram: 1) Strategies followed by an agile or lean delivery team that enable governance and 2) the external workflow with people or groups outside of the delivery team that support agile governance. I explore both of these topics in detail below.

Strategies that Enable Team Governance

Figure 1 calls out several agile strategies that support the governance of DA teams. These strategies are:

1. Enterprise awareness. Enterprise awareness refers to the concept of DA teams realizing that they work within your organization’s enterprise ecosystem, as do your other teams. There are often existing solutions (products and services) that should not be negatively impacted by the release of the solution they are working on. Better yet, their solution will leverage existing functionality and data available in your operational infrastructure instead of reinventing the wheel. DA teams will work with other teams that are working in tandem with them, striving to leverage each other’s work. They will work towards your organization’s strategic vision. Enterprise awareness is the underpinning of effective governance.
2. Release planning. Early in a project, or when a product team is first initiated, a DA team will invest some time in high-level release planning. They do this to identify and think through any dependencies on other teams and often to identify a reasonable cost and time estimate for the current release that they are working on. They will keep this high-level plan up-to-date as development progresses, sharing it with their stakeholders. Release planning enables the team to answer critical governance questions regarding forecasted schedule and cost.
3. Team dashboard. The basic idea is that the tools used by your team should be instrumented to record important events when they occur. For example, your work management tool could record when a work item ticket is defined, when work begins on it, when the work is validated (if appropriate), and when it is marked done. Within a software team, whenever a build is run, your build tool could record basic information such the date and time it was initiated, the time it took, the number of tests run, the number of successful tests, and so on. This sort of information, or more accurately intelligence, can be recorded in a data warehouse and later reported on using business intelligence (BI) tooling via dashboard technology at the team, program, or portfolio, or enterprise level. The real-time, accurate information radiated by a team dashboard enables the team to make better decisions and provides better transparency to stakeholders (including governance people).
4. Information radiators. An information radiator is a visible display that shows something of interest to a team or their stakeholders. Examples include a whiteboard with an architecture sketch on it, a corkboard with index cards tacked to it, and a wall-mounted monitor showing the team’s dashboard. Information radiators enable better governance by increasing transparency.
5. Active stakeholder participation. Active stakeholder participation is the practice of having on-site access to stakeholders, or at least their proxies (i.e., Product Owners). Active stakeholders have the authority and ability to provide information and make timely decisions regarding the prioritization and scope of requirements. This enables more effective governance through improving the team’s access to decision makers.
6. Demos. On a regular basis, typically at the end of each iteration/sprint for teams following an agile life cycle or on an as-needed basis for lean teams, the team demonstrates the solution to key stakeholders. The team shows completed work and invites feedback. This enables effective governance by increasing transparency and providing better opportunities for stakeholders to steer the team.
7. Coordination meetings. The team meets for a few minutes, typically at the beginning of each day, to coordinate their activities. The team lead, who may be a Senior Scrum Master or Project Manager, facilitates the meeting and is responsible for keeping it short and focused. This practice is often called a scrum meeting or daily stand-up meeting, although neither of those terms accurately conveys the concept that the aim is to coordinate. This enables tactical governance within the team itself through increasing internal transparency and reducing the feedback cycle within the team.
8. Light-weight, risk-based milestones. Effective milestone reviews are as simple and short as possible. For a small co-located DA team, a milestone review could be as simple as a few people from the governing body, or their agents, visiting the team room and having the team spend an hour walking them through whatever is to be reviewed. For larger efforts, this could be upwards to half a day and be held in meeting room. Teams in regulatory environments may need to invest a bit more effort, particularly around creation and baselining of artifacts, to be reviewed and to have a recording of action items from the review. With adoption of common agile practices such as demos and team dashboards, described earlier, there will be less need for status discussions in milestone reviews. The milestones suggested by the DA tool kit are risk-based, not document based. For example, the Proven Architecture milestone is best fulfilled through development of beginning-to-end functionality that implements high-risk requirements, not the creation and review of an architecture model.
9. Retrospectives. A retrospective is a facilitated reflection meeting performed by the team. The goal is to identify potential areas of improvement. Retrospectives often last thirty to sixty minutes. Retrospectives help teams to become more self-aware and become improvement focused, supporting your overall governance goal of continuous improvement.

These strategies support a streamlined approach to governance while improving the overall effectiveness of the team. Where traditional governance was something to be dreaded, agile governance should be something to be welcomed.

How the Rest of Your Organization Supports Team Governance

Figure 1 calls out several important workflows with other groups or activities within your organization. This reflects the fact that team governance addresses a wide range of concerns, many of which affect your team. These external teams/activities support the governance of DA teams in the following manner:

1. Continuous improvement. People share improvement suggestions with each other to help spread good ideas throughout your organization.
2. Data management. One of the many important aspects of data management is to collect and share back, ideally in real time, intelligence about what a team is doing and how well they are achieving their outcomes. Data from outside of your organization will also be leveraged as available and as appropriate. They provide dashboard technology to the teams, perform data analytics on the gathered intelligences, and guide teams in the usage of data and data technologies. They will also develop, evolve, and support data-oriented guidance as part of your overall governance efforts.
3. Enterprise architecture. Your enterprise architecture activities may produce common roadmaps, models, and guidance for teams to follow. An effective strategy is to embed enterprise architects, often in the role of Architecture Owner, on DA teams to help ensure that the team follows architectural conventions and to provide a concrete feedback mechanism to the enterprise architects. The architectural guidance may include coding conventions, user interface conventions, security conventions, and many others.
4. Governance. Your organizational governance activities will often provide guidance, such as enterprise policies or value statements, that apply across your organization. It will also provide domain-specific guidance, for example data conventions, security guidelines, customer experience (CX) guidelines, finance conventions, and more. This guidance would be collaboratively produced, evolved, and supported with your organizations data management, security, design, and finance groups respectively (if you have them). The governance team will work closely with your legal team to identify, understand, and disseminate regulatory guidance to teams. Finally, the governance effort will leverage intelligence provided by data management to help identify how to best guide various teams across your organization.
5. Portfolio management. Your organization’s portfolio management efforts provide the initial team funding and vision to get them going, effectively giving them initial direction.
6. Stakeholders. A team’s stakeholders will provide direction to DA teams regarding what functionality they want and the priorities thereof. Stakeholders will also provide regular feedback and other forms of input to the teams. DA teams produce consumable solutions for stakeholders and provide visibility regarding what they are doing and how they are working – this provides stakeholders with greater transparency and opportunities to steer the teams.
7. Strategy. Your organization’s leadership team will drive your strategy, including the identification of your organizational objectives, values, desired outcomes, potential initiatives, and potential measures of success. Your strategy will be an important motivator for how you will govern your teams.

Concluding Thoughts

I end this article with the following observations:

1. Disciplined Agile teams are significantly easier to govern than traditional teams. This is the result of greater transparency, accurate and timely intelligence and greater opportunities to steer disciplined agile teams. 
2. Traditional approaches to governance are guaranteed to harm agile teams. The bureaucratic, documentation driven governance strategies of yesteryear provide little more than a governance veneer regardless of the paradigm being followed. Agile and lean teams must be governed in an agile/lean manner.
3. Disciplined Agile teams demand good governance. Your teams deserve to be governed well and should settle for nothing less.
4. Agile practitioners must be prepared to educate existing governance people. When you provide a coherent governance strategy to management, you are more likely to be governed effectively. My experience is that most existing governance strategies are still traditional in nature and this inappropriate for agile/lean teams. Worse yet, the people involved in the governance effort either don’t know that this is a problem or if they do,  they don’t (yet) understand how to govern in an agile manner.
5. Agile team governance is part of your overall organizational governance strategy. This is true of data governance, architecture governance, portfolio governance, and many other governance aspects. These other aspects of governance are addressed in the appropriate process blades and collated in Disciplined Agile’s Governance process blade.

This article has been adapted from Governing Agile Teams.