Summary:
- the difficulty of estimates
- software engineers often don't estimate correctly and may overcommit
- managers take estimates as exact time
- managers believe software engineers bloat the estimate and request task to finish in a shorter time (thereby overcommitting)
- to get better at estimation, compare your estimate with how long it really took
- how long is a working day? (16 hours, 8 hours, 4 ideal hours?)
- man days vs. calendar days
- the difficulty of communicating estimates
- when you see the estimate was wrong, communicate the updated estimate as soon as possible (don't wait until 2 weeks before the final delivery and then announce a 2 year delay)
- different people communicate differently - you may be able to explain you estimate to a fellow engineer in technical terms, but to a manager/customer you might have to find less technical explanation
- to build trust, try doing what you say you will do
- the difficulty of keeping your team happy
- protect the team from too much outside stress (but they must still understand there is a deadline to keep and a product to deliver)
- best case situation: team members are in the team because they want to be. In this case, even team members with missing prerequisite knowledge want to learn and therefore can be taught and will likely be happy to contribute even just a little bit
- worst case situation: team members are in the team because they have to be. In this case, unqualified team members may not want to learn and may be very hard to motivate.
- take time to educate your team (maybe with one-on-one coding (or other) katas)
|
