Instead, here’s how we often react. We “flip the bozo bit” all 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.

Specifically, one of the relatively more polite jibes from the #NoEstimates movement at their critics is the constant objection that the critics haven’t themselves tried NoEstimates, so how could they possibly dare to venture an opinion on it. “Just try it”, the NE proponents insist, and they thereby somehow imagine triumphantly that they’ve dropped the mic. Examples:

• “Have you ever build software using a #NoEstimates approach? Don’t criticize something you don’t understand/haven’t experienced.”
• “Simply: False! Glenn you don’t know what you are talking about. Take #NoEstimates for a spin, and *then* comment. Not the other way around.”
• “I was hoping you would have said you tried it already and found that you lost something from not doing estimates. My concern here is the assumption that estimates are untouchable. Have a small team try #NoEstimates for a while and compare their performance. Then let’s talk.” 
• “Have you tried NE? Because I’ve done both NE and Estimates. The only one that has actually worked in practice is NE for me. Thats why I’ve advocate for NE.”
• “A lot of #NoEstimates guys say they tried #estimates and it didn’t work in their context. I missed the post where you tried #NoEstimates.”
• “The best answer to “prove that X works and I’ll try it” is “prove that what you’re doing now works.” Requests for hard metrics are even more ridiculous. Give me hard metrics that prove that what you are doing now is optimal and I’ll believe that you don’t need to change.“

“Just try it” is both a poor suggestion and not an argument 

Here’s the way I look at it, and this post will explain why: the incessant NE catcall of “just try it” actually deserves not just to be criticized, but to be rejected soundly; it simply makes no sense. And it reveals much about the NoEstimates mindset: chiefly, that they haven’t thought a whole lot through. 

Let’s think about some objections that come immediately to mind when I’m told I should “just try” NoEstimates.

• It’s unclear what “trying it” even means, because as I’ve often pointed out, NoEstimates advocates steadfastly refuse to clearly define what their movement actually recommends/stands for. 
• “Trying it”, for any definition of NoEstimates, isn’t a mere personal choice. You can’t just “go it alone” on trying NoEstimates and then come to your own conclusions, with no involvement from or effect on other people. 

“Just try it” in the case of NE, in fact, really means “impose some (ill-defined, vague) new approach on the entire team, for a non-trivial amount of time, as its new approach to building software.” And (unless you’re simply dictating to the team what it has to do), when we try something like that for an entire team for a good length of time, it first needs to pass the “red face test”: the approach must be justifiable up front, using a solid reasoned argument, one that is plausible both to the team and to your management chain. There are needs and impacts at business scale that take such an experiment far beyond being a purely individual trial. You need to have people bought into the idea, or the whole experiment will be useless anyway. And from a business perspective, you also need to be able to minimize, or at least accommodate, any associated ripples or side-effects. When the CEO asks about your team’s plans and progress, it won’t be an acceptable answer to tell her, “oh, this quarter we’re experimenting with not thinking at all about that.”

No compelling case

So, NoEstimates’ catcall of “just try it” doesn’t make logical sense for the above reasons, but there’s more (or, I suppose, less): the taunt, even after six years of Twitter tempest, also hasn’t ever been backed up with a presentation of a compelling case for NE and/or the addressing of the counterpoints that critics have raised.

It shouldn’t be hard to intuitively grasp the following: “just try it” makes zero sense in general, if you don’t present a reasoned and compelling rationale for WHY people should try the thing you’re proposing. For example,

• I haven’t “just tried” driving with my eyes closed.
• I haven’t “just tried” having my team code outside in a rainstorm.
• I haven’t “just tried” having my team do all their work with classical music blaring at maximum volume.

Let’s recap some of the above: “just trying” NE isn’t like trying a new kind of mayo for your sandwich. It’s way more than just a personal quick experiment; it affects others, and as such it merits a reasonable amount of forethought versus just whimsy. In short, EACH ONE of the three words in “just try it” is problematic when applied to a team approach such as NoEstimates: 

• “just”, which trivializes the duration needed for the experiment, dismisses the need for getting buy-in to your compelling reasons for doing it at all, plus ignores the possibility of negative side-effects;
• “try”, which makes it sound like a quick look-see, rather than a lengthy and team-wide effort; and 
• “it”, which NoEstimates has quite intentionally left undefined; they even proudly pitch NE as entailing a potentially different approach by every proponent.

We actually have alternatives to “just trying it”. Thankfully. 

We can and do evaluate all sorts of ideas without having to actually try each one. In fact, we do that all the time, in daily life and in business: we don’t ourselves try everything that comes to mind, or everything that anyone happens to propose or evangelize. It’s natural and healthy to winnow down what you’ll invest time, money, and energy into trying.

Unsurprisingly, we’re not inclined to try an idea that strikes us as entailing high risk, resulting in low payoff, or having little compelling argument for its adoption, no matter how strongly someone pushes such an idea at us. It’s even possible (indeed, common) to adopt a very strong stance against a clearly bad idea without having actually tried it, and it’s easy to think of examples: activities like doing crystal meth, hitchhiking, bike riding without a helmet, staring at the sun during a solar eclipse, spanking children. I don’t need (or desire) practical experience in any of those to oppose them.

“Just try it”, as commonly used by NoEstimates proponents in the example tweets, is the attitude of the salesman (come on, just try it), the zealot (it always works if you just do it right), and the playground taunter (what are ya, CHICKEN?), all rolled into one. It’s definitely NOT the attitude of anyone who understands that there may be pros and cons to the proposed idea, and who is willing to soberly discuss them with those who may be hesitant.

#NoVersionControl: a Modest Proposal

Let’s further illustrate the magnitude of the NoEstimates “just try it” disconnect, by concocting an extended analogy from the software development world that demonstrates why “just try it” is such a poor approach to convincing anyone of something as problematic as dispensing with estimates: let’s hypothesize an advocacy group for eliminating the use of software version control. Let’s be clear: I myself happen to greatly value using robust version control in software development. And indeed, most people with much experience in software development feel the same way. 

But bear with me, and keep in mind that this is just an analogy: let’s imagine for a moment that a group of folks pops up on Twitter and elsewhere, espousing a #NoVersionControl movement. They write blog posts and deliver conference talks, insisting they work fine without version control, and that in fact “all that time you spent on version control could have been doing real work” instead. And they even use words like “evil” and “suicidal” and “mentally deranged” to describe version control. Their main argument appears to consist of repeatedly stating dramatic things like “git makes you cry.” They revel in telling horror stories about hapless individuals who have erased or corrupted their entire code repository with a single errant git command. Maybe they even regularly post cartoons depicting bad git experiences. They routinely declare that “there are better ways” than traditional version control, but remain quite vague about what those better ways are. They also demand that anyone questioning them needs to “prove” that doing version control is actually worth the time and effort.

Imagine further that these #NoVersionControl advocates react very badly to questions and criticism. Say that they routinely refer to their critics as trolls, morons, dinosaurs, and worse, even using profanities. They block their critics, and encourage others to block them too, and proudly describe doing so as “filtering out the noise”. They refuse to answer direct questions about their stance, and they retort that those who question their stance simply “aren’t ready for the conversation”.

More oddities, perhaps, about these imaginary #NoVersionControl advocates: say that they assert they can’t possibly discuss the topic on Twitter, while nevertheless tweeting tens of thousands of times favoring the idea. They insist that only one-on-one conversations on the topic will suffice, to truly impart their #NoVersionControl wisdom. And maybe several of them travel the world giving paid workshops on #NoVersionControl, all the while innocently maintaining, “I’m not trying to convince anyone.”

Picture everyone’s confusion when these hypothetical #NoVersionControl folks also frequently aver, “I’m not saying never use version control.” (In the next breath, maybe they often boast that they haven’t used it in more than 8 years). And despite reiterating that they’re not advocating “never use version control”, they refuse to name situations when version control would indeed be suitable. And, of course, one of their go-to arguments is that people should “just try” going without it.

Drop the mic, for realz

So, seeing all the attitudes and behavior described above, and having heard no compelling arguments that would cause me to reject version control as a generally wise practice (not to mention that I can easily envision some very real dangers of not having my code under version control!), why would I possibly “just try” #NoVersionControl? Why would I be so inclined, given the poor arguments (and even worse behavior) shown by the #NoVersionControl advocates?

Now, extrapolate all that to NoEstimates; doing so shouldn’t take long (unless you start clicking on some of the links to NE statements that I’ve helpfully included in the analogy). “Just try it”? I don’t think so.

And by the way, if you’re reading this as a NoEstimates advocate and thinking that my concocted #NoVersionControl is an utterly outrageous comparison, and that of course no one in their right mind would oppose version control: well, maybe think a bit more about the implications of that reaction.

Bottom line

Reality: in the business world, basically no one tries anything non-trivial without assessing (and needing to justify to others) the likely merits of what they’re trying. We don’t “go it alone”, and we shouldn’t. No one has unlimited budget (either mental or financial or time available) for experimenting in all dimensions and areas, particularly with company money and an ever-present and understandable scrutiny on how company funds are spent. We all pick and choose what we’ll champion and what we’ll experiment with, selecting from the superset of possibilities, intentionally leaving some paths unexplored. We all use our judgment to make that selection. And we all should be able to soberly describe the specific reasons and criteria for our choices, and be able to convince others that our experiments are justified.

So, you want me to “just try” some specific new approach? Then convince me why I should. (And no, that’s not a demand for “proof”, it’s an utterly natural and human request that you actually present a reasonable case that I should try the technique you are proposing).

• Describe to me in detail how it worked for you, AND where it didn’t, or where it wasn’t ideal. 
• Think about how generalizable your approach actually is. Put yourself in others’ shoes. Prepare civil, comprehensive, non-dismissive answers for our likely objections.
• Stop thinking that the more vigorously and vehemently you evangelize your approach, the more convincing your pitch will be. Because it’s probably just the opposite. 
• And maybe hold back on hurling insults like “scary” or “you don’t know what you’re talking about” at people who still won’t try what you’re so avid about, because all that shows is that you haven’t convinced them that it’s worth their time, money, energy, and reputational investment. In other words, the gap is your problem, not theirs. And if you arrogantly posture as if their reluctance is their problem, they’ll be even less likely to give your idea any credence.

