AoAD2 Practice: Context

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


Product Managers, Coaches

We know who and what we have to work with.

Which skills are available to your team? What resources do you have? Who are your stakeholders?

If you don’t understand your context, you risk being blindsided by people and expectations.

These are all part of your team’s context: the larger system they’re embedded within. Understanding your context is important for reducing risk. If you don’t understand your context, it’s easy to get blindsided by people or expectations you weren’t even aware existed.

Chartering Context


Your team’s chartering session, discussed in “Planning Your Chartering Session” on page XX, is a good time to discuss your team’s context. You can also discuss context in a separate session, if that’s more convenient, but it’s best if you solidify your team’s purpose first. That will help everyone understand what your team is meant to do.

During the context discussion, you’ll work with key stakeholders to consider three aspects of your team’s context: the skills available to your team, the team’s boundaries and interactions, and the resources committed to your team. Afterwards, you’ll review the results with your executive sponsor and get their commitment to supply anything that’s missing.1

1This agenda is based on [Larsen and Nies 2016] (ch. 7), with some changes. I’ve added the skills inventory, inspired in part by their Core Team activity, and I’ve removed their Prospective Analysis activity, because I’ve saved it for “Visual Planning” on page XX instead.

Available skills

Start by reviewing the skills available to your team. Ask each team member to introduce themselves and describe the skills and experience they bring to the team. They can also describe any relevant connections or permissions they have. As each person speaks, the facilitator should scribe their answers onto a flip chart. For remote teams, mark off an area of your virtual whiteboard to use as a virtual flip chart. Label it “Skills Inventory.”

“Permissions” includes electronic permissions, such as “I have the ability to view the production database,” legal permissions, such as “I have a corporate credit card and signing authority for equipment purchases,” and social permissions, such as “I’m allowed to talk to that one customer who’s so easily upset.”

For example, someone with an operations background might say, “I’m Ha Lam, and I’ve been working in ops for five years, two at this company. My speciality is infrastructure-as-code, and I have a lot of experience with Kubernetes. I have good connections with our platform team and permission to do production deployments.”

After all team members speak, make a separate list of people who contribute to your team, but aren’t fully dedicated to the team. This might include your product manager and coach. If they’re present, they can introduce themselves; otherwise, whoever knows them best should describe their skills. In addition to listing their skills, experience, and so forth, also include their availability and the best ways to communicate with them.


Once people’s skills have been noted, draw everyone’s attention to the team’s purpose. (You might have it on a flip chart or a shared document, or you can hand out copies.) Read a few salient points, then ask participants to take a moment to review the skills inventory. Are there any skills or permissions missing that the team needs? Ask participants to use simultaneous brainstorming (see “Work Simultaneously” on page XX) to create a sticky note, or its virtual equivalent, for each one.

While they’re doing that, prepare two more flip charts. Label one “Skills Needed” and the other “Permissions Needed.” Then ask everyone to post their sticky notes on each chart. Duplicates can be combined or discarded. When you’re done, take a moment to review the results, then set the charts aside temporarily.

Boundaries and interactions

In your next activity, you’ll create a context diagram that identifies all the different groups that your team needs to work with. Start by preparing a large surface for the diagram. (It’s best to prepare it in advance.) It needs to be big, so tape several flip charts together on a wall or table, or use a large whiteboard. Remote teams will use their virtual whiteboard as normal. Draw a circle in the center to represent your team.

When you’re ready, ask participants to use simultaneous brainstorming to create a sticky note for each stakeholder group that your team needs to interact with. Think very broadly: everyone who affects or is affected by your team’s work, either positively or negatively. That includes software teams that your team interacts with, including teams that own systems that your software will communicate with; other groups within the company, such as Marketing, Sales, and Operations; groups outside the company, such as your customers, competitors, and suppliers; and even groups further afield, such as government regulatory bodies.

