BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Articles Agile Goal Setting

Agile Goal Setting

Bookmarks

Much has been written in agile literature about vision, mission, and goal setting, but few experts seem to agree on what it really means to set goals in an agile way. Dictionaries don’t agree with encyclopedias, and process frameworks don’t agree with leading consultants. Or the other way around. This article is my attempt at adding some fuel to the fire. I hereby suggest a slightly modified approach to agile goal setting.

Give People a Shared Goal

I sometimes use the terms goal, meaning, and purpose interchangeably. However, I have developed a personal preference for using the term "goal" only in the case of an extrinsic or autonomous purpose, and the term "meaning" only when talking about an intrinsic purpose. My (extrinsic) goal as a living being can change regularly, depending on whatever happens in my environment; but the (intrinsic) meaning of my life is rather static. (So far, the answer has always been 42.)

Management literature is virtually unanimous about the value of goal setting, though implementations of it are often quite terrible. Goals are necessary for expressing directives. But they also significantly help to improve morale among team members. That’s two for the price of one!

Leadership researchers found that among the strongest needs of teams were a vision from their leaders [Thomas 2000:57]. Defining a purpose for a team enables a manager to unite and motivate people [Stallard 2007:17], by giving them a shared and realizable dream [Thomas 2000:56-57]. And, perhaps most important, a goal gives a group of people an "awareness of their context" [Fox 1998]. (For the moment, let’s consider vision, mission, goal, objectives, and purpose as equivalents.)

The lack of an explicit team goal may result in stakeholders only thinking about their own individual goals. They will then tend to optimize their own jobs, at the expense of the whole team. [Lencioni 2002]

The message is clear: There should be a shared goal across a group. In the past, this has been called management by objectives (MBO)[1]. But MBO has earned itself a bad name among agile experts because many managers have been implementing it so badly throughout the years. What usually happens with goal setting is that top management defines an annual "shared" goal and hands out bonuses at the end of the year to people when this goal is achieved. Let me make it clear: This is not agile!

A shared objective (extrinsic purpose) should transcend any goals of individuals or (sub)teams within the group for which a stakeholder is responsible, and therefore the corporate goal should also transcend the goal of the CEO, and the team goal should transcend the goals of all stakeholders. It is, literally, a "higher purpose" that is assigned to a whole group, intending it both as a directive and as a way to improve employee satisfaction.

The shared goal is not the same as the goal of the Product Owner (who is just a stakeholder); it is not the same as the goal of the project manager (who is just a stakeholder); it is not the same as the goal of the shareholder (who is just a stakeholder); and it is not the same as the goal of the manager himself (who is... well, I’m sure you get my point). Elevating any of these stakeholders’ goals to the group level would lead to sub optimization and dysfunctional measurements.

So... how should we do this agile goal setting thing?

Checklist for Agile Goals

Should you define just one goal, or can you have multiple goals? I would suggest that, in theory, having one goal is best. But theory often takes a lot of practice, so you might end up with a couple of goals extra.

When you’ve defined a set of goals, you could run each of them against the following ridiculously long checklist. I created it by combining various sources, including the famous S.M.A.R.T. criteria[2] (that I disagree with), and various wisdom tiles from my grandmother’s bathroom:

  • Is the goal specific and understandable enough so that people know what you mean?
  • Is the goal simple and concise enough so that it fits on a small card or sticky note?
  • Is the goal manageable and measurable so that success can be determined?
  • Is the goal memorable and reproducible so that people can easily communicate it to others?
  • Is the goal attainable and realistic so that people have a chance of actually achieving it?
  • Is the goal ambitious and stimulating enough so that it isn’t (too) easy to achieve?
  • Is the goal actionable and assignable so that it can be turned into specific actions?
  • Is the goal agreed-upon and committable so that people actually feel responsibility for it?
  • Is the goal relevant and useful enough for people so that they really care about it?
  • Is the goal time-bound and time-specific so that people know when to do it?
  • Is the goal tangible and real so that people can see the effects of achieving it?
  • Is the goal excitable and igniting so that it motivates people to do their best?
  • Is the goal inspiring and visionary so that it helps people to see a bigger picture?
  • Is the goal value-based and fundamental so that it builds on top of company values, team values, or personal values?
  • Is the goal revisitable and assessable so that you can reassess its applicability later?

A crucial difference between old-style Management by Objectives (MBO), and new-style Agile Goal Setting (can we call it AGS?) is that the criteria for goals must depend on the context, and are allowed to be changed regularly. For example: It is too simplistic to suggest that all goals should be SMART (specific, measurable, attainable, relevant, and time-bound). If your goal is to enjoy a vacation in Norway, how are you going to measure that? Will you track the number of thrilling experiences, or the average number of laughs per day? Does it matter for the decisions that you need to make now? And if your goal is to beat your competitors next year, are you going to measure this by revenue, profits, market share, employees, or customers? And does that really matter for inspiring people right now?

A goal that satisfies all previously listed criteria is impossible to define. You will simply have to pick a few criteria that you find important to your current situation. Some goals must be simple, while others must be actionable. Some should be measurable, while others need to be inspiring. What matters is that goals help people with the decisions they need to make right now.

There are also a few things that you should stay away from when you’re setting goals. Susan M. Heathfield described five possible dangers[3]:

  • Goals should not be created to intimidate people and to threaten them with loss of their jobs if they’re unable to achieve them;
  • Goals should not be defined merely to impress stakeholders or people watching the organization from the sideline;
  • Goals should not favor short-term wins over long-term losses;
  • Goals should not distract people from a desired outcome by focusing only on an action plan;
  • And you should aim not to have too many goals. Which sounds like a fine goal to me.

But by far, the biggest danger with goals is when managers connect them to rewards. The consequences of extrinsic motivation are more often bad than good. You should not introduce unpredictable non-linear dynamics when trying to set a course for a team. Always connect goals to people’s intrinsic desires. Enjoying your vacation is the reward. The reward is not some financial bonus connected to a certain number of laughs per day.

Examples

Here is an interesting example of a goal:

Google’s mission is to organize the world’s information and make it universally accessible and useful.[4]

Google’s mission statement is understandable, concise, memorable, ambitious, actionable, useful, plain, tangible, excitable, and inspiring. It seems to fulfill about half of the criteria for goals, which is a good score. And it allows for quick decisions. Sure, it doesn’t answer all questions, and it’s not supposed to. But it gives people a direction, so they can answer their own questions in many cases.

Another example is this one:

At the end of the year we will release a product that will change the way people do business in our industry.

This goal is simple, inspiring, memorable, ambitious, time-bound, tangible and fundamental. It might not be the goal of the customer, or the goal of the shareholders, or the goal of the managers. This goal appeals to a higher purpose, which means it also links to people’s intrinsic desires. Many people want to be part of something revolutionary.

Conclusion

To summarize how agile goal setting is different from old-style goal setting,

  • An agile goal is a "higher purpose," which transcends the goals of all stakeholders. It is a goal for the entire living system, not a goal just for the Product Owner, or the manager, or the CEO, or the shareholders;
  • Agile goals are not required to conform to a whole range of criteria, like specific, measurable, etc. A goal depends on its context. Sometimes it should be inspiring, sometimes it should be measurable;
  • An agile goal should not be connected to rewards or incentives. Extrinsic motivation distorts the system and causes non-linear consequences, which often defeat the purpose of the goal itself. Instead a goal should address people’s intrinsic desires;

And, don’t forget, goals are allowed to change more than once per year. They are not created to please stakeholders, but to give teams a sense of direction. And that direction can change from sprint to sprint.

This article is an adaptation from a text out of the book "Management 3.0: Leading Agile Developers, Developing Agile Leaders," by Jurgen Appelo. The book will be published by Addison-Wesley, in Mike Cohn’s Signature Series, and will be available in book stores near the end of 2010.

http://management30.com

http://mikecohnsignatureseries.com

References

Fox, John. "Employee Empowerment: An Apprentice Model" 22 June 1998

Lencioni, Patrick. The Five Dysfunctions of a Team. San Francisco: Jossey-Bass, 2002.

Stallard, Michael L. Fired Up or Burned Out. Nashville: Thomas Nelson, 2007.

Thomas, Kenneth. Intrinsic Motivation at Work. San Francisco: Berrett-Koehler Publishers, 2000.


[1] http://en.wikipedia.org/wiki/Management_by_objectives

[2] http://en.wikipedia.org/wiki/SMART_criteria

[3] http://humanresources.about.com/cs/strategichr/a/aadark_goals.htm

[4] Taken from Google’s corporate website

Rate this Article

Adoption
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Example of goal

    by Fabrice AIMETTI,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    "First, I believe that this nation should commit itself to achieving the goal, before this decade is out, of landing a man on the moon and returning him safely to the earth." John F. Kennedy, May 25, 1961.

  • People are sarcastic

    by Andrej Ruckij,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    as i noticed from my real life experience people tend to be very sarcastic about such goals (some of them event treat it as corporate stuff)
    when i say to my teams things like that i see smile on their faces. What i want to say is you need to make A LOT of effort to make them believe.

  • Re: People are sarcastic

    by Patrick Huizinga,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I believe that's one of the points Jurgen tries to make:
    "... top management defines an annual "shared" goal ... This is not agile!"
    "Always connect goals to people’s intrinsic desires."

  • a simpler set of checks for the checklist

    by Jason Little,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    give people too many options in a checklist and they'll spin. A great model for conveying goals is explained in the book Made to Stick. It talks about a simple approach for making ideas stick.

    I don't agree there is "an agile way" to set goals. Goal setting is goal setting regardless of the methodology you're using. Another great approach to goal setting is found in Implementing the Rockefeller Habits.

    The more simple the better.

  • Re: a simpler set of checks for the checklist

    by Mark Levison,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Jason - I think Jurgen is agreeing with you on the checklist point. I took him as trying to say that the laundry list checklists are nearly useless.

    As to "an Agile way" to set goals, I agree there is no such thing. However I would say that Agile goals differ from traditional goals as they're context dependant and need frequent updating.

    Cheers
    Mark Levison
    Agile Pain Relief Consulting

  • Re: a simpler set of checks for the checklist

    by Jason Little,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Thanks for pointing that out Mark. I hadn't mentioned that I wasn't referencing the checklist, just suggesting another approach to goal setting from the model in Made to Stick.

    I don't think Agile goals differ, goals without context and frequent re-visiting is just dumb. If an org needs 'agile' to understand setting goals they have deeper problems.

  • Deployment Automation

    by XebiaLabs XebiaLabs,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Jurgen, great advice. When introducing a new methodology to the team, it becomes even more important to be very clear about what you are hoping to achieve and how you will measure that achievement. One of the beneficial aspects of agile is that it incorporates so many tools that can help teams accomplish more in less time, such as deployment automation, which prevents programmers from getting bogged down by a lengthy to-do list. When programmers spend less time on tedious deployments, they are free to do the jobs they were hired to do, and accomplish more of the goals companies set to achieve. Are you seeing more IT departments using deployment automation to eliminate the busy work and achieve their goals?

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT