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, these estimate detractors 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…]

CMO outspending the CIO on technology: “so what?” Here’s what.

Rarely do I write targeted responses to specific blog posts, but last week, a CMO-related 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…]

IT consumerization, the cloud, and the alleged death of the CIO

As with just about any area, IT is a discipline subject to fads and memes, “received truths” that seem to arise in the press or the blogosphere and then ricochet around the echo chamber until they sound plausible even to skeptics. A number of these roll across my Twitter stream every day. But one such meme rises so high to the top that it has to be the sole focus here. And that is the much-repeated “death of the CIO” meme, coupled as it is currently with dreamy visions of the world brought to us by the consumerization of IT and the cloud. They’re all linked, at least in many pundit eyes.

Here’s the gist of their argument: users can go out and get their own technology now; they don’t need IT to do it for them. End-users are now IT-savvy, and can fend for themselves.They’ll bring their own devices (BYOD); they don’t need or want IT to provide devices for them. They’ll procure the services they need and want from the various SaaS offerings in the cloud or from outsourced vendors, and they’ll handle it all themselves.

All this ultimately gets not only expressed as the question of who needs a CIO anymore, it goes even further: who needs an IT department at all anymore? Says one article, “If IT does not provide the end user with the infrastructure they need, the latter can rent it, by the hour or month from companies like Rackspace or Amazon… All you need is a credit card and no approval from IT.”  Other CIO “thought leader” articles feature astonishing blanket statements like, “With the consumerization of IT, consumers can create value for themselves and the enterprise, using technology that costs the enterprise nothing.” And people even take this so far as arguing that the CIO at this point should just leave technology up to the VARs.

Let me be clear once again: this frequent linking of cloud and IT consumerization to the looming demise of the CIO and IT is not just misguided, but actually gets it completely backwards. In fact, I argue that IT consumerization and the cloud will actually elevate the importance of IT within a company, as both a service and a strategic focus.

[Read more…]

Novels of IT, Part 3: Adventures of an IT Leader

My long quest for an insightful, broad, and practically applicable “novel of IT” finally met with resounding success, once I got my hands on the outstanding book that is the subject of this post: Adventures of an IT Leader, by Robert D. Austin, Richard L. Nolan, and Shannon O’Donnell.

To recap: I was looking for a book that was both reasonably engaging as a novel and one that accurately portrayed a broad swath of the inner workings, nuances, and personality types that are typically part of the landscape of IT in today’s world. Reading the book should provide a window into common dilemmas and disagreements regarding IT issues, lending perspective and insight into all parties’ motivations and interests. See my earlier posts on Chris Potts’ FruITion and John Hughes’ Haunting the CEO.  Again, my views aside, I should emphasize that all three of these “novels of IT” are worth reading and forming your own opinion.

Adventures of an IT Leader comes by far the closest to meeting the criteria I had outlined for a “novel of IT.”  It opens with an executive, Jim Barton, being unexpectedly tapped as CIO by the new CEO of his firm, after long and successful stints managing other areas of the company.  In short, Barton isn’t an IT person by training or experience. In fact, one reason for his selection as the new CIO is that he has long been the foremost critic of the IT function at his company. And now, unexpectedly, he has to walk a few miles in IT’s moccasins, so to speak. The novel then follows Barton and his numerous IT challenges and crises for about a year.

[Read more…]

Novels of IT, Part 2: Haunting the CEO

Last time, I introduced this series by pointing out that reading what I call “novels of IT” could serve a few very useful purposes for those of us who work in and around information technology.  In fact, I presented a number of criteria that come to mind when answering the implicit question of why anyone should bother to read a novel of IT.

Ideally, it’s because such novels, at their best, can do the following:

  • provide a degree of engagement and entertainment in making their points
  • provide a realistic insight, in a “show not tell” kind of way, into what motivates the typical players in these business scenarios,
  • help all factions (inside and outside IT) come to see the other side’s perspective and arrive at deeper understandings of common problems and disagreements.
  • allow the CIO to hand the novel to his or her CEO or CFO and trust that everyone’s reading of it will help reach common ground in how to collectively and collaboratively approach the company’s goals.