When people run out of ideas, have them arrange the stickies in a large circle around the center team. Stickies that are similar can be combined. For example, you might group most software vendors into a single sticky labelled “software vendors,” but keep a separate sticky for your cloud infrastructure provider. Similarly, groups that have minimal impact on your team (and vice versa) can be discarded.

After the stickies are on the chart, ask participants to think of what they provide to each stakeholder group, and what they receive from each group. Have them draw an arrow for each interaction and label it with a brief description. If your chart is on paper, start with something temporary, like pencil or another sticky note, so you can make changes easily.

While participants work on the context diagram, prepare a few more flipcharts. Label them “Resources Needed” and “Communication to Provide” and put them next to the “Skills Needed” and “Permissions Needed” flip charts.

Agile teams avoid calling people “resources.” It’s dehumanizing. By resources, I mean things like time, money, goods, and services.

Once the context diagram is done, you’re ready to analyze it. Break into small, cross-functional groups and divide the stakeholder groups from the context diagram among them. For each stakeholder group, discuss how the team will interact with that group and brainstorm the skills, permissions, and resources the team needs in order to do so. Similarly, think about what sorts of communication that group needs from the team. Write each idea on a sticky note and post it on the appropriate flip chart—“Skills Needed,” “Permissions Needed,” “Resources Needed,” or “Communication to Provide.”

Finally, have the whole group review the “Communication to Provide” chart and decide how to combine and simplify your communications. Some communication can satisfy multiple groups. For example, you can use a mailing list to inform people about progress and roadmaps. Just create a rough plan for now; the team will refine it in the weeks to come.

For each type of communication, choose someone to be responsible for that communication. Choose someone else who will check in and help everyone remember to follow through. Once your team establishes a rhythm, these responsibilities can be more flexible, but in the beginning, it’s easy for things to fall through the cracks. It’s best to have clearly defined responsibilities.

If deciding how to follow through on communication takes more than a few minutes, set it aside until after the meeting. (Just don’t forget!) You don’t want to waste the other participants’ time.

Committed resources

After the previous two exercises, you should have three charts that describe what your team needs: “Skills Needed,” “Permissions Needed,” and “Resources Needed.” Have participants work simultaneously to sort the stickies on each chart into four categories: must have, should have, could have, and don’t need.2 As they work, if they think of new items, they can add them.

2This is called MoSCoW prioritization. The last category is usually “won’t have,” but I’ve called it “don’t need” to distinguish it from things you want, but can’t have.

Take a moment to review the results with everyone present, and make sure the team and stakeholders are in broad agreement about the items needed and how they’re categorized. It’s okay to have minor disagreements about the details, so don’t try for perfection.

Once that’s done, you can discard the “don’t need” stickies. Update the remaining stickies with a note describing:

  1. Who can provide each item;

  2. How committed they are to providing it; and

  3. How to get it, if it isn’t obvious.

The group can work on multiple stickies simultaneously.

Finally, ask everyone to take a step back and review all the needs. Is there anything important the team needs, but can’t easily get? If so, highlight each one. You’ll need to ask your sponsor to provide them. Prepare a few options for your sponsor to consider. For example, if you need database tuning skills, you could ask to engage with a consultancy, obtain training, or hire someone.

Sponsor commitment

Wrap up your discussion of context by inviting your sponsor back into the room, if they’re not already there. If you also chartered your team’s purpose, now is a good time to have the sponsor ratify those changes. Then turn your attention to your team’s needs.

Review the skills, permissions, and resources your team can’t get on their own, and ask the sponsor to commit to providing them. If they do, you’re done. Decide who on the team will be responsible for following up on those commitments, and who else will help that person remember, just as before.

If your sponsor can’t provide everything your team needs, have a frank conversation about tradeoffs.

If your sponsor can’t provide everything you need, take a closer look at the tradeoffs involved. How does the lack of each resource. skill, or permission affect your team’s ability to fulfill their purpose? Have a frank conversation with your sponsor about what they’re risking and what they need from your team.

