Jeremy W. Sherman

stay a while, and listen

Agile

I take agile as rejecting the notion of estimation as having value. In the event you have a deadline, the best you can hope for is to deliver as much working software as you can before that deadline. Dithering over what’s going to fall on which side of the deadline is time better spent delivering a feature and winnowing out low-value crap that came along with the high-value bits of your original ideas so you don’t waste time implementing the dross.

If I do need to estimate, I reject the silly notion of giving a ludicrously precise single value, and instead give a more honest pair of (estimate, complexity), where complexity is rated on a scale from “I’ve done this a hundred times” to “nobody in the world has ever done this” (http://lizkeogh.com/2013/07/21/estimating-complexity/). And potentially give a range instead of a single value, though some sort of highly-skewed normal distribution might be better.

I similarly reject the notion of “backlog” as wasting time counting your chickens before they’ve hatched (http://ronjeffries.com/articles/015-10/the-backlog/article.html). The only project artifact that matters is the running code you have at the end of a sprint. Everything else is BS; use whatever support tools you need, but don’t confuse your list of dreams with what you have in hand now. If you can’t ship what you have now? You’re probably setting yourself up for serious pain and suffering when the budget suddenly runs out, or your main dev gets moved to another project, or quits, or…

I joke that the product champion should keep a stack of might-wants in a Trello board with “a pony” at the bottom. No-one ever gets everything they want implemented in software; most of those inchoate wants are a mix of some good and valuable ideas and a bunch of lossy cruft that would be a waste of time to do anyway. (Also: diminishing returns.) We forget human finity at our, and our projects', peril.

Many project management artifacts and behaviors seem smoke and mirrors rituals attempted in the vain hope of preventing the dread manifestation of Learning and consequent Change. Unfortunately, no matter how many ways we invent to scream, “COME NOT IN THAT FORM!” into the unknown, we remain saddled with imperfect knowledge, or alternatively, blessed with the joy of learning ever more and new things about our domain of interest. Dispensing with these distractors – from the primitive state of both today’s tools and the discipline of software development as a whole, and more generally from our own cloud of unknowing – is terrifying, but addressing reality head-on frees you to make the best use of the precious time and limited tools you have.