We had a great conversation at the CMP October Event. Here are some highlights including definitions, myths and break out group summaries!

1. Agile and Change
Management
… a relationship…
1

2. Let’s get to know each
other…. 2… we have soooo much in common! Let’s date! 

3. Opportunities 3
US!!! 

4. Common Myths
• Continuous deployment means too much or more
change fatigue
• I can’t see Agile working with all the change
documentation we’re supposed to do
• Change in the middle of the project means everything
changes, just when I planned it all!!
• I don’t have time to go to all the stand-ups, retros,
showcases… What are they anyway?
• Agile means we stand up all the time*
4
* partly true, sorry…

5. Agile Values
• Formalised by a group of software development experts
in 2001:
• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan.
Followed up by a number of principles…
5

6. Agile Principles
• Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.
• Welcome changing requirements, even late in
development. Agile processes harness change
for
the customer's competitive advantage.
• Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.
• Business people and developers must work
together daily throughout the project.
• Build projects around motivated individuals.
Give them the environment and support they
need,
and trust them to get the job done.
6
• The most efficient and effective method of
conveying information to and within a
development
team is face-to-face conversation.
• Working software is the primary measure of
progress.
• Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.
• Continuous attention to technical excellence
and good design enhances agility.
• Simplicity--the art of maximizing the amount
of work not done--is essential.
• The best architectures, requirements, and designs
emerge from self-organizing teams.
• At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.
We follow these principles:

7. Common Definitions
Burn up chart
• A visual map of how the project is progressing. It is visible at
all times on the team wall.
• This chart allows a Sponsor, Project Manager, Team and
stakeholders to understand progress of the project, so they can
make timely and informed decisions throughout the project.
Definition of 'Done'
• The universal term that defines the work being complete. They
key is... the team decides together.
7

8. Common Definitions
Estimation sessions
• A meeting organised within the project team with
representatives from everyone taking part in the work. The
team work together to apply relative weightings on each user
story to represent effort required to deliver the functionality in
the user story. Differences in estimations are discussed with
agreement reached. Sometimes called Planning Poker..
Iteration / Sprint
• A pre-agreed set time (between 2-4 weeks) where a pre-agreed
list of user stories are developed, tested and showcased to
stakeholders. Like a mini-project cycle.
8

9. Common Definitions
Leadership
• The team is self organising but generally one person is
nominated as the ‘scrum master’ or ‘iteration manager’ who
manages the day to day activities, ensuring the team feels
supported, and visual management is up to date. Removes
impediments.
Product Backlog
• Estimated, prioritised collection of work items (represented by
user stories). The backlog evolves regularly (often referred to
as 'backlog grooming') to ensure priorities are always
represented and any changes are reflected.
9

10. Common Definitions
Showcase
• A session used to demo the working functionality delivered
during the last Iteration/sprint and present the latest burn-up
chart. The Sponsor and any other interested stakeholders are
usually in attendance and direction is adjusted if needed. This
is an information and decision making forum.
Story board/wall
• A visual display of User Stories / task cards which shows
project progress. You should be able to easily see what cards
are in the backlog, what are in progress and what have been
completed.
10

11. Let’s talk 11
Break Out Topics (it’s so hard to decide!):
• Impact of Agile on Change Management methodologies
And…
• Culture Change

12. Agile/CM Methodologies
• Within Change Management methodologies themselves, there are only slight differences in
the tools used and terminologies as the basic sequence of change is more or less the same -
prepare, change and sustain. This sequence does not change when using an Agile approach.
• The core values of Agile are nicely aligned with Change Management philosophies, such as,
the emphasis on collaboration, individuals and interactions, and being responsive to change.
• There is less ‘demonstration by documents’ and in fact, change is liberated by Agile. No
more 100 page documents with version control and multiple sign-offs! Hooray! The
deliverables are fundamentally the same, however, the documents produced are lighter and
fit for purpose. For example, a plan to page (with no sign offs) can be placed up on a wall
for all to see and comment upon.
• Under Agile, the need for a clear vision is vital and the ‘as is, to be’ needs to be well
understood by all, supporting change enablement and the building of collaborative teams.
• There is the element of discovery aligning with change’s ’test and measure’ approach.
• At a fundamental level, there is very little impact to Change Management methodologies
when using an Agile approach as change impacts still need to be assessed, the change needs
to be communicated, stakeholders need to be managed, the users prepared, etc.
12

13. Change Manager Role
• The challenge for Change Managers is that they really need to know their stuff as
they can no longer rely on following the bouncing ball. In using Agile, there is no
need to throw out everything you know. Change Managers need to know what
tool to bring out and when.
• Expectations management becomes more important. There can be misconceptions
of what Agile is and the Change Manager can help educate stakeholders. The flat
structure enables laziness to be called out. “Agile is not an excuse to be lazy.”
• Implementation is in mind with design, not the other way around. This enables
the Change Manager to influence deployment and it can be aligned with the user
experience. For example, “this is what they want, so let’s deliver that in the first
sprint.” No more “We [the developers] don’t care about implementation. It’s your
job to implement”.
• The Change Manager can play the role of “Change Facilitator”; encouraging
collaboration and place more emphasis on adopting and embedding the change.
They can spend time working in the “white space” to glue it all together.
13

14. Culture Change
• Project or organisation?
• We vs Me – everyone provides value
• Low ego
• Deliberate action (planned) or evolution (via stories)? Both!
• Create the environment – supportive structure
• Social contract
• Stories to demonstrate/understand desired behaviours
• Share learning through journey mapping and conversation between team members
• Strengths based approach
• Understand individuals’ interests and background (e.g. passion for photography could help
the team in other ways)
• Range of experience
• Role modelling
• Learn by doing
• Executive sponsorship and support – ‘brave leadership’ essential for success
* Agile enterprise change another time, anyone?
14
(for today)*

15. Thank you for coming!
Let’s keep the conversation going over at the Change
Management Professionals LinkedIn page…
https://www.linkedin.com/grp/home?gid=1924310&trk=my_groups-tile-grp
15