Estimates – Uses, Abuses, and that Credibility Thing Again

In my last post, “#NoEstimates – Questions, Answers, and Credibility”, I brought up the potential for damaging ones credibility by proposing changes without being able to explain why the change should be beneficial. Consider the following exchange on Twitter:

When the same person states “There is a lot written about this” and “The question is young and exploration ongoing” back to back, it is reasonable to wonder how much thought has been put into the “question” versus the desired solution. It’s also reasonable to wonder if this really qualifies as a “question”:

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. It’s not a matter of being tied to a particular practice, but a matter of avoiding things that make us look foolish such as these:

[Note: I find these dismaying not because of opposition to agility, but because I am a proponent of agility.]

None of this is to deny that some misuse, even abuse estimates. That being said, abusive managers/clients are unlikely to either surrender their “stick”. The problem is not the tool, but how it’s employed. It might be useful to consider exactly how likely they are to give up being abusive even if they do agree to quit asking for estimates.

Many of the issues around estimates stem from communication and knowledge issues in my opinion. Typically, the less we know about something, the harder it is to reason about it (size, complexity, etc.). In my experience, two practices mitigate this: providing estimates as a range (wider initially, with a narrower range when the item is better defined) rather than a single point and changing the estimate when new information arises (regardless of whether the new information is an unforeseen issue found by the team or a change requested by the customer). It shouldn’t be a surprise that it’s hard to succeed by making a single estimate up front and refusing to revise it no matter what new information comes in. That’s a bit like driving somewhere by putting on a blindfold and following the GPS without question.

Another practice that can help with uncertainty is using a proof of concept. When in unknown territory, I’ve found it’s easier to estimate how long to explore something than to estimate both the exploration and the implementation of a specific feature. Additionally, this practice makes it explicit for the customer that they’re paying for the learning, not feature itself. Transparency about the risks allows them to accurately determine how much they’re willing to pay just to find out if the tool/technology/etc. will meet their needs.

This is probably a good time to repeat the way estimates are used (from Woody Zuill’s “Why do we need estimates?”):

  • To decide if we can do a project affordably enough to make a profit.
  • To decide what work we think we can do during “a Sprint”. (A decision about amount)
  • To decide what work we should try to do during “a Sprint”. (A decision about priority or importance)
  • To decide which is more valuable to us: this story or that story.
  • To decide what project we should do: Project A or Project B.
  • To decide how many developers/people to hire and how fast to “ramp up”.
  • To decide how much money we’ll need to staff a team for a year.
  • To give a price, or an approximate cost so a customer can decide to hire us to do their project.
  • So we can determine the team’s velocity.
  • So marketing can do whatever it is they do that requires they know 6 months in advance exactly what will be in our product.
  • Someone told me to make an estimate, I don’t use them for anything.

All of these are valid enough as stated, but let’s re-word a couple

  • To help the customer decide what work we should try to do during “a Sprint”. (A decision about priority or importance)
  • To help the customer decide which is more valuable to us: this story or that story.
  • To help the customer decide what project we should do: Project A or Project B.
  • To help the customer decide how much money we’ll need to staff a team for a year.

It needs to be really clear that the customer’s needs are the important ones here.

Another use is to help determine whether a particular issue is worth addressing. It’s hard to determine the level of technical debt without a sense of what the cost is to fix versus the cost of not fixing it.

To determine value, we need to know both benefit and cost. A feature that earns a million dollars for a cost of $999,999 is a lousy deal compared to one making $10,000 for a cost of $1,000.

Shaping our practices around our customer’s needs is a good way to create a partnership with those customers. In my opinion, that’s an easier sell to the customer than “dump the estimates and let’s see what happens”.


#NoEstimates? #NoProjects? #NoManagers? #NoJustNo

Drawing of Oliver Cromwell

#NoX seems to be the current pattern for hashtags designed to attract attention. While they certainly seem to serve that purpose, they also seem to attract more than their fair share of polarized viewpoints. Crowding out the middle ground makes for better propaganda than discussion.

So why does a picture of a long dead English political figure grace a post about hashtags? Oliver Cromwell was certainly a polarizing figure, so much so that when the English monarchy was restored after his death, he was disinterred, posthumously hung in chains, and his head was displayed on a spike. Royalists hated him for overthrowing the monarchy and executing King Charles I. The more democratically inclined hated him for overthrowing Parliament to reign as Lord Protector (which had a nicer sound to it than “dictator”) for life. To his credit, however, he did have a way with words. One of my favorites of his quotes:

I beseech you, in the bowels of Christ, think it possible you may be mistaken.

That particular exhortation would well serve those who have latched onto the spirit of those hashtags without much reflection on the details. Latching onto the negation of something you dislike without any notion of a replacement doesn’t convey depth of thought. Deb Hartmann Preuss put it well:

For many of the #NoX movements, abuse of the X concept seems to be the rationale for doing away with it. Someone has done X badly, therefore X is flawed, irrational, or even evil. Another Cromwell quote addresses this:

