Looking for a game to demonstrate agile s/w architecture

182 views
Skip to first unread message

Elad

unread,
May 17, 2012, 6:08:12 AM5/17/12
to AgileGames
hi all,

I am doing a training for architects about agile and as a part of this
training i am looking for a game in which they can experience the
traps, pitfalls and benefits of doing architecture in an incremental
manner.
I was thinking about something with Lego but until this time I was not
able to think of something that delivers what I am looking for.
Any ideas?

Thanks for your help.
Elad.

Marc Loeffler

unread,
May 17, 2012, 6:44:39 AM5/17/12
to agile...@googlegroups.com
Hi Elad

What about the marshmallow challenge? Here is a link: marshmallowchallenge.com

Cheers
Marc

2012/5/17 Elad <elad....@gmail.com>:
> --
> You received this message because you are subscribed to the Google Groups "AgileGames" group.
> To post to this group, send email to agile...@googlegroups.com.
> To unsubscribe from this group, send email to agilegames+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/agilegames?hl=en.
>

Elad Sofer

unread,
May 17, 2012, 6:58:57 AM5/17/12
to agile...@googlegroups.com
Hi Marc,

I like the marshmallow game. Like it a lot actually but I Believe it's
target is to inspire creativity.
What I am looking for is a game that will emphasize the power of agile
& emergent architecture in a changing requirements environment.

Thanks for the reply,
Elad.

Sent from my iPad

Adrian Perreau de Pinninck

unread,
May 17, 2012, 8:08:54 AM5/17/12
to agile...@googlegroups.com
You can try a Lego Serious Game
Adrián Perreau de Pinninck Bas, Ph.D
Twitter: @eidrien

Elad

unread,
May 17, 2012, 8:55:17 AM5/17/12
to AgileGames
H again Marc and all,

Marc's reply made me think and I want to hear your thoughts:
If i use the marshmallow challenge and I introduce a requirement
change in the middle of the game like a bigger marshmallow or maybe
that the tower needs to be able to stand when the wind is blowing (the
wind being me blowing at it for example).

Would love to hear your thoughts...

Thanks,
Elad.

On May 17, 1:44 pm, Marc Loeffler <marc.loeff...@gmail.com> wrote:
> Hi Elad
>
> What about the marshmallow challenge? Here is a link: marshmallowchallenge.com
>
> Cheers
> Marc
>
> 2012/5/17 Elad <elad.so...@gmail.com>:

Jean-Charles Meyrignac

unread,
May 17, 2012, 11:13:47 AM5/17/12
to agile...@googlegroups.com
In fact, the Marshmallow Challenge is the perfect tool to demonstrate that we need to test the design incrementally. But there are much better exercises to test creativity.

I remember that the people who perform the best on this exercise are children and architects (the worst being CEOs), so I doubt that it'll be a challenge for them.

Another idea to encourage people for incremental design is to credit them for the size of their construction after each iteration (one iteration=10 or 15 minutes).
If the construction is not stable, they get a zero.
The winning team is the one with the highest total.
This will encourage early stable designs, and will introduce iterations/sprints.
You could also give them a 1 minute retrospective after every iteration.

JC

Michael.Tarnowski, Plays-in-Business.com

unread,
May 18, 2012, 6:00:16 AM5/18/12
to AgileGames
Hi Elad,

I developed a kind of LEGO construction challenge called "LEGO
Excavator" :

* for each group of participants buy one LEGO excavator kit (ex:LEGO
technic 8047, 7630)
* remove the building description for each.
* place *one* picture of the ready constructed kit on one table aside
(in a separate room for example).
* each group elects one or two "architects"
* the architects have ony *visuable* access to the picture as often
they want. (no camera, mobiles allowed, only paper & pencil)
* the architects describe their dev group members what they have
seen / what & how it should be implemented.

Do a debriefing on lessons learned:
* team communication
* changing implementation requirements

Have fun playing. Please drop me note on your experience: info@plays-
in-business.com

Cheers Michael
(Plays-in-business.com)
--------------------------------------------------------------------------------------------------


On 17 Mai, 17:13, Jean-Charles Meyrignac <jcmeyrig...@gmail.com>
wrote:

David Koontz

unread,
May 18, 2012, 6:42:27 PM5/18/12
to AgileGames
Great idea Michael. I did this in a master's class using kinect kit
helicopter - similar style game rules. It was fun and created
interesting group dynamic to discuss. But rather than one arch that
gave building instructions our rules allowed any team member to go
look - but there was only one member at a time allowed. I find the
arch is the only one allowed to "know" the design an interesting twist
that may create a great conversation about shared understanding of
design.

On May 18, 5:00 am, "Michael.Tarnowski, Plays-in-Business.com"

David Koontz

unread,
May 18, 2012, 6:57:47 PM5/18/12
to AgileGames

A colleague and I created a Jinga block exercise a month ago - haven't
iterated on the game yet.

Basicly: use a large number of Jinga blocks - we dyed some various
colors and numbered some of the blocks. We also had about 5 sets (54
blocks to a set). Most of the blocks we dumped on the table for play
were normal - some were dyed & numbered.

We gave the group instrucions to divide into build teams. Then gave
each a story to build in about 5 min.
- Build a barn
- Build a house
- Build a corral fence
- build 3 horses
- build 5 crops

We had 3 build teams, they built there stories. Then we stoped - took
pictures, had them demo their story, explain it to the other groups.

Then we had the teams switch tables... now they owned someone elses
work. Their next task was to integrate that sub-component with the
other components on a integration table. 1-2-3- go.

We gave them 10 minutes to integrate the scene ( a house, fence with
horses inside & crops on outside of fence).

After integration we stoped and demoed the poorer design, so much was
lost in translation (physical & figurative) the scene was had to
recognise.

Then we did Custome Validation Testing in the integration environment
- the colored blocks were defective and removed.

Fix the build. - But not on the integration table - take it back and
fix it in the dev environment. Then bring it back to integration and
re-integrate.

Out message was the waterfall process of integration hell that the
group had allowed to be standard operating procedure was hard in Jinga
blocks - guess how hard it was going to be in software.

You might try a variation on this type of simulation.

David
Reply all
Reply to author
Forward
0 new messages