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.