Estimation Is Not For Accountability (It’s For Visibility)Filed Under Estimation, Software Process
Almost all software teams run some sort of software process whether it’s Scrum, Agile, Waterfall, or Scumerfall. Each and every one of these processes includes a window of time (for example, Scrum uses the concepts of 1 week iterations).
A recent comment made me about fall out of my chair. Paraphrasing:
One of the best reasons [from a management perspective] to adopt Scrum is the fact that iterations are “accountable commitments” to what the team could accomplish in a week…
Screeeech. No. Estimations are not meant to be used as accountability rulers. They are meant for visibility.
But don’t we need estimations so that we can make business decisions and commitments; therefor aren’t they for accountability? Although, the last sentence would suggest a maybe…still a resounding – no.
Let me make something perfectly clear to everyone reading – nobody should ever be held accountable for estimations. Estimations are naturally shitty, wrong, and optimistic, so why even continue to do them? Because we need the business visibility of how long software is going to take, and as a measurement stick if we can continue the current game plan or react to a different (less optimistic) reality.
I want to repeat that – it gives early visibility to know that our business schedules will work, or early warning they will not so we can react accordingly.
So you are a team manager a few weeks away from a deadline that appears is not going to be meet. What are you to do? Here are a few things to avoid:
- Ignore the early warning signs and pray for a miracle
- Guilt or force your team into working overtime
- Don’t start preparing upper-management that timelines may slip
- Post Deadline: Chew out your team for not making the deadline
Alright, what should you do? Here are a few ideas:
- Realign management strategy
- Bribe the team into working late with food, bonuses, or tech gizmos
- Post Deadline: Aid your team in providing better estimations
Being middle management should be one of the hardest jobs. I have equated software management to being an Army Sergeant, and how you handle the tough decisions of this scenario really draw parallel. You don’t push hard against the officers – shit rolls down hill onto your troops. You don’t rally the troops to accomplish the mission – the overall strategy goes to hell. Either way, you are not a popular person but that is because you make all the hard decisions that everyone else skirts around.