2 ms·
Working 10:00am - 6:30pm or 10:30am - 7pm is an 8.5 hour day. Lets say they have a 30min lunch break and stuff around at the arcade/gaming area for an hour. Tha
by sheepmullet 13y ago
Working 10:00am - 6:30pm or 10:30am - 7pm is an 8.5 hour day. Lets say they have a 30min lunch break and stuff around at the arcade/gaming area for an hour. That is still a solid 7 hours worth of work each day!
So 12 developers each working a solid 7 hours each day but unable to produce quality work within a reasonable time frame. That says one of a few things:
1) The team is working hard but you have a lot of crap code (aka technical debt) and so it takes a long time to make even simple changes.
2) The team has implemented more thorough processes. E.g. Previously they might have went straight from coding a fix to putting it into production but now they have proper QA and Testing phases. So now it looks to outsiders that they are "complacent" when they have really just improved processes.
I would never give a business person an estimate of anything less than a day.
3) Politics/dynamics between the dev team and the rest of the office have changed. For example if management had a serious go at the developers for a defect in production or business users have been passing the blame onto developers, or everyone got pay rises/bonuses but the devs, etc then it is likely they are operating in an extreme risk averse, document everything manner.
I know entire dev teams who have stopped being productive because business stopped listening to them.
4) Team politics. Are one or two of the developers/managers doing something that is really throwing the other developers out of joint?
5) The team is productive and business expects too much or is only looking at superficial indicators. For example you keep mentioning standard working hours as though working 8 hours is being lazy. The devs having fun at the arcade/gaming area. The rest of the company "grinding" etc. It almost looks like you care more about shared misery than results.
If you bring in a new developer and they are significantly more productive than the existing team then you could rule out 1&2&5.