Directing Agile Change

Association for Project Management (APM)

• Publisher: Association for Project Management (APM)
• Year: 2016
• Print ISBN: 9781903494608
• eBook ISBN: 9781903494615
• Topic: Business
• Subtopic: Project Management
• Index: Business

"Agile working is increasingly recognised by organisations as a competitive advantage, where a speedier but controlled response is needed to changing environmental conditions. How should organisations oversee the delivery of agile projects? This guide provides the answer."Jennifer Stapleton, foreword author.Directing Agile Change is the latest offering from APM's Governance Specific Interest Group (SIG).Written by SIG members Brian Wernham, Adrian Pyne, Roger Garrini and Martin Samphire, this latest guidance is aimed at those involved in the governance of all change initiatives, with an emphasis on those at senior level – board members, sponsors and stage gate reviewers etc.Divided into five main sections, the guide covers the main principles of agile governance, when to adopt an agile approach and, importantly, how to gain the most value from being agile. Also included are checklists to adopt and key questions to ask.Directing Agile Change is the first 'how to' agile guide published by APM. It seeks to recognise that agile is not limited to software development but can also be applied to many aspects of an organisation.

1

Context and introduction

1.1 Agile

“Agile is a state of mind”, says Steve Messenger, chair, DSDM Consortium (see Appendix B).

‘Being agile’ requires new behaviours as well as different procedures:

• within projects and/or programmes (referred to hereafter as ‘projects’);
• across the organisational environment of projects (referred to hereafter as ‘enterprise project management’).

At the core of agile is the requirement to exhibit core values and behaviours of trust, flexibility, empowerment and collaboration.

Collaboration rather than confrontation is the focus in the agile approach. Traditional ‘waterfall’ project management approaches seek to capture up front the detailed requirements for a product or service, put it into a contract-like specification and then assume that little will change. Agile recognises that user needs and the environment into which projects are delivered change. Agile builds in from the outset the ability to change priorities and elaborate requirements as more is understood about the service or product. Sometimes a ‘hybrid’ approach can be used with some activities being ‘agile’, and some being ‘waterfall’.

Traditional planning assumes that few changes of course will be required from inception to completion. But where innovation is required and uncertainty exists, then changes of ‘tack’ may frequently be needed. Some elements of a programme may be more certain than others, in which case a ‘hybrid’ approach may be optimal. These differences in approach are illustrated in Figure 1.1.

Good governance of project management is described in the APM guide Directing Change, which should be read alongside this guide. To avoid repetition, throughout this guide, the word project will mean equally project, programme or portfolio as explained in APM Body of Knowledge.

Figure 1.1 Key differences in approach and concept from traditional project management

1.2 Research

The Standish Group released an annual report called the Chaos Manifesto. Its 2012 report stated that agile projects succeed three times as often as waterfall projects (see Figure 1.2).

Notice that there was no significant change in the percentage of ‘challenged’ projects between categories.

Figure 1.2 Chaos Manifesto output

APM research into the Conditions for Project Success, has similarly found that smaller, shorter projects had a significantly higher success rate than bigger, longer ones.

1.3 Using agile

Sometimes a traditional approach will be optimal. Agile works where the business requirement has cost and time parameters that are ‘hard’ and the prioritised scope and benefits are ‘soft’. Agile project management focuses on delivering maximum value against business priorities in the time and budget allowed. Lessons are learned from the feedback from practical implementation. Good project management disciplines are still applied, irrespective of whether agile, waterfall or a hybrid approach is adopted.

How much time should be spent upfront in a project developing appropriate delivery strategies and plans? We take the view that ‘just enough’ (to avoid near term nugatory work) strategy, architecture and planning work should take place before starting development activities.

Agile may present other challenges to an enterprise including:

• having a consistent method for incremental delivery at the heartbeat of the business, not at the convenience of the project team;
• evolving solutions with stakeholders;
• building teams with accountability and authority to benefit the business;
• maintaining alignment of development activities and product releases with strategic business objectives.

Here we focus on the governance of agile projects not agile development methods with a set of principles and behaviours that will facilitate any of the major popular ‘agile’ methods.

1.4 Agile development methods

Agile working is not limited to software development, but can also be applied to many aspects of an organisation. A list of common agile development methods that claim to follow the Agile Manifesto are summarised in Appendix B.

1.5 Agile myths

Table 1.1 Myths about agile governance

Myth	Reality
Agile is only for stars.	Agile working produces best value when there are capable agile project teams, operating in a supportive agile landscape. To gain value from agile governance, organisations need to invest in it.
Agile does not fit our culture.	Wh...

Table of contents

• Copyright Page
• Contents
• Figures and tables
• Foreword
• Acknowledgements
• Chapter 1. Context and introduction
• Chapter 2. Principles of agile governance
• Chapter 3. When to adopt an agile approach
• Chapter 4. Gaining value from agile
• Chapter 5. Governance guidance lists
• Appendix A: References and further information
• Appendix B: Compendium of agile development methods
• Back Cover