The USS Quad Damage

Problems with Agile software development

Is it just the capital "a"? Time will tell... sooner or later... time will tell.

You can instantly tell agile software apart from regular software.

Agile software development is soon to be the next Capitalism: Someone is going to write a quote about it being pretty terrible, but still being better than waterfall. Eventually, there’ll be a worldwide crisis and we’ll all start talking about a “requirements revolution” where we pre-define the software we’re making. Well... maybe.

We’re starting to use Agile at our company. That’s with a capital “A”, not that it really matters. We’re a fairly pragmatic team, and we have a fairly good understanding of the principles. We’ve made a couple of changes, but they’re very minor. We intend to change things as we see it, so we’re fairly pragmatic (which means we’re willing to change our “A” to a little “a”, but we’d like to try the “A” first, just to see how it all pans out). Well... I suppose I can’t speak for everyone, but me at least, and I’m pretty sure it carries.

There are some problems. Actually, there are a fair few problems. The first is iteration 0: the bootstrapping which happens before the project gets going. Theoretically, this is all that’s required to get the developers all they need for the project. However, even at the very beginning of the project, we’re already in a second iteration 0. Maybe we screwed up the first one, but maybe there needs to be more time to develop things which customers need. This is the least of the problems.

A massive problem we’ve encountered is the planning phase of the iteration. This is supposed to take a day, at most. However, it’s been taking a lot longer than that. Even if stories are written correctly (not an easy task as I’ll explain later), creating the task breakown, especially to a state when each task is under a day, is a long and... eventful process. That’s if everything is fine and we don’t feel the need to split up a user story.

User stories and scenarios have issues of their own, and this is what I perceive to be the biggest problem with agile software development. Because these things are vertical slices, not only are these stories difficult to split up, but you can instantly tell agile software apart from regular software. In agile software, you can do complete your tasks really quickly, but if you want to complete a task for which there’s been no user story, all of a sudden it’s not possible due to the way the software has been designed.

Refactoring is a fear, but not a realisation just yet...