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.
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.
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