Team Plays · teamsuccess.ioSkip to contentTeam Plays<br>These are plays I've run or been part of. Some work better than others. The point isn't the artefact you produce, it's the conversation the play forces.<br>Includes plays adapted from the Atlassian Team Playbook, Google re:Work, and Miro, along with established agile and management frameworks.
Manage risk<br>Risk RegisterDocument, assess, and track risks before they become blockers.<br>60 min<br>Brainstorm risks Each person silently lists every risk they can think of for the project.<br>Group and deduplicate Cluster similar risks together and remove duplicates.<br>Score likelihood and impact Rate each risk on a 1–3 scale for both dimensions.<br>Prioritise Focus on high-likelihood, high-impact risks first.<br>Assign owners Every risk on the register has one person responsible for monitoring it.<br>Define mitigation actions For each priority risk, agree on the steps that reduce likelihood or impact.<br>Review regularly Check the register at every sprint review or project milestone.
Dependency MappingMake cross-team and cross-system dependencies visible before they delay delivery.<br>60–90 min<br>List work items Capture everything the team needs to deliver in the planning horizon.<br>Identify dependencies For each item, ask: what do we need from another team or system before we can start?<br>Map the connections Draw links between dependent items on a shared board.<br>Estimate duration for each item Add a rough time estimate to every item. Without durations you cannot find a critical path, only a longest chain.<br>Find the critical path Identify the path with the longest total duration across the network. This determines your earliest possible finish date. It is not the same as the chain with the most dependencies.<br>Flag risks Highlight dependencies with unclear owners, missing agreements, or tight timing.<br>Negotiate handoffs Sync with dependent teams to confirm timing and agree on interfaces.<br>Track throughout delivery Review the dependency map at each planning cycle and update it as things change.
Pre-mortemImagine the project has already failed. Prevent it.<br>60 min<br>Prep Create a board with columns for threats and strengths.<br>Frame the prompt Ask the team to imagine the project has gone wrong, or gone well.<br>Brainstorm 10 minutes of silent individual sticky note writing.<br>Group Cluster similar ideas together.<br>Vote on threats Three votes each to prioritise the biggest risks.<br>Vote on strengths Three votes each to prioritise the most important success factors.<br>Discuss 10 minutes on each top item: develop mitigation strategies.<br>Assign actions Every action item gets an owner and a deadline.
Incident Post-mortemLearn from what went wrong without assigning blame. Then fix the system.<br>60–90 min<br>Prep the timeline Before the session, reconstruct a factual timeline of the incident from logs and notes.<br>Set the blameless norm Open with a reminder: the goal is to understand the system failure, not who failed.<br>Walk the timeline Review the sequence of events together and fill in any gaps.<br>Identify contributing factors Use Five Whys to find underlying and contributing causes: technical, process, and communication failures. Complex incidents rarely have a single root.<br>Celebrate what worked Note every decision that contained or shortened the incident.<br>Define action items For each contributing cause, agree on a concrete fix with an owner and a deadline.<br>Share the report Share internally with appropriate access. Redact personal, customer, security, and confidential information before circulating more widely.
Escalation PolicyDefine how and when issues get escalated so decisions don't stall.<br>45 min<br>List decision types Identify the categories of decisions the team regularly encounters.<br>Define thresholds For each type, agree on what conditions trigger escalation.<br>Map escalation paths Document who to contact at each level: team lead, manager, exec.<br>Set response time expectations Agree on how quickly each level should respond.<br>Document and share Write it up, put it somewhere accessible, and walk new team members through it.<br>Test it Run a dry run with a hypothetical scenario to confirm everyone knows the process.
Incident Response TabletopRehearse a breach or major incident response before you need one.<br>90–120 min<br>Choose the scenario Realistic and relevant: ransomware, data exfiltration, insider misuse, a critical vendor breach, a lost laptop with production access. One scenario per session.<br>Assemble the response team Security lead, engineering on-call, legal, communications, data protection officer, executive sponsor. The people who would actually be on the bridge.<br>Set the ground rules This is a rehearsal, not a test. Blameless, learning-focused. What people say stays in the room. Written notes for actions only.<br>Walk the scenario in phases Detection, containment, eradication, recovery, post-incident. At each phase, facilitator injects new information and asks: what do we do, who owns it, how long does it take?<br>Test the decision...