And especially, show some basic business savvy: don’t tell me, when your proposal involves a major SDLC-impacting shift in approach, that I should “just try it,” because that just shows you don’t realize or care that “trying it” is far wider in scope, company impact, employee buy-in, and personal responsibility than trying a different kind of mayo on my sandwich.

When you fail to take into account people’s natural concerns and objections about your new idea, you come off as just plain arrogant. Your evangelistic urge has clearly pushed aside your critical thinking and empathy. And that will drastically reduce the odds of people taking you seriously on this or maybe much else.

The post “Just try it”? How NOT to sell a controversial idea appeared first on CTO/CIO Perspectives.

But everything can be estimated to some degree of accuracy, and “accuracy” doesn’t imply precision. And the very phrasing of the question misses the point on what estimates actually are: note the casual misuse of “reliably” to imply some level of what amounts to certainty. No profession works with certainty. My dentist has never put a crown on this particular tooth, but she has no problem discussing with me the probable time frame, cost, and risks that are involved in doing so.

We’ve got to stop thinking (and we’ve certainly all got to stop exuding the pervasive attitude to our business compatriots) that software developers are special snowflakes who just can’t be reasonably asked to give their professional judgment in a similar manner, in areas they are deeply familiar with in general.  Note too that estimates, properly done, are always revised regularly as your understanding increases. It’s not a one-shot deal. Professionals in any arena simply don’t chronically scoff at normal business questions, and questions on cost, effort, time are all perfectly normal.

Also, think about the automation claim: it’s actually a rather strange and quite techno-centric assumption to make, that anything that you can understand would be both possible and somehow easy to automate. For example, all of us understand quite well the basic process and mechanisms required for driving, but look at auto manufacturers and technology companies struggling with automating the trickier aspects of self-driving vehicles.

Often, what’s very hard to automate isn’t at all hard to estimate usefully. In fact, that’s the whole point. When I drive, any new trip I embark on will have unfamiliar territory and new challenges, yet I am perfectly capable of making some assumptions, setting an overall plan, and adjusting as needed as I proceed. Equally, just because a software project incorporates something new (a technology, an approach, an integration) doesn’t meant that it’s a completely brand-new beast with absolutely no commonalities to what’s come before. We’re humans, we’re engineers, we’re practitioners, and that means we extend tried-and-true techniques and practices every day in various ways without somehow sailing off the edge of the world into the completely unknown/unplannable. We’ve got to stop raising the all-too-frequent lament of “here be dragons” for every new initiative; it makes us come off, to our business colleagues, like Chicken Little combined with Eeyore.

8. We could estimate reliably, but there are other approaches that produce better outcomes. Using estimates takes your attention away from those other approaches.

This is essentially the oft-repeated NE “there are better ways” argument. But that statement carries no weight whatsoever as an abstract declaration, i.e., when it is used (as it almost always is) as a stand-alone deepity containing no specifics on what those “other approaches that produce better outcomes” may actually be. “There are better ways” worked (maybe) as an argument when the NE movement was starting out years ago. Yet years later, we’ve heard little or nothing about these surmised “better ways”. Instead, we simply hear wild claims, the same arguments just repeated more loudly, and zero discussion of the counterpoints that have been raised to them.

If you want to argue that there are better ways, go ahead, but the burden is on you to describe those better ways in detail, so that they can be evaluated and responded to. Anything else is just empty rhetoric.

9. When there’s a lot of technical debt, you can’t estimate reliably because you don’t know when you’ll hit a quagmire. Accidental complexity greatly exceeds essential complexity, but inconsistently. See “7 minutes 26 seconds”.

Again, true but only to a point. The sizable impact of technical debt on estimating is acknowledged and discussed in any text on estimating, such as McConnell. The answer, of course, is to set about actually addressing the overall issue of technical debt in the systems you’re dealing with, not simply throw up one’s hands in helpless despair and say there’s never any use in estimating whatsoever.

10. When the team owns its business outcomes, it doesn’t need estimates. See “AFM Optimizing”.

Not sure what this means, exactly, but it smacks quite a bit of the lofty insinuation of “if only we were in charge.” Really? I’ve rarely (if ever) met a developer who was chomping at the bit to “own the business outcome”, because the implication there is that if the business outcome turns out to be negative, the developer’s job is more seriously at risk. Or maybe this means basing developer compensation on business metrics success: I suspect most developers would run from that idea, because (and this is a reasonable basis for such a reaction) business success may indeed depend on lots of external factors besides the quality of the software systems they construct.  If the stated NE approach/argument somehow means neither of these things, a fair question is “what does it really mean to “own” the business outcome?”

Of course, though, the devs are usually NOT in charge, and someone else owns the business outcome. Even the CEO reports to the Board of Directors. And everyone needs estimates for obvious, non-nefarious purposes: to help decide where we should invest our scarce resources, and to monitor the company’s progress according to the plans we’ve laid out, sometimes even publicly. And whoever “owns the business outcome” is pretty much always going to be interested in setting and watching such plans, using something other than earnest gut-level assurances about how dedicated the team may be. If the business outcome matters to you, you’re going to want to see a plan, and you’ll want to have some notion of how well you’re tracking to that intended plan. Anything else is just asking people to go on faith.

And faith is never enough: specifically, the attitude of “just let us own our business outcomes and trust us, you’ll love the result” doesn’t cut it for most business endeavors. Anyone declaring that is (de facto) aligning themselves with the likes of Elizabeth Holmes of Theranos, where investors lost many hundreds of millions of dollars by trusting a confident, compelling spokesperson and failing to do basic due diligence on the claims they were hearing.

11. My boss uses estimates as a tool of abuse and manipulation, creating an unsafe work environment.

That’s unfortunate and regrettable. Chances are high in such situations that your boss uses other tools and other approaches as well that contribute to an unsafe work environment. Either way, that behavior has nothing to do with the value of estimation when it’s used properly, collaboratively, and non-abusively. Despite what you may see NE proponents claim, the everyday use of estimating doesn’t automatically and always lead to forms of abuse and manipulation; if it did, given the prevalence of estimating in our daily lives, none of us would be able to get out of bed in the morning. So let’s stop making the absurd logical leap of equating estimation with abuse just because that occasionally happens: seeing plentiful examples of bad driving and occasional twisted metal car wrecks on your daily commute doesn’t make a compelling argument for #NoCars.

Moreover, proper use of estimates can in fact be a team’s best defense against being arbitrarily saddled with work that goes way beyond their actual capacity to take on. A healthy culture of estimation and capacity-fitting forces trade-offs, as people up the chain are brought to realize they can’t “have it all”.

Additional points (not in Jay’s original list) that are often cited to justify #NoEstimates:

12. There’s no need to estimate. Just pick the most valuable thing to do, complete it, then move on to what is now the most valuable of the items remaining. Wherever you decide to stop, you’ll have implemented the most valuable aspects of what you set out to do.

OK, but who determines “the most valuable thing to do”? Based on what, and at what granularity? And does the entire team work on that and only that? And what if you run out of money or time before you actually finish the absolutely vital parts of “what you set out to do”? Software isn’t composed of independent chunks where any grouping whatsoever, any subset of its fragmented features, will provide the desired business value. A tricked-out sports car that lacks side-view mirrors and headlights, just because those were deemed less important than the steering or braking systems, is still unusable on the highway.

This item-by-item, no-long-range-plan approach may work fine for something like a software system in maintenance mode, with mostly small, independent, uncertain items (especially, bugs) in an ever-evolving list/backlog. But using it for everything a team needs to take on, especially major initiatives? On its face, it’s an anti-planning, very reactive stance, focusing on one item at a time, purposely ignoring any kind of big picture. And as such, it still doesn’t answer the fundamental, overwhelmingly common, unavoidable business question: I need business capability X. What’s the likely time frame, cost, level of effort, risk associated with getting me that capability?

13. Deliver regularly. Users will stop asking for estimates because they know that the team delivers regularly.

Color me (intensely) skeptical about the odds of users suddenly deciding they don’t need to know likely levels of effort (cost, time frame) for their initiatives. Users are not going to be fooled: regular delivery of smaller items in general doesn’t say much, if anything, about the delivery of a *specific* desired larger business capability.

As the metaphor I always use illustrates: just because a bus terminal features buses arriving every 3 minutes doesn’t tell me anything whatsoever about when MY bus to Pittsburgh will show up. Why would the regular arrival of various buses possibly cause me to stop asking about the arrival time of the bus that I need? Why wouldn’t I care about being informed if, say, that specific Pittsburgh-bound bus breaks down en route to the terminal and there will now be a substantial delay before it will be there? Why wouldn’t I take it amiss if your answer to my “when will the Pittsburgh bus be here” is a smiling, placating, infuriating “oh, not to worry, buses arrive here on average every three minutes”?

Similarly, your team may be delivering various items every week into production. That’s laudable and something to strive for, but it is a completely irrelevant fact when people ask (and they always will) when the team will likely finish building a specific larger capability that will take multiple weeks.

Not answering (essentially, point-blank refusing or even politely fending off) the question about when something can be expected can work just fine, in all those cases where no one especially cares when that something will be delivered, what exactly might be delivered, or how much it is likely to cost. Because that means that there are no stakeholder expectations and no curiosity about progress and likely time frame. I’ve encountered exactly zero such circumstances in my decades as an IT professional.

So between Part I of this post and Part II, I’ve laid out, item by item, approach by approach, the specific counterpoints to all of #NoEstimates’ collected “definitions”.

And let’s make the key point again: NE proponents cannot and do not ever respond to these counterpoints with actual reasoned responses attempting to argue their invalidity. Instead we hear insults, name-calling, and blocking of anyone who challenges their thinking. Draw your conclusions.

The post “Definitions of #NoEstimates”? An enumerated list of counterpoints, Part II appeared first on CTO/CIO Perspectives.

Of course, each of the described approaches/arguments has been outlined (and countered) individually many times before. But as far as I know, none of the major NE advocates has ever actually addressed any of the counterpoints to them, choosing instead just to block and insult the people making those counterpoints, often boasting proudly that they do so to “filter out the noise”.

