Team and Workflow

These activities form the team, write down how it works, and check on it as the project runs. Most work best with every member present, because they surface how the team actually functions, and an absent member’s view is the one nobody else can supply. The conflict exercises apply the conflict guide to a situation your team is actually in, so read it before running them.

“Always assume positive intent.” (Indra Nooyi)

Conflict and Performance ConversationsWhat kind of conflict you're looking at, how to raise a contribution problem, and when to escalate. The conflict exercises below assume it.

Two truths and a bug

Whole team15 min

Find out who you’re actually working with, in the fifteen minutes before anyone opens a laptop. Fifteen minutes, once, when the team first sits together. The working agreement guide covers the norms a team writes afterward, once it knows who it has.

Write three claims each: two true and one invented, all about your life with computers. Specific beats impressive: “I took down production with a missing semicolon”, “I learned to program on a graphing calculator”, “I have never once used a debugger”.
Guess before the reveal: the team votes on which claim is the lie, then the author says. One round per person, a minute each, no deliberating.
Chase the interesting one: whichever claim caused the most argument, ask for the story behind it.
End with a want: one sentence each on what you most want to be better at by the time this project ends. Nobody collects these; you say them out loud so your teammates know what you’re here for.

A good output is that every person can name something about each teammate that the roster doesn’t say, and one thing each teammate wants to get better at.

Identify Individual Learning Objectives and Skills

Whole team

Each team member creates two lists:

one for motivations and learning objectives, and
another for current strengths and skills.

Prioritize learning objectives and motivations over existing strengths, since there’s time to develop new skills over the course of the project.

Learning goals can extend beyond technical skills to include societal or entrepreneurial interests. Once everyone has their lists, explore ways to complement each other’s strengths and objectives. For instance, one person may teach a skill they excel in to someone who wants to learn it.

Capture a summary of the discussion, including the list of learning objectives, skills, and action items. This conversation is a natural input to your team charter.

A good output is two lists per team member, motivations and learning objectives alongside current strengths, compared as a team to find the gaps and the overlaps.

Team Formation Strategies Assessment

Whole team

Identify which stage of formation your team is in, and apply appropriate strategies to move your team forward. Start from Tuckman’s stages of group development.

Stage	Characteristics	Strategies
Forming	Team members are polite, roles are unclear, high dependence on leader for direction	Clarify goals, set expectations, encourage open communication
Storming	Conflicts arise, clashing ideas, team members challenge each other	Address conflicts openly, promote active listening, foster trust and collaboration
Norming	Team begins to resolve differences, stronger cohesion, more cooperation	Encourage collaboration, reinforce team norms, facilitate role clarity and feedback
Performing	Team operates efficiently, strong autonomy, high motivation, and productivity	Support autonomy, celebrate successes, continue providing feedback, and adapt as needed
Adjourning	Team disbands after completing goals, members experience mixed emotions	Celebrate achievements, conduct reflection sessions, provide closure and next steps

Optionally, run this a second time with an AI agent and set the two outputs side by side, noting where they differ, because the comparison shows what the tool changed; either version can be the one you keep.

A good output is your team’s current stage named, with the specific strategies you’ll use to move to the next one.

Map Your Team’s Working Styles

Whole team

Find the trait gaps inside your team that will otherwise show up as friction nobody can name. Thirty minutes each, plus half an hour together.

Take the Big Five test individually. It’s free and open source.
Compare as a team, one trait at a time. You’re looking only for the gaps: where two people sit at opposite ends.
For each gap, write one tactic each way. A conscientious member working with a spontaneous one agrees not to impose rigid schedules; the spontaneous one agrees to commit to dates and flag slips early. High extraversion agrees to leave space; low extraversion agrees to prepare contributions in advance.
Keep it about behavior, not identity. The traits are spectra and shift with context, so write each tactic as a behavior someone can change.

A good output is a short table of the trait gaps in your team with one agreed tactic on each side of each gap.

Assess Your Team’s Conflict Styles

Whole team1 hPrepares:Team Charter

Find out how your team actually handles disagreement before you’re in the middle of one, and agree which style fits which situation. One hour as a team, early, before the first real disagreement.

Read the five modes in the guide: competing, collaborating, compromising, avoiding, accommodating, positioned on assertiveness and cooperativeness.
Name your own default. Everyone says which mode they reach for first. If you claim “collaborating” for everything, check whether you’re avoiding.
Fill the assessment together on a real disagreement your team has had or expects.
Complete the outcomes matrix below: for each style, what would happen to this specific situation if you used it.

Team Conflict Situation Assessment Template

Handling Style	Positive Outcome	Negative Outcome
Compete
Collaborate
Compromise
Accommodate
Avoid

