Monday, April 14, 2008

Introducing Agility

Many blogs and articles have been written that cover this subject and I just wanted to add my own two cents. Why is it so hard to introduce agility in the workplace. There are many reasons, but I have to say that top of the list is that its just plain hard to change people. Most folk have a comfort zone beyond which they simply don't feel happy going. Agility is so much more than just another process, its much more of a culture change than anything else, and its very hard to bring about culture change.

Whatever you're trying to change, you're always going to face resistance, because change could affect someone's role in a way that alters their stake and they (sometimes justifiably) fear the unknown will land them in a less desirable situation than the one they're currently in. Before doing anything in your organization though, analyze the situation, don't introduce something just for the sake of it, there has to be a good reason.

The implications of introducing agility will be far reaching and very uncomfortable for many at least initially. Also consider whether or not you actually have the raw materials to enable agility to happen. For example - are you going to have ready access to your customer? If not, this is a huge problem for any agile method - which works on the premise that frequent face-to-face communication is one of the best ways of loading the dice in your favor. With this example a good idea (I believe) would be to dip your toe in the water and see if you can run a small project with all the customer support you need to see if the idea will be welcomed. If not, don't even bother trying to introduce agility yet, your company is simply not ready to make the commitment. Most organizations, are in this stage and most of those who claim that they are agile are not, whether they think so or not.

I used to believe that it was an all or nothing proposition - and as far as declaring 'am I agile' is concerned, then it definitely still is. However, when it comes to introducing it into organizations, its far too much for most people to stomach at one sitting. So is it possible to introduce elements of agility? I think so, as long as you don't blame the principles and practices if they don't work for you, because most are designed to work cohesively together to produce results. Of course there are elements of danger breaking these up, because if you don't understand how things work together you could be staring trouble in the face. For example, refactoring and test driven development go hand in hand, try refactoring without tests and its like walking a tight rope without a net. Ideally, principles and practices should be used as they are so that you can learn how to crawl and then walk before you run, but its tough to introduce things in a big bang fashion.


Brad Wiederholt said...

Andrew, I had come across the original versions of this book circa 2001:

Had sent a note to the author with the idea of putting these onto index cards, see that this was adopted in the book, like to think that I had a little something to do with this. I still have the original set of prototype index cards I made for myself in my office.

Anyway, it is a simple book about simple ideas about introducing change into an organization. Lot's of stuff that we probably already know and have used in the past, but worth a thumbing through for some new ideas or relationships....

Paul said...

Hi Andrew,

When I was introduced to Agile, my Coach at the time came in and changed everything. It was a shock at first, and it definitely wouldn't have happened unless he had the support of the management team.

The management weren't interested in Agile, but it was clear that the project costs had spiralled out of control and they were willing to try anything as a last ditched attempt to get back on plan. Besides the Coach and a number of top XP Developers came from a leading Agile Consultancy and we were paying the a fortune, so what they said went :)

I agree you can achieve process improvement without using the dreaded "A" word. Alistair Cockburn talks about getting projects into the safe zone, and I think you can do this purely by introducing effective practices within an existing organisational culture.

I had been introduced to prior to the experience I describe above, in this way, we were told to think about tests before writing the code, and get someone else to review our code before checking it in. You can recognise these as watered down TDD and pair programming practices.

Haveing Ivan (our Coach) impose full blown XP though was a completely different experience. It changed my view of what was possible, and made me question all my prior assumptions.

For me I think this is the issue. Incremental changes will improve the team perhaps getting you into the safe zone, but I don't think you will "get it" this way. The big picture I mean.

That was my experience.