Agile is about the people

When Steve Yegg's article on the good and bad of agile development showed up in my feed reader a few months ago, I decided to pass on it. The summaries I saw sounded too much like Steve just needed to vent hist frustration with all the agile hype. Which is fine by me, but doesn't make it onto my already overpopulated reading stack.

But today one of my many managers put the article on my desk, saying it was an interesting read for him. I know when not to argue, so I read it on my way home. Don't worry, I travel by public transport so didn't endanger anyone. Although I did draw some attention by nodding in approval and making snorting noises while reading.

Steve has some very valid points about the whole Agile Methodology hype. Luckily he also tells plenty about a place where development is done in a less then formal way very successfully: Google. We all hear the stories about why Google is such a great place to work. But Steve provides insight in why it actually pays for Google to be such a great place to work. If you're interested in that, just read Steve's article. I just want to talk a bit more about my experience with agile processes.

I've seen less formal development processes work and I've seen them fail. I'm still trying to figure out what causes success or failure. But I'm getting more and more convinced that it isn't caused by the project and it isn't caused by the process; it is caused by the people.

When agile processes worked for me, it was because the people took ownership and felt in control of their project.

The ownership wasn't imposed upon them from above by a manager. The responsibility was taken by them from feeling involved in the project. Simply by letting people make their own call in most cases, they took ownership of the project and thus took responsibility for its success. Which also means they took credit in the success of the project. I've never worked with an incentive system such as Google's, but even smaller rewards work wonders here.

The people also felt in control of the project. Progress was monitored (but not planned) by the project manager. And progress was even somewhat predictable. When unexpected problems got in the way of getting something done, it was clear what to do with the problem. Create a separate task/feature for it and get on with what you're working on. Sure the list of tasks would grow at times, much to the frustration of project managers that wanted to finalize the project. But at least it was there, out in the open and it couldn't be denied. And it was always clear for the developer what to do next: just look at the list.

But I've also seen the lack of a rigid process fail. In those cases people weren't taking ownership. And they certainly didn't feel in control of things. Like I said before, I'm still not entirely sure why this happened. But I have a feeling that the people themselves had something to do with it.

When someone isn't comfortable with the subject matter, he is not likely to take ownership. Solving this problem is actually quite easy: either he should get comfortable with the subject or he should not work on it.

The lack of feeling in control is slowly becoming more clear to me, in a large part thanks to insightful articles such as Steve's. We made people give estimates on tasks that were assigned to them. But often the people were not yet in control, so they couldn't give reliable estimates. This led to them not making their self-imposed deadlines, which many project managers like to point out in useless progress meetings. And if you hear a manager say "we're not making enough progress" week after week, you have to be pretty strong to keep your feeling of control.

That's why I like Steve's (or actually Google's) approach of not having estimates. Given enough tasks/features the size of the list will become enough to estimate by. If there were thirty items on the list a week ago and there are now twenty, a very simple estimate is that you'll need two more weeks to finish what's on the list. It might or might not be very accurate. But in my experience the same is true for estimates that take a lot more time to produce.