Understanding Context

Gaining an understanding of context helps the core team members see how the team’s mission fits into the larger organization. Like purpose and alignment, an awareness of context enables the team to better make decisions by taking the whole system into account when needed. Understanding context also reinforces and extends the alignment agreements.

Facilitating an awareness of context includes three kinds of work:

  • You’ll help the team visualize team boundaries and interactions with stakeholders (greater whole system).

  • You’ll examine the organizational commitment to provide resources (nonhuman tangible and intangible parts of the team) for the ongoing work.

  • You’ll support the team in anticipating opportunities for risk and benefits and lead them through a prospective analysis (the system through time).

images/PACContextImage.png

Boundaries and Interactions

Boundaries mark the limits of an area and provide a dividing line between inside and out. Consider the Welcome To and Now Leaving signs at city limits. Like cities, teams have boundaries that define what’s included as part of the team’s work and what’s not.

The team’s boundaries define the relative responsibilities of the core team and others in the project community. They also define the limits of authority, including who makes what decisions. For example, the product owner, as part of the core team, might decide backlog priorities. Technical core team members might decide how to take on the work. Others might be responsible for providing information, help, and other resources for the project. And other stakeholder groups might market the product or provide customer support.

In agile teams, boundaries are permeable to varying degrees. Information and exchanges flow back and forth within and across boundaries. Where boundaries meet, you can expect turbulence. The purpose of defining team and work boundaries in chartering is to enable smooth flow. Without a clear understanding and alignment of boundaries, that flow can become agitated, dammed, or sluggish.

In establishing boundaries, your team and stakeholders should use the purpose as a guide. Participants should explore their common understanding of boundaries and consider the containers, differences, and exchanges of the work. The team’s exchanges can include expectations, communications, and flow of information.

Often, agile chartering is the first interaction between the core team and stakeholder groups. During chartering, everyone who attends takes a first pass at defining boundaries and future interactions. Participants discuss the information, resources, and support each group will need from the others. You’ll help them develop collaboration agreements that lead to successful product development.

Interactions Matter

images/aside-icons/tip.png

Defining interactions gives time for everyone to ask for the exchanges they need to do their work and realize the impact of certain exchanges.

For example, in the boundary and interactions discussion for a program that involved several teams, the HR representative brought up the annual performance-assessment process as a crucial interaction. The HR rep wanted coaches to complete a forty-two--page performance-assessment document as well as complete an annual assessment for each of the fifty team members across the program.

During the discussion, the HR rep finally realized the impact of the request. HR’s request would consume all the attention of one of the three coaches for a month at critical year end and create a unacceptable slowdown in production. The teams and the HR rep negotiated and created a new interaction agreement. Together they found a way to collect the performance data they wanted with much less impact on productivity.

The context diagram that follows illustrates a helpful way to capture both organizational boundaries and the interactions among the parts of the system. For information on how to facilitate the discussion of boundaries and interactions, see Activity 1: Establish Boundaries and Interactions.

images/boundary_diagram.png

Committed Resources

Every team needs nonhuman resources to do its work. These resources can include intangibles such as time, permissions, and access to people or information. Resources can also include familiar tangibles such as budget and funding, work space, supplies, equipment (hardware), and tools (software). To do its best work, every team needs to trust that it’ll have the resources it needs to move forward.

Your team benefits when team members understand the organizational commitment to their work. Team members want to know if early plans for providing resources match what the team expects to need. They want to know whom to go to in the future to secure resources needed but don’t yet have.

Commitment to providing resources comes from the project sponsors—the people who hold organizational authority to pledge the resources to achieve the mission. When sponsors participate in chartering, they benefit by hearing directly from the core team about the team’s needs, and the rest of the team learns the levels and nature of the sponsors’ and organizational commitment.

Examples of committed resources to consider include the following:

Time

Establish a definition of sustainable pace and use of slack. Determine the percentage of time each team member will be assigned to the team. (We recommend full-time team membership! In their books, Waltzing with Bears: Managing Risk on Software Projects [DL03], Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency [DeM01], and Peopleware: Productive Projects and Teams [DL99], Tom Demarco and Tim Lister repeatedly come back to the same theme: spreading an individual’s effort across teams reduces, rather than increases, productivity.)

Access

Determine the availability of team members and stakeholders for collaborative discussions, as well as attendance at product demonstrations, planning meetings, and retrospectives. Determine the level of access to stakeholders who have information or skills needed on an intermittent or ad hoc basis, access to administrative assistance, and access to timely decision-making.

Funding/budget

Maintain and clarify mutual understandings about revenue, cash flow, expenses, and contingencies. Any or all committed resources can have implications for budgeting.

Workspace

Determine the configuration of the work environment—ideally, sitting together in an open workspace—and the arrangements for virtual workspaces, when needed (for example, web, video, and other mobile collaboration tools; travel budgets; and so on).

Supplies/equipment

Ensure that the team has all of the tools and equipment it needs to do its work: sticky notes, index cards, and other meeting-facilitation aids; continuous-integration machines; automated build servers; test environments; pairing stations; kitchen items (for example, coffee pots, microwave, refrigerator).

Tools

Determine what security and domain-specific software are needed.

Team training

Determine the technical skills, agile process skills, collaboration skills, and/or product training team members may need.

Prospective Analysis

Prospective analysis in chartering is the first time a team looks ahead together. It’s a time to identify team members’ hidden and overt assumptions and consider the potential threats and hazards, and the opportunities and benefits, that may lie ahead. As Demarco and Lister tell us in Waltzing with Bears [DL03], “Risks and benefits always go hand in hand.” However, don’t expect that the team can identify every threat and opportunity before the project starts. Agile methods build in ways of highlighting and managing risks throughout development and delivery.

The product manager, core team, and stakeholders take a first look at the risks from their many perspectives. Depending on what the chartering group discovers during a prospective analysis, this activity can add to the team’s understanding of the work boundaries. The team might learn more about what resources are needed and discover new stakeholders and what interactions to expect with them. The team might also learn if the mission is viable as stated.

When working on a prospective analysis, help your core team look for materializing opportunities. Help it stay alert for changing assumptions. Help it scan for homegrown game-changers. You might encourage your team members each to think ahead all the time. However, an informal prospective analysis activity involves everyone peering into the future together. Raise the whole team’s awareness of assumptions about risks and risk indicators. What do the team members anticipate over the next two to three months? You’ll learn more as the work continues. Repeat the prospective analysis, always looking a few months ahead.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset