51–60 of 73 posts
I've tried that before, many times, and found it similarly futile. They just start negotiating what the "scope" means until they've negotiated it back up to what they were originally asking for... because that's what (they think) they actually needed in the first place. Scope is just too vague to be used this precisely.
> Bargain scope, not time I've started applying this and it's amazing how well this works. Of course sometimes it's just not possible to reduce the scope any further, but the key point is that the stakeholders just want something, anything and as soon as possible at that. You give them that and suddenly there's much less pressure and you can focus on delivering the rest, or sometimes dropping it entirely because in h…
In my experience, management digs its heels in on scope and time anyway by bringing in more people. Usually lots of them, and the cheapest people they could get.
Earlier quoted context omitted.
Velocity is derived. It's scope/time.
That's the necessary velocity to complete in time. It might be very different from the actual current velocity of the team.
I remember a pretty similar dialogue that I had with a PM once, it went like this: PM: so what is your estimate for this feature? Me: 4 weeks to prod. PM: hmmm, that looks like a lot for a small task that is also very important for us, maybe you can do it in 2 weeks? Me: no, considering the amount of additional commitments that we have, I’m pretty sure this will be done in 4 weeks. PM: well, I’ll provisionally set th…
Sure, all of this is easy when working with good people and difficult when working with people who constantly lie both up and down the management hierarchy. Essential I feel this stuff only works when results are a by product of earned trust from management on delivery. If there isn’t that trust built up people are likely to try to appease whoever is going to give them a raise.
Yeah a lot of these approach only work if applied to the perfectly spherical manager and engineers.
I remember a pretty similar dialogue that I had with a PM once, it went like this: PM: so what is your estimate for this feature? Me: 4 weeks to prod. PM: hmmm, that looks like a lot for a small task that is also very important for us, maybe you can do it in 2 weeks? Me: no, considering the amount of additional commitments that we have, I’m pretty sure this will be done in 4 weeks. PM: well, I’ll provisionally set th…
(I mean, you might be able to limit the damage to the company, too, but that would take exposing and undermining the PM now, rather than once the damage shows up. This is difficult, for two reasons. First, upper management really wants to believe what the PM is telling them, because it sounds better. Second, it's a political battle, and most coders aren't equipped to fight those successfully. One reason not to bother is the "nobody bats an eyelash" - if everybody knew it was a BS estimate, so there wasn't any damage to the company because nobody relied on it.)
Sure, all of this is easy when working with good people and difficult when working with people who constantly lie both up and down the management hierarchy. Essential I feel this stuff only works when results are a by product of earned trust from management on delivery. If there isn’t that trust built up people are likely to try to appease whoever is going to give them a raise.
Yeah a lot of these approach only work if applied to the perfectly spherical manager and engineers.
I don't think it requires perfectly spherical humans in a frictionless office, but it does require everyone to have the same incentives in place.
When I wrote this, I worked on a pretty well aligned team with a very short power distance. If you're in a truly adversarial position, you probably need to take a different tact, or find a new role.
The trap isn't bargaining, the trap is allowing someone to shift the responsibility from demand to creation. What I mean is that the role of demand hasn't fully defined exactly what they want, it's nebulous, once the demand role accepts the responsibility for developing a timeline for a non-defined project it also accepts the responsibility to develop the requirements. I simply never accept shift in responsibility.
Having been on a nebula project with a timeline once or twice, you're right, this is definitely a trap to avoid.
I'd love to hear an example of how you've negotiated it.
It's been a long time since I wrote this, and I've come to appreciate that there are a lot of nuances, a lot of different teams, and a lot of different ways incentives are aligned in different environments.
I'd love to hear some illustrations of ways y'all have navigated these issues. What factors made it successful? When would it not have worked?