In any case, let’s centralize those counterpoints now: here’s an item-by-item recap, springboarding off of Jay’s enumerated list of #NoEstimates approaches. For reasons of space and manageability, I’m splitting this rundown of counterpoints into two separate posts. Here goes:

1. Size everything about the same and count them, it’ll give you just as good results as estimating, without the cost of estimating.

It’s easy to SAY “size everything about the same”, but that’s devilishly hard to do in software, either in large chunks or small chunks. This is especially true if you try to adhere to the tenet that a completed story needs to provide real (and independent) user value. (And let’s not even cover the irony that “size everything about the same” incorporates (wait for it) estimating).

Let’s walk through a fictitious example. Say you need to add a new column to an on-screen grid, and populate it with specific information based on business rules that might differ from row to row. One “chunk” (sliced story) might be just adding the physical column to the grid. Value added, right? Not really. An empty column does the user no good at all. However, it’s probably relatively quick to do, compared to (say) actually populating the column according to the necessary business rules.  Now think about the business rules: maybe some of those business rules requires new data amalgamations of some kind (client side for some, server side for others, perhaps) and will thus require significantly more development and testing time than others. And some of the rules may turn out to be almost trivial to implement.

OK, so maybe in this example you can “slice” the story so that each business rule is a separate story. But, does that really provide independent user value in each slice? Some NE advocates will argue it does (some results being better than none), but in my experience, users want to see their grid populated correctly for all rows, not just a subset. It wouldn’t be logical to argue that having just a few of the gauges and controls in your car actually working would be acceptable in any sense to the normal driver. So slice away, but I submit that you’re going to have great difficulty slicing the needed full capability (a revised grid with the new column populated) into meaningful, truly-user-valued deliverable chunks. Don’t get me wrong: slicing is a smart way to divide up the actual work, but recognize that you’re probably going to have to compromise (often) on the “has independent user value” aspect for each slice.

But here’s the point: as you should be able to tell from that example, it’s not uncommon for sliced, supposedly “small” stories to widely vary in size, from taking 10 minutes to taking (say) 2-3 days to complete. That’s two orders of magnitude in size difference (a reminder to my NE friends: one order of magnitude is 10x), which completely destroys any argument that “counting will give you just as good results as estimating.”

2. Split stories as small as you can and then count them, it’ll give you just as good results as estimating, without the cost of estimating.

Same basic counterpoint as above: there are potential orders of magnitude of difference in slice size. And what’s this vague hand wave of “split stories as small as you can”? Again, if sliced stories are meant to have independent user value, that user value and sliceability is determined/bounded by the nature of the envisioned capability. Some stories will not prove very sliceable at all – my canonical example is when Twitter expanded the length of tweets from 140 to 280 characters.  There were of course a lot of related tasks and subsystems to change across the Twitter ecosystem, but there was no conceivable user-visible middle ground of partial delivery. Maybe they decided to defer work on some of those subsystems, but they still would have had to put in the necessary work to carefully confirm that such deferral was technically possible without dire impacts.

Moreover, if you’re going to base your “results” (by which the notion of forecasting is meant here) on story counts, then when do you slice your story? There are only three alternatives (up front, just-in-time, and trying to dodge the dilemma by using a “splitting factor”), and they all have notable issues:

• • If you slice stories up front for all envisioned capabilities, that’s BDUF by definition. You might never implement some of those stories by the time you reach them, or their definition/approach might change enormously by that time, so including their count in your forecast will throw it off.
  • If you slice stories just-in-time as you tackle/slice each original story, then what can you “count” when forecasting the completion of the whole set of stories that you have yet to take on? You don’t yet know the end count of stories. Your forecast contains apples (original stories) and oranges (split stories).
  • If you forecast your so-far-unsliced stories by boosting their story count via using one or more “splitting factors” (e.g., determining that most original stories have historically turned into an average of 1.78 stories once sliced), now you’re just playing with math and coarse-grained conversion factors, while studiously ignoring that there may be glaringly non-average stories that remain to be tackled. Again, original stories (especially epics) can vary in size by orders of magnitude. Spreadsheet calculations often feel nicely plausible and comforting, but they aren’t always the answer, and discarding the human judgment factor by outsourcing it to mechanical calculation has great risks. Reflect, for example, on the many times you’ve been frustrated by the Windows progress bar.

Summary: counting stories to use in forecasting, without taking story size into account, is a chimera of a real alternative to estimating. Using data is great as one way to triangulate on the “when will we have it” answer you need, and it’s recommended for your toolset, but don’t depend on it exclusively. Especially, don’t have that approach extend to accepting the bizarre implicit NoEstimates “taboo” on taking story size into account when planning or even discussing.

3. It’s useful to estimate whole projects so you can decide whether to fund them, but don’t waste time estimating day-to-day activities.

Apart from using what is universally acknowledged to be the most dangerous and ill-advisable estimating technique (i.e., raw gut: “oh, that’s a four month effort”, often spouted off in the hallway with little or no thought), no one can viably estimate whole projects without doing some form of analysis/decomposition, whether that’s back-of-napkin or something more formalized. And once you do that, it’s natural to size those individual chunks and roll them up to a whole, informing your overall estimate. That’s an advisable and more granular approach than “whole projects”, but it isn’t estimating day-to-day activities.

But think about the straw man being implicitly evoked here: estimating the likely cost/impact of anything is natural and useful, whether that’s done holistically or for an individual task. In other words, the question of “how long will this likely take” is really never out of bounds. Why would it be? Asking “do you think you can be done with that by Friday, or will it take longer?” is not, as NE tends to depict it, an indisputable example of Evil Oppression By The Man. Equally, asking “why did our actual effort on this story turn out to be three times what we had collectively anticipated” is an utterly reasonable question, fully worthy of coming out in a retrospective, with perhaps important lessons to be garnered about what the team might have missed and what it could now take into account in the future.

Again: why would there be a taboo?

4. Estimate day-to-day activities because they are simple enough to understand, but don’t try to estimate whole projects which are full of unknowables.

“We can’t predict the future” is the constant lament of the #NoEstimates advocates. But predicting the future is exactly what we are all called upon to do in business in general: to take our best shot at anticipating factors such as demand, supply, sales, overhead, seasonality, and more. We don’t get to choose NOT to, in fact. How many widgets should we manufacture to meet the likely holiday demand? How many customers do we need to sign up at a particular price point in order to break even? What’s the likely impact of dropping our price by 20% to undercut the competition? All of these require coarse-grained judgment calls. Even though they’re “full of unknowables”. We’d better figure out ways to make such calls, if we want to stay in business.

5. Estimates are unreliable, so we shouldn’t use them to make decisions. That would be irresponsible.

See the above counterpoint to #4. “Unreliable” seems to be used, in this #NoEstimates argument, as a synonym for “not guaranteed to be absolutely correct”. But in the world of business (or life), there are never any guarantees. We seek the best information available in order to make the necessary decisions, in the hope of tilting the odds of success in our favor; making estimates of size/effort/impact/benefit is simply unavoidable. If you have to make a decision about anything in the future, and you do, you are in fact estimating in some form, even if you steadfastly refuse to admit it.

6. Estimate value, not cost. Value varies by orders of magnitude. High-value work will exceed the cost by so much that cost won’t matter.

“Cost won’t matter” can be true (sometimes) for a few rare “big bang” products (think iPhone etc). (Also note that those sorts of projects tend to be huge corporate gambles as to their probable success: compare the Amazon Fire Phone experience to the iPhone).

But “cost won’t matter” is simply not true for the vast majority of software projects, which tend to be incremental add-ons, internal capability enhancers, enablers of integrations with other products, etc. For most things we consider taking on, cost does matter, particularly opportunity cost (i.e., what else we’re NOT working on as we tackle a particular project). Weighing the whole picture in advance (the likely cost and the likely resulting value) is a far wiser approach than just “going for the shiny”, being seduced by the hope of big gains. “Going for the shiny” with no regard for its cost or time frame, thinking optimistically that those aspects “won’t matter” because you’re sure your reaped value will be so huge, is a great way for firms to go bankrupt.

So there you have it for the first half of the collected “#NoEstimates Definitions” that Jay listed: item by item, approach by approach, the specific counterpoints to each. What’s most interesting about the debate at this point is that, aside from hurling insults, name-calling, and blocking, NE proponents cannot and do not ever respond to these counterpoints with actual points to argue their invalidity. Which is the most telling behavior of all.

Stay tuned for Part II, where I’ll cover the remaining 5 bullets from Jay’s original list, plus adding a couple of common NE arguments that he omitted.

The post “Definitions of #NoEstimates”? An enumerated list of counterpoints, Part I. appeared first on CTO/CIO Perspectives.

• Enable us to gauge the team’s overall capacity to take on work, by basing it on something other than pure gut and/or table-pounding; and
• Enable us to fill that team capacity suitably, despite having items of different size, and, again, basing our choices on something other than pure gut.

But there’s lots more to cover. I have more observations about the role of story points, and I want to provide some caveats and recommendations for their use.  And it’s also worthwhile to list the various objections that people routinely make to story points, and provide some common sense reasons for rejecting those objections.

Provisos, bold observations, and recommendations

• Yes, of course story points are addable — because that’s really their main use/purpose: to be collectively weighed as a total against a notion of total team capacity. You can’t do that effectively with a disparate bunch of t-shirt-sized items. I’m mystified about why we see such monumental outrage about “you can’t do math with story points”. Here’s why you can:
  • They’re a rough approximation of magnitude.
  • They’re intentionally a numerical approximation, correlated to size/effort, even though imperfect. When I’m weighing a slate of stories against an assessed total team capacity for a given time frame, of course I sum up the story points for the individual items: that’s the whole point, as long as one keeps in mind their nature as a rough approximation.
  • The very reason for choosing a numeric representation for story points is to have that kind of arithmetic make sense; otherwise we could have used colors or animals or funny icons (or whatever) instead.  And it’s related to why we typically use a Fibonacci scale and don’t use a straight arithmetic progression such as 1, 2, 3, 4, 5, 6, etc. The idea is to make the assessment of different items correlate clearly (even though approximately) to discernible size jumps, not to argue incessantly over whether a given item is a 5 vs. a 6.
