More Strawmen for the #NoEstimates Fire

Plenty of strawmen left to set ablaze as we wrap up this week of #NoEstimates posts. Read along as I pose the oft repeated arguments from the critics and then toss these worn out strawmen in to the fire.

More strawmen for the #NoEstimates fire.

#NoEstimates advocates are anti-management

The 3 main #NoEstimates proponents – Woody Zuill, Neil Killick, and Vasco Duarte – are either in management roles today or have held management roles in the past. After meeting Woody and speaking with Neil and Vasco, I don’t believe any of them suffer from self-loathing…

Looking broader at the #NoEstimates community you’ll find people in roles ranging from developer, tester, analyst, manager, director, vice president, and even c-level executives who are all interested in exploring these and other agile ideas.

#NoEstimates advocates don’t want to do things they don’t like to do/are hard to do

The question here is not about difficulty or desire. Value is at the center of the #NoEstimates discussion. As seen in the Nordstrom video, a small team was able to deliver value back to customers without estimates.

Can such an approach work on larger projects and still give the business the information they need to plan? Certainly.

What does that look like across multiple contexts and domains? That is what people are still exploring and testing.

However, #NoEstimates and Agile are not silver bullets. These ideas are not one size fit all. These are ideas built on transparency, inspection, and adaptation. Inherently, you have to adjust for your domain and context.

And sometimes, Agile is not a good fit for what you are trying to do.

#NoEstimates advocates avoid commitment, fear blame, and loath accountability

This is just a character attack that is unfounded and offensive. Agile and #NoEstimates advocates support transparency, are open to inspection, and are skilled at adaptation.

We embrace uncertainty and cope with the unknown by making small decisions frequently.

Working like this means we embrace the commitments we make to our customers, take responsibility for our work, and are accountable to our teammates to bring the best of our abilities to bear each day. We inspect these commitments frequently and make adjustments as we learn new things about the product we are building.

Perhaps the reaction from developers and team members that some have observed is a disdain for coercion.

When someone with authority addresses the team and says, “I promised those features for next Wednesday. How long will it take you to get them done by next Wednesday?” people get annoyed.

Equally damaging is taking an estimate and turning it in to a deadline. To add insult to injury, these same people shame the team for missing a date they never committed to in the first place.

Coercion is a damaging practice that is often mistaken as “avoiding commitment”, “fearing blame”, and “loathing accountability”.

But that’s not the fault of estimates, as they say. Bad management is to blame!

#NoEstimates does not fix bad management

Sure it can. Agility and #NoEstimates make the work and the systems that impact the work transparent. Transparency is the bane of control minded management (“bad management”). It threatens power structures and the rewards that come with such things.

With #NoEstimates Embracing Customer Collaboration, transparency is magnified.

Clearly Agile and #NoEstimates concepts have the best chance of chipping away at the command-and-control mindset of traditional management (“bad management”).

It’s isn’t shocking that #NoEstimates critics are not happy with the advocates. Look what critics stand to lose.

#NoEstimates arguments appeal to the disgruntled, naive, gullible, and inexperienced

Ad Hominem much? Another baseless attack. Agile minded developers, managers, and executives are motivated, intelligent, and experienced individuals. Along with a wide range of roles, the Agile community has a wide range of skillsets and experiences.

#NoEstimates advocates avoid exchanges with critics

Hardly the case: The 3 main advocates have gone 100’s of tweets deep with many critics and those who ask questions about the #NoEstimates concepts. Each of them are also very generous with their time and participate in 1:1 sessions over Skype, record podcasts, sit down for interviews, and engage in the community through participation at agile conferences.

Are there a few individuals who typically find themselves on the “blocked” list of agilists? Yes.

However, honest inquiry is almost always answered with thoughtful responses and generous donations of time and energy to help others understand these advanced agile concepts.

Here are podcasts with all 3 of the main #NoEstimates advocates sharing their ideas and opening themselves up to questioning, scrutiny, and criticism:

I’ve yet to see a critic do the same…

Agile Software Delivery with #NoEstimates

How can you make decisions about software development – in the presence of uncertainty – without estimates? Ask Nordstrom’s Innovation Lab.

