Dependencies cause a log jam - Pitched

Hopefully this one is self explanatory! If you've got people waiting on someone else finishing their work before they can start then you will have to get creative with your planning of resource. This becomes a serious source of waste when the problem occurs so often that you are always trying to juggle the order of work and can never seem to get on top of things. If your backlog constantly has a whole load of tickets marked as “blocked” then you are in a project manager's version of dependency hell.

The route cause is one of not understanding the shape of the work hitting the system. In a simple example, if your front end devs are always waiting for back end to finish stuff then its clear you need more back end developers. However, it is rarely that simple. Often you'll hear the phrase, “I have to wait for <insert “specialist” developer's name here> as they are the only one who works on that”. This is the same thing, but based on skill or technology. At this point you should be looking at the skillset that your team has. If your team is big enough then make sure the core technologies are understood by more than one person.

If you are suffering from this problem then I will bet your developers don't have individual learning plans! When was the last time you held a Knowledge Transfer (KT) session, or organised some internal training? Do you schedule some work as a pair programming so you can create the opportunity “for another developer to learn that area”?

I've said frequently that its important to estimate your work and to follow up with measuring what you do, the trick here is what to measure? Step back from the problem and have a look at it. If you already know what “areas” you have problems with, then your intuition will help you create a classification of work that should clearly identify the problem areas! Add this to your estimates and measurements and hopefully you'll have the proof that a course or lesson in <insert “specialist” developer's skill> will help alleviate the blocked items and reduce waste.

Estimation is inherently problematic - Pitched

There is a pretty good article which describes some of the inherent problems with estimates, and that a more statistical approach is needed. It still recognises that some form of estimate is needed and advocates using the t-shirt size approach to estimate features on a broad basis. It still misses one important point in that estimates should not just concentrate on duration! What about the complexity? Just saying something is a Medium (translates as 90% of time it will be done within 3 days!) excludes the fact that it might only be able to be done by the office genius!

Another thing that is missing from most people's estimates is a level of confidence. The accuracy of an estimate depends on when you ask. Ask a developer who has spent 10years working in the domain how long it will take to tweak an existing feature and you'll have a high level of confidence... ask him about an industry he doesn't know or to use an unfamiliar technology and you'll struggle to get anything except an “I dunno”.

This is where the “cone of uncertainty” can be used as a useful visual tool. I would suggest having it printed large and stuck on the wall. Every time you are asked for a time estimate you should point at the cone and say where you think you are on it. It is the developer's best defence to the statement “but you said it would take a week!”. After a while management will start to use estimates for what they are and not as deadlines.