1. Give yourself a really tight dead-line.
Nothing focuses the mind better than a really, really tight dead-line!
2. Decide to go Agile.
Cool, super, great... trendy! TDD, that sounds good, it means that not only will be have a super new site, but it will all work first time because we tested it all before we wrote the code! DDD, oh wow, our business guys will practically write the code... BDD mad, crazy! That means our design will actually behave the way we want it to!
2. Bring in some consultants to 'teach you Agile'.
Yeah, what we need here is to be told how to do it, however, we don't really trust anybody except ourselves, so we're going to let the developers buy into this stuff, but actually ignore all the advice the consultants give us, after all we're the ones paying them!
3. Decide to do "green-field".
Good choice! I mean, what with the really tight dead-line and a completely new methology, what better choice is there than to re-write everything from scratch?
3. Decide to write a story for every single feature of your existing web-site, and all the new features you want, and spend several months prioritizing them, re-prioritizing them, planning them, re-planning them, throwing some away, writing some more, re-planning them again...
What better use of everyone's time?
4. Code!
We'd better get cracking, what with all those features to deliver (Agilely of course) before the deadline.
Who needs infrastructure? Architecture? Pah! We've got an Evolving architecture! That's much better than a stupid old 'fixed' architecture!
Anyway, we've got the buzz-words all worked out, so the code has practically written itself already!
5. Detach the most experienced developers from the team.
See those guys? Yeah, the ones with upwards of 5 years of keeping the site running, incrementally improving it and introducing new technologies? The ones who understand the domain better than anyone else? The one's who we just named 'Architects', before we decided to change everything. Yeah them. Let's sit them in perpetual meetings, away from the actual team now doing the development. How better to make sure that they can't influence, help or steer the team towards the goal...
6. Look at the time! Panic!
Oh dear, we've spent all our time shuffling these cards around, entering them into one Agile tracking system, putting them into spread-sheets, entering them into another Agile tracking system, still using spread-sheets, etc. that we've now got nearly no time left!
7. Grow the team... exponentially!
No, we've not read 'The Mythical Man Month', but thanks for suggesting it.
8. Look at the code! Panic!
Woha! Our near infinite number of monkeys sure can write an infinite amount of tests! The build now take 1.5 hours to run! But our lay architects are grumbling the actual code is complete bollocks! How did this happen, when we supplied our team with all the buzzwords our consultants told them we needed (except the ones we didn't like the sound of)?
What we obviously need here is some metrics and some guidelines! Let's waste some more time getting people to produce metrics about conformance to our (non existent) architecture, and then lets totally ignore all the reports because we don't understand them, oh, and some Javadocs would be useful...
9. Good news guys! We got on our knees and begged the business for more time, so now we've got another six months to deliver everything we promised in the first place, plus a whole bunch more they realized we'd missed out.
...time passes...
99. Well done team! In spite of the tough dead-line, thanks to some inglorious de-scoping, coupled with the late nights and weekends, and some heroic efforts of the senior developers we sidelined in the first place (in fact all the stuff we said that the Agile process would avoid), we delivered an alpha and the business LOVE it (and us especially!) because it has some completely trivial AJAX feature the UI guys knocked up in the first week!
Six more months of this and we'll be the most successful team ever! Agile rules!!
