Systemic Waste of “Estimation Debt”: How Spending Hours Debating Relative Points Creates Zero Value for the Customer—Violating the Core Definition of Lean
| Introduction In the world of software development and modern product delivery, estimating work has become a ritualized process. Teams gather for planning sessions, discussing and debating the size of user stories, assigning relative points, and striving for consensus on effort. While estimation was originally intended to bring predictability and transparency, it has evolved into a practice that often produces more waste than value. The time and energy spent on estimating, especially when it turns into a prolonged debate over points, can become a hidden burden—an “Estimation Debt.” This practice stands in direct opposition to the core principles of Lean, which prioritize delivering value to the customer and eliminating waste. This blog post analyses the concept of Estimation Debt as a systemic waste, investigates its root challenges, offers actionable recommendations, and concludes with critical reflections on how organizations can shift toward true customer-centricity. Challenges Misalignment with Lean Principles Lean methodology is clear: anything that does not add value for the customer is waste. Yet, teams routinely spend countless hours in estimation meetings, discussing whether a task is a 3, 5, or 8-point story. These debates rarely improve the quality of the product or accelerate delivery. Instead, they create process inertia, where the focus moves away from the customer and toward internal alignment on abstract numbers. The Illusion of Predictability Estimates are, at their core, educated guesses. Despite sophisticated techniques and complex point systems, the accuracy of these forecasts is notoriously poor. Teams and stakeholders often treat relative points as hard commitments, leading to pressure, blame, and stress when forecasts inevitably miss the mark. The pursuit of predictability becomes a substitute for real progress, consuming time that could otherwise be spent building and learning. Opportunity Cost The hours invested in estimation are hours not spent solving customer problems, improving product quality, or experimenting with new ideas. This opportunity cost is invisible but significant. Over weeks and months, the cumulative time spent in estimation meetings can rival the time spent on actual development. The organization pays a high price in slow feedback loops, delayed value delivery, and missed opportunities for innovation. Reinforcement of Hierarchy and Groupthink Estimation sessions often become arenas where the loudest voices dominate, and conformity is silently enforced. Junior team members may hesitate to challenge senior opinions, and teams may converge on a “safe” number to avoid conflict. This dynamic stifles diversity of thought, reduces psychological safety, and further distances the team from customer value. Estimation Debt Compounds Over Time Just as technical debt accumulates through shortcuts and poor code, estimation debt grows with every unnecessary conversation about points. This debt manifests as bloated backlogs, overcomplicated planning processes, and a culture that values internal metrics over external outcomes. Ultimately, it becomes a barrier to agility, adaptability, and customer satisfaction. Recommendations Shift Focus from Points to Value Reframe planning conversations around customer outcomes, not abstract numbers. Ask, “What value does this work deliver?” instead of “How many points is this story?” Prioritize work that directly impacts users and aligns with business objectives. Use points, if at all, as a rough guide—not as the centrepiece of planning. Embrace Lightweight Estimation Techniques When estimation is necessary, keep it simple and time boxed. Techniques like T-shirt sizing, affinity mapping can reduce the cognitive load and prevent endless debate. The goal is to align quickly and move forward, not to achieve perfect accuracy. Use Lean practices like Visual Factory and WIP Transparency allows teams to see bottlenecks and focus on delivery rather than prediction. The Lean practice of limiting work in progress (WIP) encourages faster feedback and continuous delivery, reducing the need for up-front estimation and shifting attention to actual progress. Foster a Culture of Experimentation Replace exhaustive estimation with rapid experimentation. Deliver small increments, gather feedback, and adjust course based on real customer input. This approach aligns with Lean principles and minimizes the waste of debating hypothetical outcomes. Measure What Matters Focus metrics on customer value and outcomes, not internal velocity or point throughput. Track lead time, cycle time, and customer satisfaction. These indicators provide a more honest reflection of progress and encourage behaviours that drive value. The Bottom Line Estimation Debt is a silent cost that saps the energy, creativity, and Agility of teams. By transforming estimation from a ritualized debate into a lightweight, value-driven activity organizations can reclaim time, focus, and alignment with what truly matters: delivering value to customers. Agile is not about doing more with less; it’s about doing only what matters and ruthlessly cutting what doesn’t. It’s time to challenge the status quo, question entrenched habits and reimagine estimation as a tool for learning and improvement, not a box to be checked. Questions for Reflection
|
The Ethics of Over-Allocation in Sprints. Debating Whether Pushing Teams Beyond Sustainable Velocity Breaches the Ethical Mandate for Respect Toward Human Capital
| Introduction In the fast-paced world of software development and Agile project management, the concept of the “Sprint”, also called “Iteration”, has revolutionised how product development and sometimes even project work is planned and delivered. Sprints promise rapid, incremental progress and iterative adaptation to user needs. In principle, they also foster a sense of urgency and achievement. However, as the management demands faster results and more output, a troubling trend has emerged: the over-allocation of tasks and responsibilities during Sprints, often pushing teams beyond their sustainable capacity to deliver. This practice raises an important ethical question—does repeatedly demanding more than what is sustainable breach the fundamental Agile value of Respect for human capital? This blog post analyses the ethical considerations surrounding over-allocation in Sprints, examining the challenges it poses and exploring recommendations for ethical project management. It is a discussion on how organisations can balance ambition with respect for their most valuable asset: people. Challenges The Temptation of Over-Allocation Managers, Product Owners included, often feel pressure to maximise productivity, especially under tight deadlines or when stakeholders demand quick wins. This pressure can manifest as over-committing teams to more work than they have historically demonstrated they can complete within a Sprint—their “sustainable velocity.” Their rationale is simple: if a team did 30 story points last sprint, why not push for 35 or 40 this time? The Human Cost While the intention might be to “stretch” teams to achieve more, sustained over-allocation erodes morale and trust. Team members may begin to experience chronic stress, burnout, and a sense of being undervalued. High turnover, diminished quality of work, and disengagement are often the consequences. Furthermore, over-allocation contradicts the Manifesto for Agile Software Development’s call to “build projects around motivated individuals” and “give them the environment and support they need.” The Ethical Dilemma At its core, the Agile principle of Respect is about honouring the capacity, skills, and well-being of each team member. When leaders knowingly exceed a team’s sustainable velocity, they risk treating people as mere resources rather than as humans with limits, needs, and intrinsic motivation. This raises the ethical question: Is it acceptable to sacrifice human well-being for perceived short-term gains? Organisational Culture and Systemic Issues Over-allocation is rarely an isolated incident. It often reflects deeper systemic issues—such as unrealistic stakeholder expectations, lack of psychological safety, and a culture that values output over outcomes. Teams may feel unable to speak up about unsustainable workloads, and leaders may ignore warning signs to avoid difficult conversations with upper management. Recommendations Embrace Transparency Organisations should foster an environment where teams can honestly communicate their sustainable pace (aka ‘velocity’) and any impediments they face. Transparency ensures that Sprint planning is grounded in reality, not wishful thinking. Prioritise Psychological Safety Leaders must create a culture where team members feel safe to express concerns about workload without fear of reprisal. Psychological safety is foundational to ethical decision-making and healthy team dynamics. Respect Sustainable Pace Sustainable pace is not merely a metric—it’s a reflection of a team’s collective capacity and well-being. Honour this metric by resisting the urge to over-commit. Instead, focus on removing impediments and supporting continuous improvement. Empower Teams in Planning Involve teams directly in estimating and committing to Sprint goals. Empower the team to take ownership and deliver high-quality work. Top-down allocation undermines trust and motivation. Educate Stakeholders Stakeholders may not always understand the implications of over-allocation. Invest in education and set realistic expectations about what can be achieved sustainably. Highlight the long-term costs of burnout and turnover versus the benefits of a healthy, motivated team. Lead by Example Leaders, Product Owner and Scrum Master included, should model respect for human capital by setting boundaries, encouraging work-life balance, and acknowledging the effort behind every sprint. Recognise and reward sustainable practices, not just heroic efforts during crunch times. The Bottom Line Over-allocation in Sprints is more than a productivity challenge—it’s an ethical issue that tests an organisation’s values and culture. Pushing teams beyond a sustainable pace may yield short-term results, but it undermines trust, well-being, and long-term success. The ethical principle of Respect is not optional; it is a mandate to treat people as the essential, irreplaceable assets they are. Organisations that honour this mandate will not only achieve better outcomes but will also foster loyalty, innovation, and resilience in their teams. Questions for Readers
|
The Waterfall Misconception: What Dr. Royce Really Said in 1970
| The Waterfall Misconception: What Dr Royce Really Said in 1970 Introduction The “waterfall” method is one of the most referenced and misunderstood models in the history of software engineering. For decades, it has been depicted as a rigid, linear process—a step-by-step approach where each phase must be completed before moving to the next. This model is often attributed to Dr Winston W. Royce’s seminal 1970 paper, “Managing the Development of Large Software Systems.” However, a close reading of Royce’s original work reveals that the common depiction of the waterfall is not only a misinterpretation but, ironically, the very approach Royce warned against. In this blog post, we’ll unpack the myth, analyse the source, and explore the real lessons for modern software development. 1. The Birth of the Waterfall Model The Context of 1970 In the late 1960s and early 1970s, software engineering was a young discipline. Large-scale projects, especially in aerospace and defence, were failing at alarming rates due to poor requirements, weak communication, and a lack of systematic processes. Dr Royce, working at Lockheed, set out to address these challenges. Royce’s Diagram On page 2 of Royce’s 1970 paper, a diagram appears showing a sequential development process with steps like:
2. What Royce Actually Said A Caution, Not a Prescription Royce did not advocate the strictly sequential process that is now called the waterfall method. In fact, he offered the diagram as a critique: “I believe in this concept, but the implementation described above is risky and invites failure.” (Royce, 1970) He immediately points out the dangers of discovering issues late in the cycle, when changes are expensive and disruptive. The Perils of Linear Development Royce warned that testing at the end of the process is the first time the system’s actual behaviour is observed: “Far too often the software is found to be unacceptable only after the project is near completion.” He saw this as a fundamental flaw—not a best practice. 3. The Real Message: Feedback and Iteration Feedback Loops Royce’s true recommendation was to introduce feedback loops between phases. His revised diagrams in the paper show iterations, with arrows pointing back from later to earlier steps. He advocated for:
Royce also recommended building prototypes and conducting rigorous reviews at every stage. These practices are now common in Agile and modern iterative methods. “The development process should include the construction of a pilot model for each major phase of the software project.” (Royce, 1970) He emphasised that validation and verification must happen throughout, not just at the end. 4. How the Waterfall Myth Spread Oversimplification in Practice Despite Royce’s warnings, the initial sequential diagram was easy to understand and teach. Managers and educators began to present it as a prescriptive process, omitting the context and feedback loops. Institutionalization Government agencies and contractors, seeking structure and predictability, mandated the “waterfall” approach in contracts and standards. Textbooks cemented the model, and soon, “waterfall” became shorthand for a process Royce himself criticised. 5. The Cost of the Misconception By locking teams into rigid phases, organisations experienced the very problems Royce anticipated: late discovery of requirements issues, inflexible designs, and costly overhauls late in the project. Modern Agile and iterative approaches echo Royce’s real message: embrace feedback, iterate, and validate early and often. The success of these methods underscores the dangers of the misunderstood waterfall model. 6. Revisiting Royce: Lessons for Today Read the Source Software professionals should read Royce’s paper directly. His nuanced approach is relevant today:
No single process fits all projects. Royce’s real legacy is the idea that processes must adapt to complexity and uncertainty.
|
Celebrating 40 Years of Scrum: Revisiting the Origins, Achievements, and Overlooked Limitations
Do Agile Teams Really Not Need Managers?
| Introduction One of the most persistent misconceptions in the Agile world is the belief that Agile teams do not need managers. This idea, while popular, is rooted in a misunderstanding of what “self-managed” and “self-organized” mean. As organizations adopt Agile, they often grapple with the role of management, sometimes swinging the pendulum too far and eliminating leadership positions, expecting teams to handle everything themselves. This blog post is attempting to clarify the confusion between self-managed and self-organized teams, debunk the myth that managers are obsolete in Agile, and explore how the leadership role evolves in an Agile environment. Challenges: Misunderstandings and Organizational Pitfalls Confusing Self-Organization with Self-Management A key source of confusion is the difference between self-organization and self-management. Self-organizing teams decide how to accomplish their work within given constraints—they choose their methods, practices, and day-to-day task assignments. However, self-management goes a step further. A truly self-managed team is not only self-organizing but also self-funded: it has authority over budget, staffing, and strategic decisions, essentially functioning as a mini company within the organization. Most Agile teams are not self-managed in this sense; they still rely on external leadership for resources, direction, and alignment. The “No Managers” Myth The notion that Agile does away with management stems from a literal interpretation of the Agile Manifesto for Software Development, which values “individuals and interactions over processes and tools.” However, nowhere does Agile suggest the removal of leadership. Instead, Agile advocates for a shift in leadership style—from command-and-control to servant leadership. When organizations eliminate managers without redefining their roles, teams often struggle with unresolved conflicts, unclear priorities, and a lack of support. Leadership Vacuum and Its Consequences Without effective leadership, Agile teams may encounter several issues:
Recommendations: The Evolving Role of Managers in Agile From Supervisor to Mentor Managers in Agile organizations transition from assigning tasks and monitoring performance to mentoring. Their focus is on developing people, fostering collaboration, and helping individuals grow in their roles. They support team members in resolving conflicts, identifying growth opportunities, and building new skills. Removing Impediments A critical part of a manager’s new role is identifying and eliminating obstacles that hinder the team’s progress. This can range from addressing organizational bottlenecks to advocating for better tools and resources. By removing impediments, managers enable teams to maintain momentum and focus on delivering value. Enabling Decision-Making While Agile teams are empowered to make many decisions, there are still organizational boundaries. Managers help define these boundaries and ensure teams have the information and authority needed to make timely decisions. They clarify priorities, navigate organizational politics, and ensure clear channels for escalation when needed. Developing People and Teams Managers in Agile environments are responsible for helping individuals and teams reach their full potential. This involves regular feedback, personal development plans, and creating opportunities for learning. Managers also play a role in building high-performing teams by fostering psychological safety and trust. Aligning Teams with Strategy One of the most valuable contributions managers make is ensuring that teams remain aligned with the organization’s strategic goals. They communicate vision, provide context, and help teams see how their work fits into the bigger picture. This alignment is critical for maximizing business value and sustaining motivation. The Bottom Line The belief that “Agile teams don’t need managers” is a myth rooted in a misunderstanding of Agile principles. Agile does not eliminate the need for leadership; it redefines and redistributes it. Most Agile teams are self-organizing but not self-managed in the full sense, as they still depend on organizational support for funding, staffing, and strategy. The manager’s role shifts from command-and-control to enabling, coaching, and aligning teams. Agile managers are essential for removing impediments, developing people, and ensuring teams deliver value in alignment with organizational goals. Rather than becoming obsolete, managers become even more critical to Agile success—provided they embrace their new responsibilities and mindset. Questions for Reflection
|
