You’ve heard the hype about all things Agile and Lean. You’ve also heard the traditionalists at your work curse all things “fragile” and you’re pretty sure that they’re never going to give it a go. Is there anything that you can do to glean some of the benefits without being harangued by sceptics from all quarters?
It seems that many agilistas in New Zealand accept that agile uptake here is well behind other countries where we have worked. Organizations with large ICT projects are not picking up on the changes spreading through similar organisations elsewhere.
There are many explanations for why this might be. Perhaps the critical mass of outspoken technology professionals who are willing to share their ideas for business improvement with their CEO hasn’t yet been reached. Perhaps the culture of advancement through learning is still less influential than the culture of keeping your head down and praying for promotion. I have even heard cynics say that quotes from consulting and contracting companies are influenced by the desire to work on long-running and expensive projects. I hope that’s not true, as these companies are in an ideal position to promote agile adoption and the image of lean methodologies, which are intended to bring time and cost savings to their clients.
This is not a new issue. Most large companies that have become more agile started with internal resistance; before the trend took off, almost all agile efforts would have been hard sells to management.
Subterfuge was frequently employed to divert attention from the good work happening in small teams in large enterprises. Teams adopted good processes but kept it to themselves, avoiding the old impediments and getting on with the task of delivering working software frequently. Once a few successes were reported, things became easier, but how were those first successes achieved?The change from the old ways is well documented, and I thought I’d share a few articles about it, in the hopes that it gives you a few ideas on how to pass to on your organization some of the benefits of a more agile working environment.
A little bit of background
An experience report par excellence. This was what I was going to write, but Devin got there first. Honest.
So what can you do about it?
Aimed at larger companies, this obviously speaks from experience. There’s a good amount of insight mixed with common sense. I suppose that’s why he dubs himself the Pragmatic Agilist. Though I don’t agree with all of it (information radiators do not belong in “project rooms”, whatever they are; they belong somewhere obvious so that people not on your project can also see what’s going on).
A few practical suggestions and reminders of why agile processes exist, to “[implement] the principles of maximizing the amount of work not done”. Or as I like to phrase it, “a good programmer is a lazy programmer with good morals”.
Aimed mostly at developers, and talking about what you can do rather than how you can do it. A good treatise on steps you can take, once you’ve got a bit of culture change going your way. It neatly side-steps the the problem of getting started on the road to that culture change, though.
A few extra reasons to go stealth agile. There’s another post on this blog about Improvement Backlogs, which I think would be a great idea to document improvements as you go, build a list of future improvements, and protect yourself against nay-sayers and can’t-be-done-ers.
Lists a few of the downsides to stealth adoption. Just like every other idea in software, there are times when it just won’t work, and something else is better. This is an old article (2005), and time has shown how successful stealth agile can be, but there are pearls of wisdom in this short post.
So.. should I or shouldn’t I?
Yes. Definitely. If you can’t do it overtly, do it covertly. Those nay-sayers will never be proven wrong until they’ve seen how a few little changes can add up to become a model project whose success may positively influence your organisation’s culture.
There are upsides to stealth agile that come from being forced to move slowly and document improvements. You avoid the risk of taking on too much change too quickly and losing the whole team after a string of minor but demoralizing set-backs. You choose changes based on how little they disrupt your team and your deadlines. And you get to report on incremental successes month after month, as you adopt more and more lean practices and abandon slower and more costly alternatives. As each change is accepted or rejected, the team learns more about how they want to work. It is opens itself to the ideals of continual improvement, as promoted by kaizen and the fourth point of the agile manifesto “Responding to change over following a plan”. If you’re lucky, the other team members become agile champions, finding and suggesting improvements and advertising successes to the organisation at large.
Have you adopted any lean or agile practices without prior approval? How did it go?