One of the criticisms of the #NoEstimates (NE) stance is the view that even contemplating not estimating is a non-starter – because estimates are “for those paying our salaries”, not those doing the work. That the business folk in our organisations need to know what will happen and when in order to run their company successfully.
OK, even if NE advocates could successfully argue against that assertion, perhaps it is time we started to acknowledge the “impediments” of the debate? The back and forth arguments that prevent us from moving forward to a more constructive place.
Perhaps it is time to find the common ground, and build on that.
A simple truth is that business wants (needs) both speed and predictability. I think we can all (mostly) agree on that 🙂
Some NE critics argue that we should learn better estimation skills such that our predictability improves. Yep, sure. Difficult to argue that learning to do something better is a bad thing.
Given that we have to do a lot of estimating as software practitioners, learning and using more effective estimation techniques seems a good idea.
However, in return for NE advocates acknowledging that we need to provide estimates for those asking, and get better at doing so, I think it’s time for the critics to acknowledge that arguing better estimation as the answer to all the dysfunctions surrounding software estimation is another impediment to the debate moving forward.
I see common ground in that we are all trying to create better predictability for our teams, customers and internal stakeholders. If we put aside “better estimation” as a way of doing that, how else might we do it?
Better predictability can be achieved in many other ways:
- Stability and autonomy of teams
- Limited WIP of initiatives (1 per team at any given time)
- Frequency of delivery of “done” software
- Cadence of collaboration – planning, building and reviewing together
- High visibility and transparency of work and progress
- Shared understanding of variability, its effects on long range planning and how/when to try to minimise it or leverage it to our advantage
to name but a few.
To take the NE debate forward, we need to find ways to provide “those paying our salaries” with the predictability they need, while at the same time moving away from the dysfunctional behaviours associated with holding teams accountable to estimates in highly unpredictable environments.
What is an unpredictable software development environment? One in which 1 or more of the things listed above are not being addressed. It might not be a stretch to suggest that’s pretty much every software shop on the planet.
There is common ground between critics and advocates in this debate. Let’s move on from “no estimates for anyone!” and “just learn better estimation techniques” – these arguments will perpetuate butting heads.
Instead, let’s explore – together – how we might create more predictable environments for our software teams, such that estimation becomes easier (and, in some cases, redundant).
“We are uncovering better ways of developing software by doing it and helping others do it.”
~ Agile Manifesto