Think With Your Hands!

On April 22, 2014, in Agile, by Eric Laramée

Our own Ellen Grove  on InfoQ!

EllenInfoQ

Ellen teaches improving personal development using the Lego Serious Play thinking, communicating and problem solving technique.

 

Share
 

Building Your Dreams at Agile India 2014

On March 8, 2014, in Agile, by Ellen Grove

I had a great time presenting a User Requirements with LEGO Serious Play workshop at Agile India 2014.  Sharing LSP with a new crowd is always fun, and the 100+ people who participated were enthusiastic and ready to play!

One lovely surprise from my session was the amazing graphic summary Lynne Cazaly created:

I think Lynne’s graphic is a better summary than my slides, but here they are anyhow:

If you’re curious to learn more about how LEGO Serious Play can help your team get work done or move forward in resolving a serious issue, check out my previous post on Why Serious Play Works or leave me a note in the comments so that we can chat.

Share
 

The Team Responsibility Game

On September 19, 2013, in Agile, by Ellen Grove

2013-06-14 20.26.54

I love games for learning – playing about serious matters allows people to drop some of the filters and barriers that may unconsciously affect how group discussions unfold and really explore ideas.  And the laughter and drama of playing a game that involves body, mind and emotions in order to learn about something helps ensure that the learnings stick.

At Play4Agile 2013, Markus Wittwer led an amazing and very popular game about team responsibility that explores the importance of shared intentions and playfully illustrates some of the effects of dysfunctional team behaviour.  I ran the same game during the Friday night playdate at Agile Coach Camp Canada 2013, where the participants had a lot of fun and made several excellent suggestions for how to extend and improve it.   Since then, I’ve been asked to share the exercise so that others can run it with their teams – here you go:

2013-06-14 20.25.25

Time required: 15-20 min

Number of players: teams of 7, the more teams the better

Materials:

  • big loops of rope – I bought 20M hanks of lightweight cord at a dollar store and cut it into ~6.5M long pieces.  For bigger groups, you may want longer loops.
  • beach balls – or other light balls (balloons, playground balls) roughly the size of a soccer ball.

The game:

  • Participants arrange themselves into teams of 7 and each person grabs onto the loop with two hands.  The team members should count off so that they know who is team member #1, team member #2,…through to team member #7
  • Each team make a net with the loop by passing the rope to each other until a net is formed.
  • Place a ball in the middle of each team’s net.  The team’s work is to keep the ball in play on the net – don’t let it fall!
  • The facilitator then guides the team through a number of actions/scenarios.  In each scenario, the team follows the instruction and attempts to move gently around the room while keeping the ball in play.  The facilitator may ask the team to return to a neutral state between scenarios (or not!):
    • the team moves around, learning to keep the ball in play
    • team member 1 takes 130% of the responsibility by pulling harder on the cord.
    • team member 2 gives up some responsibility by loosening their grip on the cord.
    • team members 3 & 6 have a conflict and try to pull apart while maintaining their grip on the net.
    • team member 4 leaves their home team and joins another team
    • team members  5 & 7 swap places
    • multi-tasking!: have one team member join onto another team while remaining part of their home team
    • remote team member: have one team member close their eyes
    • have the team members move around silently
    • have one team member remain immobile while the rest of the team moves around.

The debrief:

This is a really powerful game for dramatizing what happens when teams are not aligned in intent or are in a position where team members are distracted from the shared team goal by external factors.  I think it works best if you debrief as you go: run one or two scenarios, then pause and encourage participants to reflect on how they are feeling right then, and how the current situation reflects circumstances that are present on their teams.

Share
 

crazyclockAvoir un  horaire régulier pour la mêlée quotidienne est une règle de Scrum qui est considérée par plusieurs Scrum Masters débutants comme optionnelle. Pourtant, c’est leur responsabilité, en début de projet, quand l’équipe vient d’être créée, de renforcer cette règle.

Vous pensez « Vaut mieux attendre pour commencer, car tout le monde n’est pas arrivé? »

  • Si ça arrive souvent, personne n’hésitera à se faire un café à l’heure du daily, car on ne veut pas attendre pour une durée indéterminée que la rencontre commence;
  • À la longue, les gens seront de moins en moins ponctuels.

Vous pensez « J’aime mieux choisir le bon moment, dès que je me lève tout le monde se lève »

  • Si ce n’est pas prévisible, comment l’équipe peut-elle organiser son travail? Personne n’aime se faire interrompre, ça prend de 15 à 20 minutes après une interruption pour retourner dans le « Flow »;
  • Vous empêchez l’équipe d’être autonome sur cet aspect de leur organisation.

