Timing

30 mins

Ingredients

  • Supplies for each team: play dough, pipe cleaners (chenille stems)

Directions

Each team selects one Business Analyst (or Product Owner) to come look at a picture of an item that a customer wants built. The BA’s are instructed to only use imperatives and similes (no ‘rhymes with’) and to not use certain words (like the game Taboo) when describing the item to the rest of their team.

  • In round 1, the item is something simple (such as a chair), but the BA must communicate only in writing. This should only take a few minutes for the team to create using the given supplies.
  • In round 2, the item is something simple (a teapot), but the BA can speak with their team. This should show how much easier it is to communicate by speaking.

 

Note: A quicker alternative to this game is to have teams draw the items instead of using the supplies.

Learning Points

  • In software, we are rarely creating something that already exists. Without a common vocabulary, we are forced to communicate in imperatives and metaphors and, quite often, much is lost in translation.
  • Iterative development with demonstrations allow us to hone in on what is really needed, rather than what is asked for.

Tempo

30 mins

Materiais

  • Suprimentos para cada time: massa de modelar, limpadores de cano (hastes de cordão)

Receita

Cada time seleciona um AN – Analista de Negócios (ou PO – Product Owner) para ir à frente da sala para olhar a figura de um item que o cliente quer construir. Os AN’s são instruídos a usar apenas imperativos comparações (nada do tipo “rima com”) e a não usar certas palavras quando descrevendo o item para o resto do time.

  • No round 1, o item é algo simples (como uma cadeira), mas o AN deve se comunicar apenas de forma escrita. Isso deve levar apenas alguns minutos para o time criar o item usando os suprimentos dados.
  • No round 2, o item é algo simples (uma chaleira), mas o AN pode falar com o time. Isso deve mostrar como deve ser mais fácil se comunicar através da fala.
  • No round 3, é mostrado ao AN um item que não é fácil de comunicar (uma moto ou um kit de maquiagem até um mouse de computador, por exemplo). Desde que itens como esses não são comuns os mesmos devem ser bem mais difíceis de construir.

Nota: Uma rápida alternativa para esse jogo é fazer os times desenharem os objetos ao invés de utilizarem os suprimentos.

Pontos de aprendizado

  • Em software, raramente nós estamos criando algo que já existe. Somos então forçados a comunicar usando imperativos e metáforas e frequentemente muito é perdido na tradução.

Duración

30 mins

Ingredientes

  • Material para cada equipo: plastilina, limpiapipas

Instrucciones

Cada equipo selecciona un Analista de Negocios (o Dueño de Producto) para pasar la frente de la clase a mirar una foto del producto que el cliente quiere construir. El analista debe describir el producto al equipo usando sólo imperativos y símiles (parecido a… , no rima con …) y no usar ciertas palabras.

  • En la primera vuelta, el producto es algo simple (por ejemplo una silla) pero el Analista debe comunicarse solo por escrito. Esto debería tomar solo unos minutos para que el equipo lo cree con los materiales.
  • En la segunda vuelta, el producto es algo simple (una tetera), pero el Analista puede hablar con el equipo. Debería mostrar cuanto más sencillo es comunicarse hablando.
  • En la tercera vuelta, se le muestra al Analista un producto que no es tan fácil de comunicar (por ejemplo una casa rodante de moto, o una caja de maquillaje hecha en un mouse de computadora). Como los productos son menos comunes, debería ser mucho más dificil de construir.

Nota: Una alternativa más rápida de este juego es que los equipos dibujen el producto en vez de construirlos con el material.

Puntos de aprendizaje

  • En software, pocas veces hacemos algo que ya existe. Entonces estamos obligados a comunicarnos con imperativos y metáforas y, a menudo, se pierde mucho en la traducción.

Время

30 минут

Материалы

  • Каждой команде выдаются: пластилин, цветные проволочки (pipe cleaners)

Правила

В каждой команде выбирается один Бизнес-аналитик (или Product Owner), которому показывают изображение предмета, необходимого заказчику. При описании этого предмета своей команде, Бизнес-аналитик может пользоваться только указаниями и сравнениями (которые не рифмуются с предметом) и не должен использовать точные слова (как в игре Taboo или “Крокодил”).

  • В 1-м раунде, предметом является что-то простое (например, стул), , но Бизнес-аналитик должен общаться только в письменной форме. На создание предмета из розданных материалов у команды должно уйти несколько минут.
  • Во 2-м раунде предметом также является что-то простое (например, чайник), но Бизнес-аналитик уже может разговаривать со своей командой. Это должно показать, насколько легче общаться посредством речи.

 

Примечание: в качестве более быстрой альтернативы этой игры, можно попросить команды рисовать предметы вместо использования материалов.

Выводы

  • При разработке программного обеспечения, мы редко создаём то, что уже существует. Не владея одинаковой терминологией, мы вынуждены общаться, используя указания и метафоры, и, нередко, многое теряется при объяснении.
  • Итеративная разработка с демонстрациями результатов позволяет сконцентрировать усилия на том, что действительно нужно заказчику, а не на том, что просили изначально.

Перевод: Андрей Санин

7 thoughts on “What Were They Thinking?O que eles estavam pensando?¿Qué estaban pensando?Что Они Думали?

  1. A few notes on how this exercise has evolved for me over the years:
    1. I only ever have them draw, rather than use play dough or pipe cleaners. I get the same results and it is a lot easier to prep and a lot less messy.
    2. For larger groups, I pair people up (one a product owner and one a developer) and have the developers face away from the projector screen, which displays the image and taboo words. This is quicker and smoother than having a PO come up and write down the taboo words.

  2. Hi Amber,

    The taboo words I use are:

    For Chair: sit, seat, stool, rest, furniture, table
    For Teapot: tea, pot, short, stout, coffee, water, heat
    For RV-Bike: motorcycle, bike, camper, rv, trailer, chopper, harley

    Of course, these may need to be adjusted for different audiences and cultures.

    Don

  3. What words would you not allow them to use when describing the item? Obviously Chair, but what other descriptive words would you leave out?

  4. Hi Lodewijk!

    Thanks so much for your comment. I agree, many developers understand the imperfection of language to completely describe what is fundamentally an uncertain goal. The intent of this game is to illustrate that point to those less familiar with the nature of building software.

    The idea of changing the game to illustrate the need for feedback in empirical processes sounds really interesting. I wouldn’t say you’re on the wrong track in any way. It is just not the path we went down when we created the game. I would be interested in hearing how this works for you. Perhaps you could even post it as a new game!

    Mike

  5. I am very much in favor of activating people when learning, and preferably in a fun way.
    I do think this is a nice exercise, but I am wondering to what extent we need to let people experience “In software, we are rarely creating something that already exists. So we are forced to communicate in imperatives and metaphors and, quite often, much is lost in translation.”

    Certainly almost every developer is aware of this, right?
    Now I am wondering if this could be improved (and e.g. “Mr. Happy Face” does a better job at that) to let people experience an alternative way of working: indeed the difference in round 1 and 2 is doing that, but the overall feeling after the game will remain: we have a problem (as we already knew).
    So why not have (equally difficult?) assignments where in the last round, additional iteration/feedback cycles are allowed, to show that the result is actually better? (or even continuous feedback while the team is working…)

    You could even introduce economics in it, perhaps? -> e.g. cost per time unit, every time you iterate, costs additional, delivering the wrong thing will yield nothing.

    If I am on the wrong track with my suggestions; please enlighten me!

    cheers,
    Lodewijk Bergmans

    PS: especially when drawing, this is much like the party game ‘pictionary’–great fun indeed

Comments are closed.