And yet there's often an unspoken assumption that the reason things weren't done on time is that developers are basically lazy.
The problem, in a nutshell, is that people don't believe that the developers have thought "creatively" enough about how to meet the deadline; on some level they're trying to give themselves an easy ride.
Here's one of the main reasons why I think that.
Developers come up with an estimate for a piece of work which they believe is realistic. Depending on their experience and personality they might be overly optimistic or pessimistic. But at the end of the day they are the technical expert whose specific responsibility it is to estimate, design and build software. (Of course, it should always be the person who's responsible for building a thing that should provide the estimate for it).
And still, if the manager or business stakeholder who hears the estimate believes it's too high, they will usually squeeze it, despite the fact that they're neither responsible nor qualified to specify estimates. This squeezing can be overt, or surreptitious. Often it will take the form of putting pressure on the developer ("But are you really sure that piece will take 10 days? It's just config isn't it?"), or, even worse, it will be done without the developer even being consulted, by a coven of project managers, pressured into finding "creative solutions" to meeting the dates the business had in mind, convincing themselves that things can be parallelised, done more efficiently, or done by "just copying" something done previously.
"Pete said a maximum of 4 people could work on this, but there's bound to be stuff we could get one of the Indian guys to work on. And this user story says 10 days - but it's pretty much what we did last time. If we said it was only 6 days we pretty much meet the deadline, as long as no issues come out of test."
The problem, in a nutshell, is that people don't believe that the developers have thought "creatively" enough about how to meet the deadline; on some level they're trying to give themselves an easy ride.
It doesn't seem to occur to them that they could simply go back to whoever demanded an earlier deadline and say "No I'm afraid we can't do that. I've worked it through with Pete, and we don't think it's achievable."
I got a bit of a thrill saying that. Let me try some more things that rarely get said by project managers:
- "I'd need to consult with Pete, it's not my remit to say whether or not we can add more people to that."
- "It'd be best if we didn't distract Pete right now to ask him for estimates on this. He's maxed out."
- "The team as a whole has had 5 distractions this sprint already, and that's our stipulated maximum, sorry."
- "No, Pete said 10 days. He might turn out to be wrong because it's just an estimate, but he's the most qualified person to provide that estimate and we have to go with that."
- "No we can't commit to that date. We don't know if it's achievable or not. But we can commit to delivering the stuff you said was highest value first, and involving you all the way."
- "We could try and achieve that, but the team's been flat out on this stuff for months, and are having a pretty tough time. We need to try and find a sustainable pace for everyone's sanity."
But those things pretty much never get said, especially the last one.
No comments:
Post a Comment