“Last year the decision was finally made to mandate Agile across our enterprise. The decision was taken, even though there were many unanswered questions. The assumption was that forcing the migration, along with adoption of popular “enterprise Agile methods” would ensure resolution of the outstanding questions. In practice, Agile methods have been very effective in delivering specific digital business initiatives. But almost inevitably the distribution and delegation of architecture has resulted in duplication, inconsistency and increased complexity, across all project types including legacy and new projects. We are now concerned that we no longer have an effective governance capability. The question is how do we fix this without losing the undoubted benefits of Agile methods?“ Enterprise Architect, F2000 company.

Over the past few months I have heard this message over and over again. While Agile is being successful, it is increasingly in conflict with broader goals. And this is clearly becoming a major issue, manifest in increased complexity, horizon of change and coordination issues as well as inconsistent customer experience.  I am now regularly advising a practical approach to resolution by addressing from the governance perspective.

In many organizations governance is still practiced by phase or stage gate peer review, and Agile projects are forced to accommodate, which leads to WaterScrumFall or worse. But governance criteria and policies are often very weak anyway, out of date or non-existent. Consequently governance is frequently a matter of opinion and experience, highly dependent upon the experience of individual reviewers. As we all know, a basic principle of Agile methods is delegation of responsibility, and ideally we need to delegate governance to the Agile practitioners and teams. So the question is how to implement self-governance and ensure quality and consistency of governance?

I think it was an old John Cleese training film in which Cleese himself plays the part of a manager telling a subordinate that he is now empowered, and he scatters magic dust over him and shouts some magic words saying, “You are now empowered!” Clearly this isn’t any more useful than telling an Agile team that they are now self-governing! Rather we need to go back to basics and define and communicate what governance is required and provide Agile teams with guidance on what is expected.

That sounds good in theory, except that in practice no one is going to be able to accurately define all the governance requirements; certainly not in a fast changing, Agile business and technology environment; nor will Agile development teams be able to keep up with a bureaucratic regime that continually issues edicts that everyone is expected to adopt.

What’s required is a governance system that works in an Agile environment. The parameters of the Agile governance system comprise:
a) A defined Agile governance model
b) Defined principles and reference architecture that establish ways of working together with articulation of business value
c) Automation systems that progressively incorporate the principles and reference architecture into frameworks, tooling, design time platforms, deliverable profiles and knowledge management systems.

d) A Community of Interest (CoI) responsible for the governance system and communications
e) A communication system that ensures Agile projects are fully implementing the governance system, and providing at least retrospective feedback to the CoI that contributes to a common asset base as well as practice maturity.

Agile Governance Model