Vous êtes PO, SM, chargé de projet, et vous pensez « Je ne suis pas disponible, et je préfère vraiment être là, alors je vais reporter la rencontre »

  • La rencontre est d’abord destinée aux membres de l’équipe pour se synchroniser;
  • Selon le Guide Scrum, votre présence à cette rencontre est facultative.

Vous pensez « Comme je comprends qu’il faut que ce soit prévisible et toujours au même endroit, alors j’invite les gens d’avance à toutes les rencontres. Mais la salle n’est pas toujours dispo, alors ce n’est pas toujours à la même heure »

  • La routine simplifie la vie et permet d’établir un rythme de travail constant. Si la rencontre se déroule à tous les matins à 9h45, les gens vont développer un 6e sens pour s’interrompre à ce moment précis;
  • Il est possible de faire la rencontre dans un coin de bureau, il suffit d’avoir un accès au tableau de tâches;
  • Les réservations de salle peuvent se faire 1 an d’avance, bien souvent.

 

De plus, il y a un danger de tuer l’initiative. Voici quelque chose qui peut très bien arriver :Team Of 8 Blue People Holding Up Connected Pieces To A Colorful

  • Quelqu’un se présente, et elle est seule pour quelques minutes. Elle va revenir à son bureau, ou…
  • Elle va faire le tour du bureau, va demander aux gens pourquoi ils ne se lèvent pas pour la mêlée quotidienne. Si les gens résistent, elle va revenir à son bureau, sinon…
  • Elle continue sa tournée, dérange tout le monde dans leur travail, et enfin, les deux tiers de l’équipe fera la rencontre seulement : un membre est parti fumer dehors et un autre est en réunion.

Résultat :

  • Au mieux, si elle ne se décourage pas, il y aura un daily avec une partie de l’équipe;
  • Les chances qu’elle recommence sont minces;
  • Au final, il y a beaucoup de perte de temps et d’interruptions;
  • Si la rencontre n’a toujours pas lieu, les membres de l’équipe ne savent pas ce sur quoi les autres travaillent;
  • L’équipe a très peu de chances, dans ces conditions, de devenir réellement auto-organisée.

Avez-vous déjà entendu d’autres raisons? Pouvez-vous en imaginer?

Share
 

Well-formed user stories help Agile teams to make the right decisions about what to deliver next.  Ellen Gottesdiener and Mary Gorman’s excellent new book, Discover to Deliver: Agile Product Planning and Analysis, gives Agile teams practical guidance on planning and analysis practices that will help practitioners explore all dimensions of their product so that they are focused on learning the things that will enable them to deliver great products.

There ‘s an opportunity to have the “Discover To Deliver” class offered in either Ottawa or Montreal in October.  Visit this page to find out more about the course and indicate your interest in attending.  The more interest we have, the more likely it is we can bring Ellen or Mary to Ottawa to offer a fantastic learning experience.

Share
 

Agile Tour is a series of one-day non-profit Agile conferences held in 80+ cities around the world in October and November. Agile Tour conferences provide excellent learning value for not-very-much cost by bringing in top-quality keynote speakers and presenters, and are a great way to meet other Agile folks in your community.   Agile Tour Montreal has been going strong for several years now (they’re planning for 600 attendees in 2013), and I’m really excited that the Gatineau-Ottawa Agile Tour 2013 is shaping up to be even bigger and better than last year’s successful inaugural event.

Did I mention the excellent presenters at Agile Tour?  Do you have something to share that you’d be interested in getting out to an audience of energized and interested people?  Both Agile Tour Montreal and Gatineau-Ottawa Agile Tour  are soliciting proposals for presentations.  The deadline for submission is Aug 16 2013 for the Montreal event and August 30 2013 for Ottawa.  If you’ve got an Agile topic you’re passionate about, submit a proposal today!

Share
 

