Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Governance for Agile Projects

Governance for Agile Projects

This item in japanese

The Agile Governance conference defines governance as:

the alignment of an initiative (project, programme or product development) with organisational goals to create value.  Governance defines how the initiative is set up, managed and controlled.

At the Agile Governance conference on May 13 in Amsterdam thought leaders and practitioners will show how governance can support self-organized teams and agile projects in delivering value to their stakeholders.

Andrew Craddock will give a talk at the conference about properly governed Agile projects. InfoQ did an interview with him about what agile governance is and why you need to embed governance practices into your agile development process.

InfoQ: Can you share your view of what agile governance is?

Andrew: For me, governance is about two things.  The first is about ensuring that we are running the right projects i.e. projects that are properly aligned with the needs of the sponsoring business and for which there is good justification.  The second is about, ensuring that what is delivered by a project is compliant with applicable legislation and corporate policy.  Agile governance focusses on how this should be achieved in an Agile project - in a way that is both genuinely effective and in a way that does not interfere with the Agile way of working.

InfoQ: What makes agile governance important? Which benefits can it bring?

Andrew: If we accept that governance is important, in some cases essential,  and if we want to work in an Agile way then it is essential that governance is tuned to the Agile way of working.  In most organisations,  governance customs and practices assume a traditional 'waterfall' style of development and align governance with the documentary artefacts that support that approach.  In truth, this is often only partially effective in non-Agile projects and is fundamentally incompatible with Agile philosophy.  With Agile governance we can change the focus from being an exercise in overcoming bureaucratic hurdles into something that will genuinely help projects be more successful in terms of delivering real value to the business in a timely and incremental way.

InfoQ: Can you give some examples of governance practices that helps agile projects to be successful?

Andrew: As regards general project governance - associated whether projects are (and remain) viable from the point of view of return on investment - it is important to tie approval and ongoing monitoring in with the Agile philosophy of keeping documentation as lean as possible and the concept that detail of requirements and solution will emerge over time.  DSDM provides an excellent framework for this and it is part of the subject of my presentation at the Agile governance conference on May 13th.

As regards governance associated with regulatory or other standards - it is important to tie this directly to what the development team are doing, when they are doing it…  I.e. making compliance needs part of the Iterative Development process.

InfoQ: Can you elaborate on different ways for enterprises to do agile governance?

Andrew: The big difference between Agile governance and traditional governance is the alignment with the value statements in the Manifesto for Agile Software Development where Governance should be more closely aligned with: Individuals and Interactions rather than Processes and Tools; with working solutions [more than just software] rather than comprehensive documentation; with Customer collaboration rather than contract negotiation; and with Responding to change rather than following a plan.

InfoQ: How can enterprises govern that their projects will adhere to the agile manifesto without becoming bureaucratic?

Andrew: I saw a presentation a decade or more ago by Jim Highsmith - he made two points that I really took to heart.  1) that 'documentation' is not the same thing as 'understanding' and 2) that 'formality' is not the same thing as 'discipline'.  In recent years I have added one of my own 3) that 'bureaucracy' is not the same thing as 'quality'.  The enterprises you refer to really need to understand these three things.  They need to break away from the false sense of security that comes from bureaucracy and really start owning projects and the issues associated with them. Hopefully my presentation on the 13th will show how this can be achieved without it being a big and scary jump into the unknown.

InfoQ: Some people say that they prefer doing agile over being agile? What your opinion? Is governance more about being agile, doing agile, or both?

Andrew: I honestly don't think you can 'do Agile' effectively if governance customs and practices and your way of working are not aligned.  A project team could 'do Agile' but would struggle to prove that what they are proposing to do (or are doing) is valuable to the business and that the products they are producing are compliant with corporate and regulatory standards.   'Being Agile' is about taking the problem beyond the detailed mechanics of building software, beyond the confines of an individual project, into the realms of really being able to exploit the philosophy of Agile in a wider business context.   'Doing Agile' may be a good first step in a journey to 'being Agile' but it is only that…  A first step.

Rate this Article