By

5 Comments

The case against #NoEstimates, part 2: why estimates matter

Last time, I provided an introduction to a very odd and very vocal recent movement known as #NoEstimates, which seeks ways to reduce or eliminate the use of estimates in software development. I started off my discussion of it by going through some basic common-sense business reasons to reject it. Those reasons for rejection boiled down to:

  • estimates are flat-out natural, ubiquitous, and unavoidable in practical life and in business;
  • expressing general reluctance to do them unfortunately reinforces the often negative perception of IT people as aloof, uncooperative, and unsavvy about business imperatives.

Let’s look now at the many other solid reasons to keep estimates in the software development and project management toolbox:

Estimates help in project selection over a wider time frame, and they assist in filling in a project portfolio evenly to align with overall team/company capacity. Specifically: companies often need to determine which projects to sink time and company resources into: e.g., needing to pick just three out of a list of fifteen proposed projects for a given time period. This is a common and recurring dilemma in every company I’ve ever worked at, where demand for various business functionality always exceeds the supply of resources to fulfill it.

In such a ubiquitous scenario, what makes anyone think that the anticipated cost and duration for delivering each potential project should not figure into the decision process that selects the “vital few” from among the many choices? Why would you possibly rule out considering those factors to the best of your ability? Yes, of course they should be weighed along with value, risk, and other factors, but cost and schedule will always be among the key considerations to juggle.

You’re thinking that assessing probable cost and schedule can’t be done, because you’re uncomfortable with uncertainty, and perhaps you might get it wrong? I’m going to be blunt: then you’re not ready to play strategically in the business arena.

Estimates reduce overreliance on experimenting with “red herring” projects. Nothing is wrong with selective and judicious experimentation on a small scale, focused on learning and adjusting, but the universal NoEstimates answer to the project selection conundrum is to “just start”. Well, simply as a practical matter, you can’t “just start” 15 different projects as an experiment and gather enough useful, consistent information on all of them to feed into your decision meaningfully. Even if you could and did, you’d still have to use your gut (i.e., you’d have to estimate) based on what that information is telling you, since very few of the unknowns associated with each of the potential projects would have been eliminated via the short experiment. The NoEstimates panacea of “story slicing” doesn’t help you here at this up-front stage: unless (and even if!) you story-slice the entire project (which would be BDUF), unknowns will almost certainly continue to lurk in your backlog, some big, some small.

There’s simply no way around it: at some point, if you want to choose purposefully among competing options of similar value, you have to take a shot at determining what each project is likely to take (cost, schedule, dependencies), despite imperfect information.

You don’t like it that there’s a possibility that you might get it wrong and pick the “wrong” projects? Bluntly, again: then you’re not ready to play strategically in the business arena. [Read more…]

Filed Under: Estimating, Industry trends, Process
By

3 Comments

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…]

Filed Under: Estimating, General, Industry trends, Process, Stakeholders, Top 25 posts
By

8 Comments

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”. In short, making the exploration balanced wasn’t even remotely his goal.

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…]

Filed Under: Estimating, General, Industry trends, Process, Recommended reading, Stakeholders Tagged With: , , , , , , ,
By

2 Comments

Starting points for the quantitative CIO: downloadable basic tools

Much as in any field, IT executives constantly have to seek a balance between idealism and pragmatism. Given a particular problem and the range of possible solutions, do we insist on “doing it right”, or do we buckle down and “just get it done”, even with gaps?

There’s obviously no single right answer, which is what makes IT consistently so fun and frustrating at the same time. Over time, though, my own approach has typically been to focus on the continuous improvement aspect of “doing it right”: whenever possible, get something going as a start, then hone it over time as you learn more about the problem and your situation.

Using spreadsheets as a management tool definitely falls on the “just get it done” side of this spectrum of approaches. Spreadsheets are seductively easy, omnipresent, and usable by people with a variety of skill sets and technical savvy.

But there’s a host of downsides: spreadsheets are frail creatures. Errors can creep in fairly easily, even for experienced users, as data and circumstances change, and spreadsheets are especially prone to the incursion of silent errors and omissions when undergoing revision.  And once implemented, in all their imperfection, spreadsheet-based solutions can broaden and become large-scale, long-term systems (I’ve seen this happen again and again).

Yet, I feel that every technology executive should be maximally fluent in spreadsheeting: simple tracking, analyzing, modeling alternatives, understanding costs and risks. The technology provides a readily available, easy way to knock out quick and dirty models that can clarify one’s thinking and approach enormously. They work well, as long as you keep in mind that the spreadsheet is usually a stop-gap, for those times when you are faced with a glaring need and you don’t have time, budget, or staff to implement anything deeper right away.

In an early blog post, I listed the seven areas where a quantitative approach is especially necessary for the technology executive:

[Read more…]

Filed Under: Financial, Metrics, Process, Role definition, Tools
By

10 Comments

“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…]

Filed Under: Pillars of Purview, Process, Projects, Stakeholders
By

2 Comments

Valuable vs. fun: learning to love IT Asset Management

My attitude is that if you push me towards something that you think is a weakness, then I will turn that perceived weakness into a strength.

— Michael Jordan

As with so much in life, so it goes with IT: the parts that are fun aren’t always valuable, and the parts that are valuable aren’t always fun. Let’s talk about a hugely valuable side of IT that isn’t really much fun at all. And when it’s not fun, that means that it’s often neglected, and thus turns into a great weakness.

IT assets (hardware, software, systems, services) represent a major investment for most firms today. For “new economy” companies in particular, the cost of such resources (both bringing them on board and maintaining them as corporate assets) often exceeds expenditures in any area other than wages and benefits.

It’s astonishing, then, that firms (not to mention IT management specifically) don’t always embrace the ongoing hard work required to maximize the value of those expenditures and minimize the corporate risks involved. All too often, I see IT asset management (ITAM) neglected by IT executives because, well, it involves a discouraging amount of drudgery to do it right, especially over the long haul. This neglect occurs even more often when an executive succumbs to the latest faddish push for IT to focus on strategy and innovation to the detriment of fundamentals.

[Read more…]

Filed Under: Anecdotes, Book reviews, Financial, Process, Recommended reading, Vendor management
By

1 Comment

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…]

Filed Under: Book reviews, General, Overview, Pillars of Purview, Recommended reading, Top 25 posts
By

7 Comments

Three IT behavior patterns seen in the wild

Assumed Omniscience, Chooser’s Remorse, and Fixation

With all due respect to the many fine folks I’ve worked with in the career I’ve spent decades pursuing: we IT types can be an idiosyncratic, even odd, bunch.  That’s actually well known to us all, and it generally makes great fodder for this blog.

I find the sociology of the profession—how people interact with one another—as fascinating as everything else about it.  Here are three interesting behavioral syndromes I’ve observed over the many years of IT projects and teams I’ve been a part of. And as with most of my observations of this nature, I’m not presenting them from “on high”: no, I’ve been at times as susceptible to these behaviors as anyone. They’re common, and easy to fall into, but all of them are things I strive to avoid. And all of them have a common thread, as you will see.

Filed Under: Anecdotes, People
Mastodon