A good output is the completed assessment and a filled outcomes matrix, plus one line in your charter naming which style your team defaults to and when you’ve agreed to override it.

Responsibility Assignment Matrix (RACI)

Whole teamPrepares:Team Charter

A RACI matrix is a project management tool that clarifies roles and responsibilities for tasks or deliverables. RACI stands for:

Responsible: The person(s) who perform the work to complete the task.
Accountable: The person who is ultimately answerable for the task’s completion and approves the work.
Consulted: Individuals who provide input or expertise during the task.
Informed: Individuals who need to be kept updated on the task’s progress or completion.

Here’s an example of a RACI matrix:

Task/Deliverable	Team Member A	Team Member B	…	Supervisor or Instructor	Project Partner
Stakeholder Interview	R	A		C	I
Figma: User Login	R	C		I	I
Compare Databases Technology		R		I	C
Testing	R	R	R	I	A

A good output is a RACI matrix for your project, detailing roles and responsibilities for key tasks or deliverables.

Plan Your Escalation Path

Whole team

Write down what your team will do when someone stops delivering, while everyone is still getting along and nobody is the subject of it. Forty-five minutes, in the first fortnight.

Set the trigger. Not “if problems persist” but something you can point at: two consecutive sprints with no completed task, or three missed stand-ups without notice.
Write the three steps: private one-to-one, raise at the retrospective, escalate to your supervisor or instructor. Say who does step one, so it isn’t left to whoever cracks first.
Agree the timeline, in sprints rather than in feelings, so a slip can’t run for weeks while everyone hopes it resolves.
Agree what gets written down at each step, and where.
Say what happens to the work in the meantime, since somebody is going to absorb it.

A good output is the escalation section of your charter, with a measurable trigger, a named first mover, and a timeline in sprints.

Software Development Process

Whole team

Define and plan the software development process for your project to ensure clear workflow and task management.

Choose a Development Methodology: Select an approach (e.g., Agile, Waterfall, SCRUM) that fits your project.
Outline Development Phases: Break down the process into phases such as planning, design, implementation, testing, and deployment.
Set Milestones: Establish key milestones and goals for each phase.
Assign Roles: Clarify team roles and responsibilities at each stage.
Team Agreement: Discuss the process with your team and ensure everyone agrees.

Much of this belongs in your team charter.

A good output is a document outlining the chosen process, phases, milestones, and team roles.

Kanban Board Setup

Whole teamPrepares:Sprint Notes and Demos Repo Checkpoints

Set up a Kanban board to visualize and manage your project’s workflow effectively.

Create Columns: Set up key stages like “To Do,” “In Progress,” and “Done” (or project-specific stages).
List Tasks: Break down the project into individual tasks or user stories and add them to the “To Do” column.
Manage Workflow: Move tasks across columns as work progresses to visualize progress.
Limit Work in Progress (WIP): Set WIP limits to avoid overloading team members.
Team Agreement: Discuss the process and tool with your team and ensure everyone agrees.

A good output is your live Kanban board and a brief explanation of its structure.

Definition of Done

Whole teamPrepares:Sprint Notes and Demos Repo Checkpoints

The Definition of Done (DoD) establishes clear criteria for when tasks, features, or the overall project can be considered complete.

List Completion Criteria: Define specific conditions that must be met for each task or feature to be marked as “done” (e.g., all tests passed, documentation updated, code reviewed).
Include Quality Standards: Ensure the criteria cover quality aspects like performance benchmarks, usability, or security.
Team Agreement: Discuss the definition with your team and ensure everyone agrees.

A Definition of Done is the task-level sibling of a project-level agreement on what counts as finished, and practicing on tasks makes the project-level version easier to write.

A good output is the agreed Definition of Done, written into your CONTRIBUTING.md beside the review workflow.

Set Up Your Repository’s Skills

1 to 2 hPrepares:Team Charter

Install a shared set of agent workflows so that a task like “review this pull request” runs the same way every time, instead of depending on how each teammate happens to phrase a prompt. One to two hours, once.

Read two published collections: obra’s Superpowers covers brainstorming, subagent-driven development with built-in code review, systematic debugging, and red/green test-driven development, and it teaches how to write and test new skills. Matt Pocock’s skills cover spec and ticket flows, TDD, code review, domain modeling, and a “grilling” skill that stress-tests a plan by arguing with you about it.
Install one and run it against your own repository on real work.
Compare: write down what changed in the output versus prompting freehand.
Commit the choice: skills belong in the repository so everyone gets the same behavior. Your team’s AI coordinator owns which ones the team standardizes on.

Several of these are checks rather than conveniences: a separate architectural-review pass and a code-review pass each catch a mistake before it merges, and a plan-before-you-build skill is what turns “make it do X” into the kind of specification a design document can be written from.

