PMI-ACP Collaborative Team Environment: Vision, Working Agreements, Team Development and Coordination

A collaborative team environment is one where the team shares a goal it helped shape, agrees and owns how it works together, decides together, and keeps improving its own way of working, so that people deliver as one unit rather than as individuals passing work along. The PMI-ACP Examination Content Outline places this as Task 3 of the Mindset domain and lists seven enablers, which this lesson follows in order:

1. Establish team vision and working agreements: a shared why, and a shared how.
2. Form and develop a high performing team: team stages, and the structure that lets teams perform.
3. Use retrospective findings to improve the team: turn findings into owned experiments.
4. Use collaboration practices to break down silos: swarming, pairing, mobbing, feature teams, communities of practice.
5. Commit to the team's decisions even in disagreement: decide together, then act as one.
6. Evaluate the team's understanding of agile to tailor the agile approach: assess before changing the process.
7. Identify the key factors for an inter-team coordination approach: how much structure several teams need.

One idea runs through all seven: the agile practitioner is a facilitator and coach, not the team's manager. The team writes its agreements, makes its decisions and chooses its improvements; the practitioner creates the conditions, makes problems visible and brings issues back to the team. Answers that command, enforce, escalate early or decide on the team's behalf usually miss this. Psychological safety, transparency and conflict management are covered in their own lessons; this one focuses on how the team forms, agrees, decides and coordinates.

A team vision is a short shared statement of who the product is for, what need it meets and why it is worth building; it is useful only when the team can use it to make daily trade-offs. A vision handed down is a slogan. A vision the team helped build is a decision tool.

The elevator statement

