Step 12 of 44: That won't do, let's take closer look at what's slowing things down.

As the schedule progresses you will notice:
1. Work that’s taking longer to do than anticipated.
2. Work that’s just not getting done.

In the case of work that’s taking longer than anticipated, try to figure out what causing the delay:

1. New work that wasn’t estimated. For example A and B were planned for but A, B, C, D is what is required. This is a typical and uncomfortable situation to be in. You can:
a. Replan with the new work – unpopular with management.
b. Work with the team to reduce scope.
c. Work with management to reduce scope.
d. Add more people – tricky.
e. Work more hours – unpopular with the team.

Typically the answer will lie in some combination of the above.

2. In the case where the work is not going as fast as anticipated. This could be due to:
a. Team members being pulled off to support existing customers – typical.
b. An inexperienced team member – even experienced developers haven’t seen everything.
c. Increased wait times for feedback – common and easy to forget to plan for.
d. Vacations.
e. Team member absence.

For the case of work that’s just not getting done consider:
1. Is the work still relevant? Can it be dropped?
2. Is the work in the wrong sequence?

Often you will find in software projects, that there are things that won’t get done because they are of lower priority. It’s a judgment call whether the work should be dropped from the schedule or added to the next cycle.

The important thing to remember is that you shouldn’t wait to address work that is not getting done or is delayed. The team will need to answer for it in one way or the other.


Stergios Spandonidis
Project Manager
sterg@lamda-alpha.com
www.lamda-alpha.com

11(a) of 44: Is It Really Done? Defining DONE.

Quite often you will notified that a feature or bug fix is "done". This is when it's important to have a standard definition of, DONE. For a developer it may be that the code compiles. For stakeholders it may be: the feature does exactly what I want it to. Here are some things to keep in mind for your definition of done:

1. Is there a unit test for the feature/bug fix?
2. Has there been a code review?
3. Has Quality Assurance tested the feature?
4. Has the feature been demonstrated to primary users?
5. Has the feature been documented?
6. Has there been a unit test created for the feature or bug fix?

There's likely more items you can add to this list. Whether you add these items to your schedule or checklist is up to you but you will need some way of way tracking these steps.

Good luck on your projects!

sterg@lamda-alpha.com
www.lamda-alpha.com