Thursday 10 April 2008

Agile Architecture

There are a lot of opinions on how to handle architecture in an agile SDLC - so I thought why not throw mine out there too?

The first thing I think is important is to maintain a good reference architecture that readily explains the whole system including shared infrastructure and how to access it.  Having strictly defined interfaces/APIs and communications infrastructure rules is fundamental to being able to build anything with a distributed system as a platform.

Your biggest need for architecture is going to be early in a new project to build a new feature or product - so for the first few sprints reserve extra long times for sprint planning and use that time for consultative design sessions.  Lots of people use a "design sprint" or two but I've never been a big fan of that - I think a sprint is the best use of time once you've planned out exactly what tasks you're going to do and have an estimate (based on facts) of how long they're going to take.  The dedicated, concentrated burst of activity that traditionally makes up a sprint isn't the environment most conducive to the contemplative, consultative, learning process that is design.  Besides, having a designated "design sprint" tends to make you want to answer all the questions and design everything up front - and we all know that's kidding ourselves, in fact it's probably why most of us adopted agile in the first place!

Next you should make your first sprint (and perhaps even the second depending on the size of the project) long enough to build the entire width of the whole system to the barest, most skeletal framework possible (a month for example) and the depth one customer feature to [one normal sprint's worth of] completeness.  Then you can go back to your shorter, more focused, high energy sprints (2 weeks for example) and flesh out the rest of the system feature-by-feature.

This works on the theory that "deliver working, demonstrable software every sprint" overrules "many short, predictable cycles of delivery" and in any case I believe the output reflects the right mix of performing looser, more creative solution architecture activities and tightly timeboxed, ferocious task burning activities.

No comments: