There is a lot of wisdom to it. But there are good ways to add resources and bad ways. Perhaps a team isn't getting help from another group. Perhaps there are some tasks that others could offload in a way that doesn't distract the team on the critical path, etc.
It's a good adage but it doesn't mean that you can never take steps to accelerate project delivery.
Then the team should communicate that to the other team themselves.
> Perhaps there are some tasks that others could offload in a way that doesn't distract the team on the critical path
That should be the decision of the team. If they need to cut down in order to stay on the critical path, then they should do so.
In my experience, good managers can be quite valuable negotiating with other organizations in the company and with getting needed resources. In fact, I'd say that's a pretty significant part of their job.
Not necessarily. I've seen/heard engineers who take great glee in pointing this out, but they don't understand the real dynamic. The managers have probably read the mythical man month too.
If as a manager you report a problem to your boss, you're likely to get "help", even if you already have a plan. Sometimes the least costly "help" is to accept additional "resources" and fence them off someplace they don't do damage so that the rest of your team can execute its real plan. Turning down help can damage your credibility/relationships which is what you depend on to be "allowed to be successful". It's emotions, not logic.
Or, if you really really want to, you can tell your boss they're an idiot and need to learn about Brook's law.
Some sure, but not the one's violating all of its conclusions...
>Sometimes the least costly "help" is to accept additional "resources" and fence them off someplace they don't do damage so that the rest of your team can execute its real plan. Turning down help can damage your credibility/relationships which is what you depend on to be "allowed to be successful". It's emotions, not logic. Or, if you really really want to, you can tell your boss they're an idiot and need to learn about Brook's law.
Well, this doesn't contradict what I wrote above though. Just finds for a more polite way to handle the situation and not let the extra "help" make a mess of things! But it's not like I suggested telling anyone directly they're an idiot!
"For a large one, 20% accuracy is science fiction stuff compared to the actual accuracy rates of big projects.." (exactly, I made that point as well) "..especially the kind with changing requirements, new issues discovered en route, etc (which is most of them)." If you are working in an environment where shipping something at some random point in the future is fine, well, good for you. The rest of us doesn't work in that world, which means that if you start a large project, lets say over the scale of 1 year, you cannot not talk about progress during that year. This is the point that I want to make.
In that sense: "5 hours spent on X" means, dishonesty aside, that 5 hours have been spent. This has some meaning, namely:
- a) if the estimate has been 1 hour, and this doesn't cancel out over time there is a systemic problem which puts the entire estimate to question. So someone should do something about that, and, whatever that something is - adding new or different resources, changing the goal, changing the timeline, whatever), it is usually not something that developers could do. (Not that I think 5 hours is a useful estimate size for any feature; 1 week, on the other hand, for a set of features would probably be useful)
- and b) if you figure out that team members are frequently spending more than 8 hours per day for whatever features (adjust 8 hours to whatever the team agrees upon) then the team is overloaded, the workload is not sustainable, and, again someone should do something about that...
Really, it shouldn't come as a surprise that - opposite to developers' lore - managers really do add value, especially when they are good managers.
That's an insane idea (it does lead to the conclusion that the optimal team is zero sized), and not an answer to the GP's claim that a good manager must know when more people will/won't help.
Lets take say Civilizations for example and say you need to build a spearman in 7 turns to not lose - but it would take 9 right now you already have production maximized without adding new buildings. Technically building a forge could speed it up to 6 turns but it takes 20 to build it. Even if it would help adding it right now would only make an intolerable delay even worse.
To get away from the geeky metaphor bottleneck and chokepoint management are a crucial part of making projects parallelizible across many developers and even then there are expenses to making them interoperate.
Unless you are grossly behind it is unlikely adding more people will help unless you are vastly overambitious and try to do something with one person that requires a team of thousands. In which case you have probably already failed too massively to help.
The output of n programmers working on a single task is O(n), but each one of those programmers must coordinate with O(n^2) colleagues. As more people are added, the coordination costs begin to to take over, and the project slips further and further behind. Thus, going from 2 to 4 programmers might be a great idea, while 20 to 40 or 200 to 400 may doom the project.
It's potentially a bit better than O(n log n).
If a hierarchy settles into a strong tree structure, it approaches O(n) connections people have to handle - one bidirectional connection between each person and their immediate superior.
To put it a different way, a hierarchy has potential to scale without limit, or to put it differently again, the larger a system of people, the more they will be forced by necessity into a strict tree structure for the majority of 1:1 communications.
It's much more advantageous to form cliques. Small highly connected groups that work on the same thing, possibly with some lose connections to other cliques. That's the model that most closely resembles towns, cities, and even tribes.
Talking to your team boss is good for high level guidance, but wont do anything when what you really need is the details on the workings of X a colleague knows.
Where did you got this idea from what I wrote (in fact, from my direct quote of Brooks' law)?
>That's an insane idea (it does lead to the conclusion that the optimal team is zero sized)
That adding people to a late project makes it later doesn't "lead to the conclusion" that "optimal team size is zero".
That's what's actually insane (one common form of insanity is following a logic to extremes without caring for nuance and limits).
Just that more people is more overhead (e.g. managerial and communication and agreement overhead), more people later equals more time to bring them up to speed and hand-hold them until they're ready plus the added overhead (related with more people) even when they're ready.
Brook's law doesn't say you should never put more people on a late project. It does say that you should not realistically expect the project to finish at (or sooner) than the initial estimate because of you adding more people.
In other words, for a late project with X persons working and M estimated months to completion. The real completion with X persons might be MR months, and with more persons X' it could get to MP. Adding extra programmers won't (per Brook's law and based on typical observations) ever help it reach M.
Sometimes adding more persons will make things worse, where MP > MR, other times they can help finish faster than the "actual" (not the initially estimated) finish date, so that MP < MR.
So it might still be advisable to add extra people -- it just wont (per Brooks law) get you to finish in M, and in some cases might even get you further from MR.
Like the idea of throwing good money after bad, if the problem isn't rooted in lack of resources (e.g., if the problem is actually rooted in bad communication, bad training, bad requirements, etc.) it's not going to help.
He didn't even get deeply into differences between people in that chapter. It's just very basic stuff that is on project management 101 since forever. Yet he had to write it down, and most people still don't seem to understand it.
It's more about communication and coordination overhead as teams get larger (and new additions need to be brought up to speed etc).
If we know anything in IT, it's Brook's law: "Adding manpower to a late software project makes it later".
So if the manager asks that for a late project, they are probably incompetent.
>If a good team of developers estimates the effort needed for anyone task with a 20% accuracy (which would be very good indeed), that can make a 9 month project being 2 months late, which might or might not be acceptable.
For a small (a few days) project, 20% accuracy doesn't make any difference. For a large one, 20% accuracy is science fiction stuff compared to the actual accuracy rates of big projects, especially the kind with changing requirements, new issues discovered en route, etc (which is most of them).
>If developer teams would be treated like the blackbox they apparently want to be treated as would mean that whoever is managing procuesses would fly blind just hoping for the best - but the organization as a whole needs to be understanding what is going on right now.
If the manager is not part of the team / actively involved (and thus he is inside the "black box") then any numbers they get is bogus, time tracking or not. Software is a qualitative process, not a quantitative. "5 hours spent on X" mean nothing at all without knowing what was done for X.