As we’ve now launched, we’re moving into Phase 2 development, which is nice.
However, we’ve moved from 2 week intensive to 3 week, more reflective, iterations.
We are due to deliver P2 R1 (phase 2, release 1) codename Ellington on 22nd Feb with testing starting on the 15th. I’ve been looking at change/bug management solutions as we go forward. At the start of this iteration we had 11 features, bugs or enhancements to include. Less than a week later, we’re up to 24, and counting.
I love agile. I love iterating. BUT how do we manage the queue? Everyone’s suggestion is important. They all need to be included in the next release. Well, a week into the process, I realise we can’t please all of the people all of the time. There are some really easy things to fix (and we have), but some of the other stuff is really, beard-scrachingly, hard! Can I define the metatdata we’ll need to take the content, users and site to the end of our funding in March 2010? I doubt it.
So, I spent half a day wondering how we manage this. FogBugz? Trac? No, I decided to bite the bullet and use RTM (aka RememberTheMilk). My thought process was:
- Make decisions (can I do this in the next fortnight)
- Is it really useful?
- Are users asking for this? (One, very vocal, user doesn’t mean you should do it!)
- Will it make a real difference to my KPIs?
- If I was a user, would it make me a), b) or c) (enter your goals here..)
After going through this process it was easy to prioritise. You do not need a democracy, you need a benign dictatorship. I can do that in 3 weeks.
So that’s it. 3 weeks, in RTM. And I can hit those targets and reset afterwards.
- DEVELOP NOW
- ITERATE
- LEARN FROM YOUR MISTAKES
- ITERATE AGAIN
- REPEAT
And read this book...http://37signals.com/rework/
Seth is a God, and I met him at my time with beenz.com, it was a privilege.
