And so it begins...

Well hello there, and welcome to the Agile Planner blog.

Agile Planner is the project management app that I've always wanted somebody else to build. Given that it doesn't seem as though it's going to happen any time soon, I'll be doing it myself.

When using existing agile apps I either find myself cobbling together a combination of tools or fighting the processes enforced by whoever built the app. Neither option is acceptable to me.

Okay, so what am I trying to achieve here?

A bit of history

Back in 2002 I joined a small software company in Cambridge. I was the third developer.

When I arrived I'd just left a .com where I'd headed up the technical department. One of my responsibilities had included giving the board of directors a good feel for how long new features were likely to take to develop, and I'd had some success by multiplying all our estimates by 2½ before passing them on to the board. This approach seemed ludicrous to me at the time, but it proved to be quite successful in practice. I hated getting those estimates wrong; corporate decisions were often based on my predictions and any significant errors felt like a personal failing.

When I arrived in Cambridge I'd been reading about the Agile Manifesto and Extreme Programming, and had already adopted TDD and refactoring. At this point I still hadn't yet had a chance to try pair programming or working in iterations, but I was eager to try.

The agile approach to planning with yesterday's weather (the idea that you'll achieve as much work this week as you did last week) really appealed to me. I could see that tracking the team's velocity would be a big improvement over just using 2½ all the time. My new team was quick to adopt iterations and story cards.

We started to track our progress. Sometimes we found that our estimates for an iteration's work were quite consistent with what we'd achieved in previous iterations. But every now and again a story would take a lot longer than we expected, and our plan paid the price.

Why did this happen? It was because we'd made estimates without having a good understanding of the problem.

We started to be a lot more careful with our estimates, and something rather magical happened; yesterday's weather became significantly more useful. Iteration after iteration, we were able to deliver the same number of estimated story points (we used ideal days instead of craft units, but it really doesn't matter what you use so long as you're consistent).

Our iterations became so consistent that we almost knew how long features were going to take; we were no longer guessing, our estimates were as useful as facts. We were moving at a constant pace, and just as significantly, the work was done swiftly.

It was the most productive team that I've ever been in. I'll get into why we went so fast another time, but that also has a lot to do with our approach to making estimates.

We achieved speed and accuracy by following a simple process, but it's a process that isn't well supported by your typical project management web app. We used index cards and a Wiki, but the task of tracking our work and keeping the cards and Wiki in sync was admittedly rather painful.

I left that company and went freelance in 2006, but I've been applying the same techniques that we developed in Cambridge to predict how long work should take ever since.

Now I don't mean to toot my own horn, but if I tell one of my regular clients how long a piece of work will take they know they can rely on the answer. The surprise for me has been that it's still a relatively unusual skill in our field. Most of the people I've worked with over the last few years haven't been getting the kind of return from using an Agile process that they ought to.

I've taught the approach to others and it's safe to say that it works (i.e. it's not me, it's the method). I want to spread the word further.

So these are my goals with the Agile Planner:

• I want to build an app that will make my life as an agile developer easier, and

• I want to get the word out about the benefits of paying proper attention to your estimates.

Using LEAN

I'm aware that while I might be rather handy with Agile and software development, I've got plenty to learn about how to launch a product on the web. I'll be writing about my progress in the Building the Agile Planner section of this blog. I'm glad that I've finally started -- there's only so much you can learn from reading books like Start Small, Stay Small and The LEAN Startup (though both are excellent, and highly recommended).

At some point you have to just get stuck in and learn for yourself. Wish me luck... :-)