Your pretended fear lest error should step in, is like the man that would keep all the wine out of the country lest men should be drunk. It will be found an unjust and unwise jealousy, to deny a man the liberty he hath by nature upon a supposition that he may abuse it.

That some who do things will do those things badly should not come as a surprise. My singing voice is wretched, but to universally condemn singing as a practice because of that does not follow. Blatant fallacious thinking reflects poorly on advocates of a position.

In many cases, there seems to be a disconnect between those advocating these positions and the realities of business:

Owly Images

In response to his posting a link to “The CIO Golden Rule – Talking in the Language of the Business”, Peter Kretzman reported “…I saw people interpret “you need to talk in language of the biz” as being an “us vs. them” statement!” Another objected to the idea that the client’s wishes should be paramount: “the idea that the person with the purse has more of a voting right is one I don’t live under. i can vote to leave the table.” Now, I will give that one credit in that they recognize that “leaving the table” is the price for insisting on their own way (I’m assuming that they know that means quitting), but it still betrays a lack of maturity. In most case, we work for a client, not ourselves. How many times can one “leave the table” before they’re no longer invited to it in the first place.

The business is not a life support system for developers following their passion. Rather than it being their job to fund us, it is our job to meet their needs. Putting our interests ahead of the clients’ is wrong and arrogant. It is the same variety of arrogance that attempts to keep BYOD at bay. It is the same arrogance that tried to prevent the introduction of the PC into the enterprise thirty years ago. It failed then and given the rising technological savvy of our customers, has even less of a chance of succeeding now. Should we, as an profession, continue to attempt to dictate to our customers, we risk hearing yet another of Cromwell’s orations:

You have sat too long for any good you have been doing lately… Depart, I say; and let us have done with you. In the name of God, go!

This is not to say that the various #NoX movements are completely wrong. Some treat estimates as a permanent commitment rather than a projection based on current knowledge. That’s unrealistic and working to change that misconception has value. Management does not always equate to leadership and improving agility is a worthy goal provided focus is not lost. I’ve even written on the danger of focusing on projects to the detriment of the product. What is needed, however, is a balanced assessment that doesn’t stray into shouting slogans.

I’ve seen some defend their #NoX hashtag as a springboard to dialog (see the parts re: slogans, hyperbole, and propaganda above). They contend that “of course, I don’t mean never do X, that’s just semantics”. John Allspaw, however, has an excellent response to that:

Fixing IT – Products, Not Projects Revisited

Always under construction

Google “disconnect between IT and business” and you get 16.9 million hits in just under half a second. In the first page of results you’ll find names like Cutter, Forbes, Huffington Post, and Business Insider. These facts should make it clear that the problem is real and pervasive. Where did this disconnect come from and how do you remedy it?

In the first two posts of this series (“Fixing IT – How to Make a Monster (Customer)” and “Fixing IT – Taming the (Customer) Beast”), I discussed the systemic problem of customer service and how it might potentially be overcome. Another disconnect, one that I’ve touched on before, is IT’s focus on projects instead of products. Although this issue relates to customer service and customer-centricity, it has other impacts that cause it to warrant its own post.

Projects, a concept which seems to be the center of the universe for so many IT departments, are not priority for most stakeholders; the resulting product is. For IT, unless you’re running a pure flow process where the product’s lifetime is a continuous stream of changes and additions, projects are the events/activities that result in the creation or enhancement of the product. They are what happens to the thing, not the thing itself. That being said, I’m not a fan of the #NoProjects viewpoint. Just because they’re not the most important concept doesn’t mean they’re not an important concept; it’s just that perspective and priorities are needed.

How often do you think of the construction of your home? While it was a project that took time, effort and money, in the end, you probably don’t care. I’d be willing to bet that you derive more value and satisfaction from the use of it than its construction (which generally only comes to mind if a problem surfaces). Likewise, with IT’s customers, they care about the result. In fact, they start to care about that result at the same time that IT is traditionally considering it “done”.

IT Projects which are “done” represent a dangerous situation. In many cases, the project team moves on and the system is consigned to “support”, meaning that those best qualified to fix issues are most likely unavailable. This degraded level of support erodes trust, acting like the grenade in Tom Graves’ “Playing ‘pass the grenade’?”:

What’s the ‘grenade’? Well, it’s kinda like a hot-potato – except that you’ll know when you have a hot-potato, because it burns everyone’s fingers somewhat in passing, whereas a grenade feels perfectly safe and ordinary and unimportant until it blows up in your face…

One of the “grenades” Tom lists is “so-called ‘customer-service’ whose design, either by default or by intent, denies those who need that service from receiving it”. In other words, poor service due to ignorance of our customers needs and concerns can cause as big a rift as that due to outright malice. This is important because, as Seth Godin notes in “Thinking lifetime (don’t break the chain)”, only “The traveling salesman, the carnival barker and the old-time businessman can hit and run”. For all others, their benefit lies in the lifetime of their relationship with the customer. Think of this lifetime as a chain, each link representing an exchange of value between you and your customer:

Think of the interaction at the deli counter or the pump or the bursar’s office or the alumni office or on the website from the point of view of the customer and the chain. Where are the moments where you might lose her forever? What are the key places where you need to intervene and invest in the relationship instead of milk it, or drag it through the mud? Assuming that your competitors are just as selfish and metric-driven as you are isn’t a great strategy, because you’re still losing when you break the chain.

Support is not a cost center, it’s a profit center. Treating customers with urgency and clarity and respect (maintaining the chain) is more urgent than ever…

Think lifetime, all the time.

Having a product focus, rather than a project focus, affects the architectural design and the development of the system as well. A tweet from Rebecca Wirfs-Brock sums up the issue: “One tension that always exists (especially agile design) is when&how to support variability in the prob with a flexible design solution”. With a product focus, the product is not done until the day it’s taken out of service. As Brenda Michelson tweeted, “if software is never done, architecture must allow equally for structure and next transition; flex don’t break”. With a project focus, the team can “hit and run”, making it a tempting proposition to over-rely on YAGNI.

Evan Bottcher, in “Projects are evil and must be destroyed”, observed;

Projects deliver exactly what they promise. Project teams have little incentive to invest in the long term operation and maintenance of the systems that they create. I’m not saying that the team doesn’t care or are intentionally acting irresponsibly, but when delivery pressure is applied the first things to be dropped from the project schedule will be the cross-functional concerns that make the system reliable, monitorable, deployable, and maintainable ongoing.

The DevOps tenet of a team supporting what they build is an excellent example of product focus in action. Working under those conditions, the team has a powerful incentive to grow and evolve the system over its entire lifetime. In essence, the team develops an ownership interest in the product that helps to cement their relationship with the system’s stakeholders. Ownership, particularly in relation to those stakeholders, is a word that you will hear more about in the next installment of this series of posts.

[I have to give a shout-out to Tony DaSilva, his post “Thanks, But No Thanks” came out while I was still writing this one and in commenting on it re: #NoProjects, I realized that there was something more I needed to include in this post. Tony’s posts are always thought-provoking, literally in this case!]

[More serendipity – this exchange on Twitter between Lorri MacVittie, Dave Roberst, James Urquhart, and Brenda Michelson occurred after I finished the post but before I published – the money quote from Brenda: “you say “DOOM”, PMO says “Next”. Project centricity (funding, attention) dooms corporate codebase”]

Surfing the Plan

Hang loose

In a previous post, I used the Eisenhower quote “…plans are useless but planning is indispensable”. The Agile Manifesto expresses a preference for “Responding to change over following a plan”. A tweet I saw recently illustrates both of those points and touches on why so many seem to have problems with estimates:

Programming IRL:
“ETA for an apple pie?”
8h later:
“Where is it?”
“You didn’t tell me the dishes were dirty and you lacked an oven.”

At first glance, it’s the age-old story of being given inadequate requirements and then being held to an estimate long after it’s proven unreasonable. However, it should also be clear that the estimate was given without adequate initial planning, no “plan B” and when the issues were discovered, there was no communication of the need to revise the estimate by an additional 300%.

Before the torches and pitchforks come out, I’m not assigning blame. There are no villains in the scenario, just two victims. While I’ve seen my share of dysfunctional situations where the mutual distrust between IT and the business was the result of bad actors, I’ve also seen plenty that were the result of good people trapped inside bad processes. If the situation can be salvaged, communication and collaboration are going to be critical to doing so.

People deal with uncertainty every day. Construction projects face delays due to weather. Watch any home improvement show and chances are you’ll see a renovation project that has to change scope or cost due to an unforeseen situation. Even surgeons find themselves changing course due to circumstances they weren’t aware of until the patient was on the table. What the parties need to be aware of is that the critical matter is not whether or not an issue appears, but how it’s handled.

The first aspect of handling issues is not to stick to a plan that is past its “sell by” date. A plan is only valid within its context and when the context changes, sticking to the plan is delusional. If your GPS tells you to go straight and your eyes tell you the bridge is out, which should you believe?

Sometimes the expiration of a plan is strategic; the goal is not feasible and continuing will only waste time, money, and effort. Other times, the goal remains, but the original tactical approach is no longer valid. There are multiple methods appropriate to tactical decision-making. Two prominent ones are Deming’s Plan-Do-Check-Act and Boyd’s Observe-Orient-Decide-Act. Each has its place, but have a looping nature in common. Static plans work for neither business leaders nor fighter pilots.

The second aspect of handling issues is communication. It can be easy for IT to lose sight of the fact that the plan they’re executing is a facet of the overarching plan that their customer is executing. Whether in-house IT or contractor, the relationship with the business is a symbiotic one. In my experience, success follows those who recognize that and breakdowns occur when it is ignored. Constant communication and involvement with that customer avoids the trust-killing green-green-green-RED!!! project management theater.

In his post “Setting Expectations”, George Dinwiddie nailed the whole issue with plans and estimates:

What if we were able to set expectations beyond a simple number? What if we could say what we know and what we don’t know? What if we could give our best estimate now, and give a better one next week when we know more? Would that help?

The thing is, these questions are not about the estimates. These questions are about the relationship between the person estimating and the person using the estimate. How can we improve that relationship?