Since this is our first attempt at a collaborative post, Louis-Philippe Carignan and I decided to keep it small and simple by writing a top 10 list. As you’ll notice, the list got away from us! It has become a brain dump of the dysfunctions we’ve observed in various IT environments along our coaching careers. We also added a few tongue-in-cheek items ;)
brokenGears

 Top signs you work in a dysfunctional IT environment:

  1. Individuals are identified the same way as a printer: as resources
  2. Face to face communication is considered redundant if a document is available
  3. A mistake is noted and regurgitated during the annual performance review.
  4. A certification is the first measure of competence, but actual competence is a close second.
  5. The manager keeps saying, “the team needs to change”.
  6. When the team moves into the Storming phase, disciplinary measures are taken.
  7. The Architect or Team Lead decides how long something will take.
  8. Doing more in less time is seen as a cool challenge and motivational tool by management.
  9. “Generate more revenue” or “destroy the competition” are part of the Mission Statement.
  10. Looks and business clothes are promoted over innovative ideas.
  11. The analytical introverts are crushed by the driving extroverts.
  12. Management laughs at developers who dream of working at Google someday.
  13. Status quo is the strategy.
  14. Overheard: He’s not complacent. He’s a good team player.
  15. Overheard: There is no place for emotions in business.
  16. The EQ test application crashed trying to generate a negative value.
  17. Your manager looks the other way when you pass him in the hallway.
  18. Technical debt is taken care of by maintenance because the project has to stay on budget.
  19. Cubicle farms here, there, everywhere.
  20. It’s called happy hour when really it’s denial, lay blame, justify, and shame hour.
  21.  Management loves to quote passages from “The Principles of Scientific Management”
  22. Soft skills training for management???
  23. The project manager reassures the client that everything will be delivered on budget and on time.
  24. Big visible charts are taken down because it doesn’t look “professional”.
  25. The less you code, the better you are paid.
  26. To get your idea across to another silo, you need to go up the food chain until the VPs of each silo talk to each other.
  27. Coders are seen as the bottom of the food chain.
  28. In the hallway you often hear, “only 2 more days before the weekend”.
  29. “Fun” is what you do at the country club. You work at the office.
  30. Meetings extend their time boxes. Decisions are never made. No accountability.
  31. Big Hairy Audacious Goals (BHAGs) are seen as irresponsible.
  32. Transparency feels like rubbing alcohol on a open wound.
  33. The Director spreads Agile in every team like fairy dust.

What have you observed?

 

Share
 

Simulation Lego : un retour d’expérience

On July 8, 2013, in Agile, Case Study, by Isabelle Therrien

Au cours des deux dernières semaines, Ellen et moi avons donné ensemble une formation de mise à niveau sur l’Agilité et Scrum : la première en anglais (15 personnes), et la semaine suivante en français (18 personnes). Nous y avons testé avec grand bonheur la simulation Lego basée sur un article d’Alexei Krivitsky.

Détail du bar, un élément essentiel à la ville!

Détail du bar, un élément essentiel à la ville!

Cette simulation, qui dure en tout 1h30 en incluant la discussion d’apprentissage, consiste à construire un village en 3 sprints de 15 minutes. Ellen a facilité l’exercice; de mon côté, j’ai joué le rôle de Product Owner et je me suis vraiment amusée! Outre le fait de réaliser tout mes fantasmes (tel un Ferrandez, je voulais ma ville autonome, où on se déplace à pied ou à vélo exclusivement, donc sans trace d’énergie fossile), je me suis vraiment éclatée à jouer tous les travers des Product Owner que j’ai rencontrés dans ma carrière. « Comment ça, prioriser? Je veux tout! »

Détail du parc pour enfants

Détail du parc pour enfants

La première cohorte s’est vraiment surpassée, et ce dès le premier sprint. Les 3 équipes ont collaboré afin de créer les 10 maisons que j’avais demandées. Cependant, pas beaucoup de «travail terminé», et certainement pas dans un environnement d’intégration! Une équipe a toutefois songé à une « technologie » qui a permis aux autres équipes de terminer leurs maisons rapidement au deuxième sprint.

À la fin du premier sprint, ils ont réalisé que mon qualificatif d’ « harmonieux » n’était pas très clair, et ils m’ont demandé des détails qui ont été immédiatement partagés avec tout le groupe : une seule couleur par rangée de blocs! Un toit sur toutes les maisons ! Voilà un bel embryon de Définition de Terminé. Surtout, ils ont eu la prise de conscience qu’une compréhension commune de tous les termes est essentielle.

Ensemble de la ville et illustration de l'utilisation de moyens modiques pour obtenir de grands buildings

Ensemble de la ville et illustration de l’utilisation de moyens modiques pour obtenir de grands buildings

Ils ont été très créatifs en me proposant des solutions plus simples pour réduire mes coûts : ils ont utilisé les boîtes de blocs pour faire des buildings. Bien qu’au début aucun n’ait osé s’engager à tout livrer ce que j’avais demandé, ils ont réussi à la fin du sprint 2 à dire avec certitude qu’ils allaient tout terminer avant la fin du sprint 3. Il a dû y avoir des échanges de blocs entre les équipes et des ambassadeurs qui facilitaient la communication entre les équipes.