• Don’t think in terms of time needed when assigning story points to an individual item. That defeats the purpose of abstracting time away. People are notoriously inaccurate when estimating in time, and when they attempt to do so, their subsequent near-automatic step is to translate time mentally to money. Using story points provides one more layer of abstraction that helps stop that. Focus on the relative size of each item, not a direct translation to time. The goal is to provide the by-item detail that will collectively help us fill a sprint to (near) capacity, not to hit any specific time target.

• Now, this whole approach works only if story point assessments are made in good faith, which is why the oft-tweeted NFC and TFB cards (rather obnoxiously and extremely counter to the spirit of collaboration) miss the point. Somehow, the same people who insist that we need to trust developers to self-manage and always work on the right thing also argue that those developers will tend to “game” any story point assessments so that the discussion will be over more quickly or so that they’ll have less work assigned.

Attitude matters

• In short, the team has to take it seriously. No one should expect useful estimates from bad attitude. The thing is, it’s actually in everyone’s interest to take it seriously. People should intuitively see the benefit (for everyone, including the team itself) in right-sizing the workload for the team, and in making sure that expectations are aligned with what is feasible. In fact, my biggest objection to planning poker as an Agile ritual is that the metaphor itself is that of a game, which unfortunately evokes a win-lose mentality. Especially if poorly facilitated, planning poker “gamifies” the necessary analysis so much as to reduce the level of seriousness with which the team regards the endeavor.

• Equally, management has to take it seriously, by understanding the notion that a capacity limit actually exists. In fact, one little-touted advantage of story points to the dev team is that they are the team’s best concrete defense against being overladen with work simply because a manager pushes hard for more more more. If you consider that benefit, the dev team should be among the most avid advocates of using story points to aid capacity planning.

• Don’t overstuff the sprint to the full anticipated capacity; leave some margin. Over time, the team will get a good sense of what their capacity (in total story points) likely is, and will know how much buffer it makes sense to leave vacant. And they’ll have a good idea of how to adjust the target amount if there’s an absence (planned or unplanned) on the team during a sprint.

• As with anything, expect things to be off a bit. Adjust constantly: inspect and adapt. Jettison a story from the sprint at the last minute if you have to, but recognize that having to do that is a sign that something went awry in your assessments that you can and should likely address in a retrospective.

• Finally, don’t try to equate or map or compare story points across teams. They’re an approximation, specific to that team and that particular point in time. In fact, expect them to drift over time (a “2” last year may not be the same as a “2” right now, for example). They’re simply a tool, a rough assessment, not a measurement. In fact, much of the confusion and agitas surrounding story points can be tied back to the false understanding that they are somehow fixed and deterministic.

Answering the objections to story points

What are the arguments that get raised against story points? Pretty much the same as the shots taken against estimates in general, but lately even more virulent:

• Story points are viewed as “arbitrary”
• They’re hard to explain to end users
• Users want to translate them into time
• They’re too hard to determine for each story
• Sometimes they turn out to be wrong
• People determining them sometimes just spout out a number, just to be done with it, and don’t really take the time to think through the story’s nuances and difficulties

Common sense answers to the objections

Let’s talk about some answers to those objections, one by one.

• “Arbitrary”: well, “arbitrary” is a word that many people unfortunately like to use when what they really mean is “not precisely measurable; based on judgment.” But that’s not what the word “arbitrary” actually means. It’s an alternative and utterly binary definition, colored by a value assessment: precise=good, imprecise=arbitrary. But the world isn’t binary, and the mere fact that something is judgment-based isn’t a disqualifier for its usefulness. For example, court rulings are also based on judgment and can be called “arbitrary” in that same (wrong) sense, but they are anything but random, since they’re based on careful reading of the law, applied to the given situation by experienced professionals. So too with story points: that they lack absolute precision or that they require judgment does not mean they lack usefulness. They’re certainly not arbitrary in the sense of “randomly chosen without due thought”, or, if they do get randomly chosen in a specific instance, that’s an issue with the attitude or training of the people determining them, not with the concept itself.

• “Hard to explain”: yes, story points can be hard to explain to some folks. But if you explain story points in the context of team capacity, most business people innately understand the basic concept. Anyone who has observed a workgroup in just about any domain (say, staffing a restaurant for the varying crowds during a day) will not have trouble seeing that using a quantitative model can be useful despite being imprecise and despite not being guaranteed. I’ve never found an end user who couldn’t quickly grasp the benefits of approximated capacity planning for workloads that aren’t precisely predictable.

• “Users want to translate story points into time”: That kind of behavior tends to happen mostly when things have gone awry. Almost always, users tend to focus on finding out when they’ll get their desired capability, as a whole. If it gets to the point where they themselves are taking story points and then calculating the likely time for individual stories, they’re far too into the weeds of the “how”, and the reason they got there is probably that they weren’t getting direct answers to their very reasonable questions about when they could expect completion for their capability as a whole. So, users trying to translate story points into time is really a symptom of poor team and/or product owner communication with those users, not an inherent issue with story points themselves.

• “Story points are too hard to determine for each story”: this objection often falls away if there is appropriate facilitation of a planning/estimating session, designed to identify the various damaging factors such as wrong-headed striving for precision, participant fatigue, encroaching biases, occasional HiPPO influence, the “alpha wolf developer” element, etc. Pay no attention to intentionally incendiary anecdotes such as “oh, we argued for an hour about whether the story was a 3 or a 5”: those tales don’t reflect a true problem with story points, but rather are a sign of a poor process, and most definitely poor facilitation/leadership of that process.

• “People just spout out a number without thinking”: Well, the sensible advice is don’t do that, and don’t let the team do that. Again, adequate facilitation addresses this problem. When it occurs during a planning session, it’s generally very obvious that it’s happening. Time to take a break, and/or to counsel people in participating meaningfully instead of by rote.

Don’t confuse sizing and scheduling

• “Sometimes the estimates turn out to be wrong”: indeed they do, sometimes. Imagine how crippling that possibility of “I might be wrong” would be for a weather reporter, or a surgeon, or a baseball pitcher, cowed by the very prospect of error. As I’ve written before, if you’re paralyzed by the notion of occasionally being wrong, you really shouldn’t be making business decisions at all.
  • Even worse along the lines of “the estimates might be wrong”: #NoEstimates advocates will assert that story point assessments are completely useless. They “prove” that point by showing scatter plots of item size versus actual end-to-end item delivery time, with the intention being to demonstrate that the total time for actual completion (i.e., measured from conception to delivery) of an item isn’t correlated to the story points assigned to that item. Their triumphant conclusion is then that “size matters little”.

But thinking “size matters little” is wrong-headed, and here’s why. It reflects a misunderstanding that story points somehow represent an estimate of when something will be delivered; but they don’t. No one ever said that “the smaller the item, the sooner you get it,” and that of course doesn’t conform to common sense in software or any other domain. There are dozens of valid, common reasons why a specific large item might be delivered far sooner than a smaller item; that’s a scheduling issue, not a sizing issue, and it is influenced by multiple factors such as dependencies, priorities, external delays, interruptions, changes in staffing, etc. Yet that does not mean that size itself is irrelevant when juggling what gets put into the schedule in the first place.

It shouldn’t be hard to see the intuitive and universal sense behind the overall concept of “if you take on bigger items, you will generally get fewer of them done in the same time period than if you choose smaller items.”

Again, the key is thinking in terms of filling up capacity appropriately. Story points help you do that. But as with any kind of estimate, they should not themselves be mistaken for a schedule, a guarantee, a commitment, or a promise. Appropriately understood and used, they can help you arrive at those things, but they’re not those things in and of themselves.

The core puzzle

The core puzzle: whether you do or don’t favor story points as the specific approach, why would anyone want to purposely exclude size of the various items as one important factor when determining what will be a manageable slate of work for a given time period?  Can such folks really be that uncomfortable with the fairly obvious notion that planning always has to incorporate some element of judgment call about what items to include or exclude, after making and weighing approximations of approach, impact, benefit?

If you exclude taking item size into account, how then can you possibly align the chosen work to team capacity, much less gauge what that capacity really is? In short, how does ignoring size make any sense at all? What are the alternatives, besides the simplistic notion of just engaging in serial work: slogging through one item at a time, chosen without considering its size (or worse, picking just one slice of the overall item), and hoping for the best? How is that a plan?

My answer is that no one has made a plausible case (other than through frequent and adamant assertion) for any viable alternative. Some form of sizing always needs to enter into the discussion when slating a body of work, in software or any other domain. If you don’t consider sizing explicitly, it happens implicitly somewhere along the line. As I always say, I prefer doing things on purpose and with appropriate transparency (and debate) among all participants.  Transparency, of course, carries with it the possibility of being wrong, and having to justify one’s decisions. Accountability, in short.

As discussed above, story points are actually one of the most reasonable and practical solutions to various issues/problems surrounding capacity planning and filling. And that may be why they are now attracting particular animosity, from people who appear to be perhaps by nature opposed to estimation of any ilk. Workable solutions, especially in the estimating arena, are often lightning rods for criticism from people who staunchly fight the very concept of estimating at all.

Stand down, story point bashers

Bottom line: let’s stop bashing story points. Stop claiming they’re “widely discredited.” Because the idea is sound, and if a well-facilitated team makes a bona fide effort to use story points appropriately, they work well as a way to roughly align workload to team capacity. Which is a highly desirable outcome for all.

And finally, although pride of ownership makes this hard to admit, “story points” is a far better term for the concept than “quocknipucks”.

The post Quocknipucks, or, why story points make sense. Part II. appeared first on CTO/CIO Perspectives.

What’s the team’s capacity, I asked? How much can it reasonably take on before it becomes too much? How do we viably fit in smaller items along with the major initiatives, instead if it being an either/or? No one really knew, or even had thought much about what seemed like natural (even mandatory) questions to be asking.

At the time, I declared that it seemed like we just needed some abstract unit of capacity (I jokingly proposed the first Carrollian word that popped into my head: Quocknipucks) that could be used to help us “fill up the jar” with work items, large and small, without overfilling it. Each item would be valued in terms of its number of Quocknipucks, representing some approximation of size, and we’d come up with a total team capacity for a given time frame by using the same invented Quocknipuck units, which we would adjust as we gained experience with the team, the platform, the flow.