A story map with a timebox enabled great things at Nordstrom.

A small team of developers and UX designers converged on the shopping floor of the flagship Nordstroms to create an iPad application that helps people decide which pair of sunglasses they like best.

They were given one week (timebox) and continual access to their customers (collaboration) to develop their app. They started by creating a story map with capabilities, features, and stories. Once the stories were prioritized, they got to work.

By the end of the 1 week experiment, the team delivered an application that met the needs of their customers. And they did all of this without estimates.


So how did Nordstom’s Innovation Lab get a product shipped in 1 week without using estimates?

Here are a few key points:

  1. Timeboxing:  By limiting their time to a week, the team had to slice stories down to a size that made sense within their timebox. This kept the work small and the stories focused. In other words, the timebox helped create a natural heuristic for breaking down work. This short timeline also helped to naturally limit the teams Work in Process (WIP).
  2. Located the Team in the Store:  By putting the flash mob dev team in the middle of a store, the customer was always front and center in the process. The customers could at any time see what the team was working on and could provide much valued guidance and feedback as needed. This made sure that the team was “never working on anything not valued by the customer”.
  3. Utilized a User Story Map:  The user story map kept the big picture in mind and also made the work visible. By breaking down capabilities in to features and features in to stories, the customer could then prioritize the stories and make sure that the most important items made it in to the app.
  4. Paper Prototyping:  Cheap and quick feedback reduced waste and significantly lowered the cost of change. UX/UI ideas were quickly validated and refined by the customer in real-time (thanks to colocation) and only after the customer agreed was any code written. The design was emergent.
  5. Short Feedback Loops:  The customer was involved in every decision and saw progress regularly. Trust was high between the dev team and customers thanks to these short feedback loops. This happened because the work was transparent and progress was obvious.
The majority of the agile manifesto shines through in those 5 points. It’s a great story of a simple project that embraced agility and delivered.
But this video raised a lot of questions and criticisms. While I can’t cover all of them in this post, there were a few that I found interesting that I’ll share some thoughts on:
  • What about forecasting Estimates at Completion (EAC)? You can’t do that with #NoEstimates!
    • What this is asking for is the forecasted cost at completion. And I think we can get there with the way that the Nordstrom Innovation Lab does their work.
      • The cost is fixed. Let’s pretend that it costs $10,000 per week to fund the team.
      • Let’s also pretend that the team finishes 10 stories per week.
      • Since the team created a story map (such a great tool – read Jeff Patton’s book to learn more) we can forecast how many weeks (sprints) it will take to complete all of the needed capabilities.
      • Multiply that number by $10,000 (weekly burn rate) and you can provide an EAC.
      • Is it perfect? Nope. Is it exact? Nope. Will it change? Yep. But it is likely accurate enough for some contexts.
      • And it gets more accurate as the project progresses.
  • But this is a simple project, what are the parameters for a “real” project? Can’t just claim 1 and done!
    • That’s moving the goal post down the field. You should be careful when doing that, they weight over 1,100 lbs. Make sure you life with your knees. The question posed was “How can you make decisions – in the presence of uncertainty – without estimates?” Nordstrom answered it with their video. They made lots of decisions with a burn rate, a story map, and a timebox.
  • Can this apply to larger projects? Possibly. What I outlined above could be a way to go. I’ve worked that way with in-house IT teams and did well with it.
  • Can it work for consulting firms or work for hire? No idea. I’ve never been a consultant.
  • What about domains with regulation XYZ? No idea. I’ve never been subject to regulation XYZ and I’ve probably never worked in your domain.
  • Would you deploy ERP this way? Nope! I’m not sure that agile is the right approach for highly coupled massive initiatives like ERP deployments. YMMV

Last, but certainly not least is one of my favorite questions:  “Isn’t the team making implicit estimates by slicing work in relation to a 1 week timebox?”  Sure. Feel free to claim the win with the “everything is an estimate” argument.

BUT in the scenario I laid out, the estimate/forecast is a by-product of the work being done.

This subtle difference is critical to teams successfully delivering software with agile practices.

Question: I’d love to hear your thoughts on the video. Please leave a comment below. You can leave a comment by clicking here.

#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.