“Just try it”? How NOT to sell a controversial idea

Alas: when it comes to pitching a controversial idea, many of us in technology fail miserably. We often fall reflexively into extreme “oversalesmanship” of a pet idea. We tend towards the binary: we seem to find it next to impossible to see the idea’s downsides, or to imagine how other people might be viewing it and how we could usefully, effectively, and without condescension counter their various objections (i.e., barriers to the “sale”) of our idea. 

Instead, here’s how we often react. We “flip the bozo bitall too readily on anyone who criticizes our baby: such folks are clearly clueless, we think; we rant that they must not be technical; they’ve “probably never written software at all” and “possibly can’t work their <expletive> email; they’re a PHB; they’re a troll; they’re a dinosaur; we can’t wait for them to die out so we, the enlightened wizards, can take over. (Actual examples of such declarations are easy to find).

None of this attitude is inevitable or unfixable. A start at combating this weakness when selling others on a controversial idea is to heighten our own awareness of the problem. Inspect and adapt, after all. So let’s focus here on one particular tactic of such bad salesmanship, as frequently employed by the (yes, very controversial) #NoEstimates movement: the “just try it” taunt. [Read more…]

Deconstruction of a #NoEstimates presentation

It’s been over three years now since I published a lengthy dismantling of the very bizarre “No Estimates” movement. My four-part series on the movement marched methodically and thoroughly through the issues surrounding NoEstimates — e.g., what common sense tells us about estimating in life and business, reasons why estimation is useful, specific responses to the major NoEstimates arguments, and a wrap-up that in part dealt with the peculiar monoculture (including the outright verbal abuse frequently directed by NoEstimates advocates at critics) that pervades the world of NoEstimates. I felt my series was specific and comprehensive enough so that I saw no reason (and still see no reason) to write further lengthy posts countering the oft-repeated NoEstimates points; I’ve already addressed them not just thoroughly, but (it would seem) unanswerably, given that there has been essentially no substantive response to those points from NoEstimates advocates.

However, the movement shows little signs of abating, particularly via the unflagging efforts of at least two individuals who seem to be devoted to evangelizing it full-time through worldwide paid workshops, conference presentations, etc. Especially at conferences attended primarily by developers, the siren song that “estimates are waste” is ever-compelling, it seems. Even though NoEstimates advocates apparently have no answer to (and hence basically avoid discussion of) the various specific objections to their ideas that people have raised, they continue to pull in a developer audience to their many strident presentations of the NoEstimates sales pitch.

So here’s my take: the meaty parts of the topic, the core arguments related to estimates, have indeed long been settled — NoEstimates advocates have barely ventured to pose either answers or substantive (non-insult) objections to the major counterpoints that critics have raised. For the last several years, then, the sole hallmark of the NoEstimates controversy has actually not been the what, but rather the how, of how the NoEstimates advocates present it: its tone, rhetoric, and (ill)logic.

With that in mind, it’s time to deconstruct a NoEstimates conference talk in detail. There are several such talks I could have done this with (see the annotated list at the end of this post), but I decided to choose the most recent one available, despite its considerable flaws. And by “deconstruct”, I’m going to look primarily at issues of gamesmanship and sheer rhetoric — in other words, I won’t take time or space to rehash the many weaknesses of the specific NoEstimates arguments themselves. As I’ve stated, those weaknesses have been long addressed, and you can refer to their full discussion here.

I’m arguing that at this point, the key learning to be had from the otherwise fairly futile and sadly rancorous NoEstimates debate is actually no longer about the use of estimates or even about software development itself, but really more about the essence of how to argue any controversial case, in general, effectively and appropriately. It’s an area where IT/development people are often deficient, and a notable case example of that is the flawed way that some of those people argue for faddish, unsupportable ideas like NoEstimates.

The NoEstimates conference talk that I’ll deconstruct here, given at the Path To Agility conference in 2017, is characteristic: in particular, it starts out setting its own stage for a “them against us” attitude; then, it relies on:

  • straw man arguments and logical leaps
  • selective and skewed redefinitions of words
  • misquoting of experts
  • citing of dubious “data” in order to imbue the NoEstimates claims with an aura of legitimacy.

[Read more…]

Stop letting people “just wing it” at work

I wrote last time about some cringeworthy comments overheard from developers talking to stakeholders, and I promised a follow-up that did some exposure of the “other side.” So here goes: rather than focus specifically on cringeworthy comments from stakeholders (I’ve covered some of these here and here), let’s talk a bit more generally, about ways that I’ve see stakeholders contributing to overall dysfunctionality in the workplace.

