Monthly Goals

Software teams should use a monthly goal system. On the 1st of each month, the team delivers the result from the previous month's work and immediately decides what to do for the next month. The managers consult the team to find what they prefer, consider the long-term goals of the group, and weigh in a variety of intangible factors like what's most exciting. The outcome is the monthly goal, a one-sentence theme for the next month's work. This is then published to the workers and to interested parties within the company, and work begins.

Why Does it Work?

This system works on several levels. First, it provides focus to the group. Because the goal is so simple, everyone on the team knows all the time how his/her work fits into the big picture. A good goal can be visualized, so everyone can imagine how their part will fit into the whole. When the work is done, the worker can point to the result being distributed and say, "I did that". To some degree, the worker means the whole result, not just his/her part. This feeling of personal ownership of the group's result is an important motivator.

Second, the monthly goal gets the group in the habit of meeting schedules. Individuals learn that there really is such a thing as a hard schedule date, and that if they promise a feature by that date they must deliver or they miss out on being part of the result. This teaches many valuable skills to the team members, like planning for mistake-correction time.

Third, monthly goals give a tangible and measurable result. The common practice of making goals is to say "we are 6% done with each of 20 tasks, therefore we are 6% done overall" is ineffective. The problem is that it's impossible to judge what 6% done really means. Or 10%, and particularly 90%. It's a cliche that when someone says a subtask is 90% done, usually that really means 50%. The only numbers that really mean anything are 0% and 100%, everything else is too hard to measure.

So our method is to instead say "we have 100% completed 3 of the 20 tasks". This is measurable, it's relatively easy to determine that those 3 features are indeed completely done. The end result can clearly demonstate the completeness of the features that were implemented, and management can see that they really are done.

Fourth, the method of picking the monthly goal right after finishing the previous one gives the team lots of flexibility. Projects that plan too rigidly for the future can't adjust to the actualities of changing corporate direction that exist in high-tech companies. The managers may have thought about possible monthly goals, but one isn't chosen until the last possible moment. This means that the team can change direction within 4 weeks without any loss of efficiency. The longer-term plan has to remain loose and somewhat unpredictable anyway, because no one can really predict accurately as much as 3 months ahead on a high-tech development schedule. There are just too many unknowns and plan changes. The monthly goal system works within that reality.

How Does One Do It?

There are several key aspects of the monthly goal method that we've fine-tuned over time to give the most benefits. The reasons were outlined above, here's the recipe:

Choosing the goal

• Prepare alternatives: managers should form a rough list ahead of time of possible goals, and should get any input from outside the group that they feel will help the goal choice. For instance, higher-managmeent or customer input should be sought during the previous month. That's so that this info will be ready and waiting when the moment comes to actually choose the goal.
• Last minute goal choice: choose the next month's goal the day of or the day after the delivery of the previous month's, preferably immediately after hearing feedback from the presentation of the previous month's result. Until that moment all the information needed to make the best next-month choice is usually not available. But the decision must be made quickly, otherwise it'll hold up the rest of the group. Therefore, the manager should be prepared to devote a significant number of hours to the goal-choice process immediately at the start of each month, during the optimal goal-choice window.
• Consult the team: a small meeting of the team to decide which of several possible goals is best might make sense. The manager makes the final decision, but the workers will have good ideas about it and will be interested in making their opinions known. The best goal comes from unanimous team agreement and excitement.

What's a good goal

• Concise and Thematic: keep the goal short. Very short. Shorter than you think. One sentence only, and a short sentence where possible. The goal will have to be communicated to a lot of people, both in the team and outside it, and you want them to remember it without having to consult the announcement. One 5 word phrase would be the best where possible.

  To make a goal this short one must make it thematic. Somehow the several features to be done that month must fit together in a theme, so that they're all parts of one more major "feature". This requires extra work by the goal designer, and may force rearrangements on the perceived best order of doing the tasks, but the benefits of having a goal everyone can understand and remember far outweigh the disadvantages.

• Tangible: the goal must be something that people can visualize, can imagine putting their hands on and messing around with. That means that there is a real advantage to picking a set of tasks that come together into one or two major new features that are apparent to the user of the product.
• Builds on previous goals: the result should be a demo of the product, with all the previous month's stuff plus the new features. This continuity shows everyone (most especially the team itself) a continuous progress from nothing at the beginning to the final product at the end.
• Is of a specified quality level: since all the features done at all each month are 100% complete, that means they are DONE. Typically goals will be to one of two standards: first-time or internal (alpha) and shippable (beta). The difference is not so much one of quality as of expectation of iteration: alpha-level features are expected to be reworked before becoming shippable. This is used for features that need some user feedback before becoming locked down.

  But even alpha-level features should be of runnable quality. They should be tested, and run without crashes. Beta features must have extra polish and need no more work whatsoever to be shipped. That "polish" is basically a matter of finishing up all the details that had to be left loose while the design was still changing, tightening all the screws for shipment.

