Team Building Project

You have Version 1.

You have test results.

You have failures, confusion, and at least one revision.

Good.

Now make the routine usable.

This is not enough:

We have an idea for improving team communication.

This is closer:

Here is the problem.
Here is the routine.
Here is who owns it.
Here is how to use it.
Here is what broke.
Here is what we changed.
Here is how we know whether it helps.

The final Team Routine Prototype

The goal:

Someone outside your group should be able to use the routine without you standing beside them explaining everything.

That is the test.

Part 1: The problem

Use one slide or section.

Answer:

• What happens?
• Why does it matter?
• When does it happen?

Weak:

Communication is bad.

Better:

At the start of practice, players frequently begin without confirming roles, which causes duplicated responsibilities during the first games.

Now we know what the routine is trying to fix.

Part 2: The routine

Show the sequence visually.

Example:

5 minutes before match
  ↓
equipment check
  ↓
role confirmation
  ↓
today's focus
  ↓
final caller confirmed
  ↓
ready

Keep it readable.

Part 3: Ownership

For every important step, identify:

owner
support
backup

Remember Week 03. If nobody owns it, "I thought somebody else was doing that" eventually returns.

Part 4: Access

Your routine must contain at least two ways critical information is available.

Examples:

spoken + visible
checklist + teammate confirmation
role card + verbal call
timer + screen prompt

Communication channels fail. People miss things. Good systems do not assume perfect humans.

Part 5: Test evidence

Show:

Version 1

What you expected.

Test

What happened.

Failure

What broke or caused confusion.

Version 2

What changed.

Part 6: Retest

Test Version 2, even briefly.

Why? Because your revision might introduce a new problem.

Example:

Version 1: verbal instructions caused missed steps.

Revision: add a giant fourteen-step checklist.

Now nobody misses a step. They just spend twelve minutes reading.

Retest.

Final evidence table

Include:

You may add another measurement relevant to your routine.

Do not pretend this proves the routine is perfect. It gives you evidence for comparison.

Part 7: Team defense

Each group presents for approximately 2 to 3 minutes.

Answer five things:

1. What team problem did you choose?
2. What did you build?
3. What broke during testing?
4. What did you change?
5. Why do you believe Version 2 is better?

Use evidence.

Audience job

While another group presents, choose one question type:

Dependency question

What does this routine depend on?

Failure question

What happens if __________ is missing?

Inclusion question

How does a new participant learn the routine?

Evidence question

What would tell you it stopped working?

Good questions help teams find weak points.

Project requirements

Your Team Routine Prototype must include:

• one clearly defined team problem
• one routine with 3 to 7 steps
• clear ownership
• at least one backup
• at least two information/access methods
• Version 1
• testing evidence
• at least one failure
• at least one revision
• Version 2
• one short retest
• final evidence comparison

Suggested Google Slides structure

Slide 1: The Problem
Slide 2: Why It Matters
Slide 3: Version 1 Routine
Slide 4: Roles and Ownership
Slide 5: Inclusion / Access
Slide 6: Test Evidence
Slide 7: What Broke
Slide 8: Version 2
Slide 9: Retest Evidence
Slide 10: What We Learned

You can do fewer slides if your design communicates everything clearly.

I care about the thinking, not slide count.

The ugly test

Before submitting, give your routine to someone who did not design it.

Ask them to follow it.

Do not explain.

Watch.

If they immediately ask, "What am I supposed to do?" good. You just found something to fix.

Final question

Complete:

Our routine improves the team by making __________ more predictable.

That is the core idea.

Source note

This project synthesizes Learn with League concepts around teamwork, responsibility, communication, participation, and respectful team behavior.

The prototype-design framework, Version 1 / Version 2 testing cycle, access requirements, failure testing, evidence comparison, and student defense are original Robotnix Academy project components.