The anecdotes below are, of course, taken from real life. I should hasten to add that I have a self-imposed moratorium on writing about my clients. I’ll wait a minimum of two years, usually more, before I’ll mention a real-life incident or even general issue in a blog post here. And when I do, I change key details to avoid finger-pointing, while still using the overall incident to make the key point.

At one large client a few years back, I came to see some clear commonalities (dysfunctionality) in the culture of how people worked together. It started by observing various day-to-day behaviors that were enormously impacting overall productivity and results. These dysfunctional behaviors came chiefly from business stakeholders, but I also observed IT people feed right into them and perpetuate them by playing along. I’m talking about behaviors like these, taken verbatim from my notes at the time: [Read more…]

Cringeworthy comments overheard in the IT trenches: the developers

IT developers and PMs: have you ever heard a colleague say something to a stakeholder that just made you cringe, knowing how the stakeholder is likely hearing it and reacting negatively? I have.

Heck, I’ve even been that developer, especially early in my career. But fortunately, enough of getting smacked upside the head (usually metaphorically, thank goodness) by one or more irate constituents tended to clear my thinking on these matters, particularly over time. But yet, I continue to overhear such cringeworthy remarks on a regular basis in IT circles, and I wince in sympathy with the stakeholders when I do. So let’s do some smacking. Metaphorically.

First off, I should note that communication skills always need work. Always, and for all of us. We all can improve. And of course, I know that none of the examples I provide here is usually said with any ill will (and I do recognize that many of them often have certain grains of truth behind them), but that still doesn’t make them defensible. It’s pretty important that none of them ever be heard by a stakeholder.

As I go through some concrete examples, try to hear each of them through the stakeholder’s ears. Anticipate what the stakeholder might be thinking, feeling, and perhaps assuming from your words, from the situation, and even influenced by what they’ve experienced before from you or your brethren. And if you hear one of these gems dropping from the lips of a colleague, pay it forward: say something.

Here are among the worst things a developer/PM can say to a stakeholder. And yes, these are real-life examples; I’ve heard every single one of them, usually many times. [Read more…]

IT and baseball: no silver heuristics

Along the lines of my last post that discussed avoiding slogans and “lazy thinking” in IT, let’s talk about the increasingly popular word “heuristic”. I think we can all agree that developing software is anything but simplistic. So why aren’t we more skeptical when people propose adopting simplistic heuristics for developing software? Let’s look more closely at this manner of thinking, with a specific example.

In a recent exchange, a #NoEstimates advocate declared that one example of someone making a decision amidst uncertainty, without estimating, was the act of catching a fly ball. My response was that there are in fact many estimates involved in that activity, whereupon the #NoEstimates advocate put forth essentially the notion that a fielder uses the following heuristic instead:

“One good way to catch a fly ball is to hold up your gloved hand at a constant angle, and run so that the falling fly ball is directly aligned with your glove. If the fly ball appears above your glove, it is going to go over your head: move back. If it appears below your glove, it is going to fall in front of you: move forward. Left of glove: move left. Right: move right.”