• Balances workload: the goal must bring in components from each of the team members, so everyone feels involvement. Much of the skill in picking a goal is in finding a theme that includes the right amount of work from each team member, while also remaining thematic. It's ok for some team members to have less to do and to then help others. This is a team effort, it's not like Sally can sit back after finishing if Joe has a lot yet to do. Some might say that it's not efficient for people to chip in with each other's parts like that, but they're wrong. The focus on the goal and the team spirit that results are far more important than ideas of keeping one person plugging away efficiently on the code that only s/he knows.
• Conservative: the goal should be in two parts: the guaranteed part, which the team thinks it can finish by the 20th or so, and the optional part, which the team hopes to do some of but isn't promising to anyone. The optional part should be designed to add every-increasing impressiveness to the month's demo. Sometimes disaster will strike (especially early in the adoption of a hard-deadline system like this) and the team will barely finish the guaranteed part before month end. Other times it'll work out better and the team will have the pleasure of producing beyond what they've promised.
• Promised by the workers: each worker must commit to producing the parts of the goal s/he is responsible for. Note that this is not a matter of prediction, but one of promise. A worker should understand that. S/he is expected to come up with a feature set s/he is willing to deliver, at whatever personal cost. The manager's job is to keep the promises reasonable for naive workers who might overpromise and get into trouble later. The best promises have no personal cost and are finished exactly as planned without extraordinary measures, on the 20th, leaving time for optional work.

Distributing the goal

• Within the team: the goal should be published in an extended form within the group. The list of features needed to achieve the goal should be made clear, and everyone must understand their role in making the goal happen. Detailed lists are useful here, but the overall goal should stay in sight too. Part of the value is that the team will help judge whether the detailed lists are indeed sufficient to bring about the goal. Optional parts should be clearly listed as optional, so everyone knows what must be done and what would just be nice.
• Undercommit outside the team: the goal should be published in a minimal form, with none of the optional stuff listed at all. Like the individual team-member promises discussed above, this is not an estimate or a goal, but a promise. By publishing it to a wider audience, the team has its reputation on the line. It must deliver. Again, the manager must be very careful to make sure these promises can be met without extraordinary measures. Promising what you think you can have by the 20th works about right.
• Find an audience: try to show the month's result to a group of outside interested parties. Also, put the demo in a place where a much wider group of people can run it when they have time, with a message about what's new if it isn't obvious. This enables a lot more people in the company to be informed about what your group is doing, whenever it is convenient to them. This helps overall corporate planning, and it's enjoyable for your team that they're doing something good that's visible.

  Some sort of minimal audience is necessary, otherwise it won't be a motivator to the team but just busywork. At a minimum, the next boss up the chain can serve as the the audience each month. At best, some monthly demos will be shown to the entire management team or to the whole company.

Doing the work

• Initial setup: the most work for the manager occurs at the start of the month, interviewing people and designing an appropriate goal.
• Set weekly priorities: although one might feel the one-month goal is close enough, in fact that's far enough away that people feel they can take it easy at the beginning of the month (reading mail, doing whatever), only have to make up the work at the end. It's much easier on everyone if the work is done at reasonable efficiency over the whole month instead of in a rush at the end. The fix is to work with team members to set weekly goals so that the subgoal is much more directly in sight. This allows a one-week read-email-then-work cycle, which works out much better for the workers.
• Major checkup on the 20th: after the 3rd week the project should have reached its guaranteed deliverable. Usually some parts are done and others aren't. The manager must shift the team into help-others mode as needed to make sure the demo is brought together. In the monthly minicycle of product development, the last 10 days are the "ship it!" phase. It's "do whatever it takes" time. Some people will not be drawn into this, they can work on optional features or even start on things you think but aren't sure will be part of the next month's goals.

References

A. Cockburn, "Unraveling incremental development," Object Magazine, pp. 49-51, Jan 1995. 49-51. A pithy description of the advantages of incremental development.

G. Head, "Six-Sigma Software Using Cleanroom Software Engineering Techniques," HP Journal, Vol 45 No 3, June 1994. Has a small section on short-interval scheduling.