Designing and Developing Cross-Cutting Features
Every developer has had to integrate with another system, API or component. Tis article provides strategies to handle the change and for he separating system boundaries.
The content has been bookmarked!
There was an error bookmarking this content! Please retry.

Posted by Jurgen Appelo on Oct 26, 2010
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.
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?
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:
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]:
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.
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.
To summarize how agile goal setting is different from old-style goal setting,
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://mikecohnsignatureseries.com
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
"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.
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.
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."
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.
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
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.
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?
Every developer has had to integrate with another system, API or component. Tis article provides strategies to handle the change and for he separating system boundaries.
Alex Russell talks about the shortcomings of the web platform and how it is evolving in order to adress them. He also explains about how browsers are improving and shares his vision on things to come.
Jeff Lindsay discusses creating distributed and concurrent systems using ZeroMQ – a lightweight message queue-, and gevent – a coroutine-based networking library.
Brian Ketelsen introduces Skynet, a platform for polyglot, distributed and composable services that communicate with each other over RPC/JSON.
Carin Meier tells the story of Alice discovering Monads, meeting three types of monads – Identity, Maybe, State-, and learning how to implement them in Clojure.
The need for agile, queryable, reliable, scalable storage without the pain of SQL schema migration is real. This article uses MongoDB to introduce NoSQL concepts to Java, PHP, and Python developers.
Jérôme Giraud introduces Wink Toolkit, an open source mobile JavaScript framework for HTML5 web or hybrid apps, showing widgets and interactions.
Greg Wilson and Christophe Coenraets demo Adobe Edge, a motion and interaction tool, CSS Regions and Shaders, and PhoneGap.
7 comments
Watch Thread Reply