AGILE GAMES

Conway’s Compositions

AGILE GAMES

Conway’s Compositions

In 1967, Melvin Conway introduced the idea that states “organizations which design systems… are constrained to produce designs which are copies of the communication structures of these organizations.” This has become known as Conway’s Law. While Conway was a programmer, his law rings true for about any product that a system of people develops.

This game is intended to demonstrate the impact different organizational structures can have on product development efforts. The product being developed in this case is a story book and the structures will be between groups of functional disciplines and cross-functional teams working on the same product. There will also be some leads for the groups or teams.

The storybook should equate to the number of chapters for the number of teams. It is highly recommended though that at least 3 chapters be created and for planning purposes, it is best to think through what the cross-functional teams look like first and then engineer the functional disciplines into groups from that. Cross-functional teams will produce one chapter (or if there are only two teams due to lack of people, then 4 chapters will be produced with one team doing the odd-numbered chapters and the other team doing the even-numbered chapters).

The Publisher is the facilitator and lets people know what story they would like and sets the deadline for publishing.

There are three primary roles; each of which would make up a team:

  • Writer – creates the story based on the theme
  • Illustrator – creates diagrams for the story
  • Layout – lays out the pages with images and illustrations so that the book flows properly and is readable

And there are three optional roles:

  • Binder – does final integration of book to present to the customer with pages and such; not on a team, acts as an interface to the Publisher
  • Editor – if used is the one that ensures good grammar and proper spelling; correcting these errors is on a team
  • Observer – watches the work occurring and makes notes of interesting aspects about it; not on a group or team

So organizing cross-functional teams of the first three roles (with an editor if you have enough people) will work best. Then you can assign people who perhaps are not on a team role of Binder (only one) or Observer.

It may be helpful to describe what a typical story arc looks like, so they mentally have an idea of how a story should start and end with a bit of flow in the middle. Here is a typical story arc…

We have a beginning, and everything is going well (context is set, etc…) until a crisis happens; then something happens to change the downward path and then the story closes out with an ending.

The game is played over rounds. The first two rounds will have people organized into functional groups. The structure would look something like this:

Each group has a functional lead. In the first round, these leads should be the only ones allowed to communicate with each other and through the Binder (if you have one) or the Publisher (facilitator). This simulates how most organizations communicate due to politics, responsibilities, authority, et cetera. In the second round, you can allow more free-flow communication between the groups. NOTE: as a facilitator, ping your leads on the status of THEIR deliverables. Remind them they are measured on this.

After exploring two rounds of this organizational structure, it is time to reorganize into cross-functional teams. These should look like this:

Only have editors if you had them as a functional team; and, again, the Binder may be optional as well. Each team should appoint a team lead. In the third round (the first cross-functional round), communication again is limited in-between teams to working the Binder or Publisher (facilitator). This arrangement mimics how many organizations choose to formalize communications as they scale cross-functional teams. In the fourth round, communication can be more open between teams. Remember to ping the leads on how they are doing on their deliverables; the need for delivery never stops.

An optional fifth round can allow a retrospective to see what changes the teams would want to make to their structure and/or processes and try it out. This structure is shown below with the Illustrators as the functional group:

Another possible optional round could be to keep one functional discipline in a separate group (perhaps with fewer people than teams) and to only get help from this group by the team lead talking to that group lead. The Illustrator, Layout, or Editor role are good candidates for this. This is particularly helpful if you have need to demonstrate how an organization is limiting delivery with a functional team bottleneck.

Each round has one minute of discussion between leads about any considerations they want to have; this is followed by the team executing the delivery. Remind participants at 2 minutes and 1 minute of the end of their timebox for delivery. A recommendation is to reduce the time of each round by one minute, starting with 10 minutes for the first round and going no lower than six minutes.

Each round the groups/teams will get new story requirements; generally try to make these a bit harder each round. Here are examples in use currently:

Round 1) A Children’s Book on colors that also helps reinforce the alphabet.

Round 2) A Super Villain Comic Book with the demise of a corporation.

Round 3) A Fantasy Book for Young Adults about love and battles with a princess and a dragon.

Round 4) A Realistic Science-Fiction Book for hardcore sci-fi lovers featuring a frog and a snake.

Optional Round 5) A Suspense/Mystery Spy novel solved through cooking to unlock clues.

Other optional themes for 5 –

A Royal Cookbook themed around the marriage of Prince Harold of Hare and Princess Rebecca Rabbit in the town of Bunnyburg in the Kingdom of Cottontail. It should foretell their future life together through its magical recipes.

A poetic ballad telling the tale of circus entertainers escaping being held as political prisoners.

You could also use Rory’s Story Dice to create increasingly complex stories to be written (rolling more dice I suppose – this is untested).

If you want to add another element, ask for the book to be in an unusual shape so that it catches the attention on the shelves.

After each round, the facilitator should critique the end product. Items for critique:

  • Story flow; did the story flow between chapters well (the next chapter picked up logically)?
  • Characters; did the story introduce new characters, drop characters, or alter characters in the story inexplicably?
  • Illustrations; did the illustrations match what was going on in the story?
  • Layout & Binding; did the storybook have a consistent feel to the layout? Did the pages match the sizes?
  • Matches audience; did the story introduce words, concepts, or descriptions that aren’t for the targeted audience?

The stories will be short with the time limits, so don’t expect them to get too deep. Declare if you think you can sell it or not.

At the end of all your rounds, it’s time to debrief what is seen. Set aside at least 20 minutes to debrief and you may need more. Here are some questions to help guide your debrief:

  • What happened?
  • How did the structures contribute or detract from the story creation?
  • In what way did limiting communication between groups and teams affect the teams?
  • Where and when did most problems occur?
  • How was your planning? Useful? Why or why not?
  • Did any particular roles work more closely together than other roles in the last two rounds?
  • How did any of this simulate what you see in your workplace?

Want the facilitation guide? Get it here.

About Tasty Cupcakes

This content was originally published on Tasty Cupcakes, a community-run website founded by Michael McCullough and Don McGreal after they presented a series of games at Agile2008 in Toronto. The site’s tagline was “fuel for invention and learning.” After 15 years at TastyCupcakes.org, the content has found a new permanent home here at Agile Alliance.

The games, techniques, and approaches presented are here to use and explore. All we ask is that you tell others about us and give us some feedback on the games themselves. All of this work is licensed under a Creative Commons Attribution 4.0 International License.

Add to Bookmarks Remove Bookmark
Add to Bookmarks Remove from Bookmarks
Add to Bookmarks Remove from Bookmarks

Got feedback? Join the conversation!

Explore additional Agile Games

Description Organization and prioritization are two distinct activities that can be used to improve the quality of a product backlog. A simple linear list is difficult to prioritize. As well, many stakeholders are forgotten in the rush to deliver cus…
Objectives Learn about the attributes and duties of a role. Verify what your students already know about the subject (complemented by a short lecture). Let your students learn from each other. I've successfully used it with all three Scrum roles: th…
This activity was designed to teach continuous integration concepts and value without resorting to code, a continuous integration server, or any hardware or software.  While the participants will experience some frustration in trying to complete the …
While we've all heard about "pair programming", pairing is not just for programmers. In this activity, participants will use fiction/creative writing to understand the importance and value (and fun) of pairing. Timing Prep: Printing out the ha…

Discover the many benefits of membership

Your membership enables Agile Alliance to offer a wealth of first-rate resources, present renowned international events, support global community groups, and more — all geared toward helping Agile practitioners reach their full potential and deliver innovative, Agile solutions.

Privacy Preference Center

Not yet a member? Sign up now