We recently went through mid-year reviews and I found myself repeating similar advice several times. Here it is: Be very clear about what your goal is and continuously reassess whether you are on track to get there.
To make this more concrete, consider a plane trip from Seattle, WA to to Austin, TX. If you look at a map, you can see that the heading to Austin is something like 135 degrees from Seattle and the flying time might be 7 hours. Does the pilot take off, set the compass to 135 degrees and set an alarm for 7 hours later? No. If he does, he could be in Little Rock by the time he wakes up. Why is that? Wind will push the plane around. If the pilot doesn't correct for the wind, he won't end up where he expected. Instead, the pilot constantly monitors his location and recalculates the necessary heading and speed to get to Austin on time.
There are two tendencies I've noticed among developers which can be rectified by following the example of the pilot. The first is the tendency to fail to monitor progress. The second is to focus on the trip, not the destination.
There are three aspects to the tasks most developers are asked to accomplish. They are called upon to implement some functionality by a specified time and in a quality fashion. When a developer decides up front what work needs to be done and then plows through it without reassessing along the way, he runs a high risk of failing to deliver. There are too many unknowns (and unkunks) for a plan created at the onset to be successful. Without reassessing on a regular basis, the developer won't recognize that he is behind and thus will not be able to correct. Like the pilot who lands in Little Rock instead of Austin, the developer who does not evaluate progress along the way will get to the end of the project and realize he still has a month of work to do. This is one of the secrets of Scrum. It forces reassessment on regular intervals. Another technique I have found to work is to break up your tasks over the project (or milestone) into granular work items. Each item should be a few days at most. Then, at least weekly, mark off progress against them. Keep track not of how much time you've spent so far but rather how much time is left and compare that to the amount of work left. When work remaining exceeds time left, it is time for a course correction. Because quality cannot be sacrificed, either move out the delivery date (if possible) or cut features.
A different problem is when a developer mistakes the assigned tasks for the goals. An example comes from the test development side of the world. Let's say the goal is to test a new video manipulation API. This Core Video or DirectX Video Acceleration or something. To test whether this works correctly, it is determined that it makes sense to write a simulator. The test developer starts writing this simulator. Along the way, he confuses his real goal (test the API) with his task (write the simulator). If, at the end of the milestone he has a great simulator but hasn't had time to actually use it to test the API, has he succeeded? In his mind, he has. Unfortunately, he is like the pilot who confused "Fly at 135 degrees for 7 hours" as his goal instead of "Land in Austin." What is the solution? Always keep your eyes on the real goal. If the simulator is taking too long to complete, consider alternatives. Is there a way to cut a feature and still test most of the API? Would it be better to cut the losses and approach from another direction?
Constant course correction can only work if the pilot knows his true goals. Having the wrong goal in mind or not recognizing when he has flown off course is disastrous for a pilot. Likewise, not noticing you are behind or that you aren't going to accomplish the real goals of your project is disastrous for a developer. Work with your manager (or program manager) to understand what the reason for your project is and always keep that in mind. This way, you'll be able to correct course before it becomes a problem. Don't mistake your tasks for your goal.
Note: I'm not a pilot. Some of what I say about planes is inevitably incorrect.
Good Advice and Great Explanation
ReplyDelete