The case against #NoEstimates, part 1: introduction and common sense

In the immortal words of Pogo, “we have met the enemy, and he is us.”

The long-held stereotype of IT portrays us as uncooperative, unable to integrate socially, always arguing over nits, and deeply, intractably immersed in our own tunnel vision and parochial perspective.

That stereotype has held us back, as individuals and as a profession: it’s actually one root cause for the oft-lamented situation of the CIO needing a seat at the executive table and not getting it.

Now a whole movement has arisen that unfortunately reinforces that negative perception of IT people, a movement that coalesces around the Twitter hashtag #NoEstimates (all movements need a Twitter hashtag now, it appears). It started with long screeds about how inaccurate estimates are for software development: they’re nothing more than guesses; “there is nothing about them that makes them necessary, or even beneficial to the actual creation of software”. They’re a “wasteful and deceptive practice“, lies, and needing them is even comparable to how heroin users need their heroin. You can’t predict the future, they insist. The #NoEstimates rhetoric has become increasingly harsh, and replete with drastic imagery: estimates are a “game of fools“; an “inherited disease for the industry“; “we predict like gypsy ladies.” In what seems at times to be some kind of “top the previous hyperbole” competition, estimates have even been referred to as “management by violence”.

This sort of overreaction, this IT resistance to estimates, isn’t really wholly new, of course. More than once, I’ve watched in horror as an IT person earnestly explained to a company’s senior management how predicting systems delivery is so very difficult and so very filled with uncertainty, justifying how (for example) they couldn’t possibly commit to having a system deployed in a particular quarter. One time, I witnessed the VP of Sales in particular having zero patience with that: “Hey, I get asked to set my sales quotas way in advance based on my best professional judgment; what makes you folks in IT think that you should be an exception?” Business runs on goals and commitments, and on the “best judgment” estimates that help create those goals and commitments. And everyone in the room seems to understand that, except IT.

Setting achievable, concrete goals is healthy, in business and in life. Making solid, reasonable commitments is healthy. Taking responsibility for meeting one’s commitments all or at least most of the time is natural and should be encouraged. And if you’re perceived as constantly wailing that you’re different and special, in fact so special that you believe you can’t really be expected to state when you’ll be done? That’s a non-starter. This blog post is an introduction to how some IT practitioners have been pulled in by the seductive but ultimately wrongheaded NoEstimates claims, and what the resulting implications are for our industry.

What’s #NoEstimates about? Well, its proponents are actually quite slippery on providing any solid definition, reflexively pushing back whenever anyone tries to summarize it for them, and they often prefer to vaguely say it’s just “a hashtag for a concept about alternatives to estimates and how they might help make better decisions.” However, it seems to boil down to a virulent and unshakable base conviction that estimates are utterly horrible, for all the reasons stated above and more. Using estimates allegedly leads to chronic abuse of developers by management, cements inflexibility into projects, and disturbs developer “flow”. The sole alternative to estimates that the NoEstimates advocates clearly identify, however, seems to simply restate the age-old Agile principles of small teams, user stories sliced into doable chunks, use of “drip funding” so as to achieve a predictable fixed cost, and software delivery “early and often”. They point out that software project scope tends to change drastically and frequently during such frequent delivery, and argue that this scope variability allows projects to be declared as done and successful, long before and without ever having actually delivered all the upfront-identified desired functionality.

Over the next two blog posts, I’ll first lay out the reasons to see considerable value in a software development estimating process and its outcomes, and then respond to the myriad NoEstimates complaints that are levied against estimates as used for software development. But we’ll start here, as an intro, just with invoking basic common sense about life and business.

[Read more...]

Towards a more balanced list of content about #NoEstimates

Both my readers will have noticed there’s been a fairly large gap between my posts here, as life (picnic, lightning, and all that) has intervened. Like J.D. Salinger, however, I have continued writing drafts on various topics, and I plan to post more in the coming months.

My past posts here have often delved into a favorite theme of mine: that IT people tend to go to extremes, often rejecting something useful (an approach, a technology, a tool) simply because it has downsides. Such rejection is at times emotional and even self-righteous; we can get so caught up in it that we fail to look at a topic at all evenhandedly, let alone dispassionately.