As you have this conversation, remember that sponsors have to make difficult tradeoffs. They’re often stuck with a choice of two bad options. Sponsors own the team’s budget, yes, but their resources aren’t unlimited. Sometimes they have to make a tough choice between giving a team everything they ask for, and making a bet that the team will be resourceful enough to deliver even without it.

Some things you need will be essential, though, and your team won’t be able to achieve their purpose without them. If there are any essential resources that you can’t get, you’ll need to work with your sponsor to change, cancel, or postpone the team’s purpose.

Iterating Context

Team Room

After the chartering session is finished, keep a copy of the skills inventory, context diagram, and committed resources somewhere accessible to your team. You’ll refer back to them and update them as needed. Post the context diagram prominently in your team room.

Remember to take time to follow through on the communication plans you created during the “Boundaries and Interactions” activity. Be sure to follow through with your sponsor, too, regarding your committed resources.

After each of the first several times you communicate with a stakeholder group, take a moment to evaluate and improve the communication plan. Over time, your communication will settle into a comfortable groove.

Revisit the team’s context every three to six months to bring it up to date.

It’s a good idea to revisit the team’s context from time to time—every six months or so—to refresh everyone’s memory, bring the information back up to date, and revise communication plans. You don’t necessarily need to hold a full-blown meeting with stakeholders; it can just be a quick review in your team room. Do include your product manager, though, if they aren’t already part of your team.


What if we don’t have the resources we need, but our sponsor won’t listen?

That’s a tough situation to be in. If you know anybody with political savvy—such as a product manager, project manager, or coach—ask them to help convey the message. In the meantime, work on what you can, and keep reminding your sponsor and business stakeholders that you’re expected to do X, Y, and Z, but you’re only able to do X and Z because of the resources you’re missing.


Collecting the context information described here requires the participation of people who have a lot of knowledge about how your organization works. Be sure to include people with the perspective you need.


When your team understands their context and has the appropriate committed resources:

  • Your team has access to everything they need to accomplish their purpose.

  • Your team isn’t blindsided by previously-unknown stakeholder groups or expectations.

  • Communication with stakeholder groups is smooth and steady.

Alternatives and Experiments

Chartering context gives you a bunch of information about your team’s situation, but these three results are particularly important:

  1. Learning who your stakeholder groups are and what you need from each other.

  2. Deciding how you’re going to communicate with stakeholders.

  3. Adjusting your purpose and stakeholder expectations to match the skills, permissions, and resources available to your team.

The chartering agenda described here is just one way of achieving these results. You can use any approach.

Some organizations, rather than holding a chartering session, have project managers or business analysts interview stakeholders and create a set of documents. That can work, too, but don’t discount the value of having the team and stakeholders work directly together to learn each other’s perspectives. Having a chartering session in collaboration with your key stakeholders is great for creating connections and empathy in both directions. It’s much more visceral and memorable than a set of documents some people will never take the time to read.

You still have plenty of room for experimentation even if you keep the basic idea of a chartering session. Start with the practice as written, preferably with the help of a skilled facilitator, just to get a sense of how it’s supposed to work. Then experiment.

For example, a big two-day meeting can be pretty draining. What would happen if you spread it out over several smaller meetings? What about the specific activities? Can you think of ways of improving them, or replacing them? What if you do more pre-work up front? Or include different people?

If you’re in a large organization, try volunteering to conduct chartering sessions for other teams. They’re valuable for any team, not just Agile teams, and not just software teams, either. They don’t have to happen when a team first forms; if a team hasn’t been chartered before, they’re likely to benefit regardless of how long they’ve been working together. You’ll have plenty of opportunities to experiment, and there’s lots of things you could try. See what you can learn.

Further Reading

Liftoff, Second Edition: Start and Sustain Successful Agile Teams [Larsen and Nies 2016] has more information about chartering context and facilitation in general.

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.