Junior teams and project management

How does one manage a schedule when no one has any idea how long things should take.

//==================================================

This case recently came up: what if the tech director is too busy to supervise everyone and the programmers are all too busy to report on their progress such that missed deadlines are reported properly?

This is an emergency situation and is guaranteed to release the product late. However, there are multiple strategies that a producer can do to mitigate the disaster... especially if the producer has little or no domain knowledge.

Before I discuss those, let's talk about what information must be reported and gathered before anything can be done effectively.

Reporting and gathering:
You have already blown a sprint or two discovering that your crew is fairly junior and that the tech director is too busy to adequately help estimate. Plus, estimating the work of juniors is fraught with absurdity and inadequacy. You need to figure out what your velocity looks like and what is impeding development. We have lots of techniques to come to increase your velocity, but right now measuring is important. 

The first question you should ask is can your juniors even perform the work. If your team consists of Javascript programmers and you are building a WebApp, then you may be in alright shape. However, you may be building embedded controllers: then you are in trouble. If you find yourself in the second situation, you must inform your management immediately that you will probably never finish the task. This is a situation where being hopeful that the JS programmers can learn the tech will NOT pay off. You should treat this situation with extreme prejudice and pessimism. People nearly always head into these situations believing that it will "all just work out" or that "with proper mgmt", that you should be able to 'project manage' this into success. This is a classic mgmt technique to make you feel inadequate if you can't properly manage people who are clearly not up to he task and you should not fall for the trap; you are a pro and your professional opinion should matter.

Now, having one qualified junior on a team where the rest are not still spells disaster. You cannot complete this task and neither can the team. You really need a modicum of skill. This is another evaluation that must be made with prejudice. Juniors always think that they are good according to the Dunning-Kruger effect. You really need outside help. This is where outside teams or hiring comes in. Talk to outside management or other groups to find out the availability of engineering talent. This often goes nowhere simply because labor will not be available. This can mean hiring temporary experts, bringing in people part time from other groups, 



Once you have settled that, you need to identify who has which skills on the team and how to have the team members share that knowledge with each other. 

Seek immediate instruction to raise the average ability of the team.


Techniques to reduce risk:
1) Resident expert brought in
2) Tasks are broken down into minutiae. The tasks must be absolutely clear for more junior people. Experienced people can deal with
3) Check in with production every 3 hours ... destructive
5) Hire consultant
6) Pair programming
7) Specialized training
8) Scrum and estimation training

Estimation itself
1)  All overages are due to bad estimation... when the programmer says only another hour or two, you should immediately treat this as a lost day.
2) All estimates should be doubled ... at least. 4x is a better track for the beginning until you better understand the ability of the programmers to estimate.

Reporting to mgmt
1)