1

Agile and Change Management

… a relationship…

2

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

3Opportunities

US!!!

4Common 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*

* partly true, sorry…

5Agile 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… 

6Agile Principles

• Our highest priority is to satisfy the customerthrough early and continuous deliveryof 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.

• 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.

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.

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.

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.

11Let’s talk

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.

13Change 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.

14Culture 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?

(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