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.

Purpose

Audience
Product Managers, Coaches

We understand why our team is valuable.

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!

That’s a shame, because nothing matter 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 Vision

The money for your team comes from somebody’s budget. As III used to say, the person who owns that budget is your team’s Gold Owner. They’re also the team’s Goal Donor. (Say them both out loud.) That’s because of the Golden Rule: they that has the gold, makes the rules.

Ultimately, the team needs to satisfy the Gold Owner, who, more prosaically, is typically called the team’s executive sponsor. And although the Gold Owner, as the Goal Donor, should be in charge of the team’s purpose, it’s not always so cut and dry.

Sometimes the vision strikes as a single, compelling idea. One person gets a bright idea, evangelizes it, and convinces the executive sponsor to pursue it. More often, the vision isn’t as clear. There are multiple stakeholders, each with their own unique idea of what the team should deliver, and each with their own influence over the sponsor.

Allies
Whole Team

The team needs a single, clear purpose. Somebody has to unify the visions into a purpose, communicate it, and promote it. They need to make sure the executive sponsor is enthusiastic about the purpose, the team understands it, influential stakeholders agree with it, and other stakeholders accept it. As the “Whole Team” practice discusses, people with the skill to so are called “product managers,” and at least one should be helping your team.

Like the children’s game of telephone, every step between the product manager and the original visionaries reduces their ability to maintain and promote the team’s purpose. If there’s one clear visionary, the best approach is for that visionary act as the product manager directly. This reduces the possibility of any telephone-game confusion. 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.

If the visionary isn’t available to participate fully, as often happens, someone else must act as product manager. The next best option is to choose someone the visionary and sponsor both know and trust: someone who regularly interacts with both and understands how they think.

Frequently, the team will have multiple stakeholders who influence the overall vision. It’s particularly common when developing tools for internal use. If this is the case, you need a product manager with the skill and political savvy to unify their visions.

Before you go too far down that road, however, question whether the ideas should be combined. Is each stakeholder’s vision significantly different? Can you execute them serially, one at a time? If so, you probably have multiple purposes, and working on one at a time—switching off periodically—might be a better approach.

Create a Draft Purpose

As you work with the sponsor and key stakeholders, refine their ideas into a document that describes your team’s overall purpose. The way you do so will depend on your company’s standards. Some companies like to use Key Performance Indicators (KPIs). Others will use a template of some sort. Whatever the format, you ultimately need 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.

  2. Mission. What will the team do to help achieve the vision? Describe what the team is expected to accomplish, but only at a high level. Describe what isn’t part of the mission, too. Leave plenty of room for the team to work out the details.

  3. Mission Tests. How will the team know they’re on the right track? Describe up to five high-level success indicators. Be concrete, include time frames, and make sure each has an unambiguous yes/no result. Avoid talking about specific features (such as “ship feature X on date Y”). Instead, talk about the business results stakeholders expect.

The draft purpose 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 mission tests are missed, that doesn’t mean the team is penalized. If they’re achieved, that doesn’t mean everybody stops working.

Remember the Agile Manifesto: “Customer collaboration over contract negotiation.” The draft purpose 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.

Chartering Purpose

With the draft purpose in hand, 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]. Your chartering session typically represents the launch of your new effort. For details about how to plan the session, see the “Planning Your Chartering Session” sidebar.

Chartering isn’t just for when work starts. It’s valuable for any team that 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] (Chapter 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 the “Seek Consent” section.) The vision is owned by the sponsor, so it’s not likely to change—remember the Golden Rule—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

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 mission tests, 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 Mission Tests

Finally, it’s time to revise the mission tests. This part can be the most contentious, because they’re the most concrete. Good mission tests have a “yes” or “no” answer. They have a concrete date and an explicit business goal. That can be a little scary.

Remind everyone that the mission tests 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 mission tests, it means you need more help or lower expectations. If you’ve exceeded the mission tests, it means you’re ready to raise your expectations and shoot higher. The mission tests will be iterated, just like everything else, and they’re not the only business metrics worth paying attention to.

To revise the tests, break up into small cross-functional groups again. Divide the mission tests among the groups. For each test, make sure each test can be used to check progress towards achieving the mission, that it has a concrete point at which it can be evaluated, 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 all 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 the “Context” practice), you can wait to bring your sponsor back until after discussing context.

Promote the Purpose

Allies
Team Room
Informative Workspace
Release Planning
Iteration Demo

Once the purpose is decided, 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 release planning sessions. Make sure they see demos, even if that means a private showing. Involve them in discussions with real customers. Solicit their feedback about progress and ask for their help in improving your plans. They can be invaluable for helping with company politics, too.

Involving your key stakeholders may be difficult, but make the effort. The less your team and key stakeholders communicate, the less your team will understand the product they’re building. While the purpose document is necessary and valuable, stakeholders’ passion and excitement communicates far more clearly. 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.

When I’m faced with inaccessible sponsors or stakeholders, I don’t assume that the problem is insurmountable. Because their participation is so valuable, I take extra steps to include them in any way I can. I don’t take organizational structures for granted, and I push to remove barriers.

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. Mission tests 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 focused on the purpose. 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 mission tests will need to be updated or replaced.

Questions

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, but you do need the most important stakeholders to agree. (Who’s “most important?” That’s for your sponsor and product managers to decide.) 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 visionary 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 visionaries. It isn’t due to lack of vision or consistency; instead, your sponsor sees a variety of opportunities and changes 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 visionary and stakeholders and try to identify that larger purpose.

Allies
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 visionary’s entrepreneurial spirit.

Your visionary 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 visionary what the team can reasonably accomplish.

Can individual releases each have their own purpose?

Absolutely! This can be a great way to iterate on the team’s purpose. Often, the vision will stay the same, but the mission and mission tests will change to meet the needs of each release. It’s a great way to prepare for the next round of release planning.

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.

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.