|
The new challenge in Agile adoption |
|
|
|
|
Written by Allan Kelly
|
|
Thursday, 02 October 2008 |
The good news is: Agile is going
mainstream; it is not some fad nor is it just for unwashed coders. Managers get it. The not so good news is: this means the
approach to introducing Agile needs to change.
Agile Software Development started at the
code face. Kent Beck's original Extreme
Programming had little - if anything - to say about the wider organization and
the role of management. Developers could
- and did - just adopt practices like test driven development and stand-up
meetings.
Regular planning meetings and frequent
releases required some co-operation from management but overall the
introduction was bottom-up and driven by development. The question I am often
asked by developers is: "How do I persuade my managers of this?"
Managers
take the lead
Now things are changing. Managers, even senior managers, now get
Agile. They understand the
benefits. This might be because the
community has got its message across, or it might be because enough companies
have demonstrated the results.
Personally I think the economic downturn plays a role. Companies have to make changes, they have to
do something different, the downturn means the risks of changing is less and
the need to change is more.
Whatever the reason, organizations are
moving to Agile development. Increasingly it is senior managers deciding they
want their organizations to be Agile.
The question I now get asked is: "How do I persuade my developers?"
Developers are no longer leading the Agile
charge, they are on the receiving end of it. Managers actively want teams to
change the way they work. And this means
the change is top-down, not the bottom-up change it has been historically.
While some of the tools and techniques used
in the past still work, managers are in a more difficult position. Development teams can start the change by
just doing it. Managers are in a more
difficult position because few of the Agile practices relate directly to their
work. Managers cannot start pair
programming. More significantly, the reversal of the change process, from
bottom-up to top-down, poses particular challenges for Agile.
Cynicism
During the last two decades employees have
been subject to plenty of top-down change initiatives: Total Quality
Management, ISO-9000, Six-Sigma, Business Process Re-engineering and CMM
compliance to name a few. Consequently
many employees harbour a high degree of cynicism about any management-imposed
change. Almost as soon as management
starts talking about "change" people get defensive and Dilbert cartoons
multiply. Given that some 70% or more of
change initiatives fail such cynicism isn't without justification.
Cynicism is particularly dangerous because
true Agile development demands a culture of reflection, learning and
improvement. Without the learning
element any Agile process can become another box-ticking exercise with people
going through the motions, performing prescribed practices but without
enthusiasm, understanding, interest and without any incentive in improving
practices. Take away the learning and
improvement and Agile isn't much different from what has gone before.
So what can managers charged with
introducing Agile top-down do?
Real
change
To start with managers need to decide which
order they want to do things in. Do they
want to create a culture of learning and improvement within which a team can
find the Agile practices which work for them?
Or, do they want to impose an Agile method and then create a culture of
learning and improvement?
While some would suggest adopting an Agile
method then asking the team to improve I believe this approach can hinder long
term improvement efforts. A better
approach is to create an improvement culture and help the team find their own
way to an Agile approach that works for them.
When management decides the best way to
proceed - as happened with BPR and many ISO-9000 implementations - there is an
implicit assumption that management knows best.
Management alone decides on the changes and processes needed. Once this is decided they communicate the
change and wait for everyone to fall in line.
This approach feeds cynicism because it is
disempowering. It assumes that one group
of people knows what is best for another group.
Even if this is true it undermines later learning. Managers start by saying "we know best" and
by the time they switch to asking the team for insights people have switched
off; the team expects managers to provide the answers.
Taking the other course, management works
with the development team to come up with their solutions and proposal to
improve work from day one. This does not
mean management is passive. Managers are
part of the team, it is their responsibility to get things started and they
need to drive the process. To do this
they need to ignite the same bottom-up change that has created Agile success to
date.
Trust
the team
Agile has been around long enough now that
in every organization there are people who have heard about Agile and may be
keen to give it a go. Managers need to
find these people and encourage them to try Agile practices.
Managers sometime tell me their teams
resist change. I have never yet met a developer who is not keen to try reduce
the amount of bug fixing that is needed and potentially eliminate bugs
altogether. Developers are keen to try
new ideas and improve this but they sometimes need support, they need the
skills to try something or they need management support to do things
differently.
Just as the Agile community has done a good
job of explaining the benefits of Agile to the business, managers now need to
take time to listen to developers' concerns and use these as opportunities to
introduce Agile practices.
Making time to listen to developers'
concerns is a good start. Some developers
may feel inhibited from trying something new and a simple "Yes, give it a go"
may be enough. Other times managers may
need to follow up by providing money for training or coaching, or allowing some
schedule flexibility so a team can try new methods.
Taking time to engage with developers is
one way of countering cynicism head on.
Ultimately the best cure for cynicism is demonstrable change and
improvement.
Worse
before better
When Agile is first introduced things may
appear to get worse before they get better.
This is because Agile thinking addresses causes not symptoms. To do this some partial solutions - think of
them as Band-Aids - are removed to make problems visible. Once problems are seen for what they are they
can be addressed and resolved properly.
For example, short range work estimation,
using cards and boards reveals how inaccurate long range estimates on Gantt
charts can be. The problem is not the
new way of breaking work down and estimating it but rather the illusion that
the Gantt charts provide. The end date
never could be accurately estimated but the problem was hidden, Agile exposes
an existing problem,
The removal of Band-Aids happens both at
the process level and at the individual level.
Developers and their immediate managers will hold a set of assumptions
about how the development process works and what the organization expects. When a company adopts Agile many of these
assumptions no longer hold true. It is
the role of more senior managers to expose these assumptions help people find
new answers.
Real
change
Past change initiatives have left a lot of
scar tissue in the form of employee cynicism. If managers want Agile
introduction to be something different, to be a change initiative that actually
delivers, they need to show that this time is different. Managers introducing Agile need to walk the
walk. They need to spend time with the
development teams listen to their concerns, talk through problems and providing
support for new approaches.
Agile introduction will not happen over
night and it's likely the first few weeks will be difficult. Management needs to not only keep the faith
but continue to encourage teams to stick with new techniques even when things
are proceeding slowly or seem to be getting worse not better.
When Agile is adopted by managers and teams
working together to learn and improve the change becomes continual. "Change" is no a one off event, it is a
dynamic ongoing process, in other words, it is Agile.
About the Author
Allan Kelly is a London-based consultant
and interim manager specializing in Agile adoption. His first book, "Changing Software
Development: Learning to be Agile" was recently published by John Wiley &
Sons. He is a qualified Product Manager
and Project Manager, and holds a BSc in computing and an MBA in management.
Comments () |
 |
|
|
|
Tags:
Click to add your tags...,
|
Podcasts 