Little did I know that I was independently coming up with the basic idea behind story points. Interestingly, the term I chose was deliberately whimsical, to separate the concept from things in the real world like the actual amount of time needed for any particular item.

Here’s what I’ll argue: the basic idea behind story points is sound, and useful; yet, somehow a certain set of Agilists has now come to reject story points entirely, even referring to them (wrong-headedly and quite overstated) as “widely discredited”.

Not only do I tend to not like bandwagons, I tend to especially dislike reactive backlashes that become anti-bandwagons, as it were, such as the vitriol that is now often directed at story points. So, let’s discuss my now-contrarian view that story points were actually a good and reasonable idea to begin with, and how they can be fruitfully used without (as seems to be the dire stance about them these days) somehow sapping the very life motivation of a team.

What story points really are

A story point represents, in essence, a unit or portion of total team capacity for a given time period. It bakes in some rough assessment of level of effort needed. But that assessment is not size alone, purely: the greater the risk, complexity, or uncertainty involved in the item, the higher the likelihood that the item will consume more of the team’s capacity, so the greater the amount of assigned story points.

Note that a story point assessment of an item is an estimate, not perfect. It’s not intended (at all) to be used directly to predict specific delivery time/date of the item. In fact, I’d argue (contrary to many Agile pundits) that story points don’t even make sense to think of as a unit of time, any more than gas tank capacity units really represent miles driven. They’re capacity units, not time units. They intentionally “abstract away” the time element, for solid reasons discussed below.

Common problems that story points solve

Here’s why story points made sense to invent as a concept/approach. There are two huge and intertwined problems to solve when it comes to planning what work items a team should take on for a specific period of time:

1. we don’t know the team’s overall capacity to take on work
2. we don’t know the size of each proposed item. And most people intuitively understand that when you’re filling a fixed-dimension bucket, the size of each item you put into the bucket matters, a lot.

Let’s double-click on each of those problems, and examine how story points fit as a solution, particularly as compared to the alternatives commonly used or proposed.

Problem #1: we don’t know/can’t precisely measure the actual capacity of the team: i.e., the total amount of work the team can viably take on for a specific period of time.

Approaches to solve:

• “Just count stories” and track how many the team actually does: there’s your capacity, at least for moving forward. But wait: stories aren’t all equally sized, and can in fact vary drastically in size from item to item. A team might finish a dozen small stories in a sprint, or just a couple of larger ones. (Note that #NoEstimates advocates disagree with this fundamental point: they appear to believe that all stories, no matter what, can be sliced into essentially equal-sized (and independent!) pieces. But no actual examples ever seem to be provided that would demonstrate that this fervent belief in “slice size equality” is well-founded. In my decades of software development, I’ve not worked on an application where desired stories, even when sliced, were even close to either equal-sized and independent, much less both at once. See my example below of Twitter’s tweet-length change).
• Or: use story points, methodically assigned based on the gauged size/complexity/risk of each item, and track how many total story points the team typically accomplishes in an equal-length sprint. That’s your capacity, and it allows you to take item size differences appropriately into account as you plan your next sprint.

Problem #2: we don’t really know the size of each item. Why does that matter? Think capacity planning: again, when you’re filling up a finite-sized bucket, you’d better take into account the sizes of the various items you’re putting into it.

Approaches to solve:

• Estimate the likely hours of work entailed for each item, and use a “people multiplied by available work hours” as the denominator in the formula for determining total capacity. This has proved problematic in many ways. People aren’t good at gauging the time (measured by time unit) that it will take to do something. And time required for an item can vary, often drastically, depending on who does the item. So most people now recognize that this isn’t a viable approach.

Slicing? But stories aren’t sushi

• Or, slice apart every item so that the resulting slices are approximately equal in size, and small. But in the end, that basically recreates story points, in that it answers the critical question, how big is the original item? I.e., this particular item is 5 stories once sliced; that one is 8 stories. Moreover, this approach raises another issue: you don’t have the luxury to do that depth of analysis on all items up front, and if you did, it would be doing so too soon, because a) things change as development progresses on a system; and b) you’ll have whole (original) items that you will end up de-scoping from delivery entirely, meaning that the slicing work was wasted.

Slicing and counting as an approach also tends to assume fungibility/equality-of-size of each end slice, with few or any interdependencies, dismissing the business need for the whole, and emphasizing delivery of mere fragments, one by one. That assumption (often) is simply not viable or true. And if I’m a product owner needing the development of a particular end business capability, I don’t especially care if that capability is composed of ten sliced stories or five, from the point of view of the development team. Getting three out of the ten slices may do the business almost no good whatsoever; despite what advocates claim, it’s often not easy (or possible) to make slices independently valuable, much less independently deliverable. Rather, a product owner typically needs essentially all those slices implemented to deliver the end business capability they’re seeking.

Slicing: no, stories aren’t tapas either

My canonical example: consider what might have qualified as independently deliverable, same-sized “slices” for the necessary dev work when Twitter moved (in November, 2017) from a character limit of 140 to 280. You can’t, at least not meaningfully, when you think about the likely number of subsystems that had to jointly support the higher limit. Were there individual chunks of work involved? Of course. Were any of those chunks really useful (to the end user) on their own? And were those chunks arguably all the same size? Of course not. What mattered was (solely) the end goal, and the concrete delivery of all necessary and coordinated changes, to support the overall desired 280-character capability.

So, for these reasons, slicing (alone) isn’t a great answer to the underlying need for sizing. You just can’t wish away the fact that not all work is the same size and that work cannot necessarily be forced into the same size.

Again, story points provide a workable solution

• Or: use story points to approximate the relative size of each original item. An individual item’s story points DON’T specifically predict duration or time frame to complete, at least not to any level of precision. They’re meant to form an abstract notion of size, combined with risk, combined with complexity, and expressed in a numerical sense relative to other stories. Story points intentionally abstract away important factors such as who will do the work, when it might begin, and whether there could be long interruptions while doing it. As such, story points of course don’t/shouldn’t translate directly to a schedule. This should be blatantly obvious, but often isn’t. See Mike Cohn’s article that presents an analogy of “walking points”, where he points out that the same exact task (or, in the analogy, walking distance) but with greater risk or complexity is “larger” than the task without those aspects.

So, story points provide a workable solution to both of the huge issues outlined above. They help you approximate the total capacity of the team, and they give you a meaningful and explainable way to roughly fill up the team’s capacity bucket appropriately with a variety of different-sized items, without overstuffing it.

There’s so much more to be said on Quocknipucks story points, but this post has already gotten quite long. So, stay tuned for Part 2: now that we’ve delved into why story points make sense, I’ll list some observations, caveats, and recommendations for using them in general, and cover some common-sense answers to the specific objections that tend to get raised about them. And I’ll discuss why, ironically, the dev team should actually be among the biggest advocates of doing capacity planning via the use of story points.

Lagniappe:

• Cohn, Mike. Agile Estimating and Planning. Prentice Hall, 2005.
• Here are links to a few blog posts that disagree with all or part of my stance, and whose arguments I will address in Part II:
  • • Brad Black, May 19, 2016. “Are Story Points Evil?“
    • Mike Veerman, August 30, 2017. “Stop using Story Points!“
    • Joshua Kerievsky, October 12, 2012. “Stop Using Story Points“
    • Michael Dubakov, 2010. “5 Reasons Why You Should Stop Estimating User Stories“
    • Ben Northrop, August 22, 2012. “Velocity and Story Points – They don’t add up!“
    • Steven Lott, September 23, 2016. “Story Points: Should We Give Up on Them?“
• Blog posts from Cohn: all of these are worth reading, but I disagree with his end stance in the final article.
  • Mike Cohn, “Story Points Are Still About Effort“
  • Mike Cohn, “Velocity-Driven Sprint Planning“
  • Mike Cohn, “Capacity-Driven Sprint Planning“
  • Mike Cohn, “Why I Prefer Capacity-Driven Sprint Planning“

The post Quocknipucks, or, why story points make sense. Part 1. appeared first on CTO/CIO Perspectives.

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.

I won’t go into depth on every single example of these from the talk, but will focus in on just a few representative snippets for each of these aspects, citing specific direct quotes, with time stamps, from the YouTube video available here, and capturing one or two of the slides available here.

“Them against us” attitude

0:04 “I like to gauge the audience. There’s more of you than there are of me. I like to know where the punch might come from. Where are my developers? That’s devs; all right, there’s my friends.  Who’s in a PMO or in a project management role? Oh… OK… OK.” (shows mock trepidation).

It’s really notable: the speaker divides the audience right at the start, expressing an outright “them against us” stance.

2:25  “Hashtag NoEstimates… I’m not responsible for what happens if you tweet to this hashtag. You have been warned. It’s a very good discussion; sometimes it’s not so good.”

The speaker somehow feels the need to warn the audience against posting to the Twitter hashtag of #NoEstimates. He gives no specifics, just vague but dire warnings. All of that is especially odd, given the frequent declarations of #NoEstimates advocates of the importance of collaboration and trust.

Straw man arguments and logical leaps

15:49 “Conversation around the estimate could be valuable… which means the estimate is not valuable.”

What? The fact that one can hold useful conversation about something somehow makes that thing itself not valuable? That’s quite a leap.

18:10 “Magic numbers happen in a lot of ways…. Padding the numbers by 20%, why not 40%.  That’d be too high, they’d never accept it… Or Excel gymnastics… A spreadsheet that padded a number, you fill in the effort, talk about the number of people impacted, etc., through creative Excel gymnastics, you got a number that was so inflated you could never be wrong. This will take twelve months, but we’re just adding a line of code.”

As one frequently tweeted quip states, “please stop using really poor examples of ____ to illustrate why ___ doesn’t work.” What extreme depictions of estimating such as “Excel gymnastics” actually illustrate, from this speaker, is an inability to understand or recognize how estimates can actually be used appropriately and productively. The analogy I always use: countless photos of twisted metal car wrecks do not make a convincing case for #NoCars. Similarly, if you dismiss all estimates as “magic numbers”, you probably need to read up on the many useful, well-known, non-“magic” ways to estimate.

