AoAD2 Practice: Purpose

Book cover for “The Art of Agile Development, Second Edition.”

Second Edition cover

This is a pre-release excerpt of The Art of Agile Development, Second Edition, to be published by O’Reilly in 2021. Visit the Second Edition home page for information about the open development process, additional excerpts, and more.

Your feedback is appreciated! To share your thoughts, join the AoAD2 open review mailing list.

This excerpt is copyright 2007, 2020, 2021 by James Shore and Shane Warden. Although you are welcome to share this link, do not distribute or republish the content without James Shore’s express written permission.

Revised: July 13, 2021

Purpose

Audience
Product Managers, Coaches

We understand the reasons for our work.

Every team has a purpose: a reason for their existence, and expectations about their output. But, far too often, that purpose isn’t communicated to the team. Instead, the team is told a lot of details about what to do... but not why they’re going to do it, or how it helps the company achieve its goals.

The Purpose practice is about making sure everyone understands the big picture, not just the details.

Start With the Vision

Before a product has a team, someone in the company has an idea. Suppose it’s someone in the Wizzle-Frobitz company. (Not a real company.) “Hey!” they exclaim, knocking their coffee off their desk. “We could frobitz the wizzles so much better if we had software to sort the wizzles first!”

Okay, it’s usually not that dramatic. The point is, a team’s purpose starts out as an idea focused on results. Sell more hardware by bundling better software. Attract bigger customers by scaling more effectively. Sell more cloud services by providing machine learning technology. These are all real examples from teams that I’ve worked with.

Somewhere in the transition from idea to team, the compelling part—the vision of a better future—often gets lost. Details crowd it out. You have to staff a team with programmers, domain experts, and UX designers. You have to define features, plan releases, and report on progress. Hustle, people, hustle!

Nothing matters more than delivering the vision.

That’s a shame, because nothing matters more than delivering the vision. If the goal is to sell more cloud services through machine learning, then even the most amazing machine learning product is no good unless it’s part of the cloud platform. If you’re scaling so you can attract bigger customers, you’ve got to make sure the way you scale fits with those new customers’ needs. Conversely, if you figure out a way to attract those customers that barely involves scaling at all, does it really matter how you did it?

Identify the Purpose

The money for your team comes from somebody’s budget. They’re typically called the team’s executive sponsor. Although the sponsor technically has final say over the team’s purpose, it’s not always so cut and dry. They’re influenced by a variety of people, called key stakeholders, whose support is also necessary for your team to succeed.

Ally
Whole Team

Somebody has to unify all their ideas into a coherent purpose. They need to make sure the executive sponsor is enthusiastic about the purpose, the team understands it, key stakeholders agree with it, and other stakeholders accept it. As the “Whole Team” practice discusses, these skills are called “product management,” and at least one person who has those skills should be part of your team.

If there’s one clear visionary, the best approach is for that visionary act as the product manager directly. As long as the vision is both worthwhile and achievable, the visionary’s day-to-day involvement as product manager greatly improves the team’s chances of delivering an impressive product.

Ally
Real Customer Involvement

If the visionary isn’t available to participate fully, as often happens, someone else must act as product manager. Try to get someone who is as close to the key stakeholders as possible. Like the children’s game of telephone, every step between the product manager and the key stakeholders reduces their ability to maintain and promote the team’s purpose.

In some cases, your team will actually have multiple purposes. If key stakeholders’ visions are significantly different, and they all have to be fulfilled, you can create a purpose for each one. Work on one at a time, switching between them periodically.

Document the Purpose

The goal of your conversations is to create alignment about the team’s work.

Product managers, as you talk with the sponsor and key stakeholders, refine their ideas into a draft purpose document. The goal of your conversations is to create alignment about what the team should work on, why they’re working on it, and what success looks like. Your purpose document is a living document that reflects that joint understanding. You’ll revise it regularly.

Your draft purpose document is the first, rough take at documenting that conversation. It’s used to help drive the conversation forward. The format of the document depends on your company’s standards. Some companies like to use Key Performance Indicators (KPIs) or Objectives and Key Results (OKRs). Whatever the format, it ultimately needs to answer three questions:

  1. Vision. Why is the team’s work valuable? Describe how the world—or, at least, your small part of it—will be different when the team is successful. Clarify why this is important to the company and its customers. Think long-term and focus on value.

  2. Mission. In the next 3-6 months, how will the team help achieve the vision? Describe what the team is expected to accomplish, and what’s out of scope, but only at a high level. Leave plenty of room for the team to work out the details. Focus on outcomes and value before deliverables. It can be helpful to think of concrete deliverables first, but work backwards from there to start with the why, not the what.

  3. Indicators. How will the team know they’re on the right track? Describe up to five high-level success indicators. Be concrete and unambiguous. Avoid talking about specific features (such as “ship feature X on date Y”). Instead, talk about the business results stakeholders expect. Explain how the indicator shows the mission’s value is being achieved. If this is difficult, it may mean your mission isn’t focused on value.

The purpose document is a guide, not a set of hard and fast rules. It’s a way of helping people understand what the team is trying to achieve. As such, it represents people’s best understanding of the situation as it exists today. If the indicators are missed, that doesn’t mean the team is penalized. If they’re achieved, that doesn’t mean everybody stops working.