No better case example along these lines has come along in the past year than the active and contentious #NoEstimates debate on Twitter and in the blogosphere. I’ll have a much more detailed post soon about my objections to the #NoEstimates approach overall (full disclosure: I’m one of its most vocal critics), but right now, let’s focus on one aspect of the relentless advocacy I see in the hashtag’s proponents: its lack of evenhandedness.

Specifically, proponents of #NoEstimates insist repeatedly and proudly that they’re “exploring”; recently, one major advocate tweeted out a call for links to posts about the topic (“I’m gathering links to #NoEstimates content”) so that these could be collected and posted. Yet, it turned out that only posts advocating one side of the issue would be included, even though the resulting list of links was then touted to people who might be “interested in exploring some ideas about #NoEstimates.” When challenged on this dubious interpretation of the meaning of “exploring”, the advocate then defiantly attached a disclaimer: “Warning! There are no links to “Estimate-driven” posts”.

Advocates can use their own blog for whatever purposes they want, of course. Yet, there’s an interesting split going on here: staunchly claiming to be “exploring”, while rejecting the inclusion of any summarizing or critical posts, and then sneeringly labeling all such posts as “estimate-driven.” 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.

[Read more...]

CMOs outspending CIOs on technology: “so what?” Here’s what.

Rarely do I write targeted responses to specific blog posts, but last week, an article crossed my screen that I think is both representative of many people’s attitudes, and enormously flawed in its assumptions, logic, and conclusions. Esmeralda Swartz, writing for ReadWrite.com, titularly opines the following: “So What If Chief Marketing Officers Outspend CIOs On Enterprise Tech?” Even more grandiosely, the post’s subtitle is “Isn’t it possible that a technology buying process driven by marketers instead of technologists will make things better?

Well, I suppose I should allow that anything might be possible, but no, not by the unconvincing (yet not atypical) line of argument Swartz pursues, and not when you consider standard business realities. Here are a few representative quotes related to the backbone of her argument, namely that buying technology is like buying a new car:

  • “Let’s look at an everyday example. Prior to investing large sums of money in a new car, few people feel the need to master the inner workings of the internal combustion engine. “
  • “Despite all this blindness, for the most part, what we buy doesn’t let us down.”
  • “Ultimately, we’ve got a problem that buying a car solves, so we buy a car.”
  • “Buying software – wait for it – simply because it threatened to get the job done – will likely ruffle some feathers.”

Here’s the thing, though. IT systems are not cars. 

[Read more...]

“No IT projects”? A practical take

If you follow the news, it’s quite clear that we’re in the “silly season” of politics, that time when people eagerly grab hold of any questionable statement of their opponent and use it to extrapolate rank incompetence or dastardly intentions (or worse). Language is frequently quoted out of context, definitions become blurred, things get inappropriately juxtaposed. We’ve all seen it.

That’s why they call it silly season. And that behavior isn’t just true of politics, but also can appear in normal business life, on Twitter, and (often) in IT matters as well. When I run across items I disagree with, though, I try to remember that rather than expressing categorical disagreement (let alone outrage), it’s far more useful to look first for common ground, then aim to identify the areas of contention or difference in perspective. That struck me recently when I read Todd Williams’ (@BackFromRed) recent blog post with the title “Stop All IT Projects!” and recalled that another esteemed colleague, Steve Romero (@itgEvangelist), has expressed views along the same lines.

Todd and Steve are both smart, experienced IT professionals whom I highly respect. In Todd’s case, we’ve met in person; in Steve’s, we’ve exchanged numerous emails and blog posts over recent years. Both of them unquestionably “get it” when it comes to IT matters. I generally agree with what they post or tweet; they’ve each written books that I recommend to others. In fact, I even agree with much of what Todd writes in this particular post. But still, with consummate respect, I think these colleagues (and others) are picking the wrong battle when they insist so staunchly on “no IT projects”. Here’s why.

[Read more...]

Mending Wall: Matches and mismatches in IT stakeholder expectations

Oil and water? Some days, the disconnect between stakeholder expectations and IT capabilities (and sensibilities) seems staggering.

