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.

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 a stream of new ideas starts to flow; when one idea leads to the next and profoundly obvious (but previously unseen) and elegantly simple (yet not simple-minded) solutions start to present themselves to us for our use.

I see project teams experience a rush of energy and insight when this happens; when they make the mental shift from "why we can't" to "how we can." This shift goes right to the heart of the agile mindset. The high that people get during periods where new ideas flow one after the other is similar to the high athletes get when their adrenalin kicks in and they feel like they can run forever.

So, are we feeling a little sore today? That's okay; remember what this soreness means. It means we are learning to get things done four times faster than we used to think possible, and for less money than we used to think was needed. And getting our minds around stuff like this is just like getting our bodies used to a routine of working out regularly.