Advice for Date Driven Development Model

Question

Does anybody have any advice on working in a Date Driven Development environment? Essentially, we are updating our RIA every 8 weeks. I work in a small team of less than 5 developers, so I'm concerned about how to manage long-term features that don't fit in small cycles. Additionally, I'm concerned about being in a state of perpetual crunch-time.

Answer 1

Rule 1. Defer features.

If it's not done, (1) defer it to the next release and then (2) figure out why.

"Pushing", "Overtime" and "working smarter not harder" don't actually do much. The point is to be realistic about your plans.

1. Plans are an attempt to predict the future.

2. You cannot predict the future.

3. Therefore, your plans will be wrong. Always.

Rather than rant and rave about "the plan", "the commitment" and "customer expectations", think about this.

Your goal is to deliver features at a pace that is faster than the users can make use of them.

Strive for 2-week increments. Tested, Integrated, ready-for production.

After the first four sprints, you're at 8-weeks, ready to release. You will have built things, deferred things, and wound up with a deferred list at the end.

Many cycles of new features will -- generally -- bother the users with the pace of change. You wouldn't release each 2-week sprint because the users don't like this. If you release too often, you get told to bundle the features together into a bigger release so that the pace of change seen by the users is slower.

You must still do many small cycles. Aim for 2-week sprints where you build some small subset of your bigger backlog.

You just don't release each small cycle.

Answer 2

8 weeks is a lot of time....compared to some shops that have 1 or 2 week releases...so you're fortunate. Some recommendations:

• prioritize your maint/bug fixes with the help of your client/business owner after each release and work your way from top of list down...(sounds simple until you get a last minute must have in there)
• the development for cycle 'D' should actually start in cycle 'C' in regards to planning and should end 1-2 weeks prior to delivery to ensure proper QA and fixing of found issues
• there will always be 'something' to make you question pushing the delivery date - don't give into it - reduce scope/keep to the date
• break the larger deliveries into smaller ones and promote in a manner that they are 'there' but no 'live' (beta) - this incremental work might add some extra effort, but should reduce end of delivery QA/bug related issues and risks
• track important metrics - for planning and showing progress