01.15.09
starting a new project: weighing up agile methods
Here at ticket-text we have just embarked on a new software project. I’m not going to get into the specifics of what it’s supposed to do*, but suffice to say it’s a large-ish django app. We’ve spent the last couple of months figuring out what it’s supposed to do and doing proof-of-concept work. Now we’re starting to build production code.
At my previous employer, ammado, we used an agile/XP hybrid approach to manage our work. It started off well but we ran into some pitfalls:
- the team got too big to manage effectively with a self-organising process.
- the usual rule-of-thumb for agile is that it works for teams of up to about 8 or10 people. We had over 20.
- fetishisation of index cards.
- short-termism of agile allowed us to ignore architectural issues. Over the course of several iterations we built up substantial technical debt which caused progress to slow significantly.
- cultural resistance to pair programming led to less refactoring and more code duplication than we would have liked (pair programming keeps you honest!).
There were some positive points too:
- constant emphasis on shipping working code. Before we adopted the agile approach we spent a year making exactly zero releases. Afterwards we were releasing once a month.
- retrospectives after every iteration helped change my mindset (I can’t speak for the whole team, but I would like to think I’m not the only one who got this) from ticking-off-items-on-a-requirements-list to how-can-I-make-this-team-work-better.
We are adopting a similar process here in ticket-text. We would like to maximise the positives and avoid the pitfalls outlined above. I’m going to keep track of how we are progressing here - hopefully we’ll all learn something.
* in case one of my millions of readers leaks it to the competition. Lolz!