This all sounds very well but is written entirely from the perspective of efficiently managing the work itself. During the course of the piece you shift the time frame from being forward looking (a forecast) to being retrospective (actual capacity) without acknowledging the magnitude of this transition.
The list of stakeholders you've ignored in doing so is huge:
- Customers waiting on the feature/product you're building
- Sales and marketing efforts attempting to plan GTM and sales processes for it
- HR and team leadership trying to predict organisation-wide capacity deficits and manage hiring processes
From a pure engineering perspective, it's facile to suggest that waterfall is wholly inadequate to solve the *engineering problem* of delivering a product. But you ignore the wider business context in which this effort occurs in the first place. None of the engineers have salaries without an organisation that needs to understand what will be delivered, when, and in what state of quality. There can be flex on all of those qualities, but they cannot be a complete mystery until the product ships. There's no universe in which teams get to drop something like that – not for venture backed startups and certainly not for mature businesses.
All of which is to say, we will never escape the pressure to PUSH, no matter how much PULLing makes more sense for our personal needs as product teams. And nor should we. There needs to be some ownership and accountability for our future intention and how it aligns with eventual reality, otherwise we're all just hobbyist inventors.
Great comment, let me try to address the issues you raise:
1. You can have accountability for future intent based on the Empirical data of pull (historical forecast). You even have this historical data for larger initiatives before you do anything. This should be enough for forecasting.
2. You set a budget for the maximum amount of time you want to spend on something. E.g. you do this based on money. How much money do we want to spend on this? You can translate this money to time.
3. When the teams pull work, they can take this budget and its feasibility into account. And use this for your forecasting conversations and keeping others in the loop, like the GTM you mentioned.
Thanks for this considered reply! I remain a little concerned at feasibility however. Past performance cannot reliably inform future expectation given (a) fluctuations in team availability and distraction, (b) the effectiveness of tackling problems that may be in different area of competence for the team, and (c) mitigating factors caused outside the team, such as changes introduced by e.g. platform team, deploy processes, or role or process changes. These things all take place routinely in any dynamic business and have real impact on estimation efficacy.
And while I love the idea of setting an effort budget, in real terms stakeholders think in terms of capability and this will be the line they gravitate towards. With the best will in the world, politics will trump rationality. YMMV of course 🙂
Andrew, the items you call out are variables that need to taken into account when forecasting while taking past performance into account. In practice, these items would be dealt with as development and delivery risks with risk management plans for them. Key here is the likelihood of occurrence as well as the timing of the occurrence. We often are not guaranteed that we can assemble the “ideal” delivery team and must assemble the best team we can and estimate and plan accordingly.
Dale, thanks for that take, and I agree with the risk management approach.
Assembling a team is even more concerning though! If this group of people has not worked together before then no past performance data exists at all. Every group of people is unique in my experience and even capable performers need time to normalise with the rest of the team.
In the real world I think we all know that this is all beside the point; we have to get on with things and do the best we can. It's just that a lot of 'best practice' advice (and I've dispensed my fair share of this too) tends to gloss over the inconvenient details that trip up the most well-intentioned approaches.
> None of the engineers have salaries without an organisation that needs to understand what will be delivered, when, and in what state of quality
When this needs to happen depends on what you're optimising for.
Customers "waiting" on a feature - Usually means someone announced or sold something that doesn't exist. This isn't a feature, it is an opportunity. Still doesn't speed up development. If they really need it, it will be great as soon as it arrives, but not sooner. Customers should plan accordingly.
Sales and marketing efforts attempting to plan GTM - this is an interesting point, especially because it is often used as a strong argument to know things precisely. As if Apple hasn't moved Apple Intelligence after announcing it for the iPhone 16. Ideally you can announce (even to customers) and deliver on time. But what would you rather? Have sales and marketing prep and wait for the actual availability or have everything decided up-front and then play catch-up?
Lastly, HR and leadership... IDK too much there. I've seen so many poorly timed waves and decisions (just look at MAMAA firing waves) to put much thought into that
Apple Intelligence is a perfect example of misalignment between product and sales/marketing. Apple's stance on AI is genuinely unique, and should position them as one of the least reactionary tech companies in the world. Instead? They exaggerate the product roadmap, overpromised and underdelivered. They've been getting called out for it, rightfully, ever since. Just this week it turns out Siri is being delayed yet again. The gearing between what is coming of product and what is being marketed is pivotal to projecting a capable company to the market.
This is really intriguing because I’m struggling to forecast estimated effort and it’s hurting my ability to roadmap and give cost estimates to client. I typically have a fixed staff (so assume fixed capacity).
I don’t understand what I change in the PULL system. Maybe it’s because in my agency, clients won’t accept starting work until we give them budget estimates and timelines and so are forced to go back to PUSH?
I've worked in fixed-price, fixed scope situations.
That's tough.
The main thing you should prevent from doing is e.g. you assume X tasks take 2 weeks and pull all those X tasks in. Pull them in gradually, based on the reality of the work.
You will complete more work than if you PUSH it all in. Because once resource utilization shoots up, flow goes down.
For a standalone team without constant scrutiny by leaders who inevitably want more, I agree push can be better than pull. For larger efforts that require coordination between teams, whether organized in an Agile Release Train (ART) or not, planning effort is warranted, especially to surface and sequence work in ways that address dependencies between teams. And yes, we should consider team topologies to minimize dependencies between teams first, but some dependencies may remain. In this situation, planning can and should lead to some level of push. Further, it's critical to never plan to capacity and the percentage of capacity to plan depends on the context, but typically should not exceed 80%.
The real issue is frequently a lack of understanding by leaders on the nature of engineering work, that you've articulated well in terms of why it's not possible to plan with certainty. I recently witnessed a leader declare that teams were missing commitments and this will have to stop. As if just declaring it would make it so. This was for a large ART implementing multiple AI use cases and implementing on a newly-adopted cloud platform.
I call on engineering leaders who understand the complexities and uncertainties that can be associated with product development to educate your colleagues, especially on the business side. This education should go all the way up to the board level. It's not about throwing up our hands and saying we have no idea when we can deliver, but rather striking a balance between developing roadmaps based on what we know at a point in time and updating based on discovery and adjustments or pivots that occur with rapid and continual feedback loops that lead to delivering what the customer needs.
Thank you for sharing, Maarten. If institutions had started pulling with agility decades ago, imagine what a wonderful place the world could be today without the legal illusion of adherence to contracts and a command-and-control hierarchy. Take a look at Horizon and the relationship between Post Office and Fujitsu, who helped contribute to the Post Office scandal, affront to the public conscience, miscarriage of justice, harm to people and cover-up of wrongdoing. Systems are made for humans, not humans for systems. 🙏 #Unity #LovingOthers
I believe in reforming from self-preservation systems to right leadership grounded in servant leadership and great stewardship. #PDCA #Btfa
This all sounds very well but is written entirely from the perspective of efficiently managing the work itself. During the course of the piece you shift the time frame from being forward looking (a forecast) to being retrospective (actual capacity) without acknowledging the magnitude of this transition.
The list of stakeholders you've ignored in doing so is huge:
- Customers waiting on the feature/product you're building
- Sales and marketing efforts attempting to plan GTM and sales processes for it
- HR and team leadership trying to predict organisation-wide capacity deficits and manage hiring processes
From a pure engineering perspective, it's facile to suggest that waterfall is wholly inadequate to solve the *engineering problem* of delivering a product. But you ignore the wider business context in which this effort occurs in the first place. None of the engineers have salaries without an organisation that needs to understand what will be delivered, when, and in what state of quality. There can be flex on all of those qualities, but they cannot be a complete mystery until the product ships. There's no universe in which teams get to drop something like that – not for venture backed startups and certainly not for mature businesses.
All of which is to say, we will never escape the pressure to PUSH, no matter how much PULLing makes more sense for our personal needs as product teams. And nor should we. There needs to be some ownership and accountability for our future intention and how it aligns with eventual reality, otherwise we're all just hobbyist inventors.
Great comment, let me try to address the issues you raise:
1. You can have accountability for future intent based on the Empirical data of pull (historical forecast). You even have this historical data for larger initiatives before you do anything. This should be enough for forecasting.
2. You set a budget for the maximum amount of time you want to spend on something. E.g. you do this based on money. How much money do we want to spend on this? You can translate this money to time.
3. When the teams pull work, they can take this budget and its feasibility into account. And use this for your forecasting conversations and keeping others in the loop, like the GTM you mentioned.
I believe all your points have been addressed.
Thanks for this considered reply! I remain a little concerned at feasibility however. Past performance cannot reliably inform future expectation given (a) fluctuations in team availability and distraction, (b) the effectiveness of tackling problems that may be in different area of competence for the team, and (c) mitigating factors caused outside the team, such as changes introduced by e.g. platform team, deploy processes, or role or process changes. These things all take place routinely in any dynamic business and have real impact on estimation efficacy.
And while I love the idea of setting an effort budget, in real terms stakeholders think in terms of capability and this will be the line they gravitate towards. With the best will in the world, politics will trump rationality. YMMV of course 🙂
Andrew, the items you call out are variables that need to taken into account when forecasting while taking past performance into account. In practice, these items would be dealt with as development and delivery risks with risk management plans for them. Key here is the likelihood of occurrence as well as the timing of the occurrence. We often are not guaranteed that we can assemble the “ideal” delivery team and must assemble the best team we can and estimate and plan accordingly.
Dale, thanks for that take, and I agree with the risk management approach.
Assembling a team is even more concerning though! If this group of people has not worked together before then no past performance data exists at all. Every group of people is unique in my experience and even capable performers need time to normalise with the rest of the team.
In the real world I think we all know that this is all beside the point; we have to get on with things and do the best we can. It's just that a lot of 'best practice' advice (and I've dispensed my fair share of this too) tends to gloss over the inconvenient details that trip up the most well-intentioned approaches.
> None of the engineers have salaries without an organisation that needs to understand what will be delivered, when, and in what state of quality
When this needs to happen depends on what you're optimising for.
Customers "waiting" on a feature - Usually means someone announced or sold something that doesn't exist. This isn't a feature, it is an opportunity. Still doesn't speed up development. If they really need it, it will be great as soon as it arrives, but not sooner. Customers should plan accordingly.
Sales and marketing efforts attempting to plan GTM - this is an interesting point, especially because it is often used as a strong argument to know things precisely. As if Apple hasn't moved Apple Intelligence after announcing it for the iPhone 16. Ideally you can announce (even to customers) and deliver on time. But what would you rather? Have sales and marketing prep and wait for the actual availability or have everything decided up-front and then play catch-up?
Lastly, HR and leadership... IDK too much there. I've seen so many poorly timed waves and decisions (just look at MAMAA firing waves) to put much thought into that
Apple Intelligence is a perfect example of misalignment between product and sales/marketing. Apple's stance on AI is genuinely unique, and should position them as one of the least reactionary tech companies in the world. Instead? They exaggerate the product roadmap, overpromised and underdelivered. They've been getting called out for it, rightfully, ever since. Just this week it turns out Siri is being delayed yet again. The gearing between what is coming of product and what is being marketed is pivotal to projecting a capable company to the market.
This is really intriguing because I’m struggling to forecast estimated effort and it’s hurting my ability to roadmap and give cost estimates to client. I typically have a fixed staff (so assume fixed capacity).
I don’t understand what I change in the PULL system. Maybe it’s because in my agency, clients won’t accept starting work until we give them budget estimates and timelines and so are forced to go back to PUSH?
I've worked in fixed-price, fixed scope situations.
That's tough.
The main thing you should prevent from doing is e.g. you assume X tasks take 2 weeks and pull all those X tasks in. Pull them in gradually, based on the reality of the work.
You will complete more work than if you PUSH it all in. Because once resource utilization shoots up, flow goes down.
For a standalone team without constant scrutiny by leaders who inevitably want more, I agree push can be better than pull. For larger efforts that require coordination between teams, whether organized in an Agile Release Train (ART) or not, planning effort is warranted, especially to surface and sequence work in ways that address dependencies between teams. And yes, we should consider team topologies to minimize dependencies between teams first, but some dependencies may remain. In this situation, planning can and should lead to some level of push. Further, it's critical to never plan to capacity and the percentage of capacity to plan depends on the context, but typically should not exceed 80%.
The real issue is frequently a lack of understanding by leaders on the nature of engineering work, that you've articulated well in terms of why it's not possible to plan with certainty. I recently witnessed a leader declare that teams were missing commitments and this will have to stop. As if just declaring it would make it so. This was for a large ART implementing multiple AI use cases and implementing on a newly-adopted cloud platform.
I call on engineering leaders who understand the complexities and uncertainties that can be associated with product development to educate your colleagues, especially on the business side. This education should go all the way up to the board level. It's not about throwing up our hands and saying we have no idea when we can deliver, but rather striking a balance between developing roadmaps based on what we know at a point in time and updating based on discovery and adjustments or pivots that occur with rapid and continual feedback loops that lead to delivering what the customer needs.
Yes, I agree with you that the complexity and uncertainties associated with software development are frequently misunderstood.
Pull does not mean no planning, it means trying to delay planning to the moment you have the best information (the last responsible moment).
Thank you for sharing, Maarten. If institutions had started pulling with agility decades ago, imagine what a wonderful place the world could be today without the legal illusion of adherence to contracts and a command-and-control hierarchy. Take a look at Horizon and the relationship between Post Office and Fujitsu, who helped contribute to the Post Office scandal, affront to the public conscience, miscarriage of justice, harm to people and cover-up of wrongdoing. Systems are made for humans, not humans for systems. 🙏 #Unity #LovingOthers
I believe in reforming from self-preservation systems to right leadership grounded in servant leadership and great stewardship. #PDCA #Btfa