8 min read
This post is a follow-up to my articles on estimation and product operating models, exploring how adaptive investment, value discovery, and team ownership align with Vasco Duarte’s call for agility beyond the team.
In my earlier posts, “Software Delivery Teams, Deadlines, and the Challenge of Providing Reliable Estimates” and “How Value Stream Management and Product Operating Models Complement Each Other”, I explored two core challenges that continue to hold organizations back: the illusion of predictability in software estimation, and the inefficiency of funding work through rigid project-based models. I argued that software delivery requires a shift toward probabilistic thinking, value stream alignment, and investment in products and initiatives, not fixed-scope, time-bound projects.
Software implementation and delivery estimations have been a constant theme throughout my career. Often seen as a mix of art and science, they remain highly misunderstood. While teams tend to dread them, organizations rely on them for effective planning. Despite their contentious nature, software estimations are an essential part of the process, sparking countless articles, discussions, and debates in the industry. I’m not arguing against estimation or planning. Organizations must plan. Leaders need to make investment decisions, prioritize resource allocation, and create financial forecasts. That doesn’t change. What does need to change is how we think about estimates, how we communicate their confidence, and how we act on the signals that follow.
This is a nuance that can be hard to understand unless you’ve lived both sides, delivering software inside an Agile team and leading business decisions that depend on forecasts. Estimates aren’t the enemy. One lesson I’ve learned, and others often mention, is that the real issue lies in how rigidly we stick to assumptions and how slow we are to adjust them when real-world complexities arise. What we need is to improve both how the business relies on estimates and how delivery teams develop the capability to estimate, update, and communicate confidence levels over time.
A team member recently shared notes from an Agile meetup featuring Vasco Duarte’s talk, “5 Things Destroying Your Ability to Deliver, Even When You’re Agile.” While I didn’t attend the talk, I’ve followed Vasco’s work for years. The talk referenced a 2024 podcast episode of his on Investing in Software1, which I hadn’t listened to yet, until now. That episode inspired this follow-up article.
In this episode, Vasco highlights an important point: traditional project management, often seen in boardrooms and annual plans, is based on a flawed assumption that we can predict outcomes weeks in advance and expect nothing to change. Software development, much like the weather, is unpredictable and chaotic.
Even today, many people treat software estimates as if they were comparable to predicting timelines for manufacturing physical products or managing predictable projects, such as constructing a house or bridge. They expect precision, often clinging to the initial estimate as an unyielding benchmark and holding teams accountable to it. However, software development is an entirely different realm. It’s invisible, knowledge-driven work filled with unknowns and unpredictability. In complex systems, even a small input change can trigger dramatically different outcomes. We’ve all encountered the “simple request” that unexpectedly spiraled into a significant architectural overhaul. I appreciate how Vasco ties this to Edward Lorenz’s 1961 discovery that small changes in initial conditions can lead to drastically different outcomes in weather models. That idea became the foundation of chaos theory.
Sound familiar?
In software development, we refer to this as “new work with unknowns,” “technical debt,” “rewrite,” or “refactor.” But we rarely treat it with the same respect we give to unknowns in other disciplines. Instead, we often pretend we know what we’re doing, and then demand that others commit to it. That’s the real chaos.
In addition to my focus on probability-based estimations and the Product Operating Model, Vasco’s four-point manifesto supports a shift I’ve long advocated for in team estimates and product leadership. It encourages an approach to software delivery that prioritizes adaptability, relies on real-time feedback, and views investment as an ongoing process rather than a one-time decision. This mindset isn’t about removing unpredictability but about working effectively within it.
1. From Estimates to Bets: Embracing Uncertainty with Confidence
Vasco encourages us to think like investors, not project managers. Investors expect returns, but they also accept risk and uncertainty. They recognize that not every bet pays off, and they adjust their approach accordingly based on the feedback they receive. This mindset aligns closely with how I’ve approached probabilistic estimation.
In knowledge work, “unknown unknowns” aren’t the exception. They’re the norm. You don’t just do the work, you learn what the work is along the way. What appears simple on the surface may uncover deep design flaws, coupling, or misalignment. That’s why I advocate for making estimates that improve over time, where confidence and learning signals are more important than arbitrary story point velocity.
Instead of forcing Certainty, we can ask:
“How confident are we right now?”
“What would increase or decrease that confidence?”
“Are we ready to double down, or should we pause and reassess?”
That’s what makes it a bet. And bets are revisited, not rubber-stamped.
2. Budgeting for Change, Not Certainty
The second point in Vasco’s manifesto hits close to home: fund software like you invest in the stock market, bit by bit, adjusting as you go. This reinforces what I wrote in my product operating model article: modern organizations must stop budgeting everything up front for the year and assuming the original plan will hold.
Annual planning works for infrastructure, but not innovation and knowledge work.
In a product-based funding model, teams are funded by their value stream or product, not their project deliverables estimated or guessed over a year. They receive investment to continuously discover, deliver, and evolve, reassessing value rather than completing a fixed set of scope under a dated estimate. This model gives you flexibility: invest more in what’s working, cut back where it’s not, and shift direction without resetting your entire operating plan.
3. Experiments Are the New Status Report
Vasco’s third point is deceptively simple: experiment by default. But what he’s talking about is creating adaptive intelligence at the portfolio level, not just team agility.
When we fund work incrementally and view features or epics as bets, we need signals to tell us whether to continue. In our organization, that signal often comes in the form of experiments, lightweight tests, spikes, MVPs, or “feature toggles” that generate fast feedback.
These aren’t just engineering tactics. They’re governance mechanisms.
When teams experiment, they reduce waste, increase alignment, and surface learning early. But more importantly, they feed information back into the portfolio process. A product manager might learn that a new feature doesn’t solve the core problem. A tech lead might identify a performance bottleneck before it becomes a support nightmare. A value stream might kill a half-funded initiative before it eats more cost.
Experiments give you clarity. Gantt charts provide you with theater.
4. End-to-End Ownership Enables Real Agility
The fourth point in Vasco’s manifesto is about end-to-end ownership, and it resonates deeply with how our teams are structured. When teams own their products from idea to delivery to operation, they don’t just ship; they deliver. They learn, adapt, and inform the next bet.
This kind of ownership isn’t a luxury, it’s a prerequisite to agility at scale.
In our transition to a product operating model, we restructured our delivery teams to align with value streams. We gave them clarity of purpose, full-stack capability, and autonomy to act. But what we hope to get in return isn’t just faster output; it’s better signals.
Teams close to the work produce insights you can trust. Teams trapped in delivery factories or matrixed dependencies can’t.
The Three Ways Still Apply
Listening to Vasco’s manifesto again, I was struck by how strongly it aligns with a set of principles we’ve had since at least 2021: The Three Ways, as described by Gene Kim and coauthors in The DevOps Handbook.
- The First Way emphasizes flow and systems thinking, focusing on how value moves across the entire stream, not just within teams or silos.
- The Second Way amplifies feedback loops, not just testing or monitoring, but real signals about whether we’re solving the right problems.
- The Third Way advocates for a culture of continuous experimentation and learning. Accepting uncertainty, embracing risk, and using practice to gain mastery.
These are all still relevant today. But what often goes unspoken is that these principles must extend beyond the delivery teams. They must engage in planning, budgeting, prioritization, and governance.
Vasco’s idea of funding software like investments and treating initiatives as “bets” highlights the need to strengthen feedback loops across the portfolio. Experimentation has shifted from simple automated testing to focusing on strategic funding and continuous learning. Similarly, flow isn’t just about deployment pipelines anymore; it’s about speeding up the process from business decisions to tangible, measurable results.
If we’re going to embrace agility across the business truly, we must apply the Three Ways at every level of the system, especially where strategy meets funding and planning.
The Real Work, Planning for Chaos, Leading with Signals
Here’s where I’ll close, echoing Vasco’s message: the fundamental constraint in software isn’t at the team level. It’s at the leadership level, where we cling to project thinking, demand estimates without context, and build plans on the illusion of Certainty.
I strongly advocate for incorporating confidence levels and probability estimations in our organization. However, we operate on an annual funding model, planning the entire year’s operating plan, including product development investments, in advance. I hope to eventually work with product-funded budgets instead. Only time will tell. However, we can still evaluate our product development investments as we go and adjust our direction if needed.
To effectively lead a modern software organization, treat funding like an investor, not a contractor. Measure progress based on learning, not hitting milestones. Enable teams to provide actionable insights, not just reports. Structure governance models around value-driven feedback, not activity tracking.
Because you’re no longer managing projects, you’re managing bets in a chaotic system. And the sooner we stop pretending otherwise, the better our outcomes will be.
Poking Holes
I invite your perspective on my posts. What are your thoughts?.
Let’s talk: phil.clark@rethinkyourunderstanding.com
References
- Duatre, Vasco (Host). “Xmas Special: Investing in Software: Alternatives To Project Management For Software Businesses.” December 27, 2024. Scrum Master Toolbox Podcast: Agile storytelling from the trenches [Audio podcast]. Apple Podcasts, https://podcasts.apple.com/us/podcast/scrum-master-toolbox-podcast-agile-storytelling-from/id963592988
Related Articles
- Software Delivery Teams, Deadlines, and the Challenge of Providing Reliable Estimates”. Phil Clark. rethinkyourunderstanding.com
- “How Value Stream Management and Product Operating Models Complement Each Other”. Phil Clark. rethinkyourunderstanding.com