If your tooling can’t load skills: the invariant is that recurring work happens the same way regardless of who does it. The substitute is a written checklist in CONTRIBUTING.md that a human follows.

A good output is at least one skill committed to your repository and a short note on what its output changed.

Regular Stand-Up Meetings

Whole teamOngoingPrepares:Project Partner Evaluation Peer Evaluations Sprint Notes and Demos

Stand-up meetings help keep the team aligned by discussing recent progress, identifying challenges, and setting short-term goals.

Hold stand-up meetings two or three times a week, where each team member shares what they completed, what they’re working on, and any blockers they face. Meetings should be brief (10-15 minutes) and focus on keeping the team updated.

A stand-up can also run asynchronously on your team’s messaging platform, on the days between meetings or when schedules don’t overlap. Hold at least one a week, in either form, so a blocker waits days rather than the whole sprint.

Keep brief notes of key discussion points: important decisions made, challenges raised, and how they were addressed. These notes make any sprint write-up fast and accurate.

A good output is an agreed cadence and format written into your charter, plus a week of stand-ups actually held.

Weekly Work Intensity

Rate each week ahead as low, medium, or high based on the effort you expect to dedicate to your project, considering your other commitments. As the weeks pass, track your actual effort and compare it to your predictions. At the end, reflect on how your expectations matched your experience and identify any adjustments needed to better manage your time going forward.

Discuss your weekly work intensity with your team and align expectations.

A good output is your predicted intensity per week next to your actual tracked effort, with a short reflection on the gap.

Rehearse a Performance Conversation

30 minPrepares:Incident Postmortem

Practice saying the hard thing in factual language, on a low-stakes example, so the words are available when it matters. Thirty minutes, in pairs.

Take a real situation, either from your team or a plausible one: a task in progress for two sprints, missed stand-ups, a commitment that slipped without warning.
Write it as situation, behavior, impact: when and which task, what you actually observed, what it cost the team. Three sentences.
Strip out every inference of motive. “You clearly don’t care” and “you’re not pulling your weight” both fail; find what you’d have written instead.
Say it out loud to a partner, who responds as the teammate would. Notice which sentence you flinch at, because that’s the one you’ll soften into meaninglessness in real life.
Swap and repeat.

A good output is a written three-sentence version of the conversation, with no inferred motive in it, that you’d be willing to say to the person’s face.

Team Dysfunctions Assessment

Whole teamWorkshop 2, WinterPrepares:Peer Evaluations

The Five Dysfunctions of a Team model names five barriers to teamwork: lack of trust, fear of conflict, lack of commitment, avoidance of accountability, and inattention to results. Name the ones your team shows, then pick a strategy for each.

Here’s a table outlining the five dysfunctions of a team from Patrick Lencioni’s model, with their characteristics and strategies:

Level	Dysfunction	Characteristics	Strategies
1	Absence of Trust	Team members are unwilling to be vulnerable or admit weaknesses.	Build trust through vulnerability, encourage open communication, and team-building activities.
2	Fear of Conflict	Team avoids discussions or disagreements, leading to unresolved issues.	Foster a culture of healthy debate, encourage open dialogue, and address conflicts directly.
3	Lack of Commitment	Team members are unclear about decisions or hesitant to fully commit.	Ensure clarity in decisions, create shared goals, and make commitments visible.
4	Avoidance of Accountability	Team members hesitate to hold each other accountable for their responsibilities.	Set clear expectations, create accountability structures, and encourage peer-to-peer feedback.
5	Inattention to Results	Focus shifts from collective success to individual goals or status.	Focus on collective outcomes, track measurable results, and celebrate team achievements.

Here’s a shorter video of the model.

A good output identifies the dysfunctions within the team, proposed strategies for addressing each dysfunction, and a reflection on how these will improve team performance.

Team Health Assessment

Whole teamWorkshop 1, SpringPrepares:Peer Evaluations Project Retrospective

Health checks are a structured input for your retrospectives: run one before a retro and the discussion starts from data instead of vibes. The formats below also work well as the basis for the retrospective at the end of a release or a project.

Google’s Five Dynamics

Google has identified five key dynamics that distinguish effective teams:

Psychological Safety: team members feel safe to take risks and be vulnerable without fear of embarrassment or punishment.
Dependability: members reliably complete quality work on time, ensuring trust and accountability within the team.
Structure and Clarity: clear roles, plans, and goals are established, providing direction and understanding of expectations.
Meaning: work is personally significant to team members, fostering motivation and engagement.
Impact: team members perceive their work as making a difference and contributing to the organization’s goals.

Of the five, Google’s research found psychological safety mattered most.

