3 ms·

I've seen that tried, I've never seen it actually work. What I've always seen happen is, they'll ask if X can be worked into the schedule, the devs will say no

I've seen that tried, I've never seen it actually work. What I've always seen happen is, they'll ask if X can be worked into the schedule, the devs will say no, it can't. Then the next day, they'll ask if X can be worked into the schedule (usually phrased just a little bit differently than before), and the devs will say no, it can't. Then a week later, they'll ask if X can be worked into the schedule. Then, when the devs say no, it can't, they accuse the devs of pushing back on everything, so the devs finally roll their eyes and agree to X (knowing that it's impossible to deliver because it's not even defined, but who cares because nothing ever happens when you inevitably miss the dates anyway). Then the next day, they ask if Y can be worked into the schedule...

cfmcdonald 7y ago
It can work. There does need to be mutual trust between product leadership and engineering. e.g. in the case you described, the engineers need to be able to communicate without fear that X1 and X2 are basically the same engineering work as X, and still can't be accommodated, and the other side needs to trust that they are not just being lazy.
MaulingMonkey 7y ago
"No" can be interpreted as pure obstinence. "We can do X... I suspect we'll need at least N weeks after we have a proper scope/spec/X/Y/Z from you, though, so if you want it done by $(MILESTONE) we need it by $(MILESTONE-N) at the absolute latest, or more preferrably by $(PREVIOUS_PLANNING_MEETING) so we have some wiggle room. No, that's not a spec. Yes, you need to participate in defining the scope of this thing - otherwise it'll take even longer when we're forced to rework completed things to work how you actually wanted them, and longer still when we work on things we thought you'd find important but don't care about. When can you meet so we can get this properly defined and fleshed out? We need a meeting anyways to discuss what other things you want that we're going to have to cut or defer to fit this into the schedule as well." If they work with you to cut/defer other things they've asked for and actually get you a scope/spec/X/Y/Z on-time, then good! You've successfully responded to a change in their priorities. If they suddenly lose interest when they might have to do some work... you've probably deflected some high work low value ask. Also good! If they put in the work but can't get you scope/spec/X/Y/Z in time... well, hey, that's not on you. You need enough time to get these things done. They might still want 3 women to make a baby in 1 month... but they might believe you when you say that's not possible if you at least look like you're trying to work with them on fitting X into the schedule.
shkkmo 7y ago
Well, I've successfully used that strategy to deal with hard external deadlines. You can't just say "no, can't do it", because in all honesty, you don't know. What you can say is "based on our current estimates and priorities, it will not be possible." If they insist it is needed then they need to increase it's priority until it fits within the amount of estated work that can be done before X dates. I think the underlying problem you are facing is viewing a set of tasks as a schedule to be set rather than a prioritized list of tasks with estimated completion dates.

cfmcdonald 7y ago

It can work. There does need to be mutual trust between product leadership and engineering. e.g. in the case you described, the engineers need to be able to communicate without fear that X1 and X2 are basically the same engineering work as X, and still can't be accommodated, and the other side needs to trust that they are not just being lazy.

MaulingMonkey 7y ago

"No" can be interpreted as pure obstinence. "We can do X... I suspect we'll need at least N weeks after we have a proper scope/spec/X/Y/Z from you, though, so if you want it done by $(MILESTONE) we need it by $(MILESTONE-N) at the absolute latest, or more preferrably by $(PREVIOUS_PLANNING_MEETING) so we have some wiggle room. No, that's not a spec. Yes, you need to participate in defining the scope of this thing - otherwise it'll take even longer when we're forced to rework completed things to work how you actually wanted them, and longer still when we work on things we thought you'd find important but don't care about. When can you meet so we can get this properly defined and fleshed out? We need a meeting anyways to discuss what other things you want that we're going to have to cut or defer to fit this into the schedule as well." If they work with you to cut/defer other things they've asked for and actually get you a scope/spec/X/Y/Z on-time, then good! You've successfully responded to a change in their priorities. If they suddenly lose interest when they might have to do some work... you've probably deflected some high work low value ask. Also good! If they put in the work but can't get you scope/spec/X/Y/Z in time... well, hey, that's not on you. You need enough time to get these things done. They might still want 3 women to make a baby in 1 month... but they might believe you when you say that's not possible if you at least look like you're trying to work with them on fitting X into the schedule.

shkkmo 7y ago

Well, I've successfully used that strategy to deal with hard external deadlines. You can't just say "no, can't do it", because in all honesty, you don't know. What you can say is "based on our current estimates and priorities, it will not be possible." If they insist it is needed then they need to increase it's priority until it fits within the amount of estated work that can be done before X dates. I think the underlying problem you are facing is viewing a set of tasks as a schedule to be set rather than a prioritized list of tasks with estimated completion dates.