Disciplined Agile

Governance Practices

The following process goal diagram overviews the potential activities associated with a disciplined approach to governance. These activities are typically performed by a variety of people within your organization. In the Disciplined Agile (DA) tool kit each of the process blades includes activities around governing the activities encapsulated by that blade. For example, the Enterprise Architecture blade includes architectural governance activities and the Data Management blade includes data/information governance activities.
Governance Goal Diagram

Figure 1. The process goal diagram for governance. 

The process decision points that you need to consider for governance are:

  1. Coordinate governance views. There are many individual functional governance area, including financial governance, security governance, data governance, IT governance, and more. Too many organizations make the mistake of treating each of these issues separately, which is easy enough to do given the different focus of each one. The DA tool kit promotes a more holistic, integrated view that results in a streamlined, consistent, and effective governance strategy.
  2. Guide measurement program. Metrics identify the measurements that you will take to gain insight into what has happened, what is happening, and hopefully what may happen in the future. The least effective approach to metrics is to have a standard set that all teams are expected to collect whereas the most effective is a context-sensitive approach such as an agile implementation of goal question metric (GQM). The measures themselves can be collected either manually or automatically (usually as the result of tool or system usage). We have found that a combination of the two is required—although automated metrics are inexpensive, accurate, and real-time you cannot always automate all of the measurements that you need to collect.
  3. Govern governance. If your governance efforts aren’t being governed, how do you know whether they’re effective?  Or worst yet, are they causing more harm than good? In DA we believe that all aspects of your organization should be well governed, including your governance efforts.
  4. Monitor teams. Information radiators and visual controls are sufficient in smaller organizations, but automated dashboards in combination with direct interaction with teams are also needed in modern enterprises. Traditional strategies, such as status reports or status meetings, do not prove to be effective in practice nor do they always provide an honest assessment of what is actually occurring.
  5. Develop guidance. An easy and important way to support governance within your organization is to have commonly accepted guidance, including standards and guidelines, for teams to follow. Guidance is ideally developed collaboratively with a combination of practitioners and experienced enterprise professionals who understand the bigger picture. Guidance should be written so that it defines enabling constraints wherever possible.
  6. Document guidance. We suggest that you keep this guidance concise and consumable, starting with high-level rules but aiming towards principles whenever possible.
  7. Define roles and responsibilities. The definition of roles and responsibilities is an important aspect of your overall governance strategy as they describe what is expected of people. The DA tool kit describes general team-level roles and responsibilities as well as specialized ones that are specific to a given process blade.
  8. Address enterprise risk. Small risks on individual teams can add up to a large risk across your organization. For example, if many teams adopt a new and relatively unproven technology and that technology is then abandoned by its creators then you have a serious problem. Similarly, when multiple teams start addressing a similar business opportunity and that line of business dries up or is legislated away you have a serious problem. Although risk is addressed at the team level via the Address Risk process goal, the focus here is on organization-level risk.