Pat O'Toole's Dos and Don'ts of Process Improvement: DONT Foul Up Size Tracking
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
#15: DON'T Foul Up Size Tracking
Do you remember when you first learned how to bowl? After getting past the between-the-legs-double-handed-heave-ho method, you graduated to flinging the ball one-handed, trying as best you could to hit the head pin. Sometimes you were close but many times your ball landed in one gutter or the other.
At some point in the "bowling maturity process," someone pointed out the dots on the approach and the arrows 12 feet down the alley. They claimed if you could learn to stand in the same spot and throw the ball over the same arrow, you would put the ball near the pocket more consistently. It sure didn't feel right – trying to knock down the pins by not looking at them, but darned if your scores didn't improve!
Watching the ball pass over the correct arrow (or not) also gave you an indication of the likely outcome. If you hit your mark, you had a reasonable chance of knocking down a lot of pins; if you missed, you had a lesser chance. The arrows, therefore, were not only targets – they were early warning indicators.
Size estimates should serve as a software project's arrows. When the team detects a change in size, they should interpret this as an early warning indicator that effort and schedule estimates are also in jeopardy. If the team uses "natural" size estimation parameters (see article #14), they are likely to recognize a change in size in a timely manner and be motivated to initiate corrective action aggressively.
For example, most project teams would recognize a threat to their current effort and schedule projections if, during design, they identified:
Ten new use cases;
The need to port the software to three additional platforms; and
The required algorithms were significantly more complex than originally thought.
Conversely, most would recognize a benefit to their current projections if they were to discover:
50% of the low level design and code could be reused from another project;
A code-generator could be used for all of the required reports; and
The system and user acceptance test suites already existed and were fully automated.
In bowling, once the ball is thrown it either hits the mark or it doesn't; the bowler cannot take corrective action once the ball leaves the hand (unlike curling where you have the guys with those wimpy brooms). However, a game of bowling has 10 frames – thereby providing a bowler many opportunities to make minor adjustments to their stance, target, and ball speed in response to changing lane conditions.
Similarly, a project's condition may change over time as new and better information becomes available. Just as most modern bowling alleys display the score sheet overhead for all to see, a project manager should find ways to keep the current size parameters in full view of the team. This will help the team determine if the current estimates missed the arrows and adjustments should be made. "Tracking size" should not be limited to tallying the results associated with a finished component; it should also include monitoring the size projections throughout the project life cycle and taking action as necessary.
By tracking the "natural" size estimation parameters over the project's life, the project manager can strike quickly when a change is warranted, thereby keeping the project out of the gutter and sparing the team splitting headaches. (Sorry!)
Copyright © Process Assessment, Consulting & Training 2002
For more information contact:
PACT
1316 Summit Oaks
Burnsville, MN 55337
Toll free: (877) 432-PACT (7228)
Cell: 612-387-PACT (7228)
PACT.otoole@att.net