The purpose document is a vehicle for collaboration, not a contract.

Remember the Agile Manifesto: “Customer collaboration over contract negotiation.” The purpose document is a vehicle for collaboration, not a contract. As work progresses and everyone gains new insights about the market, the team’s purpose will change.

Charter the Purpose

After you’ve created a draft purpose document and validated it with key stakeholders, you’re ready to discuss it with the rest of the team. This will typically happen during a chartering session, also called a liftoff, after the book of the same name [Larsen and Nies 2016]. For details about how to plan the session, see “Planning Your Chartering Session” on page XX.

Your chartering session typically represents the launch of your new effort, but it’s also valuable for any team who wants to better understand the big picture, even if they’ve already been working for years. It’s also fine for a chartering session to precede the team’s actual start date by a few weeks.

Review the Draft Purpose

The chartering session starts with a discussion of the team’s purpose.1 Begin by presenting the draft vision. It’s best if the person who led the creation of the draft is the one to present it. Typically, this will be the team’s product manager.

1This agenda is based on [Larsen and Nies 2016] (ch. 5), with some small changes.

When you present the purpose, don’t just read it; explain the thinking behind it. The conversations that occurred. The trade-offs that were made. The compromises needed. This background will help everyone understand the “why” of the purpose better.

Consent to the Vision

After reviewing the purpose, conduct a consent vote on the vision. (See “Seek Consent” on page XX.) The vision is owned by the sponsor, so it’s not likely to change, but conducting a consent vote will expose any major objections. If changes are needed, the sponsor will have to approve them. If the sponsor isn’t available, the person who led the creation of the draft purpose can act as their proxy in the meantime.

Improve the Mission
The vision is owned by the sponsor, but the mission is owned by the team.

Although the vision is owned by the sponsor, the mission is owned by the team. They’re the ones responsible for making it happen, so they need to take ownership.

To help create that ownership, solicit feedback from team members about the mission. (Not the indicators, yet. Just the mission.) Ask for reactions and comments, then break into small groups, each with a cross-functional mix of team members and stakeholders. Each group will make improvements to the mission, which can range from minor wording fixes to major changes.

When time is up, each group presents their changes, their reasoning, and the rest of the group offers feedback. The facilitator then helps everyone consolidate their ideas back into a single mission. This might require another round of small-group sessions. Sometimes mixing up the groups can help.

Once the team has a revised mission, it’s time for another round of consent votes. Does the revised mission still meet the vision? Are the stakeholders satisfied that the mission will meet their needs? Is the team ready to take ownership and accountability for achieving the mission? As you conduct these votes, emphasize that the mission doesn’t need to be perfect. It will change over time. It just needs to be good enough for now.

Revise the Indicators

Finally, it’s time to revise the indicators. This part can be the most contentious, because they’re the most concrete. Good indicators are unambiguous. That can be a little scary.

Indicators are a guide, not a contract.

Remind everyone that the indicators are not a contract. They’re a guide. A way of checking if the team is on track or not. If your team isn’t on track to meet the indicators, it means you need more help or lower expectations. If you’ve exceeded the indicators, it means you’re ready to raise your expectations and shoot higher. The indicators will be iterated, just like everything else, and they’re not the only business metrics worth paying attention to.

To revise the indicators, break up into small cross-functional groups again. Divide the indicators among the groups. For each indicator, make sure each indicator can be used to check progress towards achieving the mission, that it has a clear “yes” or “no” answer, and that the team is able to make it happen. Review the changes in the larger group, check consent, and continue revising until all objections are resolved.

As the group works on each piece, you may discover new things that cause you to go back and revise earlier parts of the purpose. That’s okay, and expected. It’s an iterative process.

Commit to the Purpose

When you’re done, conduct a final consent vote. Does everyone present agree that the purpose is clear, valuable, and achievable? If so, it’s time to commit. Ask everyone present to record their commitment, either with a physical signature (if in-person) or electronically (if remote).

After the purpose is ratified, ask your sponsor to return, if they aren’t already present. Review the changes to the purpose, ask them to commit to supporting it, and get their signature.

If your chartering session includes both purpose and context (see “Context” on page XX), you can wait to bring your sponsor back until after discussing context.

Promote the Purpose

Allies
Informative Workspace
Visual Planning
Stakeholder Demos

Once the purpose is ratified, make it a constant touchstone. Use it to evangelize the team’s work to stakeholders. Refer to it when explaining your plans and priorities. Post a copy prominently in your team room, and refer back to it in planning sessions.

Be sure to continue to include your sponsor and other key stakeholders as work progresses. Invite them to visual planning sessions. Make sure they see demos, even if that means a private showing. Solicit their feedback about progress and ask for their help in improving your plans.

Make the effort to involve your key stakeholders.

Involving your key stakeholders may be difficult, but make the effort. Stakeholders’ passion and excitement communicates far more clearly than any document can. If the team interacts with their key stakeholders frequently, they’ll understand their purpose better, and they’ll come up with more ideas for increasing value and decreasing cost.

