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