A common format is the elevator statement (from Geoffrey Moore's Crossing the Chasm): For [target users] who [have this need], the [product] is a [category] that [key benefit]. Unlike [the current alternative], our product [key difference]. Its parts answer, in order, the questions a busy stakeholder would ask: who is it for, what problem does it solve, why does it matter and why not keep what they have. Other vision tools include the product box (designing the box the product would be sold in) and a vision workshop.

Co-create, then connect it to choices

Ownership comes from participation. Even when a product owner arrives with a draft, the team shapes it with them, typically in a vision workshop; any route in which the team only reads or reacts to the vision leaves it receiving rather than owning it. And a vision that members know by heart but do not use when choosing between options needs a facilitated conversation that links it to concrete goals and priorities, because more promotion of the same words changes nothing.

A missing shared vision often disguises itself as a scope or priority argument. If members keep defending choices on behalf of different customers, the real disagreement is about who the product serves and what success means; settle that first, because any prioritization technique applied on top of it only settles the symptom.

Working agreements are the ground rules a team sets for how it works together (core hours, how decisions are made, how interruptions are handled, when code is reviewed), and a team charter is the document that records the team's purpose, shared values, decision-making approach and those agreements. Both are created by the team, usually in its first days, with the agile practitioner facilitating.

Three rules for working agreements

• The people who follow them write them. Not the practitioner, the product owner or functional managers. Agreements a team writes are agreements it keeps.
• The team enforces them, not the facilitator. When members repeatedly break an agreement, the practitioner brings it back to the team, typically in the retrospective, so the team can recommit or revise it. Any response that moves enforcement to someone else, or changes the agreement without the team, takes ownership away from the people who made it.
• They are living documents. Revisit them when the team or its context changes: new members, a move to distributed work, a new way of working. The whole team, newcomers included, reworks the agreements together so that everyone owns the result; an agreement that one group settles for the other keeps its wording but loses its buy-in.

Teams move through predictable stages of development, described by Bruce Tuckman: forming, storming, norming, performing and, when the team disbands, adjourning. The leader's style should match the stage, moving from more direction to more delegation as the team matures. Agile and PMI-ACP study texts commonly pair the stages with the four situational leadership styles of Hersey and Blanchard, shown below.

Teams regress, and leaders can push them back

The stages are not one-way. When membership changes, the team is effectively a new team: expect it to drop back to an earlier stage (old debates return, newcomers stay quiet, throughput falls). The right response is to recognize the regression as a team-level change and move back towards a more active coaching style until the team re-forms its norms.

The reverse mistake matters just as much. A leader who directs a performing team (assigning tasks, approving every technical decision) suppresses its self-organization: members stop offering ideas and wait for instructions. The fix is to delegate decisions back to the team and step in only when it asks; anything that keeps the leader making the decisions, however well explained, leaves the cause in place.

High-performing agile teams are dedicated, stable, small and cross-functional, made up of generalizing specialists who share goals and organize their own work. Each trait removes a common cause of slow delivery.

• Dedicated. Members split across several projects lose time to context switching and are never fully available to any team. Full-time membership is one of the biggest single improvements available.
• Stable and long-lived. Trust, shared norms and a reliable velocity take time to build; reshuffling rosters every quarter restarts team development each time. Bring the work to stable teams rather than forming new teams around each project.
• Small. Agile guidance typically puts a team at around three to nine people. As a team grows, communication paths multiply: stand-ups drag, planning overruns and people lose track of each other's work. Split an oversized team into smaller cross-functional teams along product or feature areas, not along skill lines, which would only turn collaboration inside a team into hand-offs between teams. Adding people to a struggling team usually slows it further.
• Cross-functional. The team holds every skill it needs to deliver a usable increment without waiting on others.
• Generalizing specialists (sometimes called T-shaped people): deep in one skill, able to help in others. If, say, only one member can make database changes, others learning that skill and sharing the work removes a single point of failure; workarounds that still route that work through one person leave the bottleneck where it is.
• Shared goals and self-organization. The team succeeds or fails together. Individual targets and rankings push members to optimize their own work instead of the team's outcome, and a lead who assigns every task removes self-organization.

A retrospective improves a team only when its findings become a small number of owned, visible improvement experiments that the team checks at the next retrospective. Long lists of ideas that nobody owns produce the same complaints sprint after sprint.

From finding to experiment

1. Narrow down. Choose one or two actions the team has capacity for next iteration (dot voting is a quick, fair way to narrow many ideas; see below). Better follow-through comes from committing to fewer actions, not from changing how the retrospective itself is run.
2. Make each action owned and visible. Give it an owner and put it where the team sees it, often in the next sprint's backlog or on the team board.
3. Decide how you will know it worked, before you start. Record where things stand now (the baseline) and the result that would count as success (the success criterion); for example, the build broke on four of the last ten days, and the target is no more than one break a week. Without both, the next retrospective can only trade opinions.
4. Close the loop. Open the next retrospective by reviewing last time's experiments. If an agreed action did not happen at all, explore with the team why it stalled, then let the team decide whether to retry, resize or replace it; the lesson is in the team's own inquiry.

Improvement stays with the team. Genuine organizational impediments can be escalated, but the team chooses and runs its own experiments first rather than handing its improvement list to someone else to own.

Silos are boundaries where work is handed from one person, skill group or team to another and waits in a queue; collaboration practices remove those hand-offs by having people work on the same item together. Measures that make a hand-off more formal or more tightly scheduled make the queue more orderly but leave it in place.

Across team boundaries

• Cross-functional feature teams deliver whole customer features end to end. When separate front-end, back-end and database teams make every feature wait in queues between them, reorganizing into feature teams removes the queues; measures that coordinate, document or buffer the hand-offs only manage them.
• Communities of practice are voluntary groups of people who share a specialty (testing, UX, security) across teams. They keep specialist skills current once specialists are spread across feature teams.
• Joint retrospectives. When a recurring problem crosses a team boundary, such as integration defects bouncing between a product team and the platform group it depends on, retrospect together across that boundary so both sides see the whole hand-off. A fix designed by one side alone tends to move the problem rather than solve it.

Agile teams use quick participatory techniques so every member's view is visible before a decision, and then every member commits to the decision the team makes, including those who argued against it.

Using the techniques well

• Reveal simultaneously. Any vote seen before others commit to their own becomes an anchor, and hidden concerns go unspoken. Have everyone reveal together, on a count; changing the order of reveal does not remove anchoring.
• Low support means talk before deciding. When most of the team shows four or five fingers and a couple show one, ask those members to explain their concerns before the team decides. Moving on without hearing them discards information the team may need, whatever the size of the majority.

Disagree and commit

Once a decision has been fully discussed and made, everyone acts on it, including those who disagreed. The decision belongs to the team, not to its most senior or loudest member.

• If a member acts against a team decision, the practitioner first talks with them directly about supporting what the team decided. Seniority does not exempt anyone, and the disagreement is handled through the team's own process, not outside authority.
• Committing is not the same as never revisiting. When new evidence appears, such as a cost estimate or security finding showing the chosen approach breaks an agreed constraint, the person who found it brings it to the team so the team can revisit the decision together. Acting on the evidence alone, or passing the call to someone outside the team, works around it.
• A member who keeps raising the same objections without new information slows the team. Coach them privately on what committing means and on bringing genuinely new evidence back to the team; until such evidence appears, the decision stands for everyone.

Tailoring means adapting agile practices to the team and its context, and how far to tailor depends on how well the team understands why each practice exists. So the practitioner evaluates that understanding first, with the team: observe the team's events and run an agile self-assessment together. Delivery metrics and second-hand opinions show what the team does, not whether it understands why.

Shu-Ha-Ri

Shu-Ha-Ri describes mastery of practices; Tuckman's model describes how a group of people develops as a team. They are separate lenses and a team can be at different points on each.

A new team that wants to drop practices it does not yet understand (for example, skipping retrospectives because they feel like a waste of time) is at Shu. Removing practices now would remove them before the team learns what they are for. Keep them as defined, coach their purpose (the retrospective is how the team improves itself), and tailor once the team understands them.

An experienced team that can explain why each practice exists and has adapted before with measured results is at Ha or Ri. When it proposes a change, such as estimating by counting stories instead of using story points, back the proposal as a time-boxed trial and make sure the team inspects the effect afterwards. The practitioner's job is to support the experiment and keep it empirical, not to hold the team to the textbook.

The right amount of inter-team coordination depends mainly on how many teams contribute to the same product and how dependent their work is; more teams and tighter dependencies need more structure, and few loosely coupled teams need very little. Other factors include whether the teams share one product and backlog, how often their work must be integrated, and whether they are co-located or distributed. Administrative details, such as how progress is reported upward or which tools the teams use, do not.

Keep the scrum of scrums on purpose

A scrum of scrums exists to surface and resolve dependencies, integration risks and impediments between teams early, rather than discovering them at the sprint review. Common questions are what a team has done or will do that affects other teams and what is blocking it that another team could help with. When it drifts into each representative reading out what their team finished, blockers surface late and teams start skipping it; refocus it on cross-team dependencies, risks and impediments. Restructuring the meeting without restoring that purpose rarely helps.

Adding structure where little is needed has a cost too: recurring cross-team ceremonies for teams that rarely touch each other's work spend time without reducing real risk.