21:12 “Here’s the drop-the-mic moment. 17% of large IT projects go so badly that they threaten the existence of the company. We’re taking a guess and we’re making a huge bet, and 17% of the time we could actually close the doors of our company, because we were just so far off.”

So, note how the speaker deliberately links major project disasters specifically and solely to the bugaboo of estimating (“taking a guess”): in short, without any specific knowledge or consideration of actual root cause, the speaker is reflexively blaming the use of estimates for those extreme project failures, across the board. Again, quite the leap.

25:05  “Who’s familiar with the Farmers’ Almanac? It predicts weather. It’s created 18 months ahead of time. It’s about 50% right… You’re better off just looking up at the sky.”

In what world are careful, methodical, facts-based estimates, made by software professionals regarding level of effort of proposed work items, equivalent to the Farmer’s Almanac? That’s a straw man, a mere derisive comparison. It’s surprising the speaker didn’t also trot out the example of Punxsutawney Phil.

Selective and skewed redefinitions of words

Watch the segment beginning at 9:07 carefully; it’s quite representative of the disturbing rhetorical flourishes throughout the talk. The speaker first polls the audience about what estimates are, pulling out selected comments that promote his targeted definition of estimates and scoffing at any that don’t. Then, he puts up a prepared slide (10:31) with five definitions of “estimate” taken from various sources.

Speaker’s list of definitions of “estimate”

Although only one of the five definitions (the one from a declared NoEstimates advocate) actually uses the word “guess”, the speaker then peremptorily declares to the audience, in front of their very eyes, that the definitions state that’s what estimates are: just guesses:

11:03 “So essentially, through all credible sources, we can distill it down to “guess”. Is that fair, does anyone want to push back on that? <two second pause> All right, so we all agree that an estimate is a guess.”

The rest of his entire presentation then becomes predicated on this flimsy foundation, this rhetorical sleight of hand, that an estimate is nothing more than a guess. He repeats it in various ways, often sarcastically, for emphasis throughout the talk: e.g., “estimates are guesses; we’re guessing and we’re wrong a lot; we suck at guessing.”  Let’s look at a number of specific examples:

• 12:45 “Why do we need estimates if they’re just a guess?”

• 13:13 “Make pretty charts, that’s important; so someone can validate their guess. So we’re gonna predicate a guess on a guess. I like that.” [said derisively]

• 14:12 “So in order for executives to make decisions, we’re going to hand them a guess. And they’re gonna make bets about our company. You’re laughing because it kind of sounds absurd, doesn’t it.”

• 14:30 “Typically estimates are required at the fore because we need to make decisions, and we believe that a GUESS is a great way to make a decision.”

• 19:28 “You’re taking a guess, adding another guess of a confidence interval. And I’m supposed to accept it.”

• 21:46: “We’re telling our leaders to make big bets on software with GUESSES. Not only that, 80% of the time we just FAIL. 17% of those failures could close our doors. Is this how you want to run a company? Who is actually in favor of this? Not a single hand up.”

Again, all of these statements leverage and reinforce the speaker’s predetermined skewed definition and premise, i.e., that estimating is just guessing. Once you accept that extreme premise (see Layne’s Law), there’s no room for fruitful discussion of the many ways that estimates actually help in software development scenarios.

Even in the Q&A period, when someone challenges the speaker’s definitions, he goes back to reaffirming what he has essentially browbeaten the audience into supposedly “agreeing” on:

44:05 “Let’s say I’m trying to get a million dollars out of you to do a project. Anything I hand you, we’ve agreed it is a guess. That’s a premise that didn’t get a lot of challenge.”

So we see, amidst the intentionally skewed definition, there are multiple instances of repeated straw man logic, coupled with what is frankly just blatant audience manipulation.

Misquoting of experts

19:46 “Steve McConnell — he provides what a good estimate is. What he says is, a good estimation approach should provide estimates that are within 25% of the actual results 75% of the time. How does that sound to you? Give me $100K.  75% of the time, I’ll hit your ROI within 25% plus or minus. The rest of the time I could lose it all, plus 10x, or I could win it all plus 10x. Who wants to give me $100K? No one in this room. But this is what we say is a good estimate, and this is what we say a company should use to invest.”

This is a rambling, agenda-laden mishmosh of extreme and unrealistic risk scenarios (lose it all plus 10x? Really?). Moreover, it’s intellectually dishonest. What he (mis)quotes is not even close to Steve McConnell’s point in his seminal book, Software Estimation. The speaker not only misreads the 25% / 75% description (which contains nary a mention of any “10x” factor), but he appears not to have finished reading the entire section, in which McConnell carefully spells out what he considers to be criteria for a good estimate.

In that section, McConnell mentions, as background, two common understandings of what a good estimate is, but then specifically says that the above criterion (“within 25% of the actual results 75% of the time”) is deficient: “an important concept is missing from both of these definitions–namely, that accurate estimation results cannot be accomplished through estimation practices alone. They must also be supported by effective project control.” (P. 11). After several more pages of discussion, McConnell ends his chapter with a paragraph helpfully and specifically titled “1.8 A Working Definition of A Good Estimate”, which, needless to say, is NOT what the NoEstimates speaker quoted. McConnell writes,

So, the speaker has cherry-picked a single isolated quote, misread it even, and then failed to notice that his cited source discusses that quote’s deficiencies and proposes something else as characterizing a good estimate.

Citing of dubious “data”

26:55 “You can abandon planning poker, story points, and roughly get the same outcome. So, a very smart guy, Bill Hanlon, he worked for Microsoft, so it’s large orgs buying into these ideas, right?”

Citing of Hanlon study

Here’s the thing: this alleged study that the speaker cites, by Bill Hanlon at Microsoft, is unavailable. All internet references to it anywhere (and references to it are indeed quite popular by NoEstimates advocates), when you follow the links to try to chase the study down, are actually references to a single paragraph, 86-word, third-hand description of that study in an old blog post by, yes, yet another NoEstimates advocate! That paragraph reads:

“Additionally, Bill Hanlon (who also works at Microsoft) has data that shows estimates to be pretty much useless as long as the story sizes are in the roughly-linear zone. He looked at 60-ish projects that used relative estimates. He looked at how accurate their predictions were as compared to the actuals. Then he reset all estimates to 1 and recomputed their velocities, made accordant projections and compared those to actuals. He found about a 3% variance in predictive accuracy between full data and just using 1.”

Maybe this study happened, but it’s unpublished: we can’t look at it or examine its context, rigor, or methodology. It’s no better than the proverbial “well, I know a guy.” And its conclusions are certainly impossible to evaluate fairly, based solely on a partisan agenda-laden short description of them. But to NoEstimates advocates, since this third-hand 86-word description of it agrees with their stance, it’s utter gold; the speaker here uses it as a way to make sweeping statements like “it’s large organizations buying into these ideas” and “planning poker is a waste of your time.”

Bottom line

I’ve done this entire lengthy blog post without even discussing the weakness of the NoEstimates ideas themselves. As I said, those substantive points have been sufficiently covered for years now, essentially unanswered by the NoEstimates advocates (other than through blocking and insulting anyone who brings them up). The above deconstruction goes beyond those unanswered specific objections, by exposing the rhetorical and logic gaps of the movement as well: in short, a key takeaway here is that it’s not just that the NoEstimates ideas are faulty, but they’re very poorly argued as well.

In fact, I believe that those two characteristics are linked. Poor arguments generally tend to lead to poor argumentation style, because nothing that is actually substantive (e.g., logic, facts, valid data) is available to promote the idea on its own merits. Rampant reliance on illogic, selective redefinitions, misquoting of experts, and phantom data actually exposes how unsupportable the ideas themselves are. Solid ideas wouldn’t need such trickery to convince people of their merit. Deconstructing this NoEstimates presentation, as I’ve done above, underscores how at this point, people need to look at NoEstimates advocacy chiefly as a glaring case study in poor behavior and faulty argumentation style.

Lagniappe:

Other presentations on #NoEstimates, with interesting quotes:

• • Allen Holub, “#NoEstimates” https://www.youtube.com/watch?v=QVBlnCTu9Ms

    • 0:07 “My topic today is #NoEstimates. And what I mean by that is what that hashtag actually says, which is to say, we need to just stop doing all estimation now. Estimation has no value at all.”

    • 0:32 “The main problem with estimates is that estimates are always based on guesswork. You’re always guessing.”

  • Gerard Beckerleg, “How to Estimate in Software Development | #NoEstimates”: https://www.youtube.com/watch?v=bicBUVbeR58

Earlier titles for this same video are quite revealing: “Do my requirements look BIG in this?” (in short, depicting business users as asking to be lied to) and “#NoEstimates – Stop lying to yourself and your customers, and stop estimating”

• • Woody Zuill, “No Estimates: Let’s Explore the Possibilities”   http://vimeo.com/79128724

    • 1:28 “For those of you here who are living in a non-agile world, I have no hope for you.”

    • 1:58 “The first time I talked about this, the audience … were so aggressively angry at me. And I enjoy that, by the way.”

  • Johan Öbrink, “Why promising nothing delivers more and planning always fails” https://www.youtube.com/watch?v=Dh3VC-8yCgA

The title on this one pretty much speaks for itself. One pictures NoEstimates advocates earnestly explaining to business folks how planning always fails.

The post Deconstruction of a #NoEstimates presentation appeared first on CTO/CIO Perspectives.

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:

Dysfunctionalities observed

• No one is willing (or at least inclined) to write anything down. Then, anger inevitably emerges at having to re-explain it. And, since explaining things just via a conversation actually makes it easier to hand-wave about complexities, the complexities tend to go underanalyzed and then unanswered.
• Preference is for hallway conversations over solid documentation. The view of what constitutes “work”, for many people who work here, seems to be (at best) just coming to meetings and declaring one’s opinion.
• Basic business etiquette doesn’t exist. No one shows up reliably at meetings, or on time. Meetings don’t get accepted on the calendar, so you don’t know for sure who’s really going to be there. And when the meeting takes place, it’s common for people to come late and then even insist on a reset of what’s been discussed so far.
• Emails go unanswered, even if beggingly marked PLEASE RESPOND etc. in the subject line.  

