1. Agile project management methods can be applied to business change projects to address common challenges like lack of prior knowledge, underestimating resistance to change, and focusing on too many changes at once. 2. The author proposes an "Agile for Change" approach using iterative development cycles to deliver change in small, prioritized increments with feedback between cycles. 3. User stories are used to describe small, measurable elements of capability to be implemented incrementally to stay focused yet flexible.

1. 1
Managing business
change projects with Agile
Adam Humphrey
INTRODUCTION Delivering successful business change is the goal of many projects,
whether through deploying new facilities/systems, improving processes,
developing people or other improvements.
But executing successful business change is never easy so having the best
possible approach or framework is important. Agile methods are mature
and widely recognised and Agile Project Management methods now exist
which can be applied in a range of situations outside software
development.
This article looks at how agile methods address the challenges of business
change projects and proposes a specific approach.
COMMON
CHALLENGES
Lets start by looking at common difficulties with traditional approaches
to business change:
 Work is planned as though we know precisely the required change
up front, although in practice we may not know what works until
we see it
 There is often limited prior knowledge/experience available to
build on
 A sequential specify> develop>implement approach is adopted
with the change all bunched up at the end
 We try to change everything, rather than focus on the easiest or
most useful changes first
 Too much time is spent on design (e.g. highly crafted
communications packs) rather than putting outputs to the test to
see if they work
 Implementation is a one-way process from project team to
business
 Not enough time/resources are allocated
 Resistance and the time taken to achieve change are often
significantly underestimated
 It is hard to adjust the rate of change to one that people can
accommodate, taking into account other changes also going on.

2. 2
HOW CHANGE
HAPPENS
Business change is all about people. If we look at our personal experience
of change – such as the way we learnt a new sport or skill we see that
common patterns emerge.
We tackle things in steps or chunks (we don’t expect to become a national
champion in a few weeks). We vary aspects such as the equipment we
use, the environment in which we do things (on our own or in a club), our
mind set/ approach etc. Sometimes we are quite experimental - trying
something novel which just might work.
In all of these we learn from the things that work, and the things that
don’t. We experience problems or setbacks we hadn’t anticipate but track
our progress and are encouraged by our successes. We learn from other
people, sharing knowledge through clubs and communities.
And of course it takes time to improve. Sometimes we get far enough and
stop at that point. We may pause to consolidate/rest before coming back
and progressing further. Often we get results we didn’t expect which
cause us to adjust our goals and go in a slightly different direction that
suits us better.
These are all characteristics of what we might call an agile approach.
AN APPROACH
FOR CHANGE
So let’s consider why an agile approach might work well for business
change:
 It involves collaborative working between the solution team and
the business with an emphasis on good communications
 It develops and delivers change in modest sized steps at a rate
which can be adjusted
 The success of one step encourages those involved to tackle more,
reducing obstacles and resistance to change
 The results of deployment steps quickly verify our approach (or
redirect it)
 Some results and benefits are achieved early on (quick wins)
 Work is prioritised to using a mutually agreed scheme such as the
most important, beneficial or easiest first

3. 3
 Unnecessarily complex features and gold plating attracts a low
priority in comparison to value-adding steps
 Small steps means lower risk and lower impact on business as
usual.
AGILE BASICS The essence of agile is using a closely integrated development/user team
to perform a series of incremental, iterative developments that target
priority areas. These are deployed with feedback on the results used to
inform subsequent development increments.
There are now well established frameworks, techniques and tools which
can be applied to a whole range of business problems. One such
framework is the Agile PM Method which provides a framework suitable
for many business situations.
Because the agile approach is taken from the world of software
development, much of the literature mixes software development and
management ideas together as one and some care is needed to separate
out the project management concepts. That said there are many useful
ideas which can be re-applied outside software development.
AGILE FOR
CHANGE™
I advocate a structured approach to business change developed from
agile concepts. I call this approach Agile for Change™ and it is based on:
 Clearly defined change objectives or vision
 An iterative approach which implements the whole change cycle
 An incremental approach which delivers change in steps
 Collaborative working between the developers of changed
processes, facilities, structures and the communities using them
 Remaining in control through incremental and iterative working
 Measurement of results/achievement, both to demonstrate
business value and to motivate the team.
Using an iterative approach means completing the whole change cycle
with a partial solution. So if the change is to improve training, we create
some training materials, deliver the training, evaluate attendee’s
responses and assess resulting changes in performance. This ensures we
have a training approach which works before doing too much.

4. 4
An incremental approach means delivering the results in chunks building
one on another. In the training situation above, we would deliver the first
training unit then select the contents of the second training unit based on
a reassessment of priorities and benefits. [It could be a new training
topic, a refinement of the first topic, or a repackaging of the first topic for
a different audience.]
Despite the flexibility of iterative and incremental approaches we need to
stay in control so we don’t jump haphazardly from topic to topic or allow
work to go outside scope. How we will assess results (measures) must be
chosen with care as they will usually drive people’s behaviour. They must
also be simple and practical to make.
USER STORIES Effective control is achieved through user stories. Stories are used in agile
software development to describe ‘bite size’ elements of functionality. In
a change project we can use the same construct to describe small
elements of capability to be implemented incrementally.
Stories consists of a short text statement with a standard structure:
As a: role/function/name, I/we can: description of capability, so that:
business result, measured by: measure. Stories may be developed by
brainstorming and then selecting/prioritising. Analysis, grouping and
refining the stories gives the flexibility to develop iterations and
increments while remaining in control.

5. 5
PROJECT
LIFECYCLE
A typical change project lifecycle comprises:
Having defined the high level objectives and initial set of stories are
created. If possible these should frame the overall scope of the project.
Prioritising stories for development can take account of a whole range of
factors including the importance of the results, but also what can be done
easily or quickly with available resources.
Change ‘ingredients’ are those things we need to design and construct
(often called enablers) and can encompass working processes, structures,
responsibilities, skills, tools, training materials etc.
Stories are refined in the light of results which might indicate larger or
smaller steps and the cycle ceases when the objectives have been met or it
is considered that sufficient change has been achieved.
There are widely available tools (many are free) for creating and tracking
the progress of user stories although practical experience is that tools are
relatively unimportant and that simple techniques such as index
cards/white boards are as good or better.
CONCLUSIONS I believe the agile approach is well suited to the challenge of business
change.
I have shown how specific agile techniques such as user stories can be
applied to business change situations to provide an approach which is
flexible, disciplined and results-focussed and provides and effective
approach to this vital category of business projects.
Adam can be contacted via mail@effective-projects.co.uk