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.
“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 Hughson – Form 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 Hughson – Form Follows Function Blog
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!
“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 Zuill – Life, 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 Hughson – Form 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.