DSbuilders is designed with facilitation in mind, however working with 40 persons playing a game is not trivial. That’s why there are rules to be checked

• during the game: rules about interactions among people/roles
• at the end of each cycle: Initiatives’ capacity, dependencies and connectors availability, strategic goals
• end of the game. victory conditions

Rules are designed to be a realistic simulation of a scaled situation where teams are in different locations. Moreover we have roles like PO and Scrum master, and we have moments like PO Sync, Sprint Review or Scrum of Scrums.

Facilitator’s main role is about helping teams working together to achieve the common goals (the Emperor’s one) over the Initiative goal (sub-optimisation).

“Agile, essentially, is about collaboration” is my favourite quote and in fact collaboration is the main objective of this experience, even if players lose the game. The usage of an “alien” font, for example, is a trick to improve collaboration in uncertain scenario; however any relevant information is available in English or icons.

NOTE. In Cycle Zero each Initiative could check that their backlog is feasible in 6 Cycles (Initiatives total points are smaller than 90=15×6). This is an ideal situation to discuss what are changes scaling to multiple team working on the same product.

The game should be strictly timeboxed to make it more realistic (and fun), so you need to monitor time.

TIMING AND PACE

The following are the suggested timing, you can adapt to your needs and experience:

Introduction: 20’

Cycle Zero: 10’

Cycles [Build: 10’ > Review: 5’ > Retro: 5’] x6 = 120’

Debriefing: 30’

The complete game can last up to 3 hours but keep in mind it may end before the 6^th Cycle.

OPTIONAL RULES

You can play DSbuilders adding some optional rules.

1) To activate an inactive Component after it has been built, the Component’s Initiative must pay 1 point (re-tap the card)

2) Each of the Gran Koenig role cards has a text on their “leadership style” to influence prioritisation for the Initiative.

3) Each component cards has information to be built using Lego bricks or similar and can be enhanced with the possibility to estimate points. This version is much more challenging (and fun) and requires twice the timing and a lot of bricks.

 

MANAGING DEPENDENCIES

One of the main goals of the game is to show the role of dependencies in the process of delivering value to customers.
Below you can find a matrix showing the relations among initiatives.
It is up to you when and how to share this information, my experience is to show this at the end, to explain the dynamic of the game, after that teams have faced the struggle to deal with strongly connected initiatives
This matrix shows the number of components that has an external dependency, and it has been designed to have an initiative that is donor to everyone (Infrastructure); also Defence appears to be as a relevant donor, while Supremacy isn’t donor to anyone even if this is the only initiative that is beneficiary from everyone.
This scenario creates different connections across initiatives that influences strongly the dynamic of the game and is able to create effective sub-optimisation possibilities.

	#components
		Ben	efic	iary
		C	D	I	L	S	T
Donor	Communication		1	1		1
	Defence	1		1	1	2
	Infrastructure	8	1		2	1	1
	Living					2	4
	Supremacy
	Transport					4

In this matrix we are not considering internal dependencies (managed by each of the initiatives) and also Integration Connectors that are connected to specific components developed by 3 initiatives: Communication, Infrastructure (2x) and Living.

 

Back to DSbuilders page