If an email isn’t answered within 15 minutes, in fact, it’s rare for it to be answered at all. In desperation, I’ve taken at times to marching a printout of email down the hall, so I can sit in a stakeholder’s office to get specific answers to critical questions. Of course, when I do that, it’s all just a verbal exchange; it doesn’t become a real commitment by that person to the answer that is provided at that specific time, and it of course (perhaps intentionally) avoids the benefit of having those answers discussed (and sometimes challenged) in a wider forum of major stakeholders.

• People work from their own memory and strong opinions, not documents. Even when documents are actually available.

For example, I saw a stakeholder ask another stakeholder what his main needs for the next application development phase would be. Rather than refer to the existing document that had been carefully gathered, documented, organized, and group-reviewed, he simply expounded on his main needs off the cuff, just going on memory, and in the process omitting some major aspects and getting others slightly wrong. He was winging it. Did he still want (in the system under construction) the features and capabilities he was leaving out in his impromptu list? Of course, and he was the first person who would feel let down if those needs went unfilled.

One core reason for this behavior: people simply don’t review documents, no matter how pressed or nagged. Careful, heads-down review of deliverables rarely seems to be included in their personal definition of “work”. And this is a problem all up and down the manager/employee chain.

• Finally, underneath it all, there’s a high cultural ethic placed on everyone being positive, meaning that the raising of red flags or warning signs is seriously frowned upon. Amazingly, then, pure cheerleading is valued over careful, thoughtful feedback. It’s a short-term “everyone feel good” emphasis, rather than a long-term outlook that recognizes the benefit of catching issues or mistakes early.

Solutions, or at least a plan of attack

All of this brings us to what should always be the operative question in such matters: we can complain about these things, but what can we actually do to help alleviate them? What specifically can YOU do to help institute a culture (or turn one around) that will largely eliminate the above dysfunctionalities?

Here’s how: by zeroing in on what is the undeniable commonality, the cultural cornerstone, of all these dysfunctionalities: the negative repercussions that occur because people are just winging it.

What do I mean by “winging it”? It’s when people throughout a dysfunctional organization, facing any issue of difficulty or especially of controversy, often come to rely on off-the-cuff responses, glibness, desk pounding, and strength of personality, rather than on careful, facts-based, reasoned logic and argumentation. And for such folks, you know what the great thing is about glibness, desk pounding, and strength of personality? It’s that little or no “work” or preparation is needed. These dysfunctionalities allow people the extraordinary luxury of being reactive, not proactive, in virtually every way.

But as I am fond of saying, it turns out there’s no good substitute for tedium. Rigor matters. Rigor pays off. So, instead of falling into step with this cultural wasteland mentality of winging it, turn it around through ongoing example. Model the following behavior, both personally and for any team you lead:

• Establish the touchstone (context) for all discussion, in the form of a defined, documented plan of record.

• In other words, write things down, and proceed from facts, as captured and reflected in that written word. Look skeptically on those folks who dismiss the critical importance of documenting your basic tenets: goals, objectives, scope, approach, timeline, etc.

• Any issues that emerge need to be examined and discussed in terms of their potential impact on the plan of record (with adjustments to that plan made as necessary). Insist that your projects and your co-workers use that written word (appropriately succinct, of course, and suitably well-crafted) as a collective touchstone for your project overall, rather than succumbing to the inclination to wing it.

• Establish the ground rules. Let’s start with something I personally witnessed Jim Barksdale emphasize repeatedly: “If we have data, let’s look at data. If all we have are opinions, let’s go with mine.” I watched Barksdale declare this, flatly, in a room filled with table-pounding senior VPs, and to my surprise, it actually had the desired effect of focusing the group and tamping down the grandstanding and rhetoric.

Doing all that requires active leadership, training and coaching, cajoling and relentless reminders, but really, what of value doesn’t?

Don’t fall into the trap, as many do, of the easy finger-pointing at counterexamples.

• One frequent one that’s trotted out: we’ve all seen people who abuse the email system by hijacking threads, making unfocused remarks, etc. But to overreact to that by shunning email entirely would be a great disservice.
• Another example: we certainly see abuse on Twitter, where bombast and poor behavior proliferate (and often prevail) over more sober, reasoned voices. A large subset of folks on Twitter don’t even seem to be able to differentiate between a loudly voiced sheer opinion and a carefully reasoned argument, and they behave accordingly. Leadership in the workplace needs to actively combat that trend: recognize that bombast doesn’t have to prevail, and work to keep things focused on rigorous, solid analysis.

Amazon’s Jeff Bezos’ alternative to winging it

Jeff Bezos apparently agrees strongly on the need for such a touchstone in business endeavors. Here’s one description of how Amazon functions: 

In senior executive Amazon meetings, before any conversation or discussion begins, everyone sits for 30 minutes in total silence, carefully reading six-page printed memos. Reading together in the meeting guarantees everyone’s undivided attention to the issues at hand, but the real magic happens before the meeting ever starts.  It happens when the author is writing the memo.

What makes this management trick work is how the medium of the written word forces the author of the memo to really think through what he or she wants to present.

It’s clear: Amazon has realized that winging it doesn’t get you there, from an organizational perspective. It just gets you strong opinions and decisions that are made principally from power positioning, rather than using the innate power of verifiable facts and solid reasoning.

Don’t get me wrong, here: I’m not arguing against spontaneity or for analysis paralysis; far from it. The thing is, it’s good to be spontaneous. It’s good not to be too regimented. But anything taken to an extreme runs the danger of going too far. And the unfortunate tendency in many companies is to let the spontaneity run rampant over any form of solid planning.

So, don’t succumb. When you’ve spent time and energy (as you should) defining the project plan of record and capturing the solid reasoning behind it, don’t let people freelance in meetings. Pull them back to that written touchstone, and insist they make their remarks in that context.

Because, after all, winging it is for the birds.

Lagniappe:

• CTO/CIO Perspectives, “Why reading and writing both matter more than you’ve been led to believe”

The post Stop letting people “just wing it” at work appeared first on CTO/CIO Perspectives.

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.

Let’s look at these statements grouped into some clusters (admittedly somewhat arbitrary, and admittedly somewhat overlapping), with a few annotations on why they’re undesirable:

Process and professionalism:

• It’ll be done when it’s done. Stop asking me when.
• That’ll go out in the first release after launch.
• We don’t even look at a reported bug unless it’s marked urgent.
• I just changed one little thing; there won’t be any impact. I don’t even need to test it.

All of the above statements serve to undermine a stakeholder’s confidence in your general dev process and (frankly) your professionalism. Because here’s what people justifiably tend to expect: professionals should be able to give some indication, at least more often than not, of likely time frames and confidence level. Professionals (in a project that has any reasonable scale to it) never freelance their way and make arbitrary process-free promises like “that’ll be in the first release”, just to shut the stakeholder up. Professionals don’t telegraph to stakeholders that users should arbitrarily mark bugs as urgent to get any attention. And professionals don’t shoulder-shrug at the possibility of ripple effects from seemingly minor changes.

Boasting and bluster:

• Trust me.

Don’t ever ask stakeholders to accept anything on faith, based on your solemn declaration that it is so. Unless you’re truly infallible (and, news flash, you’re not), it’s insulting. Show them, don’t tell them. And figure out actual, meaningful ways to show them, rather than appealing to their innate optimism or relying on your personal magnetic charm or relationship with them. Demonstrable results are what count, not your ability to “sell” them your personal representation of reality.

• We focus on producing code, not documentation.
• My code is self-documenting.
• Just read my code; it shows you exactly how the functionality works.
• “You must not be very technical, I guess.”  (This is often said in defense, when the stakeholder complains of not understanding how the software is intended to work)

To the stakeholder, statements like the above translate to essentially the following: “we don’t really care all that much whether or not you can USE the software. We don’t care about explaining it. And, we’re pointing you to the code as an answer to your pesky question, because we basically aren’t interested in doing the hard work of translating the answer into clear business English. Explaining what’s going on, apart from the code itself, just isn’t fun, plus (did we already say this?) it’s hard work, so we, well, we just don’t care.”

You may not think you’re saying that, but that’s what stakeholders often hear when you say one of the above remarks. Don’t ever ask stakeholders to be at anywhere close to your level of technical knowledge in order for them to get an answer to a basic business question. Don’t (ever) ask them to read your code. And certainly never tell them that any problem they’re experiencing with running your software has to do with their supposedly deficient level of technical ability.

General denial and dismissal of problems/bugs

• The system is actually up; it’s just that the users can’t reach it.
• It works just fine on my machine. <shrug>
• “That’s not a bug. The dollar amount is correct in the system; it just shows up wrong on the screen.”

None of the above, when I’ve overheard them in the wild, has been stated with even the slightest touch of irony or self-awareness. Let’s call them what they are: excuses, dodging of accountability, and complete (and staggering) inability to see the situation from the user’s point of view.

• That’s not a bug, that’s a feature
• That’s not a bug, that’s a feature request.
• “Bugs aren’t a quality measure” — an idealistic (but sadly and inexcusably tone-deaf) way of stating that not all bugs are weighted the same in impact and import, and that they are imperfectly and inconsistently gathered, so simply counting them doesn’t necessarily work well as a comparative measure. But think here beyond the idealism: what do you suppose stakeholders hear when they hear you say that “bugs aren’t a quality measure”? Do you really imagine that they’ll be inclined to tune into your lengthy theoretical explanation (i.e., what you really meant to say) after that?

If you think about it, you’ll note that there’s often a common theme to many of these: don’t hold me to stuff. Don’t blame me. Problems aren’t my fault. We know what we’re doing, and you don’t. We’re the experts, and you’re not. So, stop pestering me. Consider the stakeholder’s likely reaction to these kinds of (perceived) pronouncements, and don’t be that guy/gal telling them such things. Trust me. <grin>

OK, developers, I can hear you thinking: “but but but, what about them?”  All right, I grant you: stakeholders too have been known to say some facepalm-eliciting things to developers and PMs. Let’s leave those for a follow-up post. Feel free to offer your own examples of such stakeholder remarks in the comments, and I’ll see what I can incorporate.

Lagniappe:

