@natecox I’m fairly certain I’m beyond the point of “let’s not do this because I, personally, don’t like it” in my career 😅
No, the point is that I just cannot anticipate the work that needs to be done. But that is what I would have to do to provide them with what they want.
There is, in software delivery, a fundamental difference in need between company management and engineering teams. This is especially true if you are working in a software department of an otherwise not software company, e.g the App team for a supermarket.
Engineeres want to work in agile sprints without estimating too much up front. But execs want a concrete timescale for when a feature will land so they can plan for it. I have never worked anywhere where “It will be ready when it’s ready” is an acceptable answer for the board. They want timescales.
It’s the job of an engineering lead to find some way to bridge these competing desires and give everyone what they need, and that frequently DOES require estimating everything, at a high level. Even if it’s pain in the arse job that takes time away from actual delivery and we don’t want to do it, we still have to.
My personal strat is to break the deliverable down into big pieces and estimate those at a high level with sizing in terms of weeks. X weeks for this, Y weeks for that. And against those deliverables I put a confidence score in % for how likely I think those deliverables are to land within the time estimate. This confidence score provides a way to communicate to the execs that things are very wibbly to start and that it’s hard to estimate things that are far away.
The uncertainty is important because what you need to constantly communicate is that this is not a set-in-stone roadmap, but a prediction for where things will land as they are currently known. The goal is to make sure this is shared all the way up the chain. That way when the predictions change later and timescales maybe get pushed out, there is a mechanism to communicate that and nobody gets shocked.
The estimation exercise us indeed a pain but it does have some advantages for the engineering team too. If you have high risk and low confidence areas after doing it (e.g. “This integration with third party supplier APIs looks like it could really drag on”) then you can try to front-load those areas to reduce the risk.
It sounds like you need a design sprint; which fits fairly neatly into waterfall as an early step.
Google (even though I loathe suggesting anything google these days) has comprehensive documentation on how they do their two week design sprints; I have done them a few times and they do a damn fine job of helping you to find the work you need to do.
@natecox I’m fairly certain I’m beyond the point of “let’s not do this because I, personally, don’t like it” in my career 😅
No, the point is that I just cannot anticipate the work that needs to be done. But that is what I would have to do to provide them with what they want.
There is, in software delivery, a fundamental difference in need between company management and engineering teams. This is especially true if you are working in a software department of an otherwise not software company, e.g the App team for a supermarket.
Engineeres want to work in agile sprints without estimating too much up front. But execs want a concrete timescale for when a feature will land so they can plan for it. I have never worked anywhere where “It will be ready when it’s ready” is an acceptable answer for the board. They want timescales.
It’s the job of an engineering lead to find some way to bridge these competing desires and give everyone what they need, and that frequently DOES require estimating everything, at a high level. Even if it’s pain in the arse job that takes time away from actual delivery and we don’t want to do it, we still have to.
My personal strat is to break the deliverable down into big pieces and estimate those at a high level with sizing in terms of weeks. X weeks for this, Y weeks for that. And against those deliverables I put a confidence score in % for how likely I think those deliverables are to land within the time estimate. This confidence score provides a way to communicate to the execs that things are very wibbly to start and that it’s hard to estimate things that are far away.
The uncertainty is important because what you need to constantly communicate is that this is not a set-in-stone roadmap, but a prediction for where things will land as they are currently known. The goal is to make sure this is shared all the way up the chain. That way when the predictions change later and timescales maybe get pushed out, there is a mechanism to communicate that and nobody gets shocked.
The estimation exercise us indeed a pain but it does have some advantages for the engineering team too. If you have high risk and low confidence areas after doing it (e.g. “This integration with third party supplier APIs looks like it could really drag on”) then you can try to front-load those areas to reduce the risk.
How do you have waterfall without known requirements? What does waterfall have to do with anticipating work?
Can you elaborate in detail what the problem is? It’s not apparent from what you’ve detailed so far.
It sounds like you need a design sprint; which fits fairly neatly into waterfall as an early step.
Google (even though I loathe suggesting anything google these days) has comprehensive documentation on how they do their two week design sprints; I have done them a few times and they do a damn fine job of helping you to find the work you need to do.
https://designsprintkit.withgoogle.com/
@natecox Damn! That’s an excellent idea, actually! Thank you so much.
You’re welcome! Good luck with your project, friend.