La deuxième semaine, nous nous sommes assurés d’avoir des items qui allaient poser davantage de problèmes à nos constructeurs en herbe. En plus de la rivière, des parcs, des maisons, de l’édifice pour travailler et des différents commerces, j’ai demandé une piste cyclable et un centre d’achat afin d’explorer les difficultés reliées à l’intégration inter-équipes. La piste cyclable a été très intéressante : comme nous ne spécifions pas comment organiser leur carnet de produit, ils se sont retrouvés avec un item « qui ne finirait jamais » selon sa définition initiale. Nous leur avons tout simplement suggéré de s’assurer de terminer en un sprint en élaborant des conditions de succès précises (ex. « la piste se rend à tous les bâtiments terminés ») puis en l’ajoutant à la Définition de Terminé pour la suite.

Centre d'achat non terminé, piste cyclable, centre-ville et parc!

Centre d’achat non terminé, piste cyclable, centre-ville et parc!

Quant au centre d’achat, il n’a été pris qu’au 3e sprint (de force, il a fallu que j’insiste sur le fait qu’il était bien en haut du carnet), et l’équipe n’a pas cru bon me demander la taille souhaitée. Ils sont partis sur quelque chose de trop gros pour leurs moyens (en nombre de briques et en temps) et n’ont pas pu finir. Comme ils ont commencé par les fondations, plutôt que de terminer les boutiques une par une, j’en ai profité pour leur expliquer la notion d’ « incrément potentiellement livrable ».

À retenir pour la prochaine fois :

  • Laisser les équipes prendre le contrôle du carnet quand on l’élabore permet de voir comment ils l’organisent intuitivement;
  • Il est utile de soulever des points d’apprentissage clairement tout au long de l’exercice, pas seulement à la fin;
  • La phase d’estimation n’est pas essentielle, mais drôlement utile pour faire comprendre la puissance de la complexité relative (les story points);
  • Le rôle de Scrum Master dans la simulation n’est vraiment pas essentiel ;
  • Se limiter à 4 membres dans chaque équipe est raisonnable; de toute façon, les équipes plus grosses se subdivisent en petites équipes naturellement;
  • Nous avons fait plus rapidement qu’il est indiqué la phase de démarrage de projet et ça a très bien fonctionné pour nous.
Centrale éolienne et solaire, et centre de recyclage

Centrale éolienne et solaire, et centre de recyclage

À essayer pour la prochaine fois :

  • Réduire le nombre de blocs Lego en début de projet ou encore au début du 3e sprint pour voir comment l’équipe arrive à s’adapter;
  • Si on peut faire la simulation plus longtemps, expérimenter des changements dans les équipes et observer les dérangements occasionnés.

Ce sera définitivement à répéter, la rétroaction sur la formation ayant fait ressortir de façon très marquée que c’était très instructif et divertissant. De plus, la simulation nous a fourni un nombre incalculable d’exemples pour la suite de la journée, en mode « exposé ». Personnellement, j’ai aussi préféré cela aux simulations que j’ai faites dans le passé avec du papier (prototype papier ou projet de brochure) car ça élimine la variable « talent artistique » de l’équation pour mettre l’emphase sur l’activité créative, en plus d’être amusant et de produire des résultats satisfaisants pour tous : l’équipe ET le product owner

Share
 

On Tuesday, I had the pleasure of presenting “An Introduction to Lean and Agile Work” to one of the IEEE Ottawa SIGs

As a prelude  to the conversation, we played a simple variant of the penny game in order to spark some lively discussion and great questions to frame the rest of the evening.  We then talked about Agile values and principles, and how those ideas are manifested in Agile and Lean practices.  As the group was quite small, it was less of a formal presentation and more of a conversation with a few pictures to help clarify key ideas about Scrum and Kanban:

scrum 3

image

 

 

 

 

 

 

 

The conversation was lively and long (as an Agile coach, I tell myself that one day I’ll get the hang of this time-boxing thing!), and from the comments afterwards it was clear that the talk had sparked a lot of curiosity about how these ideas could be applied in practice. My favourite comment was “You know, we’re supposedly doing Agile at work, but we’re missing a couple of really basic elements.  I get it now!”.

Here are the slides from the presentation:

Download the Scrum & Kanban Fundamentals handout.

 

Share
 

Scrum has no meetings

On April 21, 2013, in Agile, by Eric Laramée
  • Sprint Planning: It’s not a meeting.  It’s an opportunity for collaborative software development.
  • Daily Standup: It’s not a meeting.  It’s an opportunity to share a goal and see how it interacts with the other team member’s goals.
  • Sprint Review: It’s not a meeting.  It’s an opportunity to showcase the most amazing piece of software ever and realize that it can be even better.
  • Sprint Retro: It’s not a meeting.  It’s an opportunity transform bad to good and good to great.
Share
 
Follow

Get every new post on this blog delivered to your Inbox.

Join other followers: