A Game Without Thrones

How to use Lego to teach Agile Organization with no command and control, no hierarchy, no managers, masters or owners. But chapter meetings, governance treaties, small councils, Leadership as a Service, self-managing streams of self-organizing teams, and the wit and wisdom of Wildlings ...

The First Agile Game

The Extreme Hour started in 1999 at Websense in San Diego. It caught mindshare when Beck and I turned it into a theatre sport at the XP2000 conference. A cottage industry slowly grew up around Agile games but the basics of the thing stayed the same. You run ceremonies in minutes instead of days, Scrum/XP as a tinker-toy, fast to learn, fun to play, a great way to gift new teams with a shared vision of Agility.

Now to teach Agile Organization we need a new game ...

Engineers of Westeros

Game of Thrones has blood, sex, magic, dragons, zombies ... yet something is missing. Can you spot it?

Where are the engineers? Whoever builds all those castles and fleets and things can't report into a Throne. Imagine telling a Lannister an estimate is only a forecast, or throughput matters more than operating expense. Can you imagine a Sprint Review?

When the leadership style is cake or death engineers can't use customer feedback to prioritise. They have to rely on analytic data, not some noble's changing gut feelings. That's what our new game is about. And at scale - not one Agile team dealing with a little pre-made backlog, but many Agile squads self-managing to build a great many-towered Westeros castle from a backlog they make themselves - as part of the game!

Chapters and Squads

To keep this simple we'll assume the engineers are Wildlings, the free folk without loyalties to Lords and Ladies. Not above building a castle for nobles, however, if the nobles will swear in turn not to make war north of the Wall ...

Wildlings building castles isn't entirely true to the GRRM books, sure, but we have to build something together in this game, and castles are a natural for Lego teams. But per Spotify our emphasis is on autonomy and alignment. We can safely assume at a squad level everything is, well, awesome ..

We'll keep the squads to the optimum size - just 6. Per Westeros religions we'll give each of the 6 squad members a chapter, and let the chapter meetings cross-link squads: 

• The Artist: metric is geometric and scale symmetry. Focuses breadth-first, never losing sight of the whole.
• The Architect: metric is enclosed volume. Focuses on reusable practices, tools and building techniques
• The Merchant: metric is # of different rooms. Focuses design on experiences of high-born lords and ladies
• The Maester: metric is sturdiness. Integrity vs winter, wobbles and walkers. Focuses on root causes.
• The Captain: metric is military preparations. Focus on defence via trebuchets, boiling oil, pit traps, etc.
• The Coach: metric is balance – the multiple of all the other metrics. Focuses work on the current bottleneck.

But who builds? Everyone builds. These roles are analytic perspectives, not hierarchical positions. Everyone loves to work with the Lego so it isn't fair to shut anyone out of it. 

Leadership as a Service

Servant leaders don't command and control. They coordinate and collaborate.

Every team has need of leadership yet good leaders are hard to find. So both at squad and council levels we use a simple protocol to supply leadership when and only when a team needs it. It's called Leadership as a Service:

1. If the team are unanimous about a decision, no individual role gets to decide. Servant leaders lead through influence, not authority.
2. If the Coach judges the team won't reach a decision before the Last Responsible Moment - then the coach picks which individual team member will decide based on what kind of decision it is. The Coach never gets to decide the question themselves.
3. Members of the team may voluntarily swap chapters at any time if need be. Otherwise your chapter defines the leadership service you provide to your team.
4. A Coach can only coach their own squad. For the sake of autonomy, no one is permitted to make decisions for any other squad. That goes for chapters and councils too - they can't over-rule squads, only define and prioritise the work.

Build - Measure - Learn - Refactor!

Agile Organization is based on interlocking, continuous, high cadence build-measure-learn cycles. You can plan and release in months and quarters if that suits you, but the plans are continuously maintained, not left to go stale in the face of current learnings.

In this game our build-measure-learn cycles are synchronised to four 5-minute ceremonies. Real world Agile Organizations have a more drawn out cadence than this, but the dynamics remain the same:

• Sprints where each squad builds and integrates features of the castle. Squads work in their own areas and don't attempt to integrate their work until the third ceremony ...

• Chapter Meetings where people of the same role share their learnings between squads and propose features and treaties.

• Refactoring where the squads work mob-programming-style to integrate their new features into the castle while paying down technical debt, and the Small Council meets to prioritise the features that were just proposed by the chapter meetings.

• Retrospectives where everyone rejoins their squads to adapt its way of working to what they've learned in the chapters and from refactoring, and to align treaties between the squads. The council members act as bridges between the retros when treaties need modification and ratification.

What about Sprint Reviews and Standups? Our timeframes are minutes here so we don't need standups. And while reviews with real customers are critically important in real world Agile, our Westeros engineers will have to use their own metrics to tell them about what their fictional customers want. That's not unrealistic - it's how Apple prioritised under Jobs.

Sprints

Let's play with blocks.

The main problem for a game-runner during a Sprint is how to get people to stop playing when it's is done. As master of ceremonies for quite a few Lego games, I used to yell myself hoarse. People love playing it only too much.

So here's a silent attention getting trick. You tell everyone at the start that whenever they see you have your hand in the air, they must put their hands in the air. And they must keep their hands there until you put your hand down. That works so well the loudest I have to raise my voice now is to clear my throat.

You can enhance this by playing "building music" - some GoT background music works well, though not the main theme - and turn the music off at the end of the sprint.

During the Sprint Squads work separately in their own area - they won't integrate their solutions with the rest of the castle until the Refactoring ceremony. In Sprint Zero, a squad is concerned with getting into a collaborative cadence and sketching out broad strokes for the layout of the castle as a whole. The Small Council meeting will define real priorities for Sprints after that.

Chapter Meetings

Each chapter's purpose is to share learnings across squads. The obsolete "Scrum of Scrums" pattern provides too little bandwidth to do this effectively. During chapter meetings all the analysts meet each other, all the architects meet each other, and so on, rather than meeting with members of their own squads.

Our game's chapter meetings have an automatic time limit of five minutes and don't make decisions, just Proposals. There are two kinds - features for the castle, which will be prioritised by the small council. And Treaties between squads, which are agreements about how to divide and align the work. A treaty might read

If and only if the Crows build towers ... the Giants will build walls between them

A treaty may involve more than one squad and each treaty must be ratified by the squads before it can take effect - the only people bound by a treaty are squads that decide, at their retrospectives, to take part in it. 

Each chapter meeting also selects one of its members to attend the Small Council as the chapter's Leader. We rotate the Chapter Leader role round robin from turn to turn so everyone gets to experience a Council session. It's the job of a Chapter Leader to represent their Chapter impartially there, not to favour their own Squad. Rotating the role round-robin reinforces this.

Mob Refactoring

In the real world, Refactoring is essential to continuously pay down tech debt. It ensures the design of each part is the simplest that can possibly work while the whole is balanced in the face of change. In our game, with no fixed product backlogs, there's plenty of that!

In our castle, refactoring arranges the features in a way that simplifies the life of the castle's inhabitants and ensures there are no loose joints between castle features. It brings overall symmetry & consistency, even beauty to the emerging design.

To refactor you don't listen to a king; you listen to the castle that will house the king's line across summer and winter, peace and war. The king worries about the past but the castle is about the future.

And who does this? Everyone not occupied in the Small Council! The key to preventing a dragon-sized hole in Mob Refactoring is for that we performs refactorings in tiny steps, always making sure that the whole castle is stable enough for the next change.

If a dragon-sized integration error does strikes the castle mid-build, prioritising repairs becomes a matter for the Council ...

The Small Council

As embodied in the Haudenosaunee council tradition employed by modern day Mohawks and their brother nations in the Native American Iroquois Confederacy, a living tradition in continuous use since the 13th century, a consensus council is made of representatives of its constituent chapters.

The Iroquois successfully scaled consensus ratification of decisions to international levels by only requiring unanimity for the teams that agree to abide by a decision. This is the basis of the traditional Indian treaty process called Brightening The Chain. An Iroquois treaty doesn't affect anyone who doesn't agree to abide by it. That's the foundation of their Great Law of Peace: non-interference. 

While the squads refactor the castle, the Council for Small Matters prioritises new features. It's made up of reps from each of the Chapters and coached by the representative of the Coach Chapter. Representation rotates from release to release to prevent hierarchy forming. Otherwise we would need a throne ...

Squad Retrospectives

The retrospective is where a squad decides how it will change the way it works in the next sprint.

There are many different formats for Agile retrospectives and remarkably few of them involve drawing swords and declaring kings, but you get the idea. To keep this part of the game to just five minutes you have to make it very simple. Squad members identify problems, make proposals to solve them - whether derived from ideas at Chapter Meetings or not - and then use Leadership as a Service to decide which of these proposals, if any, to act upon. 

Winter is Coming!

We generally run three or four 20-minute cycles. We start the with a Sprint Zero so people can experiment with different castle layouts and while getting experience of collaborating on Lego before commencing chapters and retros.

If you run three twenty minute cycles that's an hour. Allow another hour for framing and Q&A and that's Agile Organization as a tinker-toy, easy to learn, fun to play, a great way to motivate new value streams. Still we must never forget what happened to Harrenhal. Even the mightiest Lego castle won't keep dragons out. And no matter how pretty it is you must tear it down the walls at the end of the game ...

For those who find it far-fetched to think there could really be an Agile Organization of Wildling engineers building the Westeros castles behind the scenes, notice here how Tywin Lannister, The Hand of the King, long serving on the Small Council, the shrewdest, best read, farthest travelled and most powerful Lord in the history of Westeros ... has never actually met a castle engineer.

Slide Deck

XBA: Training in Exponential Business Agility

GWoT is one of the key training simulations in XSCALE's Exponential Business Agility (XBA) course. Public training sessions are available here.