Is “Agile Governance” an Oxymoron?
Project sponsors, typically C-level business executives accountable for project spending and outcomes, can be excused for being sceptical about Agile project delivery approaches because there is a perception that they don’t support governance. Agile should not be ignored though, because it is proving to be a more effective way to deliver change faster and in a more flexible manner. In contrast, traditional methods used for delivering software solutions have not been very successful, industry studies (e.g. Standish Group research) have been reporting failure rates above 60% consistently for many years.
The challenge is to apply Agile successfully to enterprise-wide solutions with large budgets, and more stringent investment approval and governance requirements. Many successful Agile projects have been small and focused, targeting relatively simple solutions with few integration points and small co-located teams.
What is governance in the context of enterprise solutions?
Large, complex enterprise-scale programmes and projects, such as the development of core systems, are usually governed by strict controls. The controls are understandable as these initiatives involve significant investment of financial and other resources and introduce significant risk to the organization. In this context, governance – which is aimed at achieving business outcomes and essentially defines decision-making responsibilities – includes upfront investment approval and oversight of project execution.
Upfront, a business case with quantified costs and benefits is typically used to gain investment approval. The costs are estimated based on a scope of work and defined work products or outputs.
During execution, the project steering committee would hold the sponsor accountable through regular progress assessments against a plan that includes defined outputs. Significant risks and issues are reviewed for a decision on what to do about them.
There are various levels of governance, which the investment committee delegates to the project sponsor, who would delegate to the project manager in turn, and so on. The fundamental point is that funding is tied to a defined final work product.
Do Agile approaches contradict traditional governance when used for enterprise-scale initiatives?
There is usually a change required in governance processes because linear, Waterfall approaches are often tightly integrated with governance steps. However, this process change is not fundamental because the principles remain the same.
1. Investment governance
Agile approaches aim to release working software into production more frequently to prove whether the solution will be used and provide an early indication of whether the benefits are likely to accrue. In principle, Agile approaches support the main goal of governance which is to achieve business benefit from investments. However, the fact that there is less certainty regarding the form/specification of the final solution is a cause for concern to the investment committee. They need to bear in mind that the apparent certainty provided by the rigid specification of traditional waterfall approaches is an illusion: software-based projects are notorious for being late and over budget due to inaccurate upfront estimates.
Recommendations for project sponsors planning to use Agile approaches:
-
- Ask an experienced Agile practitioner to explain Agile principles and successes, and use this to educate the investment committee
- Request a high-level effort and cost estimate based on a short analysis cycle for a subset of requirements extrapolated to the full set of requirements, and use this to secure an initial budget
- Use the practice of continuous releases of production software to provide additional visibility of progress to the investment committee
2. Architecture governance
Agile approaches do not naturally lend themselves to Architecture governance as the architecture of an Agile solution emerges rather than being specified in detail before building the solution. For enterprise-scale solutions, this approach can lead to significant issues due to the greater level of integration and importance of non-functional requirements, such as security and scalability.
Recommendations for project sponsors planning to use Agile approaches:
-
- Facilitate engagement between the Architecture function and the Agile solution team to agree on the level of architecture detail that is required before the solution build commences and how the architecture will be defined during the build process
- Facilitate ongoing communication and synchronisation between the Agile solution team and enterprise support functions such as Architecture, Marketing and others
3. Project governance
The main conflict between Agile approaches and typical governance processes usually occurs at the project level. The structures and tools employed for governance are often tightly integrated with linear, waterfall approaches. For example, the project governance approach expects documented specifications, whereas Agile approaches do not track progress against such specifications.
Recommendations for project sponsors planning to use Agile approaches:
-
- Use a high-level definition of the solution as the basis for the Agile solution team’s mandate
- Insist on a detailed definition of each iteration before that iteration is commenced
- Ask the Agile solution team to define how they will build confidence – through practices such as frequent reviews, burndown charts and visible storyboards
Conclusion
Although Agile governance is not an oxymoron, the project sponsor needs to understand and communicate the required changes to be successful. The biggest change is at the project governance level, where plan-based, Waterfall delivery approaches tend to be tightly integrated with project governance activities. Like any change, strong leadership – from the project sponsor in this instance – will create the necessary change momentum.
