Call me cynical, but I always build in a buffer when someone agrees to a deadline. When we moved into our house last year and hired contractors to remodel the kitchen, I was not surprised when the December deadline slipped into March. When our car is in the shop, I automatically assume it is going to take a few days longer than expected. As I write these words our taxes are being put together, and I can only imagine when the accountant will actually have it ready.
All this makes me sympathetic to #NoEstimates, which is far more than a hashtag on Twitter but an entire critique of the enterprise application software development process. Coined a few years ago by Woody Zuill, a development manager at Hunter industries, it has taken on a life of its own among those who chafe at being held hostage to unrealistic expectations of getting code into production. As more businesses focus on mobile app strategies, I expect the #NoEstimates discussion to become more heated than ever before.
The #NoEstimates Movement Explained
In one of his original blog posts explaining #NoEstimates, Zuill suggested that the time developers put into estimating the completion of a software project doesn’t offer a lot of value. That’s because, like it or not, developers often don’t know what they don’t know until projects really begin and they start to get a better sense of what the businesses’s needs are.
Of course, that’s not good enough for a lot of organizations, which may be why, as Scott Rosenberg recently suggested in his story about #NoEstimates on Backchannel, various frameworks and methodologies have been created to help improve the application development process. Whether you’ve adopted extreme programming, Agile or continuous delivery, however, Rosenberg notes it’s hard to do away with potential deadlines entirely:
Estimates play a part in nearly all of these approaches. Estimates are the siege-engines of the war on lateness. If we use them carefully and patiently and relentlessly, the hope is, maybe, eventually, we’ll win.
In contrast, the #NoEstimates movement is about avoiding any such false hopes. That’s understandable given the long history of challenges in not only creating but integrating complex business software. Many enterprise resource planning deployments, for examples, took years to finish and still didn’t work as planned. Customer relationship management applications fared little better. Developers scarred from such failures are probably loathe to give all but the most ballpark timelines for completion, and business owners are no doubt unlikely to trust them anyway.
What #NoEstimates means in a world of mobile apps
Right now more organizations than ever before are realizing that the best way to engage their customers, partners and their own employees is through the mobile devices they carry with them every day. The urgency around mobile app development will vary from one firm to another, but the increasing expectation to have tools available via smartphones and tablets might make the #NoEstimates movement seem reactionary and combative.
It should be noted, of course, that not all developers agree with #NoEstimates. In a recent blog post, developer David Wentzel suggests his peers study project management, learn to live with imperfect designs and turn estimating into a useful skill in the enterprise.
Developers need to face facts: no matter what we do some manager will always use our estimates against us. And they’ll always change requirements, usually at the last minute. We’re never going to change those facts. Therefore WE must change OUR behaviors.
Although some #NoEstimates proponents offer alternatives such as “story points” and “velocity calculations” to better articulate the time it takes to make great apps, Agile expert Ryan Ripley says the answer lies in a more human approach to negotiating an app development deadline:
#CoachingUp is the better way to solve the abuses that the #NoEstimates fans use to justify their movement. Simply deciding to not provide estimates adds to the already widening gap between traditional management and agile software development teams.
Complicating matters, possibly, is the difference between the world of traditional enterprise applications and the consumer-oriented mobile apps and games that, in some cases, were users’ first experience of mobile software. If a kid in their basement can make a hit app in their spare time, why should it take so long for a business with presumably lots of resources to do the same?
How we move the #NoEstimates debate forward
Such talk is likely to inflame an already vicious war of words, unfortunately. As consultant Peter Kretzman noted a few months back, there has been a “lack of even-handedness about the question of software and project management. This, despite the fact that #NoEstimates is ostensibly about creating an open dialogue on application development, rather than an actual call to eliminate estimates entirely.
There couldn’t be a clearer case study of IT black-and-white-ism, them vs us. Explore all you want, this behavior says, as long as you’re doing it on my side of the issue and on my terms. What, there’s a post that attempts to summarize both sides of the argument? Not interested.
I don’t know if I’ve summarized both sides perfectly either, but the need to create mobile apps that work fast, don’t crash and perform as users expect is an opportunity to add more depth to this discussion.
Given what we know about the history of estimates in enterprise applications, what have developers learned that can be applied specifically to mobile apps? How can business owners, recognizing the speed at which form factors are changing in mobile, do a better job of defining their requirements upfront?
If a business can never come up with a way to promise when a mobile app will see the light of day, its chances of success are next to nil. That’s not an estimate, but it’s a pretty educated guess.