But really: watch any major league baseball game and look for a single instance, just one, where the outfielder is doing anything even vaguely resembling the above. (However, one can certainly conjure up the specter of hapless Little Leaguers, coached in this #NoEstimates heuristic-driven technique, desperately waving their gloves back and forth in front of their faces, flinching while fly balls thud to the ground all around them). You won’t find a real-world example of the above-described heuristic, because using just that heuristic will not lead you to predictable success in catching most fly balls. [Read more…]

IT extremism strikes again: the odd resistance to bug tracking

In information technology and software development, how many of our wounds are self-inflicted?

Here’s what I mean.

What I’ve seen happen, recurringly, in IT over the years and decades: idealistic but inexperienced people come along (within IT itself or in other departments within a company), to whom IT systems and issues seem to be easier than they in fact are. They are smart and earnest and oh-so-self-assured, but they also seem blissfully unburdened by much real understanding of past approaches.

https://twitter.com/CompSciFact/status/602271417330225153

They are dismissive of the need for much (if any) rigor. They generalize often quite broadly from very limited experience. Most notably, they fail to understand that what may be effective for an individual or even a small group of developers often doesn’t translate into working well for a team of any size. And, alas, there’s usually a whole host of consultants, book authors, and conference presenters who are willing and eager to feed their idealistic simplifications.

Over the years, I’ve seen a subset of developers in particular argue vehemently against any number of prudent and long-accepted IT practices: variously, things like source code control, scripted builds, reuse of code, and many others. (Oh, yes, and the use of estimates. Or, planning in general.) To be sure: it’s not just developers; we see seasoned industry analysts, for reputable firms, actually proposing that to get better quality, you need to “fire your QA team.” And actually getting applauded by many for “out of the box thinking.” Self-inflicted wounds.

But let’s talk about just one of these “throw out the long-used practice” memes that pops up regularly: dismissing the value of bug tracking.

How can anyone argue against tracking bugs? Unbelievably, they do, and vigorously.

A number of years back, I came into a struggling social networking company as their first CTO. Among other issues, I discovered that the dev team had basically stopped tracking bugs a year or two before, and were proud of that. Did that mean their software had no bugs? Not when I talked to the business stakeholders, who lamented that nearly every system was already bug-riddled, and getting worse by the release.

Why did the development team shun bug tracking? That wasn’t quite so clear.

[Read more…]

The case against #NoEstimates: the bottom line

I’ve now methodically presented the case against #NoEstimates in three different lights: from a common sense standpoint, from the perspective of the solid reasons why estimates are useful, and by examining the various frequent talking points used by NoEstimates advocates.  Looked at from any of these angles, NoEstimates comes up way short on both its core ideas and business practicality.

Aside from these issues of substance, let’s look briefly at the behavior of the NoEstimates proponents. Blunt as it may be, here’s my summary of the behaviors I’ve seen across most NoEstimates posts and tweets:

  • Presenting, and repeating via redundant tweets month after month, fallacy-riddled arguments consisting primarily of anecdotal horror stories, jibes at evil management, snide cartoons, and vague declarations that “there are better ways.”
  • Providing little or no detail or concrete proposals on their approach; relying (for literally years now) on stating that “we’re just exploring” or “there are better ways”
  • Consistently dodging substantive engagement with critics, and at times openly questioning whether critics should even have a voice in the discussion. If NoEstimates avoids engaging actively in the marketplace of ideas and debate, why should their arguments be taken seriously? Real progress in understanding any controversial topic requires we do more than state and restate our own views, but actually engage with those who disagree.
  • Continuing to use discredited examples and statistics, or even blatant misrepresentation of the stated views of recognized authorities, to help “prove” their case.
  • Frequent use of epithets to describe NoEstimates critics: “trolls”, liars, “morons”, “box of rocks”, and more.

I pointed out in my introduction that the lofty claims of the NoEstimates movement (essentially, that software development can and should be an exception to the natural, useful, and pervasive use of estimates in every other walk of life) carry a heavy burden of proof. Not only have they failed to meet that burden, they’ve barely attempted to, at least not the way that most people normally set about justifying a specific stance on anything.

But aside from style, let’s return to the substance of the issue. Here’s my take, as backed by specific examples over the course of these blog posts: estimates are an important part of the process of collaboratively setting reasonable targets, goals, commitments. Indeed, whether estimates are explicit or implicit, they’re a reality. I see them as an unavoidable and indispensable factor in business.

[Read more…]

The case against #NoEstimates, part 3: NoEstimates arguments and their weaknesses

I’ve spent the last two blog posts introducing the #NoEstimates movement, first discussing what it appears to espouse, and presenting some initial reasons why I reject it. I then covered the many solid reasons why it makes sense to use estimates in software development.

This time, let’s go through, in detail, the various arguments put forward commonly by the NoEstimates advocates in their opposition to estimates and in their explanation of their approach. Full disclosure: I’ve attempted to include the major NoEstimates arguments, but this won’t be a balanced presentation by any means; I find these arguments all seriously flawed, and I’ll explain why in each case.

Here we go, point by point:

  • “Estimates aren’t accurate, and can’t be established with certainty”

Let’s use Ron Jeffries’ statement as an example of this stance:

“Estimates are difficult. When requirements are vague — and it seems that they always are — then the best conceivable estimates would also be very vague. Accurate estimation becomes essentially impossible. Even with clear requirements — and it seems that they never are — it is still almost impossible to know how long something will take, because we’ve never done it before. “

But “accurate” is simply the wrong standard to apply to estimates. It’d be great if they could be totally accurate, but it should be understood at all times that by nature they probably are not. They are merely a team’s best shot, using the best knowledge available at the time, and they’re used to establish an initial meaningful plan that can be monitored and adjusted moving forward. They’re a tool, not an outcome. As such, the benefits of estimates, and their contributions to the planning and tracking process, exist even without them being strictly “accurate” per se. These benefits were itemized in my last post.

Knowing the future precisely isn’t what estimating is about, actually. It’s a misunderstanding and a disservice to think it is. Here’s why. [Read more…]

Mastodon