How not to Fail an Agile Transformation?26 Sep 2018
It's all too easy for teams to drop their Agile-related efforts after a little while since their initial training. Don't we all have a natural tendency to want to go back to how things used to be?
But doing so does, obviously, render all improvement and change efforts useless. What to do then?
It's a truism by now, that any organisational changes need to match the existing organisational culture and needs. It is then crucial to keep in mind, that even the best applied and executed Agile practices will never work when they are not the answer to what a company needs, and to what it can work with. Start with checking how this looks for your Agile implementation - does it answer real needs and does so in manageable ways? Agile is a means of achieving greater productivity and better results, it's not a goal in itself.
If the standard practices seem to fail, it's worth considering injecting a general inspiration, interest in Agile through your delegated Agile ambassadors. All this involves is selling an influential employee on Agile values, so that they implement it themselves and start to generate interest within the team. Then, this team's approach becomes something other teams want to strive for etc. The reason why it should work is that the interest gets generated in the most natural way - by seeing a working example.
At kanbantool.com we see this all the time - a small team starts to use the online Kanban boards and applying Agile practices, other teams in their organisation see it work, and ask for own boards for themselves, as a start. Nothing forced, just wanting to have it as good as the other team does.
It's rare for team members to follow a new paradigm or practice when it clearly has no approval with leadership. Even more so true, when leaders only see the new thing as something they just have to agree with, rather than appreciate its merit. Ideally then, you could attempt to make your leaders your Agile ambassadors and kill two birds with one stone.
It's also worth mentioning, that bringing enthusiasm and examples to the team needn't come from named leaders only. Anyone can bring a change about, if their example implementation creates enough interest (or envy) among others.
In any Kanban and Agile system, there should be a schedule in place, indicating when your current process should be reviewed for faults and potential improvement spaces. It's the key element to keeping your Agile truly agile, isn’t it?
Do perform regular process reviews, in order for the process to be always evolving, otherwise you're just set with one, non stale-proof used-to-be-Agile process.