Stay Updated: Posts | Comments   Follow us on Twitter

Name: Erwin

Web Site: http://erronis.nl

Posts by :

    The Blame GameLe jeu du blâme

    October 27th, 2012

    This is a game to let people experience the effects of different punishments/rewards systems have on the way a team works together. One team will be ‘The Team’ which is rewarded and punished on a team level and ‘The Individuals’ have a mix of team and individual rewards and punishments.

    Timing: 20-45 minutes
    Materials: Deck of Cards, rules instructions, paper/pen to keep track of scores
    Instructions:
    Divide the groups in 2 groups. Ideally around 4-7 people per group. Explain people that the point of the game is to build one or more houses of cards.

    The 2 groups are going to have slightly different rules. One team will be rewarded and punished on a team level and the others will be rewarded individually.
    Whenever I talk about a section in the rest of the rules I mean either the 2 cards standing up ( /\ ) or the card covering it ( — )

    The ‘Team’ scores as follows:
    2 pts for every section they add to the house. This is multiplied by the layer they have added it to. So on the second layer they get 4 points. On the third layer they get 6 points.
    -10 pts for every time the house (partly) collapses.

    The ‘Individuals’ score as follows:
    1 pt for every section added to the house, multiplied by the level for the individual
    1 pt for every section added to the house, multiplied by the level for the team
    In the event of a (partial) collapse the person whose turn it is gets -8 points. And he can shift the blame by choosing someone else to also receive -2 points.

    Both teams are also required to keep track of how many sections at what level they add and how many times the house collapsed.
    It is also possible for a person to pass and not attempt to add any more cards.

    The reason to give them their printed instructions and not explain it in public is that you do not want the teams to know they are playing by 2 different rules.
    Give them 5 minutes to build houses. As soon as one collapses they can keep going and start over.

    After the 5 minutes are up, ignore the scores and gather the statistics on the amount of sections added and total number of collapses.
    Then do a debriefing to gather experiences and see what was different between the 2 teams.

    If there is time do a round with both groups on the team score for some friendly competition.

    Learning Points:

    What usually happens is that The Individuals will be competing against each other. They are probably more risk-averse and look to blame strategically. After someone has a high enough score they sometimes sit back and pass instead of taking the risk of losing their lead.
    The Team on the other hand is working together. They are figuring out the way to place cards, help each other place them and warn when they see something going on.
    Compare this with how bonuses and blame is usually distributed in their organisation.

    Special thanks to the people in my PLAID workshop at the AgileHolland Agile Games Night who came up with the problem and the resulting brainstorm and the volunteers at Agile Coach Camp Denmark for being guinea-pigs.Ce jeu a pour objectif d’illustrer et d’expérimenter les différents effets de systèmes d’évaluation (méthode de la carotte et du bâton) sur le travail en équipe. Pour ce faire, une première équipe sera évaluée à l’échelle de l’équipe, tandis que la seconde équipe sera évaluée à deux niveaux, individuel et équipe.

    Durée : 20-45 minutes
    Matériels : jeux de cartes, instructions / règles, papiers, stylos (afin de noter les scores).
    Instructions :
    Répartir le groupe en 2 équipes, idéalement entre 4 et 7 personnes par équipe. Expliquer aux participants que l’objectif de l’atelier est de construire un (ou plusieurs) château de cartes.

    Les deux équipes ont des règles légèrement différentes. Un groupe sera évalué au niveau de l’équipe tandis que le second appliquera un système d’évaluation individuelle.
    Lorsque je parlerai de « section » dans le reste des consignes, il s’agira de 2 cartes verticales posées l’une contre l’autre (/\) ou de la carte horizontale de recouvrement (—).

    L’équipe est évaluée sur cette base :
    2 points pour chaque section ajoutée au château, multipliés par le numéro de l’étage sur lequel la section est ajoutée. Au deuxième étage, ils reçoivent 4 points. Au troisième étage, l’équipe reçoit 6 points, et ainsi de suite. Un malus de 10 points sera affecté à l’équipe, à chaque fois que le château s’effondre (même en partie).

    Les individus sont évalués sur cette base :
    1 point pour le constructeur, par section ajoutée au château, ainsi qu’un point pour son équipe. Les points sont à chaque fois multipliés par le numéro de l’étage sur lequel a été construit la section. Dans le cadre d’un effondrement partiel ou total du château, la personne ayant causé l’effondrement perd 8 points, plus 2 points supplémentaires qu’il peut affecter à un membre de son équipe.

    Les deux équipes doivent enregistrer le nombre de sections construites, le nombre d‘étage atteint ainsi que le nombre de fois que le château s’est effondré.
    Il est aussi possible pour une personne de ne pas participer à la construction ou de cesser sa contribution à la construction du château.

    La raison pour laquelle les instructions sont imprimées et non pas expliquées publiquement est que vous ne vous voulez pas que les 2 équipes sachent qu’elles jouent avec 2 règles différentes.
    Après avoir pris connaissances des règles, donnez-leur 5 minutes pour construire le château. Dès que le château s’écroule il peuvent poursuivre la construction ou repartir de zéro.

    Au bout de 5 minutes de jeu, ignorez les scores finaux et réunissez les statistiques sur le nombre de sections ajoutées et le nombre total d’effondrement.
    Puis faites un débriefing afin de partager les expériences et d’observer les différences entre les deux équipes.

    Si il reste du temps, vous pouvez faire une nouvelle itération avec les mêmes règles pour les deux équipes pour une compétition amicale.

    Points d’apprentissage :
    Généralement les individus lorsqu’ils sont évalués à titre individuel entrent en compétition les uns contre les autres. Ils seront surement plus frileux face au risque et chercheront à nuire de manière stratégique. Lorsque quelqu’un a un score suffisant, parfois, il limite le risque et sort du jeu plutôt que de perdre sa place de leader.
    De l’autre coté, l’équipe travaille ensemble. Ils échangent sur la manière de positionner les cartes et s’entraident de manière à prévenir tout effondrement. Comparez cette expérience avec la situation réelle d’intéressement ou de sanction en pratique dans leurs/les organisations.

    Remerciement spécial aux participants de mon atelier PLAID lors de l’AgileHolland Agile Games Night qui sont venus avec les réflexions qui ont débouché sur le brainstorming à l’origine de cet atelier ainsi qu’aux volontaires de l’Agile Coach Camp Denmark pour l’avoir « testé ».

    VN:F [1.9.16_1159]
    Rate This
    Rating: 4.8/5 (4 votes cast)

    15 Comments "

    Agile Airplanes

    July 28th, 2011

    John Heintz, from Gist Labs, has just released his Agile Airplane Game at http://gistlabs.com/article/377/agile-airplane-game.

    It is a game in which multiple teams have to coordinate to fold certain quantities of different airplanes that meet certain acceptance criteria (like being able to fly 🙂 ). John has made a nice matrix on what aspects of agile are covered by this game:

    Read the rest of this entry “

    VN:F [1.9.16_1159]
    Rate This
    Rating: 4.5/5 (6 votes cast)

    8 Comments "

    The Big PayoffБольшой Куш

    July 3rd, 2011

    The Big Payoff is a portfolio game invented by Alexandre Boutin (@agilex) and Erwin van der Koogh (@evanderkoogh) at the Agile Games Conference 2011 in Boston during the ‘Design your own game’ track by Don McGreal (@donmcgreal) and Michael McCullough (@mccm68) of Tastycupcake.org fame. It has won ‘Most Creative Game’ at that conference.

    The game is designed to give people a taste of what it is like to manage a portfolio in an agile organisation. The learning objectives are:

    1) Show how much better Agile projects are for portfolio management
    2) Show the advantage of planning with stable teams

    Please note that this is a fairly complicated game and that it needs a bunch of iterations to properly tweak it. At the end of the post is a list of things we still think need some improving. Please help us improve by sharing your experiences with the game.

    Time:

    * Explain: 10m
    * Play: 45-60m
    * Debrief: 10m

    Ingredients

    * Big piece of paper (like flipover, ideally with grid)
    * Bunch of paper (2 different colors)
    * Pen
    * Sissor

    We need 1 board with materials for every 3-5 participants.

    Preparations

    On the big paper make a big table with horizontally 4 teams and verticially 12 quarters. Make sure the cells are big enough, about 5x5cm
    This is going to be the planning board. Now we need to make some projects. We do this by making strips of paper. The length of the paper is the length of the project and on it we put a number. The number represents the value of the project when it is completed.
    The ratio that we will be using during this game is value/quarter. So pick an average value/quarter and create a bunch of projects with value above and below that average. Use one color for agile projects and another for waterfall projects.
    Be sure to include some very juicy waterfall projects with a high value/quarter, we are going to mess with them later 🙂
    Make an overview of the projects and their value/quarter.

    Next are some constraints. Dependencies between projects, projects that need to be finished before a certain time or can’t be started before a certain quarter. Or can only be done by a certain team.
    The whole point is to give them a big puzzle where they have to optimize the projects to score as many points as possible in the next 3 years.
    Next up are the event cards. Of course nothing is going to go according to plan. So be creative and make up some events. High value projects with very tight deadlines, halving the value of big waterfall projects, CEO pet projects with no or little value that have to be completed, projects taking longer etc etc.

    Directions

    Explaining the game

    When explaining the game do not tell participants about the events. Keep those events to yourself. Just present the board, the projects and the constraints. In fact, do not even tell them about Agile and waterfall projects. Or about value/quarter.
    Explain that, except for constraints, all projects can be done by all teams.

    Playing the game

    Leave the players with the puzzle. It will usually take them about 20-25 minutes to figure out the best configuration. During this someone will have figured out value/quarter. Once they do give them the value/quarter sheet. That is going to save them quite some time.

    Once they are happy with the configuration and look at you to tally the results walk to a board, write down Q1, and write down their total for Q1, which is most likely 0. Then grab the event cards and pick one.
    Give them a couple of minutes to change the plan with this new information and then tell them the difference between agile and waterfall projects. Agile projects can be divided for the value/quarter rounded down. So an 18 value Agile project taking 4 quarters can be divided into 4/9/13/18 points. This is to represent that they are delivering value throughout.

    Keep going for 4-8 quarters or until time runs out, but leave about 10 minutes for the de-briefing.

    Learning points

    Debriefing

    Go over the game and see what people have learned. People will most likely have realized the risk of waterfall projects, how easy it is to be able to cut up Agile projects and realize partial business value. Explain that the game is a bit oversimplefied (all teams can do all projects for example), but this can work without much alteration in real life.
    And that there’s a lot more ‘shit’ happening in RL than the game.

    Things to tweak

    As mentioned before this game is still in a beta phase. There are quite a few variables that still need tweaking. This is a list of stuff that doesn’t quite work as we want it to. If you have any suggestions to improve these or other areas, please drop us a line or comment below.

    • Work out the projects/constraints/events to optimize the chances for difficult decisions
    • People are confused about the 2 colors projects
    • I am going to try names of animals next, with fishes for waterfall projects and cats for agile projects
    • How to get people emotionally involved/attached to the current plan.
    • It is now too easy to completely change a project that has not started yet.
    • Fixed events vs random ones
    • Fixed events make it possible to prepare carefully prepared traps.
    • Random events make it clear for the players that unpredictable ‘shit happens’
    • Figure out what to do with projects that go over the 12th quarter

    Портфельная игра Большой Куш придумана Александром Бутиным (@ agilex) и Эрвином ван дер Коогхом (@ evanderkoogh) на Agile Games Conference 2011 года в Бостоне на треке «Создай свою собственную игру» Дона МакГрила (@ donmcgreal) и Майкла Маккалоу (@ mccm68), которых мы знаем по Tastycupcake.org. На конференции она получил приз «Самая креативная игра».

    Игра разрабатывалась так, чтобы дать людям почувствовать, как это – управлять портфелем проектов в Agile организации. Учебные цели игры:

    1) Показать, насколько удобнее Agile проекты при управлении портфелем
    2) Показать преимущества планирования со стабильными командами

    Имейте в виду, пожалуйста, что это довольно сложная игра, и для точной подгонки потребуется не одна итерация. В конце описания мы включили список вещей, которые, по нашему мнению, всё ещё нуждаются в улучшении. Пожалуйста, поделитесь с нами вашими впечатлениями от игры и помогите нам улучшить её.

    Время:

    * Объяснение правил: 10 мин
    * Собственно игра: 45-60 мин
    * Подведение итогов: 10 мин

    Материалы

    * Большой лист бумаги (как на флипчартах, в идеале в клетку)
    * Пачка бумаги (двух разных цветов)
    * Ручка
    * Ножницы

    Потребуется по одной доске с таким комплектом на каждых 3-5 участников игры.

    Подготовка

    На большом листе нарисуйте большую таблицу с четырьмя командами по горизонтали и 12 кварталами по вертикали. Клетки должны быть достаточно большими, примерно 5х5 см.
    Это будет доска планирования. Теперь нам надо сделать несколько проектов. Их мы изобразим полосками бумаги. Длина полоски соответствует длительности проекта, а на самих полосках напишите числа. Числа означают прибыль от проектов по их окончании.
    В игре нас будет интересовать параметр прибыль за квартал. Выберите среднее значение прибыли за квартал и сделайте пачку проектов, для которых это значение выше или ниже среднего. Полоски одного цвета будут Agile проектами, а другого – водопадными.
    Не забудьте сделать несколько очень нажористых водопадных проектов с высоким значением прибыли на квартал, мы с ними потом ещё разберемся 🙂
    Сделайте обзор проектов и их прибыльности за квартал.

    Далее введём некоторые ограничения. Зависимости между проектами, проекты, которые должны быть закончены к определённому сроку или которые не могут быть начаты ранее определённого квартала. Или которые может выполнить только конкретная команда.
    Главная задача – дать участникам большую головоломку, в которой им придётся оптимизировать проекты так, чтобы за следующие 3 года набрать максимальное количество очков.
    Потом появляются карты событий. Разумеется, ничто никогда не идёт по плану. Дайте простор воображению и придумайте разных событий. Прибыльные проекты с очень жёсткими дедлайнами, уполовинивание прибыльноети больших водопадных проектов, любимые проекты CEO с нулевой прибылью, но от которых не отвертеться, затянувшиеся проекты, и т. п.

    Правила

    Объяснение игры

    Объясняя правила, не говорите участникам о событиях. Держите их при себе.Покажите участникам доску, проекты и ограничения. На самом деле, не надо даже рассказывать про Agile и водопадные проекты. Или о прибыли за квартал.
    Объясните, что, за исключением соответствующих ограничений, любой проект может быть выполнен любой командой.

    Ход игры

    Оставьте игроков решать головоломку. Поиск оптимальной конфигурации займёт у них минут 20-25. За это время кто-нибудь успеет догадаться про значение прибыль на квартал. Когда это произойдёт, дайте им листок со списком проектов и соответствующими значениями. Это сэкономит игрокам изрядное количество времени.

    Когда игроки будут довольны полученной конфигурацией и попросят вас подсчитать результат, напишите Q1 и подведите итог за первый квартал. Скорее всего, он будет 0.Затем возьмите карточки событий и выберите одну из них.
    Дайте игрокам пару минут, чтобы изменить план согласно новой информации, и расскажите им про разницу между Agile и водопадными проектами. Agile проекты можно разделить на куски, округляя прибыль вниз. Так, Agile проект длительностью 4 квартала, приносящий прибыль 18, можно разделить на куски с прибылью 4/9/13/18.Это символизирует непрерывное создание ценности в течение проекта.

    Повторите 4-8 кварталов (или пока не вышло время), и не забудьте оставить минут 10 на подведение итогов.

    Выводы:

    Подведение итогов

    Обсудите игру и посмотрите, что из неё узнали участники. Скорее всего, они осознали риски водопадных проектов, и то, как легко делить Agile проекты на части для получения частичной бизнес-выгоды. Объясните, что игра, конечно, упрощает ситуацию (так, например, любая команда могла выполнить любой проект), но и в реальной жизни всё это работает без особых изменений.
    Ну и, конечно, в жизни случается существенно больше неприятностей.

    Простор для улучшения

    Как мы уже говорили, игра всё ещё на стадии беты. В ней остаётся много переменных, которые нуждаются в настройке. Вот список того, что работает не совсем так, как хотелось бы. Если у вас есть предложения по улучшению этих или каких-то других областей, оставьте, пожалуйста, комментарий или напишите нам письмо.

    Подогнать проекты, ограничения и события так, чтобы повысить вероятность сложных решений
    Люди путаются в проектах двух цветов
    В следующий раз я попробую названия зверей, водопадные проекты будут рыбами, а Agile проекты – из семейства кошачьих.
    Как добиться эмоциональной вовлечённости и привязанности к текущему плану
    Сейчас слишком просто совершенно изменить проект, который даже не начался.
    Фиксированные события или случайные
    Фиксированные события позволяют тщательно подготовить ловушку.
    Случайные события дают чётко понять, что случаются непредсказуемые неприятности.
    Разобраться, что делать с проектами, которые выходят за 12-й квартал

     

    Перевод Alex Pchelintsev

    VN:F [1.9.16_1159]
    Rate This
    Rating: 4.2/5 (5 votes cast)

    2 Comments "

Discuss Login
Recent Comments