There are, of course, pitfalls involved in constructing such a novel, the foremost of which is falling into blatant stereotypes: most notably, the nerdy CIO who clings to technology and can’t see a larger role for himself or herself. The book I covered in my first post on IT novels, Chris Potts’ FruITion, not only fell into this trap in spades, but took it to a whole new dimension, painting IT in general as basically no longer needed as a separate discipline, and as having become so trivial as to not need an executive at all.
This time, I’ll discuss John Hughes’ recent and excellent contribution to this genre, Haunting the CEO.

Can a CIO be successful without IT experience? Define your terms!

Yes, it’s déjà vu: certain topics crop up again and again on IT-related blogs. The age-old question: does a CIO really need to have IT experience?  I’ve touched upon this before, here and here, but it’s time for a full column covering the standard arguments posed in this debate.

I’ve gone through every article I can find on this topic (most of these are listed at the end of this post), read all the associated comments, and culled out the arguments that are typically cited in support of a CIO’s ability to be successful without IT experience. These are:

  • A non-technical CIO can surround himself with a capable team who can support him in all technical matters
  • It’s the ability to lead that’s really needed, whereby the issue of technical capabilities becomes secondary
  • After all, there are some successful business CIOs without technical background
  • Even supremely technical CIOs have been known to fail
  • Considering today’s rapid pace of change, past IT experience can be a hindrance to many CIOs today as often as it is a help: that experience can make a CIO “unduly resistant to the possibilities.”

As I looked at these arguments, though, I found them all strangely uncompelling. I felt truly puzzled: how could anyone argue vehemently in favor of a lack of experience as a job qualifier, for anything? But as I thought about it, I realized it’s a matter of basic definitions. As in so many debates, this topic has been seriously hampered by many parties failing to define clearly the basic terms: what does “IT experience” or “technical” mean, and what does it mean for a CIO to “be successful”? Without a clear and common understanding of what is meant by those phrases, advocates on both sides tend to drift into “straw man” postulates, where they reach a strong and usually quite self-righteous position based on divergent definitions.

[Read more…]

Business impact and transparency: expressing system availability

“System availability was 99.83% last month!  That’s up from 99.75% the previous month!”

Sounds kind of good, no? I mean, that’s a high number, right? Right?

Actually, no.  It’s not a very useful number, in and of itself. In fact, I regard the publication of uptime metrics like that as a regrettable symptom of IT focusing on technical aspects, rather than business impacts.  Here’s a discussion of why I see it that way, followed by a presentation of an alternative focus providing much more business value.

So, what’s wrong with a time-honored metric like “the system was 99.83% available”?

  • The number is deceptive. Few people can mentally translate “99.83% availability” into a more meaningful real number, such as “system was down for 1.3 hours last month.”  Even fewer can tell you the real difference between 99.3% uptime (also sounds pretty good, right?) and 99.8% uptime.  Both 99.3% and 99.8% look (to the vast majority of business people) at first glance like pretty good numbers for uptime, but the first represents more than three times the number of “down hours” of the second.

[Read more…]

One CIO’s “lessons learned” in managing others

Here’s a shocker: none of us has failed to fail at times.

We’ve all screwed things up on occasion, and I’m no exception. And that’s especially true when it comes to managing others, which I believe is very much a learned skill. In that spirit, there are a number of things about people management (call them reminders, admonitions, lessons) that I’d especially want to tell my younger self if I had a time machine. Each one arises from a situation where I’ve learned a lesson the hard way over the years, either from mishandling something myself, or from watching a peer, colleague, or my own manager mishandle it.  As the saying goes, “Good judgment comes from experience; experience comes from bad judgment.”

So here are a few things to keep in mind when managing others.  These lessons have arisen from (largely) IT situations, but their scope and impact is hardly limited to IT.  They’ve become a capsule summary of how I want to manage, and how I like to see people around me manage others.  In fact, when I encounter an instance of “bad management”, or think back on my own missteps, I can almost always point to a deficiency in one or more of these specific areas as the underlying root cause.In no particular order:

Mastodon