Doing Business in Real Time
The global economy has a life of its own, it lives in real-time, and we are all part of it. Hello brave new world.
Just like the word "athlete", the word "agile" grabs your attention; it sounds great. But going from desire to reality always tests your commitment. I feel good after a vigorous workout but then the next day (since I don't work out as regularly as I should) I feel sore. And then I don't want to go back to the gym.
Agility makes you sore at first too. But it gets a lot better if you resolve to stick with it; after a while you don't get sore at all - quite the opposite. On some agile development projects this summer, I saw several common issues people had to work through in order to learn agility and get their systems built within tight constraints on time and resources.
[ I do lively presentations on this and related topics - mhugos@yahoo.com ]
The most common issue is the tendency of people to try to fudge, negotiate, or otherwise circumvent the constraints on time and resources that come with agile development. People want to be agile but they don't like the tight constraints that come with being agile. They offer all sorts of reasons and excuses; they want more time to create quality software; they want more time to do system testing; or they want more time to investigate system requirements.
My response is to remind people that the constraints are actually their friend, not their enemy. Accept the constraints and use them to structure the development work; set project scope to make best use of time available. If people have all the time and all the resources they want then nobody is going to be agile because there is no urgency and thus no desire. "Ya gotta wanna," as they say, or "ya ain't gunna."
One of my colleagues who worked with me on a recent 30-Day Blitz (he's also a blogger - Aaron's Technology Musings) sent me this link to a recent post in a blog written by a developer at Microsoft. It seems there are even groups of people at Microsoft (a company with lots of resources at its disposal) who feel the need to be agile. Here's a group of developers who are serious about embracing constraints and not asking for more time to get things done.
Another common issue I see is a state of mind epitomized by the statement "That's not the way we do things here…" We all (me included) do this (believe it or not!). I have no response to this statement other than to ask how the old way of doing things is working out. I inquire if people see some ways procedures could be rearranged or tweaked to better fit existing conditions. But if the old way is still good enough (and plenty of times it is) then there is absolutely no need to be agile or to change.
A third very common issue that people wrestle with is the tendency to immediately criticize new ideas; we're all prone to it. As soon as someone suggests a new way of doing something, we all think of ten reasons why that can't be done or why it won't work. Yet, to be agile, it's important to learn to temporarily suspend this behavior. Because agility happens when