We like to think that being late on one task isn't so bad because early and late completions will average out over the course of an entire project. If you flip a coin 1,000 times, it will land on heads about 500 times and on tails about 500 times. If your project has 1,000 tasks, about 500 will finish early and about 500 will finish late, right? Wrong--and many project plans are sunk by this common misperception.
Suppose it's Saturday afternoon and you and your spouse have errands to run. You decide to do the errands separately, meet at your favorite restaurant at 6:00 p.m. for dinner, followed by a movie at 8:00. Getting to the movie on time will be tight, but if you both arrive for dinner at 6:00, you should make it. Your errands go smoothly and you arrive at the restaurant fifteen minutes early. Your early finish does not help your overall schedule because your spouse arrives right on time.
Naturally, the situation worsens if either of you arrive late. Even if you arrive fifteen minutes early but your spouse arrives late, it is your spouse's late arrival that affects the overall schedule. This scenario illustrates how early finishes do not necessarily balance out late completions. The problem arises because the late completion of a task results in a late start on all subsequent tasks that are dependent on the completion of the initial task. Late completions propagate down a schedule, but early finishes do not.
The traditional solution to this problem is to improve our estimation skills and then to strictly enforce all (or even most) deadlines. Unfortunately, we can never become perfect estimators; too many things can go wrong with a task or project. Too many subtle interactions exist among various factors that will affect the actual completion time. Similarly, if we insist that estimates must be met "or else," soon we'll pad estimates with huge safety margins.
Step back for a moment and question the assumptions that lead to thinking the solution is in improving estimation accuracy and then enforcing deadlines. The problem we are trying to solve is that a task that exceeds its estimated duration causes a late start for all tasks dependent upon it. Instead of opting for the traditional solution, what if we did the following:
1. Get Rid of all Task Deadlines.
Getting rid of deadlines is simple. After all, we only care about an overdue task if it causes the overall project to be late. Instead of associating a deadline or duration with each task, what if the developers simply know each task needs to be completed as quickly as possible? Subtle peer pressure and the fear of taking longer than your peers might serve as motivation for quicker completion. Deleting deadlines also eliminates the impact of Parkinson's Law on our projects: Work expands so as to fill the time available for its completion.
2. Eliminate Task Interdependencies.
Some modules must be coded before other modules, so these interdependent tasks can never be completely eliminated. But, with some creative thinking, many of these dependencies can be removed. The interdependencies that most need to be removed are those we introduce when drawing a project on a Gantt chart. These false dependencies are caused by resource leveling, or making sure that no person in our plan has too much to do during any period.
3. Do Not Assign People to Tasks.
Often, the only reason that Module B follows Module A on a Gantt chart is that we plan to have the same programmer work on each. This type of false dependency immediately goes away when we stop assigning developers to tasks. Instead of assigning work, we'll let developers sign up for their own tasks, but only when they're ready to start.
4. Now Can We Make the Movie on Time?
Let's apply this type of thinking to the example of you and your spouse running errands. You still have the same number of errands to run and you'd still like to see a movie at 8:00. In other words, your project deadline remains. However, instead of pre-assigning errands, each agrees to start with one errand and then call the other to coordinate what should be done next. This way, if you're running behind, your spouse can take on a time-consuming errand while you do a shorter one. The schedules can be more perfectly balanced due to adjustments made in real-time. This type of continuous planning prevents either of you arriving at the restaurant thirty minutes before the other.
The types of changes discussed here are commonly used in many Agile processes. These changes allow a team to produce more software faster than if a more prescriptive process were used. Keep in mind, there is more to Agile planning than the simple changes outlined in this article. But, if you make these simple changes to your plans, you're off to a good start.
