BA 24/52: The #NoEstimates Rebellion, A TPMs POV
BA 24/52: The #NoEstimates Rebellion, A TPMs POV
Have you heard of this new movement in software development - #NoEstimates? Can it be called a movement? Has it reached peak SAFe level yet Scrum? Perhaps.
Well, if you don’t know what the #NoEstimate movement is, Malcom Issacs over at TechBeacon has done a wonderful job of summarizing the current pro and against camps of the debate.
In a nutshell - #NoEstimates is questioning the efficacy, and even the purpose, of using estimates to predict a project's cost and time line.
For more history, it all started with the wonderfully succinct blog post from 2012 on a project without estimates by Woody Zuill. The origin story of this movement, the piece led to a still standing twitter hashtag #NoEstimates started by Woody where people still argue for both camps.
As TPMs, we don't deliver code. In my not so humble opinion, we are responsible for something much more complicated - predicting the future aka so how long will it take for the team to deliver feature X and for what price.
The primary method for TPMs to address this questions is estimates. So, what does a world look like for us Project Managers if the Engineers rebel and stop giving us estimates for the work they are expected to do.
Easy - we rejoice and welcome the beautiful modern world this will usher in; let’s join the rebellion. Hallelujah!
Okay, back up, let me explain my position.
A Great TPM is a great anthropologist and diagnostician. We are able to observe situations and people, find the patterns, sysenthisize hypothesizes, identify experiments, obeserve the results, rinse, repeat.
Until something better comes along, estimates are a great barometer to understand the challenge the team is about to undertake.
Something that I have kept in mind that James Shore said in his book on Agile whenever I have put on my anthropologist hat with my engineering teams: all new systems are a response to a response never the existing system.
So - which response is the #NoEstimates movement a response to?
Let me share some of my observations about building software in the modern days having spent a decade plus working as a TPM in this industry:
Software has become more and more complicated and complex.
Leadership wants more complex software, cheaper, higher quality, faster.
Revolution in hardware means more and more is expected from software.
Demand from customers is more and more features constantly.
Every requirement is a must have requirement.
Leadership wants more and more control on the productivity of the engineering teams.
As the organization scales, it takes longer to make decisions but leadership never sees that as their problem.
Teams are more and more distributed beyond traditional satellite offices.
So, to address all the grown expectations above, naturally, here is what happened:
Newer and newer methods of estimating software development have risen - chess, poker, points, fibonacci (in some cases it’s become very comical).
Estimates get treated like commitments from leadership.
Estimates become an accountability and performance evaluation tool.
Morale and spirits of the engineering team takes a hit when leadership are upset about missing estimates.
The last bullet is the biggest driver of the #NoEstimates movement in my opinion.
Okay, now back to my earlier statement of why we TPMs should join the rebellion and how we can help engineering teams stick to being agile in a #NoEstimate world:
Constantly remind leadership, estimates when required are… estimates based on the known knowns today. Not commitments. This will change.
If you must estimate - please don’t do story points; it will be good for the soul. Stick to T-Shirt sizes to denote what you know today (Small < 1wk, Medium is 2-4wk, Large > 4wks - this is what we used at Apple and anything large meant we expect to learn more as we do work thus estimates will change.)
Give engineering teams time-box windows to incrementally make progress. Always have a train ready to ship code. I find that engineering teams are great at telling you whether they can hit a particular target versus where the target should be set. This is how we did it at Apple, it was magical. This is why I am a huge fan of Basecamp’s Shape Up Method.
Focus on ensuring the requirements are properly understood, prioritized, and sequenced. Not everything is a must have… trust me. Keep refining that list as development continues.
Throughout the development window, regularly check-in with engineering team to track progress particularly on the new knowns.
Above sharing estimates, build artifacts that showcase transparency around development progress: what is the team working on at the moment, when can they show demos of the work underway, what is still left to do, where are the unknowns + risks + blockers.
Build processes and frameworks to handle scope change; don’t be afraid of it, welcome change.
Keep streamlined comms line between engineering teams and decision makers; in BigTech (like Apple, Google, Nike) the biggest reason for missing estimates is decisions take a long time to make versus say at a startup. Obviously.
Demo, demo, demo, and demo; that is the best estimation tool you can ever use in any scale of software development. Nothing warms the soul of leadership like working software.
There will be a time and place for estimates. However, where you can, forget estimates, focus on building and showcasing working software.
For now, the anthropologist in me will continue to keep an eye on the #NoEstimate movement with much enthusiasm.
Until next time 👋!
-Aadil
How was this week’s newsletter?
https://techbeacon.com/app-dev-testing/noestimates-debate-unbiased-look-origins-arguments-thought-leaders-behind-movement