Self-assess (green/yellow/red) your team on these five dynamics. You can use Google’s Discussion Guide.

Team Barometer

Jimmy Janlén outlines how to use the team barometer to assess if the team is getting better over time. Self-assess (green/yellow/red) your team on these cards. Feel free to opt for alternatives such as fewer cards or the perfection game (see original article).

Card	Green	Red
Trust	We have the courage to tell each other the truth. We don’t hesitate to engage in constructive conflicts.	Members rarely speak their mind. We avoid conflicts. Discussions are tentative and polite.
Collaboration	The team cross-pollinates, sharing perspectives, context and innovations with other teams, and other parts of the organization.	Work is done individually. Little or no collaboration within the team or with other teams.
Feedback	We give positive feedback, but also call out one another’s deficiencies and unproductive behaviors.	We rarely praise each other or give feedback or criticize each other for acting irresponsibly or breaking our Working Agreement.
Meeting Engagement	People are engaged in meetings. They want to be there. Discussions are passionate.	Many feel like prisoners in the meeting. Only a few participate in discussions.
Commitment	We commit to our plans and hold each other accountable for doing our best to reach our goals and execute assigned action points.	We don’t have real consensus about our goals. We don’t really buy in to the plan or follow up that people keep their commitments.
Improving	We passionately strive to figure out how to work better and more efficiently as a team. We try to “know” if we get better.	We don’t focus on questioning our process or way of working. If someone asked us to prove that we’ve gotten better we have no clue how we would demonstrate that.
Mutually Responsible	We feel mutually responsible for achieving our goals. We win and fail as a team.	When we fail we try to figure out who did what wrong. When we succeed we celebrate individuals. If we pay attention to it at all…
Power	We go out of our way to unblock ourselves when we run into impediments or dependencies.	When we run into problems or dependencies we alert managers, ask for their help, and then wait.
Pride	We feel pride in our work and what we accomplish.	We feel ashamed of our pace and the quality of our results.
Relationships	Team members spend time and effort building strong relationships among themselves, as well as with partners outside the team.	We don’t really know each other or what makes others “tick”.
Ownership	We engage in defining our own goals and take ownership of our destiny.	We act as pawns in a game of chess. We don’t demand involvement in defining our goals and destiny.
Sharing	We share what we know and learn. No one withholds information that affects the team.	People do stuff under the radar and often forget to share news or relevant information.
Boosts each other	We unleash each other’s passion and care for each other’s personal development. We leverage our differences.	We don’t know in which areas people want to grow. We have trouble collaborating since we are very different and view things differently.
Loyalty	No one has hidden agendas. We feel that everyone’s loyalty is with THIS team.	The team feels like a diverse group of people with different goals and loyalties that lie elsewhere.
Passion	Each member wants THIS team to be great and successful.	People just come to work for 8 hours and focus on their own tasks.
Integrity	We honor our processes and working agreements even when we are put under pressure.	Our behaviors, collaboration, and communication fall apart when we get stressed.

Spotify’s Squad Health Check

Spotify started running Agile squad health checks around 2014. They’ve since reflected on their experience. Self-assess (green/yellow/red) your team in these areas.

Area	Example of Awesome (green)	Example of Crappy (red)
Easy to release	Releasing is simple, safe, painless & mostly automated.	Releasing is risky, painful, lots of manual work, and takes forever.
Suitable process	Our way of working fits us perfectly	Our way of working sucks
Tech quality (code base health)	We’re proud of the quality of our code! It is clean, easy to read, and has great test coverage.	Our code is a pile of dung, and technical debt is raging out of control
Value	We deliver great stuff! We’re proud of it and our stakeholders are really happy.	We deliver crap. We feel ashamed to deliver it. Our stakeholders hate us.
Speed	We get stuff done really quickly. No waiting, no delays.	We never seem to get done with anything. We keep getting stuck or interrupted. Stories keep getting stuck on dependencies
Mission	We know exactly why we are here, and we are really excited about it	We have no idea why we are here, there is no high level picture or focus. Our so-called mission is completely unclear and uninspiring.
Fun	We love going to work, and have great fun working together	Boooooooring.
Learning	We’re learning lots of interesting stuff all the time!	We never have time to learn anything
Support	We always get great support & help when we ask for it!	We keep getting stuck because we can’t get the support & help that we ask for.
Pawns or players	We are in control of our destiny! We decide what to build and how to build it.	We are just pawns in a game of chess, with no influence over what we build or how we build it

Close by updating your team charter with what the check surfaced: roles, the decision process, and anything your last retrospective changed. The working agreement guide has the patterns.

A good output is your completed health check, with the two lowest-scoring dimensions carried into your next retrospective as agenda items, and your team charter updated with what the check surfaced.