Strategies that Enable Agile Governance

 

The following diagram overviews how the Disciplined Agile (DA) toolkit enables agile delivery governance.  There are two aspects to this diagram: Strategies followed by an agile or lean delivery team that enable governance and the external workflow with people or groups outside of the delivery team that support agile delivery governance.  In this blog posting we overview the strategies.

The diagram above called out several agile strategies that support the governance of disciplined agile delivery teams. These strategies are:

• Enterprise awareness. Enterprise awareness refers to the concept that disciplined agile teams realize that they work within your organization’s enterprise ecosystem, as do all other teams.  There are often existing systems in production 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 production instead of reinventing the wheel.  They will work with other teams that are working in parallel to them, striving to leverage each others work.  They will work towards your organization’s business and technical visions.  Enterprise awareness is the underpinning of effective governance.
• Release planning. Early in a project, or when a product team is first initiated, a disciplined agile 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 projected schedule and cost.
• 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, 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. Your team management tool could record when a work item is defined, when work begins on it, when the work is validated (if appropriate), and when it is marked done. This sort of information can be recorded in a data warehouse and later reported on using business intelligence (BI) tooling via a project or portfolio dashboard. In the first DAD book we referred to this strategy as development intelligence (DI) and since the book was published this strategy has become very common within agile teams.   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).
• 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.
• 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.
• Demos. On a regular basis, typically at the end of each iteration for teams following the Basic/Scrum-based lifecycle, the team either demonstrates the solution to key stakeholders. The team shows completed work and invites feedback. This practice is also called stakeholder demonstration or sprint demonstration.  This enables effective governance by increasing transparency and providing better opportunities for stakeholders to steer the team.
• Coordination meetings. The team meets for a few minutes, typically at the beginning of each day, to coordinate their activities.  The team lead 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.  This enables tactical governance within the team itself through increasing internal transparency and reducing the feedback cycle within the team.
• Light-weight, risk-based milestones. Effective milestone reviews are as simple and short as possible. For a small co-located project teams milestone reviews could be as simple as a few people from the governing body, or their agents, to visit the team room and have 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 recording of action items from the review. With adoption of common agile practices such as stakeholder demos and team dashboards, described earlier, there will be less need for status discussions in milestone reviews.  The milestones suggested by the DA toolkit 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.  Light-weight, risk-based milestones
• Retrospectives.  A retrospective is a facilitated reflection meeting performed by the team, the goal of which is to identify potential areas of improvement. Retrospectives often last thirty to sixty minutes.  Retrospectives help teams to be more self aware and improvement focused, supporting your overall governance goal of continuous improvement.

These strategies support a light weight 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.  The bottom line is that you are being governed and we believe that you deserve to be governed well.  For more on this topic, we suggest reading the article Governing Agile Teams.