I’m dealing with this right now. A team that is downright arrogant about reducing their well-padded schedule, taking months to do a job that should take weeks, at most. Getting them to do anything is like pulling teeth, and accompanied with lots of arrogant lectures about how hard it is to estimate, how you can’t rush quality, and so on.
It’s mostly bullshit. This team has historical reasons for their bloated schedules, but at root, they’ve simply been coddled, and never forced to justify their behavior.
I’ve been on both sides of the table now. Developers like to gripe and moan about “unrealistic” schedules, but without aggressive pushback from management, a huge number of programmers will simply never ship.
That knife cuts both ways. I am fundamentally a clever lazy person. I'm always looking for ways to reduce the amount of accidental complexity I have to do, and reduce the number of trivial interruptions I get by documenting the situation a little better every time someone asks me about it, until the rate drops below my pain threshold.
If it weren't for schedules I'd have no defense at all for 'wasting time' on something that saves each of my teammates an hour of pain per week. (I've had a lot of shitty managers. Stuff like this shouldn't need a defense).
>"...taking months to do a job that should take weeks, at most..."
Well,this is basically lack of trust between you and your devs. Or lack of common understanding of priorities. I'm not sure if you're a project mgr or a client, but clearly some expectations are misaligned. Perhaps you don't see their barriers or they don't agree with your priorities
The existing contract doesn't work, so some mediation is due to close that distrust before any damage is done. After all it's the team that you currently consider yours.
”Well,this is basically lack of trust between you and your devs”
It’s pretty amusing how many definitive responses I’m getting from devs who are diagnosing my problem without any knowledge. It’s also telling how different they are.
Like I said, there are reasons, and I’m aware of them. I’m also fully aware of the technical barriers.
The devs are padding their schedule, and think they’re being clever about it. They are not. Some of it does boil down to trust (i.e. bad history with previous managers), but a lot of it is just that they don’t want to do the thing because it’s less fun than other things, and nobody has ever held them to account in the past. A sufficiently lazy developer
will find endless Legitimate Technical Justifications for not doing something he doesn’t want to do.
I’m not trying to generalize to all developers here, but I do know the people and problem I’m working with.
Are you saying there is trust between you and developers? Cause you surely don't trust them and the way you describe their communication sounds like they don't trust you.
Also, if they give you non-padded estimate, that is the one they will occasionally miss, will typical manager of your company force them to work weekends and evenings or otherwise punish them? Or will typical be ok with it and accept it as risk factor?
I am asking because the one manager that complained about paddings was the one that took pride in manipulating people into weekends - including by claiming they promised it. I do tight estimates when I know I can be late and generous when I assume it will be law or don't trust management.
Rather than second-guessing a total stranger on the internet - concerning a situation about which you know nothing - you would do well to question why you insist on assuming that everyone is as bad as the worst manager you’ve had.
To answer your question: no. I don’t do any of that. Also, this situation has nothing to do with aggressive schedules.
So then what the issue is? Is company loosing money on that project? Wish bigger effectivity? Estimate is just that - padded one makes it safer to plan. Padded one is also trust signal - people can be lazy while making tight estimates they will not make after. Estimate and when it is done are two different categories.
Sounds like a hiring problem. Start hiring some new devs and keep them separate so as to not contaminate them. As they come up to speed, let one of the other devs go. Wash, rinse and repeat.
Note: I'm a dev and I can tell you I very much dislike working with prima donnas.
Yes, but not the way I think he’s thinking (and maybe not the way you’re thinking either). If you were actually in a room with him and said, “ok, let’s just walk in there right now, fire these clowns and replace them with somebody better” he’d immediately hold up his hand and say, “but I can’t find anybody better…”. So yes, it’s probably a hiring problem but the problem is that he’s putting unreasonable expectations on the people he’s hiring.
Aggressive pushback usually ensures the other side will treat you as the enemy. Which sounds like what happened there - typical management hates developers and vice versa.
Ate they having bloted estimates or not shipping within estimates? Why there are such large features anyway? Why is manager not a ten member but instead someone who don't belong?
It’s mostly bullshit. This team has historical reasons for their bloated schedules, but at root, they’ve simply been coddled, and never forced to justify their behavior.
I’ve been on both sides of the table now. Developers like to gripe and moan about “unrealistic” schedules, but without aggressive pushback from management, a huge number of programmers will simply never ship.