Custard Melt

After about three weeks, it's all getting clearer, to the point where I just wrote out all the features I felt where missing, adding another 30 or so stories (some turned out to be duplicates). Also, we've worked out more of a routine using an issue tracker to streamline our workflow. Even looking at some of the "agile stories managers" out there, more people must have tried to keep an overview of all these details...

My own rhythm in the iterations is settling a bit too. No longer running around each day, looking at story lists and half-finished features, and feeling like not having time for All The Other Important Work -- like making sure the campaigners will want to use it, and so. At first encounter, "agile" seems to support the techie notion that developing the tool is the most important thing in the world. Instead, I let Duncan, Paul, Peter and others at ThoughtWorks just do some stories in the first days of the iteration, and then test them more in cohesion.

I do recognise aspects from other approaches. For instance, the ability to adapt, and to add or change current 'stories', and give them new priorities, is also a feature of DSDM, an approach where I've also been the "Customer". DSDM works with time boxes, and prioritises with the "MoSCoW rule", which tends to make assigned priorities more consistent across people than using "1"-"4". I've been using it for other types of projects now as well.

And since methodology wars probably still exist, as they did during my time at university, I quickly found a discussion of the differences. The bottom line seems to be really the bottom line: you pay a license fee for DSDM.

In developing web applications for clients myself, I've often had "Customers" who had far more Important Other Work to deal with -- having far less time for all this continuous testing and looking at details. Some of my customers would have run away at a site where you can join a group, but not leave it ("That's next week's story"). I think almost all would have gone crazy having to deal with so many details. Let alone sit in so many discussions about technical details.

Agile is indeed pretty process-heavy, with its good sides too: discussion topics have their place, either in the daily scrums, the weekly plannings, or the less frequent retrospectives. But it takes quite some commitment from all stakeholders to make it work!