This game was designed by Mark Noneman and Don McGreal for a presentation on the Scrum.org Nexus framework.

This is a fun and effective way to replicate the challenges of scaling product development across many teams.
It puts teams into a situation where they need to turn their individual features into one collective increment within a Sprint. They need to work out how to manage dependencies between teams as well as cross-team requirements and constraints. Consider running this exercise right before introducing a group to a scaling framework, such as Nexus.

Teams working together

Ingredients:

  • At least 3 teams of 3-9 people.
  • Multi-colored paper (at least 32lb paper stock)
  • Enough sharpies for everyone
  • A folder with 3-hole binding and a transparent cover
  • 3-hole punch
  • A Definition of Done & Non-Functional Requirements (printed out or written on flip chart) – here is an example
  • A Product Backlog (on cards) – here is an example

Directions:

  1. Setup: Teams are presented with a Product Backlog and constraints (Definition of Done & NFRs) for a bound booklet about animals in the Nexus Zoo. Each Product Backlog item represents a page in the booklet (along with some acceptance criteria).
    Example PBIs:
    Cover Page : Zoo logo and name centered on top of page ; Map of the zoo ; Images of at least three animals
    Narwhal Page: Show both common and scientific name; Three sentence description of animal ; Sketch of the animal ; Same color paper as Unicorns ; Small zoo logo on top right

  2. Plan: Teams have 4 minutes to select at least one item from the Product Backlog and plan their Sprint.

  3. Sprint: Teams have a 10 minute Sprint to create a complete increment. The increment must meet the Definition of Done.
    e.g.: Common copyright, center bottom of every page; 1 color Sharpie per page; Text should be clear and readable with no crossed-out wording (errors); One-sided page; Integrated into the booklet; No more than 3 of the same color paper; No 2 consecutive same color paper.

  4. Observe: Just step back and let it happen. As a facilitator you really shouldn’t have to do anything else. The point of it is to see how separate teams self-organize to deal with dependencies. You can give your honest opinion about things they are making, but if you are asked any questions about how to proceed, just play dumb.
    For example, we were asked what the copyright should say exactly, we just said ‘Oh wow, never thought of that. What do you think?’. The participant then looked up copyright laws on his phone and presented us with options. We picked one and he then asked how the other teams would know to use the same copyright text. We just shrugged our shoulders. So he grabbed a mic and made an announcement to the rest of the room.

    Some things to look out for:

    • How do the teams coordinate between the animals that share page colors?
    • How do they work out restricting how many same color pages end up in the booklet?
    • How do they agree on what the copyright should be? How do they communicate it to all the teams?
    • How and when do they integrate into the main branch (the binder)? Do they wait until the end and create a bottleneck? Or add pages continuously?
    • Do they form any new roles or groups? Do certain people take responsibility for integration? What about cross-team constraints?
  5. Debrief: Stop the Sprint promptly at the 10 minute mark and examine the increment with everyone.
    Debrief the exercise by pointing out many of your observations. Discuss pros & cons of their scaling practices and start to tie it to the Nexus framework (or any scaling solution).

2 thoughts on “Nexus Zoo (a scaling simulator)

  1. I have done this game with two Sprints. The Sprint defined for 20 minutes: 4 min planning, 9 min work, 3 min review, 4 min retrospectives. As facilitator, I act as the Product Owner (although someone else could as well). For the retro, I ask team representatives to meet to retro integration issues for first half of timebox and then return to their teams to complete team retro.

  2. Including some info about duration of the game (time schedule?) would be helpfull!

    Also, instead of “4. step back and let it happen”, I think it would be more fun and a better learning experience if the facilitator acts more as a Product Owner.
    Asking questions (communicating with your client / PO) should be encouraged! When no questions are asked, the Product Owner should reject the results because of additional (implicit) requirements, e.g. “the logo should be more business-like”, “the cheetah should be running in the picture because that’s what cheetahs are known for”.
    When asked questions about *what* to build the PO should provide sensible answers. Questions about *how* to build or coordinate should not be answered.

Comments are closed.