Traditional project governance is used to describe the rules and processes that are required to ensure a successful project. Traditional governance tries to manage the project work as process work. However, the use of time sheets, costs, and schedules far outweigh the more important issues like project benefits, risk management, stakeholder involvement, quality, scope, and objective control. At first glance the concept of governance and Agile seem to be incompatible, however most Agilists would agree that just enough governance might do more good than bad for the Agile project.
Andrew Clifford suggested the following benefits of governance,
- Improved shareholder value because IT systems are managed as business assets.
- Improved business IT relationship because IT infrastructure requirements are translated to measurable goals.
- Improved return on investment on IT infrastructure investments because management can track and enforce use of new infrastructure.
- Reduced project failures because technical and compliance issues are identified earlier.
- Reduced cost of compliance with regulations and internal standards because these are managed within an efficient framework.
- Reduced long-term risks and costs due to fragmentation of standards because management have visibility of the degree of compliance.
- Improved measurement of IT's performance in its role as stewards of business systems, which is particularly valuable for governing outsourced contracts.
Matthew D. Laudato suggested that though governance is often a hard part for engineering to swallow however, the budget granted to IT has to be accounted for by the VP or CIO. He recommended that governance should become a part of the Agile process. According to him,
It makes sense to add a step in the process at sprint review time (the post-evaluation that occurs at the end of each sprint) to formally document the project progress in a form that is useful for the rest of the business. Included in this report should be at a minimum what features were completed, what the cost of these features are, what the roll-out plan is for these features, and what percent of the known requirements have been satisfied to date.
Toyota’s Takeuchi and Nonaka, had the following view on governance
Although project teams are largely on their own, they are not uncontrolled. Management establishes enough checkpoints to prevent instability, ambiguity, and tension from turning into chaos. At the same time, management avoids the type of rigid control that impairs creativity and spontaneity. Instead, the emphasis is on “self-control”, “control through peer pressure” and “control by love
According to Ross Pettit, Agile governance comes down to answering two questions
- Are we getting value for money?
- Do solutions delivered meet our full expectations?
The first question talks about effectiveness of money spent as it attempts to answer fact-based measurement of outstanding scope, work completed, total expenditure, and trend with accuracy. The second question is about completeness of the solution to address full range of corporate policies, including security, architecture, quality, risk, and so forth. Ross suggested that a good governance would lead to
A reduction of "surprises," an increase in trust and confidence, and execution aligned with strategy - make IT less mired in its own problems and, subsequently, better able to be responsive to the business.
Thus there is enough justification on the importance of governance and the benefits it can bring to the project however, what is the best way to introduce governance in an Agile project?
Ross suggested the following approach,
- If governance is to be an enabler of agility, it cannot be a burden in day-to-day operations. To satisfy this, there must be non-burdensome and consistent ways to collect data across the organization.
- To assess solution completeness, IT governance must have the active participation of the entire department, including security, infrastructure, architecture, risk management, business management, the PMO, and so forth. Subsequently, there must be participation from across the entire set of IT disciplines.
- IT governance cannot become an esoteric high religion, and must instead be "part of the furniture." We must be able to communicate to all stakeholders in "native languages," and most importantly communicate in business terms to the business.
Dean Leffingwell suggested the following approach for defining a lightweight governance process. According to him, the governance model should
- Create Agile guidelines to suggest what Agile means to the company and unambiguously define Agile mandates in terms of unit testing, retrospectives, standups etc.
- Be lightweight not more than 3-5 pages.
- Recommend but not over prescribe.
Thus Agile governance serves as a perfect glue between management and IT. The key is not to overdo it lest it should kill the creativity and enthusiasm of an Agile environment.