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