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.

Why yet another blog

Why on earth would I start yet another blog? I already have two of them and they eat up quite an amount of my time. I've been talking to people about starting a third blog. And even preparing for that takes more time than I wish.

So why this fourth blog? Well, because I often have thoughts and ideas about technology that I want to write down. Over the years I've gathered insights and principles, often through many mistakes. To make it less likely for me to repeat my mistakes, I try to package my ideas in small sound bytes. Those are easier to remember, which at my age starts to matter.

So there you have it, my reason for spending yet more time writing about technology. I hope that someone finds my ideas useful. But even if no one does, at least I'll have a nice reference to refer back to when even remembering small sound bytes becomes too hard.

Who? What? Where?

Welcome to "The Puf Principle", my newest blog on programming, technology and other things surrounding software development. In this first post I'll briefly describe who I am and what I've done in my working life. It's by no means required reading, but it might serve as nice background information to my future posts.

I'm Frank van Puffelen, a software developer in the Netherlands. Friends and colleagues often call me "Puf", a nickname that I picked up in college to differentiate from all the other Franks out there. That nickname also explains the title of my Blog.

After tinkering with home computers (ZX81, C64, Spectrum, Atari 600XL anyone?) throughout high school, I decided to get my Bachelors in CS. Through some coincidence and weird choices, I ended up majoring in medical computer science; a field for which I still have a soft spot. I've been developing all kinds of software for a living since the early 90's. Through the years I've used many languages from Borland Pascal and Delphi, through MFC to Java and C#. Throw in some interrupt programming in assembly, real-time data acquisition (EKG recording) on Windows 3.1, accounting software and creating GUIs with just about any technology I can get my hands on and maybe you can see why I consider myself (not just physically) a well rounded developer.

That about sums up what I wanted to share with you for the moment. Do you want to know more? Is there stuff missing? Let me know.