Agile Stress Points

2 weeks, 1 full iteration, into my first agile gig and I can see a couple of stress points.

First, let me say that I really enjoy what we're doing. I think we've got a lot of things going well.

As a team, we've managed to complete a lot of features. Actually, as a developer I think this is a very productive way to work. Breaking work down into little pieces and focusing on just those pieces makes developing much more manageable.

I don't think that agile development is magic, or radically different than traditional development. At the end of the day we're still schlepping code. The key difference in agile development is a more awareness on the current status of a piece of a project.

In non-iterative projects I always feel like there's a looming deadline and the success of the project is based on meeting that deadline. The schedule is, if not unrealistic, not very tolerant of setbacks. One key to finishing those projects was to treat the project like it was in crisis from the beginning. Get it done as fast as possible.

Refactoring and rethinking features are a luxury. They kill schedules. A change order to a project is a PM's enemy. I'll venture to say that a majority of features that just seem crazy and out of place are the ones that were spec'ed early, and implemented late.

That's the pain of a traditionally managed project, the push at the end to finish outweighs assessing the viability or the functionality of the work that's being done.

I can see some stress points with using an iterative methodology though. I think it happens at the project manager level. A project manager typically is expected to be able to provide a status for a given project and a forecast for when the project is finished. These are basic expectations that are put on a PM.

Providing a status is easy for the iteration, but the people asking don't usually care about the iteration. One thing that iterations do is expose pain points early. That's the strength of being iterative. You get an opportunity to take care of the pain early and focus on what works. The downside of being agile is the ugly stuff comes out early. Things look as bad as they are, but worse than if the project were not iterative. In those projects the ugly stuff comes out closer to the end. If you're a PM, the project looks worse upfront than at the end. This is a case where, visibility is a strength and a weakness.

The other pain point is providing a forecast. That's tough at the beginning of a project. If you go by the velocity from a tear down chart, it's not going to look very good. Projects start slower than they end. Putting a PM in a position to say that their project is not going to end on time early. To a PM, that's starting off on the wrong foot. Ironically, I think it's setting a baseline worst case scenario. If the estimates are based off the velocity of the project and the velocity increases, then the estimates shouldn't slip out.

From this vantage, it would appear that more buy in is needed outside the project. If iterative projects are allowed to succeed I think that will slowly happen.