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.{rsform 2}