41–50 of 73 posts
Very few people want estimates, they want commitments. They just frame the conversation around estimates to get people talking.
> At this point you might think, “Okay, just double your estimate”. Don't, this just leads to an arms race of deceit, and encourages more bargaining in the future.
It's not deceit, it's conversion of an estimate into a commitment.
> 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…
Scope = Time x Resources
and could add people to the project when scope and time were sticky (say a project had to be ready for a trade show, or stuff had to be at distribution by August to be in stores by Christmas).
[1] https://en.wikipedia.org/wiki/Project_management_triangle
> 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.
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…
What do you do when eyelashes get batted?
Seems like you'd get accused of "not being a team player" or some such bullshit if you say the truth, which is: "The PM set that deadline after consulting with us, and us telling the PM that 2 weeks wasn't feasible."
The instant that bargaining begins, it's not an estimate you're discussing anymore, it's a commitment. Very few people want estimates, they want commitments. They just frame the conversation around estimates to get people talking. > At this point you might think, “Okay, just double your estimate”. Don't, this just leads to an arms race of deceit, and encourages more bargaining in the future. It's not deceit, it's con…
So after a few years I started giving estimates that I was at least 90% likely to meet. And, as you say, I committed to them. In the minority of cases when I ended up on the bad tail of the bell curve, I worked extra to meet my commitment. Management was much happier.
In compensation for those occasional bursts of extra work, on average I had some free time. I used that time to learn stuff, or clean up code, or automate some of my work. That made my work easier, allowing me to shorten my estimates while still maintaining the 90% rule.
Another way to look at it is that there are three variables. Time, scope and velocity. If time and velocity are fixed variables then it follows that only scope can be changed to make a project fit into the time box.
Velocity is derived. It's scope/time.
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…
4 weeks later the feature is delivered to prod, nobody bats an eyelash. What do you do when eyelashes get batted? Seems like you'd get accused of "not being a team player" or some such bullshit if you say the truth, which is: "The PM set that deadline after consulting with us, and us telling the PM that 2 weeks wasn't feasible."
That's what middle management is for. The PM isn't your boss (I'm assuming). And they have a boss too who's job is to keep them in check, and the other middle managers are supposed to have relationships with each other. If there's any sort of middle management at the company yet things like that still either fall on the individual developer or dev team, that's a pretty bad environment (which then falls on the CTO, for having a tech management team that can't navigate the company, but in a different way that it would be on them than in a tiny company with devs reporting directly to the CTO.)
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.
Just as a good estimate requires some modelling, so does a good requirement. By July they might not need an overhaul of the whole billing system, but there might be a few small things that would have a huge impact that could be done. Maybe you can deliver 60% of the functionality in June and another 30% in August.
My experience is that this kind of thinking plays well with upper management, C-level kinds of people. That is, they make trade-offs on this level all the time and are glad to be engaged in this way. In fact, if everybody thought this way, the company wouldn't have any problems.
My experience also is that some middle-managers are highly offended by this approach for reasons I can't understand, other than they feel like they've lost control. It seems like a small price to pay for "getting things done" for the business, but they don't like to get bypassed.
In my experience with internal dev teams there are very rarely any real deadlines. They do exist; fixed product cycles, government mandates, but most of the time its made up arbitrary marks in a calendar, sprint deadlines (yes, these are deadlines), quarterly goal deadlines, yearly objectives etc. Deadlines are just lazy management, we feel we need to set deadlines to motivate people and drive delivery, the problem i…
I think there's also a third option - that the deadline energizes. I've been in teams, where the team as a whole set a completely arbitrary deadline for the functionality they'd like to have done by a given time - and that worked well to motivate team members to hit it. Granted, this is probably not the norm though, but it's not impossible.