Thursday, December 13, 2007

The Agile Programmer With The Cowboy Hat

I recently got involved in a new project. It's not a project from my company. We just provide a few developers (including me) on a body leasing basis. We have to graphically redesign a web shop with some small changes in functionality. The process that we follow you could describe as a mix between waterfall and cowboy coding. The good thing is that we have a close collaboration with the product owner (yes, we have one) and a small self organizing team. But when I compare it to the project that I was involved before it's a totally different functioning.

In my last project we did scrum. Our level of scrum adoption was not too bad (7 yes answers in the nokia test). We had a good self organizing team with motivated people. We improved from sprint to sprint and ended as a very effective team.

Now, I realized once more how important practices like time-boxing, prioritized backlog and developer estimating are.

So what can you do as a an agile programmer if these key practices are missing?

Well, the good thing is that agile is not an all or nothing approach. You don't have to adopt all the practices at once. If you do that, changes are high that you will fail, especially when you have no people with agile experience in the team or support from an agile coach. As a developer your possibilities to change something are limited as well. But I think if you are an experienced agile developer and everything in your body resists against heading blindly for disaster you have to change something. Even if it's just the advocating of approved developer techniques. As I'm more a web designer than a programmer right now I can't to the last thing I mentioned. So I targeted the organizational level and introduced the backlog today .

We already had some work packages identified that where bundled into a gant diagram. This diagram was out of date from the first day of development and wasn't adjusted from that day on. So I translated this information into a prioritized product backlog and presented it to the product owner, the project manager and the team. The reaction was positive. The project manager was surprised when he saw how much work is still not done.

It's not a revolutionary change. But it's a small step towards improvement.