Governance in an Agile World
Introduction
It is important to understand the useful distinctions between a project governance method and a software engineering method. It can be argued that to be effective it is necessary to have one of each; governance and engineering. Together this can be termed a project delivery method.
- Governance method: a style of control to measure project progress. Example: Prince2™, PMBOK, DSDM Atern, PrinceLite.
- Engineering method: the style of organisation for the software delivery. Example: waterfall, RUP/DSDM (iterative delivery), Scrum/XP.
- Delivery method: a combination of governance and engineering methods. Therefore it is possible to combine Prince2 and Waterfall, or PMBOK and RUP, or PrinceLite and iterative.
Many organisations fail to implement a unified delivery method. They believe that because they have, for example, implemented Prince2, that this is sufficient. They are unaware of the interplay between governance and engineering.
Project control exists on two levels. There is internal control within the engineering method, and there is external control (management control) represented by governance.
A governance method measures the effectiveness of engineering progress. It can be argued that if the projects are being delivered satisfactorily, then governance is unimportant. This is the outlook of the Agile engineering community.
This paper introduces the fundamentals of agile in the context of Scrum/XP as an engineering method for delivering software. It then explores how PrinceLite can be used as appropriate companion governance method because of its emphasis on requirements management.
What is Agile?
Agile is a word that has a particular connotation in software engineering circles. The most famous Agile methods are Scrum and XP both of which are software engineering methods. Scrum/XP are primarily concerned with organising themselves to respond to emerging requirements. These two methods are very similar but not identical (http://blog.mountaingoatsoftware.com/?p=8). Here we will specifically discuss Scrum.
Scrum is an approach to building software. The word ‘Scrum’ comes from the game of Rugby where it is necessary for the entire team to move up the field as a unit in order to score. It is appropriate where the culture of the organisation is receptive to an upfront acceptance of uncertainty. Uncertainty is caused by business requirements being only partially understood. Successful Scrum implementations are characterised by small motivated teams, being comfortable with changing requirements, and little traditional project governance.
Therefore an organisation that is familiar with large teams, ‘complete’ specifications, and significant governance will often be resistant to Scrum principles.
Requirements Uncertainty
Uncertainty in planning arises from uncertainty of business requirements. PrinceLite addresses this fact by layering business requirements into a hierarchy of requirements abstraction; high level (more abstract) to low level (not abstract). The objective of this approach is to insulate requirements change to the lower levels. Thus the high level requirement to ‘Place an order’ is liable to remain stable regardless of the requirements implementation that may change during a software release once the stakeholders have had sight of the result.
PrinceLite puts light emphasis on the production of project artefacts other than those necessary for the management of business requirements. The effect of this approach is to insulate the ‘Product backlog’ (Business requirements specification) from iterative change. Where the requirements are insulated from change at the business level of representation (high), the management of those requirements is simplified. This has the effect of contributing to a planning round that is less susceptible to uncertainty based on the requirements changing, because all that is liable to change is the requirements detail; how the requirement is satisfied.
PrinceLite advocates high level requirements captured in a combination of use case model, activity diagrams and user stories. PrinceLite iteratively refines requirements through project brief, PID and finally expressed in the business requirements specification. This is compatible with Scrum/XP where the project brief and PID may contain the high level requirements prior to the project having secured full funding. When the project begins, the Product backlog can be populated by the requirements captured in the PID.
High level requirements are contained in the PID. Implementation detail regarding requirements is articulated in the Product backlog. Requirements change is normally restricted to implementation detail. At the management level, it is generally possible to produce a robust model of what the system must do through the application of business requirements patterns.
PrinceLite is a good governance fit with agile methods because it insulates requirements change by employing an abstraction of requirements expression. The by-product of this approach is to combine the terminology of Prince2 (Project brief, PID) with the agile engineering method. This is an advantage because medium sized and large organisations have likely made a considerable investment in typical governance methods and are generally more comfortable with a planning approach predicated on reasonably stable requirements.
Conclusion
The uptake of agile methods is hampered by organisational cultures that are uncomfortable with the uncertainty that comes with an overt expression of business requirements that are expected to change. Although in many ways this is a statement of fact, it is not a welcome message. To stimulate the uptake and acceptability of agile methods, they would benefit from being combined with a governance method such as PrinceLite that expresses business requirements in a structure of hierarchical abstraction that insulates them from change at the management level. In addition, PrinceLite can be considered a dialect of Prince2. Therefore, those organisations that are currently committed to a Prince2 governance framework may be more receptive to the approaches of those practitioners who wish to work using an agile engineering approach, because requirements change management is restricted to the engineering domain. The governance domain remains considerably more stable and the planning cycle more traditional.
NOTE: a more complete paper is available on this subject from Public downloads link. Sign up from the menu bar to download a copy.