The Continuous Dogfight between Product Owners and Tech Leaders: The Illusion of Estimations
Following up on my recent LinkedIn article, on why we need to reconsider the practice of project estimations in software development, I’m expanding further this dialogue to delve into my perspective on the pitfalls of traditional estimation practices and the mismatch with the true essence of software delivery.
The Misalignment of Estimations
New Teams, New Projects, Wrong Estimations
The accuracy of estimations tends to plummet with the novelty of the team and the project. This notion isn’t just anecdotal; it’s a sentiment echoed by experts in the field, like Dave, who shared similar thoughts in one of his insightful videos 🔗.
Disconnect with the Definition of Done
A recurring issue is that estimations frequently do not align with the ‘Definition of Done’. They mostly revolve around the development time of a feature, glaringly omitting crucial platform dependencies that form the backbone of end-value-delivery. The infrastructure requirements such as CI/CD, monitoring, automated testing, security, and resilience are often left out of the estimation conversation.
Ignoring the Journey of Understanding
Estimations tend to overlook the substantial time and effort needed for the team to grasp, research, and optimally deliver a functional feature. The act of coding is merely the tip of the iceberg. A significant chunk of engineering time is invested in understanding, researching, and experimenting, which are equally, if not more, time-consuming than the actual coding.
The Fallacy of Fixed Estimations
The Mirage of Software Continuity
Fixed or approximate estimations often overlook the ongoing nature of software evolution. Software doesn’t exist in a maintenance-free vacuum. It necessitates regression testing, monitoring, and continual tweaks. The environment in which a team operates and the pre-existing systems in place significantly influence the time and effort required to implement changes.
Misguided Focus
Estimations often veer off into a quest to decipher ‘What’ to build by probing ‘When’ it can be built. However, the crux of engineering and product delivery hinges on ‘Why’ we should build it. This pivotal aspect is conspicuously absent from the estimation narrative. If the value proposition is the core focus, the ‘When’ naturally takes a backseat. If the value isn’t apparent, the quest for estimations becomes a moot point.
The Definition of Done
🪶💡Definition of Done: The task of delivering a functional unit is not done, until the target persona has received the value we have promised with the agreed acceptance criteria, and we are receiving feedback (metrics) of its performance.
— Evangelos Pappas.
This is the ‘Definition of Done’ that should be at the heart of any project endeavor, guiding not just the development phase but the entire delivery process.
Conclusion:
Breaking free from the shackles of traditional estimation practices and aligning with a more value-driven, holistic approach could herald a paradigm shift in how we perceive and execute software project delivery. As tech leaders and software engineers, fostering a culture that prioritizes value delivery over time-bound estimations could be our step towards more meaningful and impactful software development.