If the mountain won’t come to the team, then the team must go to the mountain. In other words, if stakeholders don’t want to come to the team’s planning sessions, then the team’s product managers need to bridge the gap. Share the plan, get feedback, and conduct private demos. This is less effective than involving stakeholders directly in planning, and you need to make sure your product managers are able to effectively communicate stakeholders’ perspectives back to the team. If you don’t have anyone who can do that, talk to your executive sponsor about the risks of building the wrong thing. Your team might be better off doing something else until the stakeholders are available.

Iterate the Purpose

The team’s purpose will change over time. Indicators will age out and the team will learn new things about their stakeholders, customers, and market. Eventually, you’ll need to update the purpose. It’s a living document.

Set a specific time to revisit and revise the purpose. Every three or six months is a good idea. When you do, create a new draft and conduct another chartering session. It’s likely to go a lot quicker than your first one. Typically, the vision won’t change much, the mission will need some revision, and the indicators will need to be updated or replaced.

Questions

Can the whole team participate in the draft purpose discussions?

Absolutely. It’s a great way for team members to gain insight into their stakeholders. Typically, some team members will be more interested than others. Discuss how to divide the work as a team, deferring to team members with more stakeholder experience.

Discussing our purpose has led to contentious arguments, and there’s no agreement in sight. Should we proceed anyway?

You don’t need every stakeholder to agree on your team’s purpose, but you do need your key stakeholders to agree. Even if conversations about the team’s purpose lead to a lot of arguments, you should still pursue a unified vision and purpose. Otherwise, you’re likely to release software that’s equally fragmented and unsatisfactory.

It may be possible to split the purpose into multiple pieces that the team can execute serially. If that doesn’t work, consider engaging the services of a professional facilitator to help mediate the discussion.

Our sponsor is constantly changing their mind. How can we get them to pick a direction and stick with it?

Rapidly shifting goals tend to be common with entrepreneurial sponsors. It isn’t due to lack of vision or consistency; instead, they see a variety of opportunities and change direction to match.

If the purpose is constantly changing, it may be a sign that what you think of as the team’s purpose is actually a temporary strategy in a larger, overarching purpose. Take your concerns to the sponsor and stakeholders and try to identify that larger purpose.

Ally
Adaptive Planning

If you succeed in discovering the larger purpose, adaptive release planning can help you keep up with your sponsor. Optimizing fluency may be a good fit as well. Its emphasis on learning and taking advantage of opportunities will fit in perfectly with your sponsor’s entrepreneurial spirit.

Your sponsor may continue to shift direction more quickly than you can implement their ideas. Your product managers should act as a buffer in this case, protecting the team from rapid shifts and explaining to your sponsor what the team can reasonably accomplish.

Prerequisites

Every team needs a purpose. It doesn’t have to be in the format described here, but every team needs to know what’s expected from them and why. Identifying that purpose—correctly—can be tricky. It takes stakeholder buy-in and people with strong product management skills.

If you don’t have someone with the needed skills, your company is at risk of wasting a lot of money on the wrong results. Ask your executive sponsor to help resolve that risk before continuing.

Indicators

When your team has a clear, compelling purpose that’s shared by the team and their stakeholders:

  • Prioritizing features is easy.

  • Product managers have no trouble justifying their prioritization decisions to stakeholders.

  • Developers contribute to planning discussions by suggesting ways to increase value while reducing cost.

  • Key stakeholders trust that the team is building what they need.

  • The organization supports the team’s efforts.

Alternatives and Experiments

Ultimately, this practice is about making sure everyone on the same page about the high-level what and why of the team’s work. The exact way you achieve that agreement isn’t important. You can use a chartering session and purpose document as I’ve described here, but you can also try other approaches.

One startup I worked with started out with a normal purpose document, but they found that their business changed too rapidly for that to be useful. Instead, they maintained a wall of sticky notes with business priorities, in several categories (“BizDev,” “Cost Control,” “Capacity,” and “Risk Reduction”), and assigned each team to one or two of the priorities. The board was a central part of the founders’ weekly strategy review.

Some companies are so small and tightly knit that the team’s purpose may seem obvious to everyone involved. Even these teams can benefit from discussing their purpose in some form. Putting a team’s purpose in concrete terms tends to clarify people’s thinking and provides a forum for new ideas.

Further Reading

Liftoff, Second Edition: Start and Sustain Successful Agile Teams [Larsen and Nies 2016] is a comprehensive guide to Agile chartering. It’s the basis for this book’s Purpose, Context, and Alignment practices. Its guidance about preparing and facilitating chartering sessions is particularly useful.

Impact Mapping [Adzic 2012] has a nice discussion of how to discover goals and create good indicators (he calls them “measurements”) in the “Creating an Impact Map” chapter.

XXX Consider Menlo Innovations books

XXX Bill Wake recommends: Competitive Engineering by Tom Gilb

Share your feedback about this excerpt on the AoAD2 mailing list! Sign up here.

For more excerpts from the book, or to get a copy of the Early Release, see the Second Edition home page.

If you liked this entry, check out my best writing and presentations, and consider subscribing to updates by email or RSS.