Leadership, Organizations, Change and Agility

How Can Change Management Support

Agile Development Programs?
Aug 9, 2015
Agile applications development processes present new challenges and opportunities for change
management professionals to translate their expertise into business results. While the first step is
for change management professionals to change themselves, there are also best practices for
agile program sponsors and technical development teams.
Traditional change management models operate according to what agile programs call
waterfall that is, step based, linear, and sequential models. Pick your traditional change
management paradigm: chances are it includes at least three, more likely four core stages.
Almost all models assume a period of study and planning at the front end that assumes the future
state is known and defined. As the carpenters say, traditional change management models follow
a measure, measure, cut program philosophy.
Agile development turns that logic on its ear. As a result, change management has to adapt to
work within a framework where the future state is not well defined. Thats why change
management professionals have to change themselves and their ways of thinking first.
The good news is change management as a profession essentially began operating under agile
principles at its birth. What we now call change management or business transformation grew
out of organizational development, mostly in manufacturing, where best practices evolved to
bring multiple stakeholders together to work fluidly in creating and designing a future state.
In those days, consultants with expertise in the people and behavioral side of business acted as
facilitators and guides for that design process. Modern day change management professionals are
still people with high emotional intelligence who can work with individuals and groups - directly
and as systems - to bring about sustainable change. Within agile models, its precisely those
facilitative, more open ended, we dont know where this is going skills that return to the
forefront.
How is Agile Development Different?
Im not going to get into the weeds here, but lets take a big picture view. What are agile are core
values and what problem does agile development seek to solve?
Lets take a look at these seminal principles of agile development (emphasis in the original):

Leadership, Organizations, Change and Agility

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
Collaboration. Individuals and interactions. Responding to change. Those core principles all
emphasize a focus in human behavior and motivation, the very things change management
with its seminal and continuing roots in psychology understands best. Agile development rose
as a solution to the problem of technical developers operating in a bubble without sufficient
interaction, without understanding the needs of users. . . or as the rest of us call them,
people.

However, an emphasis on process agile over waterfall presents only a partial solution to the
problem of software development too often performed by and for developers with insufficient
attention to business needs and users. The bubble of technical thinking exists not only because of
older paradigm project management processes, but because the people doing the development
tend not to be the most attuned to the needs and feelings of other groups. Though its not a 100%
rule, people with the talent to code and design may be great with manipulating conceptual
models and solving complex abstract coding problems, but theyre not the go to group for
empathy, communications and attunement to others.
So whos the go to group for those skills?
Change management professionals.

X
What should you

Farooq Omar
Faculty (IMS)

do?

Lets get concrete. What are some best practices for change management as part of an agile
program?
For Program Sponsors:

Leadership, Organizations, Change and Agility

To get the most of an agile investment, you need to include change management
professionals embedded within the core design team. Their perspective and heads up
suggestions will be needed to keep the program humming and manage the training and
product installation process.
Directly introduce your lead change management consultant to all other senior key
stakeholders in the agile product development process. There will be times when your
consultant will need to act as a communications support and interactions facilitator
between your design team and these key stakeholders to head off later misfires and
misunderstandings. When those situations arise and they will your outside consultant
cant wait for or rely on internal gatekeepers to get access to key stakeholders. Thats
what happens when change management professionals are placed tightly under the
umbrella of a project or program manager.

For Change Management Professionals:

Let go of the need to check all your boxes at the front end when it comes to creating
plans and assessing stakeholder readiness and impact. Lets face it, by the time you get
hired, the decision to move forward has been made, so gather whatever information you
need about stakeholders, impacts and readiness on the fly, through conversations and
anecdotally. You cannot slow things down. Be more fluid and get used to it: thats how
agile works.
Get direct sponsor permission and unify key stakeholders on the program mission at the
front end. Try to get everyone in a room if at all possible. Once you do, facilitate the
creation of a team or sub team whose responsibility will be quick adjudication of priority
conflicts that will emerge through life of the development cycle. The role of change
management here is to facilitate and to create a governance team that will clarify strategic
and business priorities when the design team needs guidance on priorities in conflict. Ill
call that the Mission Team, but call it whatever you or your client like.

Integrate change management into each sprint. How? As stories are outlined and adopted
for development, make your best guess assessment of stakeholder awareness, readiness
and impact. Stories give you all you need to make impact assessments, so use that
information to assess impacts as stories progress. Assess also if you need to flag a
question or issue for review by the Mission Team. You may be the only one with
awareness of a potential conflict, so be ready to stick your neck out if necessary. Better
safe than later sorry. Thats your job.

Work directly and iteratively with the training team to create quick shells for training
based on stories adopted for development. Thats critical because the program will need
these shells to be ready once the program rolls out. Installation happens fast, and change
management cant slow things down by trying to design traditional and well documented
training programs.

Emphasize hands on training, and dont worry about detailed plans or even screenshots.
Once training begins, enlist your beta users as trainers. Whenever possible, perform
training directly in the development environment. That will make inevitable hot fixes
possible.

Leadership, Organizations, Change and Agility

Accordingly, pad training schedules because there will be times training is delayed or
interrupted as hot fixes are created and applied in real time. Six hours of anticipated
training should be scheduled for an eight hour day. When it comes to training materials,
remember, quick and good enough is good enough. The real learning transfer will come
from personal interactions with trainers. More detailed documentation, with screenshots,
can come after enterprise level rollout.

For Software Designers, Program and Project Managers:

Build trust with your change management partners. Dont wall them off from information
or access to stakeholders, or act as a communications gatekeeper. They will be effective
for you if they can get to know and get a feel for your organizations people,
personalities, politics and culture. It can sometimes be tempting to feel nervous or even
threatened if they have direct access to program sponsors and other key business
stakeholders, but they will need it to help you and your team achieve maximum success.
If you can take this approach, your change partners will augment and amplify your ability
to anticipate stakeholder needs and avoid delays and misfires as you bring your product
to life. If you really cant trust your consultant, find another one. Better to find new talent
that you can trust and that fits with your culture than place a consultant who could be
effective in a box that limits her ability to use her core talents of empathy, facilitation and
communication by limiting her access to people, information, or inclusion in team
meetings and conference calls.

Conclusion
Of course theres more to be said about leveraging change management to make agile
development programs successful, but these are some key best practices to get you started. In the
end, its all about putting the right mix of talent together, in the right ways, to get the best results.
Change management professionals have some unique talents that align perfectly with agile
development core principles. By integrating change professionals into an agile program as
described here, you can maximize your ROI, reduce time to go live and minimize risk of misfires
and mistakes due to crossed wires and miscommunications among stakeholders.