While there are some ideas about programming and development I have that are highly theoretical, this one is not. It comes from years of experience (mostly frustrating and negative), seeing unrealistic deadlines set way off in the future that are rarely kept. Meanwhile, there is no effort to break those deadlines down into smaller portions, so the development team has a clear short-term goal that is achievable and can be racked up as a victory. All the while, there is no push back against new requirements or tangents that turn into time vacuums. The result is a mushy muddle of a mess that might eventually see the light of day. That, of course, assumes your developers haven’t all left for greener pastures.
How do you combat this? Well, for starters, you need to embrace the concept of iterations, and stand by them. There’s not a perfect answer for the length of the iteration, although anything less than a week is madness, and anything more than four weeks is too far out to build a reliable sprint.
Whatever the iteration length is, it is locked down. All analysis, development, and QA must be done at the end of that period. If it hasn’t passed QA, it gets bumped out of the current iteration into the next one. Only completed items (tasks, stories, tickets, etc…) can be a part of that iteration.
In other words, time is always constant (at least on an iteration level). Things go smoothly? Wonderful, it’s still two weeks. Spike in some stories. Things unexpectedly go tough? Too bad, still two weeks. Cut the story (or stories) that is the least important and focus on the rest.
But what if your schedule is determined by a client’s request for a specific release date? Or what about marketing and sales? After all, sales needs time to build up their campaign, and your large customers won’t take “wait and see” as an answer.
The answer is set the date. Don’t forget that this is a guess, and that from a development stand point those iterations are what is important. As you knock out iterations, you’ll get a better feel for how much work can get accomplished in each one, and will be able to make that initial release estimate more concrete. Eventually you can set a release date, and once it is truly set, you shouldn’t break it.
Embrace the constraint of time. If the release date approaches and there are tasks left undone, figure out what must be done, and what can be held off until post-release iterations. And don’t assume that you can cram anything you want in by pushing the working hours for your development staff to the breaking point in the last several sprints. All you’ll get is tired and frustrated developers putting out sub-par code. That might cut it in the incredibly short run, but you’ll be hurting in the near future.
Latest posts by Andrew (see all)
- On Developers and Von Moltke’s Leadership Matrix - November 9, 2015
- Andrew’s Coding Corner- Beware the Sunk Cost Fallacy - November 3, 2015
- Andrew’s Coding Corner – Unit Test, Young Man, and Grow Up With the Code - October 27, 2015