Case in point: I was shown an astounding list of generic stakeholder expectations a while back, drawn up by an obviously frustrated group and titled “USER REQUIREMENTS FOR IT”.  The list is most interesting in what the items reveal between the lines. Let’s examine what probably caused this group to write down these specific but very abstract needs.

User requirements for IT

  • Must be adaptable to business situation
  • Must be able to employ multiple SDLC (Software Development Lifecycle) techniques as the situation dictates
  • Must be able to work in a highly parallized (sic!) environment
  • Must be able to accept and adapt to last minute scope
  • Should have multiple channels for functionality development both in terms of large releases and off cycle enhancements that occur in parallel.
  • Must provide the ability to externalize functionality to external teams to quickly develop new functionality
To most IT professionals, these come off as “unreasonable” demands at first examination. But they’re both understandable and revealing, if you take the stakeholder point of view, and if you remember the oft-cited adage that all progress depends on the unreasonable man.

Yes we can, yes we must: the ongoing case for IT/Business alignment

How do we (IT executives) get away from being typecast as technologists, unconsulted on core business issues and approaches? Face it, that’s a common situation and dilemma that we all encounter, early and often, and it’s the grist for a constant mill of articles and blog posts and books on business/IT alignment.

Lately, though, a part of that mill has started insisting that focus on technology should be avoided altogether by what they usually cast as the “next generation” of CIO.  So I’m going to (again) be a bit of a contrarian here: it’s possible for the pendulum to swing too far in the wrong direction. I think that we can at times go overboard in our desire to avoid being seen as the geek with the pocket protector.  Examples: some preach outright denial that there might be such a perception problem: don’t even think of using the terms “IT” and “business”, they urge, and they recommend against ever discussing “alignment” as a goal.  Stop referring to the “business” as something separate, they recommend; IT is just as much part of the business as anything else! Similarly, their advice is “avoid discussing the technology itself.” As if a mere shift in language could solve the perception problem and automatically propel the CIO into the inner circle of decision-makers.

Here’s the gist of how I see it, though: in many (I daresay most) companies, the path of IT from high priesthood to strategic key playerdom has not really been fully traversed: in other words, greater alignment IS still needed of IT with “the business.”

[Read more...]

IT transparency is good. But how transparent should you be?

A few years back, I had an extremely surprising and unpleasant experience as CTO. The director of my Program Management Office ran a weekly status meeting for project stakeholders, where we’d all methodically go through the current project portfolio, in order to communicate on issues, gather necessary feedback, and align everyone’s expectations. I typically attended in order to provide input and executive-level decision participation, but left it to the director to actually run the meeting and present the topics.

Unfortunately, immediately before one of these weekly meetings, that director was given bad news (in a brief hallway conversation, no less) about a major bug that had just been discovered in the software for our highest profile project, which was currently in testing and due to launch in just a couple of weeks.  This project, with its strategic and revenue-enhancing potential, was foremost in the minds of everyone in the company.  Stakes were high, in other words.

[Read more...]

Conventional wisdom that fails for IT

I’ve done several posts featuring what I call “Peterisms”, which are basically aphorisms I’ve adopted that encapsulate hard-earned IT lessons. Let’s turn it around this time, and talk about two sayings that sound equally folksy-sensible, and that I hear again and again, but which I feel are actually dangerous to apply to information technology work. And, of course, I’ll discuss why that’s so.

  • If it ain’t broke, don’t fix it
I know of very few aphorisms that tend to be repeated as smugly as this one, particularly by scared people. The implication is that action is generally to be avoided, that the status quo is probably just fine, and that one should wait for a true crisis before intervening. And, of course, that it’s your fault if you’ve ignored this sage advice and intervened anyway. It’s ironic, then, how IT departments themselves end up complaining endlessly about how they’re always in fire-fighting mode.  This prevailing attitude evolves among (and is a telling symptom of) burned-out sysadmins and developers, especially those who are stuck maintaining systems they didn’t themselves write or engineer. It can be equally summed up as a “don’t touch it, don’t breathe on it” kind of superstition. Or, perhaps, it’s akin to the proud but defensive statement that “we’ve always done it that way.”
[Read more...]