#NoEstimates Embraces Customer Collaboration

I recently read Gene Hughson’s blog post “The Business of IT – Customers, Clients, and Fit for Purpose” and really enjoyed his thoughts about the difference between a “client” and a “customer”.

He built on Seth Godin’s post “The Client and the Customer” and rightly noted that when in-house IT fails to treat their customers as clients the inevitable result is “shadow IT”. Any IT manager, director, or VP should take that point to heart.

We need to set this strawman argument ablaze once and for all to move the #NoEstimates conversation forward.

But Gene lost me when he connected this concept to #NoEstimates.

“Meeting the needs of my clients is my objection to #NoEstimates. Clients may have questions that require estimates to answer. In “Estimates – Uses, Abuses, and that Credibility Thing Again”, I listed several that were taken from a post by a prominent #NoEstimates advocate [Woody Zuill]. In my opinion, those questions become my concern by virtue of being my client’s concern. Suggesting, as that advocate does, that they need different questions, is not serving their needs.”  –from Gene HughsonForm Follows Function Blog

Gene is arguing that #NoEstimates does not address the needs of clients. He took this argument a step further in his conclusion by asserting that client’s needs are largely ignored in a #NoEstimates environment.

“While it is certainly possible to deliver IT in an environment where the clients’ needs are largely ignored, doing so is detrimental to the clients, to the providers, and to the organization(s) to which they belong.”  –from Gene HughsonForm Follows Function Blog

We need to set this strawman argument ablaze once and for all to move the #NoEstimates conversation forward.

#NoEstimates is an agile idea that is informed and guided by the Agile Manifesto.

The Manifesto clearly defines the working relationship between agile teams and their business partners:

  • First as a value statement:  Customer Collaboration over Contract Negotiation
  • Second as a principle:  Business People and Developers Must Work Together Daily Throughout the Project

What this means is that #NoEstimates practices cannot be applied to a project without the consent of the business people who are working together daily with the development team.  If the customer believes that an estimate is needed to make a decision about the work the team is doing, then deliver an estimate!

Woody Zuill – the #NoEstimates advocate that Gene referred to in his post – also advocates this stance.

“How Can I Get These Customers Without Estimates?  This is a very easy question to answer: You probably can’t get these customers without estimates.  They want estimates – it’s part of the way they think. You probably MUST DO ESTIMATES for these customers.  That is, you don’t tell these customers “We don’t do estimates” if you want to work with them.” [emphasis is mine –RR— from Woody ZuillLife, Liberty, and the Pursuit of Agility

Agilists do not leave their customers behind, nor do we ignore the needs of our clients.

In fact, the Agile Manifesto and the Scrum Guide both put the customer squarely in the driver’s seat and makes delivering valuable software frequently to our clients and customers our highest priority.

#NoEstimates – being an agile concept – also embraces the values and principles of the manifesto and scrum guide. We are simply asking our clients and customers questions about the way we – as a team – do our work.

Here are some of the things that we ask:

  • Does the overhead of some types of estimation make sense given what we already know?
  • Can a slicing heuristic (1 acceptance test per story) reduce the cost of estimation?
  • Does a forecast enable predictable delivery? If so, can we count stories instead of estimating tasks?
  • Can a story map keep the team aligned and aware of the big picture?
  • What decision are you trying to make and is an estimate the right tool?

Gene is right to worry that being a bad partner will impact credibility, trust, and the overall relationship with our clients and customers.

“We shouldn’t be surprised when things that don’t promote the client’s welfare (or, at least, aren’t presented in that manner) are met with a lack of interest. We definitely shouldn’t be surprised when things that are seen as a net negative to the customer are met with hostility. Understanding and respecting the client’s point of view is required to avoid damaging our credibility and relationship with them.”  –from Gene HughsonForm Follows Function Blog

In the case of #NoEstimates, however, the customer/client is in the driver seat. Part of the commitment to agile is to reflect how we can be more effective, then tune and adjust our behaviors.

We go through this process when making many decisions as an agile team:

  • Should we accept the higher upfront cost of adopting test driven development?
  • Can we afford to implement a continuous integration server?
  • Should we work in 2, 3, or 4 week sprints? Which interval gives the business the best opportunity to make a decision?

The list goes on and on. Estimates are no different. If it turns out that estimates are needed to satisfy the needs of the customer, then we provide estimates.

If not, we continue to seek better ways to do our work together.

Please note: I reserve the right to delete comments that are offensive or off-topic.

  • Pingback: More Strawmen for the #NoEstimates FireRyan Ripley | Ryan Ripley()

  • Henrik Ebbeskog

    …trying to imagine a business conversation with the questions you mentioned.

    – I have this idea I’d like you to do.
    – OK, interesting. Tell me more.
    – Well, I’m thinking that we could build a digital online ordering system so clients can use that instead of calling us. That would save both them and us time. And we’d hopefully get higher quality on the orders as well.
    – Sounds like a good idea. But, does the overhead of some types of estimation make sense given what we already know? Can a slicing heuristic (1 acceptance test per story) reduce the cost of estimation? Does a forecast enable predictable delivery? If so, can we count stories instead of estimating tasks? Can a story map keep the team aligned and aware of the big picture? What decision are you trying to make and is an estimate the right tool?
    – ???

    Those questions become rather “silly”. But it cuts to the case that those questions you mention doesn’t really make sense when “working together”.

  • galleman

    Sounds like what you’re saying with “The Agile Manifesto & Scrum Guide put the customer in the drivers seat.” is you’re transferring the responsibility as well as the accountability for making decisions in the presence of uncertainty to the customer. This moves the developer’s role to labor, directed by the customer. Which is fine, but it removes the developers from the table where the business decisions are made.

  • Henrik Ebbeskog

    Hi Ryan!
    Have some thoughts, hope you appreciate them.

    I can’t really wrap my head around this post. I think of the Motte and Bailey Doctrine when I read this. At one hand you say: “work together with biz as a team” (as I read it), then on the other hand you say “If the customer believes that an estimate is needed to make a decision about the work the team is doing, then deliver an estimate!” That doesn’t sound like “working together” to me.
    And also, if we’re working together with biz, then none of those questions you mention in “Does the overhead…” are actually never brought up. At least not in my experience, having worked closely with biz for many years. The “story map” point is something we have discussed though. The others, no.

    So, bottom line, while I appreciate that #NE isn’t “leaving the biz behind”, I still don’t get what #NE do instead? Seems like #NE is a “dev team approach”, but then it isn’t really about “working together”. I can’t make sense out of this.

    Kind regards