• CTO/CIO Perspectives, “How not to get what you want from IT”.
• CTO/CIO Perspectives, “Astounding IT sayings: the inaugural post”.
• CTO/CIO Perspectives, “More astounding IT utterances”.

The post Cringeworthy comments overheard in the IT trenches: the developers appeared first on CTO/CIO Perspectives.

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.

In fact, you don’t need to be a major leaguer to understand that there is a whole host of empirical observations and, yes, estimates, engaged in immediately and in an ongoing fashion by our model outfielder when confronted with “the crack of the bat”. These activities are based on accumulated knowledge and experience, as well as evaluating current parameters. Here are just a few of these assessments/estimates, none of which can be dispensed with via the substitution of a heuristic:

• Where am I right now: did I already “play in” towards the infield, based on my earlier estimate of where this batter typically hits the ball?
• Is the ball headed my way? Do I start running immediately? Which direction?
• What’s the ball’s speed, direction, spin, trajectory? There’s no “one size fits all” here: left fielders know, for example, that balls hit to them by left-handed batters tend to behave differently from balls hit by righties.
• Should I adjust for wind, thinking about a similar situation in the first inning, where a fly ball like this plummeted suddenly because of high winds?
• Do I need to call off our hotshot center fielder who might run into me while I’m trying to catch the ball? Or does the center fielder maybe have a better chance of catching this ball than I do, and I should back off?
• If I run as hard as I can to make the catch, will I run into the wall? (in essence, a cost/benefit evaluation)
• My knee is still throbbing from yesterday’s slide into second. Can I viably run at full speed?
• Can I dive for the ball, or do I need to position myself for an immediate throw after I make the catch, to try to nail a runner who’s off the bag or who will attempt to advance after the catch by “tagging up”?

Fly ball situations are complex, in other words. They’re simply not solvable by a sole magic heuristic, and neither is software development. In complex situations requiring judgment and uncertainty, there aren’t easy shortcuts or silver bullets. Judgment calls require, well, judgment. There aren’t many ways (if any) to avoid putting yourself on the line. But there are most certainly ways of deluding yourself that you can escape accountability for judgment calls by using some kind of pseudo-automatic “paint by numbers” approach. It’s once again the seductive lure of the oh-so-easy answer: the no-muss, no-fuss heuristic.

But a heuristic, at least in most cases, just isn’t sufficient as a replacement for judgment amid complexity: you don’t get something for nothing. Insistence on the efficacy of a heuristic can often serve as an example of what H.L. Mencken famously said: “there is always a well-known solution to every human problem — neat, plausible, and wrong”. 

#NoEstimates advocates, who I’ve observed quite often gravitate to selective redefinitions of basic words and concepts to support their arguments, might insist that the fielder trying to catch the ball is “assessing” various factors, not really “estimating”. But that’s mincing words: the fielder is most definitely amassing (even if implicitly, instinctively) a series of judgments and weighing possible reactions, based on both new data and historical knowledge of the situation, judgments that will figure into the many decisions that she has to begin executing immediately. She is constantly tuning and modifying those judgments as the play transpires: she may suddenly decide to dive for the ball, or, recognizing that making the catch is unlikely, to pull back so the ball can drop in front of her and she can then be sure to hold the runner to a single. She is, in fact, estimating, in an uncertain, complex situation: juggling cost, benefit, impact, risk. Because, after all, that recurring pattern of assessment, decision, action, and adjustment is really all that estimating actually is.

Think about when someone says, “the outfielder misjudged the fly ball”: no, it isn’t the case that the outfielder somehow failed to apply a heuristic. Rather, the outfielder failed to estimate appropriately at the start, and/or failed to adjust her original estimates well enough to make the catch. And, do note that there’s little chance of that outfielder making the catch at all if she decides that it’s useless in general to engage in all those complicated acts of estimating I’ve enumerated, based on someone having told her that the heuristic is all she needs.

It should be clear by now: other than in the brevity of the time span involved, the process of catching a fly ball has numerous parallels to building software to achieve a functional goal:

• In software development, you’re a professional who’s done this many hundreds or thousands of times before; faced with a new request, you make dozens of hourly judgment calls and trade-offs, as you explore, design, and start to build what’s needed.
• You decide, based on new data and historical knowledge and experience, what parts of the job are easy, what parts are risky, what parts will require extraordinary effort, etc.
• As new information becomes available during the process, you adapt and change your approach as necessary, but your aim is still to catch the darned ball.

There may of course be situations in software development where heuristics can be of use. But when people insist that a heuristic will suffice to solve a tough problem, be at least skeptical. Consider if they’re actually presenting a form of silver bullet as the answer for a complex situation.

In short, don’t wave your glove at a fly ball just because someone has told you that it’d be low effort, low risk, or maybe even the One True Way to succeed.

Lagniappe:

• Daniel Kahneman, Thinking, Fast and Slow, 2011.
• “Outfield 1 – Pro tips for how to play outfield and how to catch a fly ball”

The post IT and baseball: no silver heuristics appeared first on CTO/CIO Perspectives.

In fact, “Goals and Values” wallet cards were handed out to each employee.  And let me make sure I affirm one important thing here, prior to what I’m about to say: these were, without a doubt, very worthwhile values: “Stay close to our customers”, “pursue excellence in all we do”, and so on. Note that I still carry this wallet card with me today, two decades later.

But here’s the thing: the values, despite all their great qualities, became cliches, overused, cited on every conceivable occasion and for every possible purpose. I remember the company president at the time: he even roamed the halls every once in a while, popping his head into random conference rooms, barking one or more of the company values at the nonplussed attendees: “Well? Are we staying close to the customer?” And in almost every meeting, people would spend substantial time itemizing earnestly how well a proposal fit in with the values, sometimes more than the time they spent explaining the actual pros and cons of the proposal itself.

Here’s where I’m going with this (and do hang in there for the connection I’ll draw specifically to IT): easy references to the goals and values became for many a substitute for actual thinking. And substitutes for actual thinking are seductive and rife.  But alas, good ideas and concepts, even when innately wise and useful, can turn counterproductive when simply used de rigueur and without thinking. Most insidiously: they can be used to justify what you want or don’t want to do anyway, often for reasons you can’t or won’t state transparently.

At its extreme, such behavior, such unquestioning embracing and sloganeering, is downright lazy, a species of lip service, even a kind of ideological technopolitical correctness, as it were. And when these easy phrases pervade a culture or work environment (or, say, a Twitter hashtag community), it becomes an echo chamber: no one dares speak out on the opposing side of anything which has one of these magical shibboleths attached to it. And as a result, people use those slogans, both consciously and unconsciously, to exploit the slogans’ incantational power, and to avoid the hard work and actual accountability for having to reason through a real stance on important issues.

In everyday life in American politics, one example of this would be when people reflexively cry “socialism” about nearly any program involving government spending. Such people are often not really sure what socialism actually is, but they have figured out that using it as an insult works really well to make many people recoil in horror from whatever is being so depicted.

Now to the IT connection on this: as I’ve written before, IT black-and-white thinking is generally and distressingly common, and that syndrome often emerges via the embracing of such slogans. In fact, there’s a whole set of “magic incantations” that I see get trotted out in IT circles as a way to win arguments without the awkward and risky messiness of actually having to support one’s viewpoint with anything much more concrete than the incantation itself. Most commonly, these IT “magic incantations” take the form of bugaboos: tools, processes, and perspectives that are somehow loftily deemed to represent “much that is wrong with our industry”.

The list is long of the IT incantational bugaboos currently in vogue and responsible for justifying this kind of sloppy thinking: muda, waterfall, command and control, fixed mindset, Theory X, Taylorism, “that’s a smell”, “you’re not open-minded”. Let’s look at a couple of these in depth, then a few more in passing:

Muda

At one client a few years back, I saw an internal operations IT person strongly resist providing some necessary input for an internal IT audit, simply by shrugging that the effort seemed to him to be “muda”. Without bothering to think through the actual business need, he had grasped onto a slogan that gave him (or so he believed) an ironclad, facile excuse to reject something that in truth he just didn’t feel like doing. Alas, “No MUDA” often becomes some folks’ loud and selectively applied battle cry about the less fun parts of their jobs.

Or as Gene Hughson put it, “Some people latch on to ideas that tell them they shouldn’t have to do things they don’t like to do. Responsibility, however, sometimes requires us to do things we don’t like to do. “ 

“Not Agile”

I’m hardly the first to note that Agile, which of course has so much to recommend it, unfortunately has often become a sloganized rationalization in and of itself. Various IT stances or situations are often met on Twitter with the simple-minded and full retort of “not agile”. I don’t know what such a response really even means, or why such responders believe it to be a mic-dropping argument-ender; it seems that it is often little more than a knee-jerk substitute for “I don’t like that.”

More extensively but in a similar vein of black-and-white-ism: in a particularly glaring use of self-referential and self-righteous quasi-scriptural devoteeism, we’re told that “all you need to do is read the Scrum Guide and the Agile Manifesto to figure out if you are taking an Agile approach to building software.”

Let’s list just a few more examples of wannabe mic drops: i.e., sloganeering, black-and-white responses to IT discussions, often substituting for actual thought and discourse:

• Waterfall: “that seems 100% waterfall to me.” 
• Open-minded: in response to a disagreement: “how about keeping an open mind?”
• Command and control, said mockingly: “I am here to command and control. I will ask for estimates.”  
• Fixed mindset: “fixed mindset vs growth mindset”
• Theory X: “Way too Theory-X for my taste.” 

So what’s the bottom line? Easy: don’t fall for this kind of sloppy thinking, either in yourself or in others. Think through the core issues for yourself; don’t just adopt someone else’s slogan (or dogged scriptural adherence to a manifesto) to tell you how or what to think. In fact, consider reading up on both sides of an issue, rather than accept dogma from ideologues. Beware of received truths that usually turn out to be in service of some unstated sacred cow, lurking as the real driver of someone’s stance.

Don’t tolerate lazy, automatic thinking, in your team, your peers, your superiors, or yourself. Goals and values are great as focusing statements, but they can’t and shouldn’t replace your brain.

The post Lazy thinking: IT shibboleths, sloganeering, and sacred cows appeared first on CTO/CIO Perspectives.