Pyxis

Mettre de la pression sur le système pour faire apparaître le gaspillage

Afin de faire apparaître les goulots d’étranglement dans le processus de réalisation d’une équipe fonctionnant en Kanban, j’ai proposé de réduire les limites du WIP¹

Lors de la mise en place, l’équipe a fixé des limites confortables pour le WIP. Après deux semaines d’utilisation du tableau, l’équipe n’a pas identifié de goulot d’étranglement.
Lorsque j’ai fait ce constat, j’ai proposé au coordonnateur, lorsqu’il a remodelé le tableau à la réception du nouveau tableau, de réduire la capacité de certaines colonnes en plus des modifications prévues lors de la rétrospective.

Cela va bientôt faire trois mois que le tableau Kanban est en place et deux mois que les limites ont été baissées, et nous avons observé des difficultés telles que les suivantes :

1. Des cartes sont bloquées depuis plusieurs jours et il ne reste qu’un espace disponible dans la colonne pour passer des nouvelles demandes.
2. Il y a deux cartes dans une case.
3. Une case ‘blocage spécial’ à été crée pour sortir une carte qui est bloquée et qui n’est plus prioritaire.

En discutant avec l’équipe, il apparaît que la baisse des limites a eu l’effet escompté, puisque avant cette baisse, il y avait suffisamment de place libre pour que de nouvelles cartes puissent passer même si d’autres étaient bloquées.

Content de ce résultat, je comptais proposer à l’équipe de réduire le nombre global de cartes présentes dans le tableau, car actuellement, les limites établies permettent d’avoir un nombre que « je » juge trop important d’items en cours simultanément.
En effet les limites sont établies par étapes du flux de travail, mais les mêmes personnes travaillent sur plusieurs étapes et cela ne force pas les items à sortir le plus vite possible, certains restant même plusieurs jours dans le backlog.

Mais je me suis ravisé car mes solutions ne seront jamais meilleures que celles de l’équipe.
Alors, au lieu de proposer ma solution de réduction du nombre de cartes dans le tableau, j’ai proposé à l’équipe de travailler sur la notion de gaspillage lors d’une rétrospective.

À la suite de cette rétrospective, après avoir identifié l’attente (une carte est souvent en attente dans le tableau) comme l’un des plus gros poste de gaspillage, l’équipe a commencé à mesurer le temps passé par les cartes dans les différentes phases du processus à l’aide de la méthode proposée dans l’article « Flow. Discover Problems and Waste in Kanban ».
J’espère que ces mesures permettront à l’équipe de trouver « ses » solutions pour éliminer le gaspillage, solutions qui rendront la mienne obsolète.

Quels sont les mécanismes que vous mettez en place pour contraindre le système ? Quels sont les résultats que vous obtenez ?

_agilely Timer permet aux praticiens de l’Agilité ayant un iPhone ou un iPod Touch de gérer efficacement les blocs de temps, les mêlées quotidiennes et les tables rondes. Dans quelques jours l’application sera gratuite. Cela veut dire qu’il ne vous reste que peu de temps pour vous procurer l’application et ainsi faire un don à FIAN, une ONG internationale travaillant au respect et à la réalisation du droit à l’alimentation.

Merci de soutenir cette initiative!
~françois

Astuces d'équipe pour améliorer la mêlée quotidienne

Il y a quelques jours j’ai publié « Odeurs de mêlée quotidienne », article dans lequel j’évoquais des symptômes observés lors de mêlées quotidiennes.

Depuis, l’équipe a fait des progrès très intéressants que je souhaite partager.

Les symptômes présentés dans le premier billet sont répétés ci-dessous accompagnés des solutions ou bien des étapes des solutions mises en œuvre.

L’équipe ne répond pas aux 3 questions.

Afficher les 3 questions pour que l’équipe puisse les voir facilement chaque matin. Mais, comme on pouvait s’y attendre, le fait d’afficher les 3 questions, n’a pas eu l’effet attendu. Cette solution ne venait pas de l’équipe qui n’en a donc pas tenu compte. Pour que la mêlée quotidienne s’améliore, il faut aider l’équipe à se l’approprier.

Montrer l’exemple. Dans ce deuxième essai, à la fin de la mêlée, j’ai repris un comportement observé et je l’ai rejoué pour présenter un exemple de l’intervention attendue de chacun des membres de l’équipe. Il peut être bon de répéter le processus de temps en temps pour aider l’équipe à progresser.

L’équipe ne s’approprie pas la gestion du tableau et des graphiques de progression (burndowns).

1. Éloigner le ScrumMaster pendant un jour ou deux, ou bien, profiter de son absence. Pendant ce temps là, l’équipe continue à faire sa mêlée quotidienne.
2. Au retour du ScrumMaster, attendre la fin de la mêlée et poser la question suivante : « Êtes-vous confiant en votre engagement? [...] Quand je regarde le graphique, je ne suis pas en mesure de le savoir. » La conséquence directe de cette dernière question : une belle discussion, de très bonnes interrogations sur le fonctionnement et l’utilité des graphiques visuels et une prise en charge des graphiques par plusieurs membres de l’équipe.
3. Reposer  ensuite la question de l’engagement à plusieurs reprises. L’équipe se la pose toute seule très rapidement.

L’équipe rapporte son occupation de la veille au tableau ou bien au ScrumMaster, sans regarder les coéquipiers avec pour effet de bord ‘d’autoriser’ des conversations parallèles.

1. Éloigner l’équipe du tableau. La première fois l’équipe est déstabilisée, mais les coéquipiers comprennent vite qu’il est préférable de se préparer avant la mêlée et forment un cercle pour se parler.
2. Proposer au ScrumMaster de sortir du cercle pendant quelques temps. En se positionnant en arrière il bénéficie d’un poste d’observation privilégié. N’étant plus visible  des membres de l’équipe, ceux-ci ne peuvent plus lui parler directement et lui rapporter l’activité de la veille. Inviter le ScrumMaster à intervenir à la fin pour donner de l’information au besoin.
3. Le respect de la parole est régulé par l’utilisation d’un objet de parole que l’équipe s’approprie et se passe de main en main.

Les effets de ces petites astuces se sont très vite fait sentir dans l’équipe avec pour conséquences immédiates de ramener la mêlée à 10 minutes et à son utilité première, c’est-à-dire, un moment de synchronisation de l’équipe. Il reste alors 5 minutes pour des informations complémentaires, mettre à jour les graphiques d’avancement, ou bien retourner travailler plus vite sur les tâches de l’itération en cours.

Ces astuces ont permis de progresser rapidement vers une mêlée quotidienne beaucoup plus efficace, menée dans un temps plus court.

Un grand bravo à l’équipe pour ses apprentissages.

Et vous, quels sont vos ‘trucs’?

Venez nombreux aux Microsoft TechDays à Paris la semaine prochaine.

Eric participera à une table ronde le lundi 8 février de 16h à 17h.

Celle-ci sera suivie d’une démonstration de Urban Turtle par Mathieu. L’occasion de voir en action dans Team Fondation Server l’outil fait par des Agilistes pour toutes les équipes de développement logiciel.

Tous les détails de la session ici.

My journey is actually the PMI bootcamp – A five day course to prepare for the PMP certification, completed with fellow Agile coach – and it has allowed us to see some great stuff.

To the left, we had beautiful Rolling Waves and to the right, Progressive Elaboration. Most days were warm and sunny in PMI country – running through the green fields of cost, risk, and talent, oops! HR management. But these dark clouds kept showing up once in a while and without warning, a bolt of lightning would reveal this official process: “Create Work Breakdown Structure” a.k.a. the WBS.

What we’ve got here is process number 3.4.4 in the PMBoK and this, I believe, is where the PMI got cocky. WBS is so central to the PMI that our trainers would actually say that if you don’t have the answer to a certification question and WBS is one of the options – choose it!

Throughout the PMI-PMP bootcamp training I kept asking myself the same question – If these PMI trainers recognize the distinctive nature of project management within software development, why am I getting so much resistance in the field?

My last blog generated some parallel discussions in the Scrum Practionners Group on LinkedIn, and some of the replies did shed some light.

Doug Shimp stated:

“The difference [between a WBS and the Product Backlog ] is big and forms a paradigm shift in thinking equivalent in magnitude as going from procedural code to object code. This is not easy and takes most people months to understand by doing an applied practice.”

He continued to say:

“This is one area I see messed up so often, it is painful. Our training community must get much better at understanding and teaching this stuff. For PMs coming from an long history of using an activity based WBS the change to an agile/scrum format can be quite head rattling.”

This is exactly why my colleague and I attended the PMI training. We need to understand where PMs are coming from. What are those things that prevent PMs from making the shift? The WBS seems to be one of the culprits. I’m not saying a WBS is not practical or even essential in some cases. Maybe upper management demands this type of breakdown and is not quite ready to deal with a simple and naive release burnup chart based on tested and working software, available on a pre-production server. Ok, I’m being a bit facetious. I do see value in a high level WBS that identifies product AND project requirements. I’d just assume use a mindmap but that might be too “fluffy” for some. There I go again. A WBS can provide some great value by:

• Defining deliverables
• Helping to define what DONE means
• Establishing a common language
• Setting up Organizational Breakdown Structure (OBS)
• Managing change

I might even encourage a team to create a WBS and link it up to their Product Backlog if I thought it would add value to the project. But for the most part, the Scrum teams I work with start with a Product Vision broken down into clear business objectives. We then identify the Epics required to achieve those objectives and wrap up with just enough User Stories to get started.

One thing, new agility seeking organizations can be certain of, is that WE WILL set aside the WBS, just like we would any other “traditional” tools and methodologies. I might recognize the immense potential value of their WBS, but as an experiment, we’ll leave all that aside, start anew, and see what happens. Every 2 to 4 weeks, we’ll inspect, adapt and start yet another experiment.

Of course there are those PMs who resist and feel the need to create a WBS and break it down as quickly as possible to the task level. You can imagine their reaction when I tell them that the team will do this at “the latest most responsible moment”. Some PMs almost pee their pants when I add the fact that “the latest most responsible moment” is actually one day before we start coding. I must admit – I do enjoy that one. (Yes, I do practice “Situational Coaching”, and in some cases, “TELLING” offers the highest return on investment)

At issue here is not the potential value of a WBS, but the obligatory use of one. Actually, I wonder if OPM3 would consider our Agile teams “immature” for not having this. Would it recognize the fact that we compensate or even exceed the value of a WBS with Agile related artefacts and ceremonies? CMMi Level 3 does!

But who am I to criticize the fact that the WBS is a required process and not just an optional tool? Scrum does require the use a Product and Sprint Backlog. They’re not optional tools but nonnegotiable artefacts. But there is one difference; Scrum is all about software development. It’s not interested in building sky scrapers or highways. PMI boasts that their processes apply to “all of the above” projects, and I’m fine with that. But if it wants to remain credible, it needs to abstract this WBS process. I’d call it the…Work Refinement through Execution Process. The WRX…I like the sound of that! It might include various tools and techniques such as a WBS, Product and Work (not to say Sprint) Backlog, and some activities to get these to evolve throughout a project.

I think the sun is coming out again. Time to go play with Project Communications Management…

Following is a conversation I had with a new Scum Master that had me thinking about how coaching works. It’s not about telling people what to do but allowing them to figure out what needs to bo done. One powerful tool to do just that is changing perspectives. Reliving the facts as they happened but from a different angle may generate insights that open new opportunities for the coachee. Below is the conversation as I remember it. I hope it generates some insights for you as well.

SM: So what do you think about the sprint planning the other day ?

Coach: Well one thing I noticed, and I did mention it on the spot, the team was about to bend some process improvement rules they agreed on implementing during the last retrospective. Your role as a Scrum Master is to make sure that the team follows its own process so that they may inspect and adapt it if need be. If the team partially implements the process in some cases and fully in some others, than interpretation of the results is more difficult and it will be harder to see what to improve next. You want to be careful when introducing changes to a process so that you know what you will be inspecting in the end.

SM: Well you are right. Sticking to our decision not to include big or unclear stories in the sprint made us realize that we were accepting to tackle underspecified functionality. No wonder our estimates were off and we were not able to complete all the stories in the sprint.

Coach: Good. But what about you ? What do you think about the sprint planning meeting ?

SM: Well, one thing that bugs me is that team members don’t participate in the process.

Coach: Oh? What do you mean ?

SM: I mean they don’t seem to care or are not motivated. For instance, in our Scrum Masters group we thought it would be a good idea to let developers take turn at the Scrum Master’s role in the daily meeting so that they realize what we are dealing with. When I asked my team if one of them would like to take my place I had to wait for a long time before someone reluctantly offered to conduct the daily.

Coach: So you want them to feel what it’s like to wear your shoes ?

SM: It’s not that. It’s just that team members are not getting involved. You witnessed what happened at the sprint planning meeting. When I asked them if they were able to commit on delivering the sprint backlog, I didn’t get an answer.

Coach: Well your organisation has a culture in which developers have been told what to do, when and how to do things. The change to self organisation is not going to happen overnight.

SM: I know. That’s why I want them to get involved in the process but they don’t want to get onboard.

Coach: And why do you think the don’t want to get onboard ?

SM: I don’t know. And that’s why I’m asking you this because I’m running out of ideas.

Coach: So… What are you doing that’s impeding them from getting involved in the process ?

SM: I’m not sure I understand the question… What do you mean ?

Coach: When you are not getting the response you’re expecting from others it’s often useful to consider that you are the one causing them to act the way they do. This empowers you to make some changes instead of waiting for others to change their behaviour.

SM: I’m not following you at all…

Coach: Ok. So let’s go back to that sprint planning meeting. Remember how the room was laid out and where everyone was sitting. You remember ?

SM: Yeah…

Coach: Let’s say you take John’s place. What do you see ?

SM: I’m really not sure where you want to go with this… But the only thing I see is that the monitor is too far away and its difficult to read.

Coach: Well that’s something to consider. And what are you doing in the meantime ?

SM: I’m updating the backlog and moving stuff around.

Coach: And how do you think John is perceiving this given the organisational culture ?

SM: I see… So we should probably use index cards that team members will be able to play with and update themselves.

Coach: Good! That way you solve two problems. By giving the team access to the sprint backlog you allow them to grasp more fully and own its content. They’ll probably feel more comfortable committing to it at the end.

SM (not really listening anymore): I can even update the backlog in the tool afterwards so that the flow is not interrupted. Thank you. That’s a great idea!

Coach: Well you know it wasn’t my idea. It’s yours. You just had to change your perspective on things.

SM (already leaving): Good. I’ll let you know how it turns out. Talk to you soon.

Coach (to himself): I’m not really sure what he saw exactly, but changing his perspective really allowed him to find new ideas on how to tackle this issue. This coaching stuff really works… I should blog this…

Photo de mêlée attribuée à http://www.flickr.com/photos/cdm/

Il y a quelques semaines de cela, après plusieurs jours sans intervenir auprès de l’équipe, j’ai pu observer, lors de mon retour, une mêlée quotidienne¹ avec quelques dysfonctionnements.

Avertissement :

Ce que vous lirez n’est pas un jugement, ce que j’ai observé ne constitue pas à mes yeux des erreurs, mais démontre plutôt un apprentissage naissant de la mêlée quotidienne.

Contexte :

• L’équipe a terminé une première itération et s’apprêtait à commencer la deuxième.
• Finalement, elle stabilise pendant une semaine l’application pour une release annoncée très tard. Son passé l’a rattrapé et la date ne peut être manquée.
• De façon autonome, l’équipe a gardé les nouvelles pratiques mises en place dans la première itération et n’est pas retombée dans le mode “panique livraison” du passé.
• Je suis présent le jour de la mise en ligne et elle a lieu sans que l’équipe n’ai eu à faire de temps supplémentaire.

Symptômes observés :

• La ScrumMaster(SM) donne la parole à tour de rôle : “c’est à toi Louis”, Louis fait le tour de la table pour venir parler.
• Une personne fait du reporting face tableau ou tournée vers le ScrumMaster,  et des conversations parallèles ont lieu.
• Personne ne donne un statut sur le format des 3 questions²
• Le tableau de l’équipe n’est pas à jour. Le statut des toutes les tâches est mis à jour en direct, le tableau ne reflète l’état d’avancement qu’après l’intervention. Cela fait perdre du temps et provoque des cassures de rythme dans la prise de parole.
• Il y a par moment des personnes en retrait ce qui donne deux “épaisseurs” au groupe.
• La ScrumMaster demande plusieurs fois ce que l’on fait de certaines tâches au tableau avant d’obtenir une réponse.
• Un bureau gêne l’espace devant le tableau, personne ne le déplace.
• Une personne est occupée pour la mise en ligne, elle n’intervient pas du tout et ne donne pas de statut aux autres membres de l’équipe.
• Deux personnes sont assises.
• Finalement, la mêlée dépasse de 5 minutes le temps imparti.

Debrief et plan d’action :

À la suite de la mêlée quotidienne, je prends quelques minutes avec la ScrumMaster pour lui demander comment elle a perçu cette mêlée, comment elle se sent. Ce que je trouve formidable c’est qu’en quelques secondes elle m’a donnée la plupart des observations ci-dessus assorties de commentaires pertinents : “c’est comme s’ils n’avaient pas encore pris la mesure le l’utilité de mettre à jour le tableau” par exemple.

S’en est suivi un dialogue ressemblant à celui ci-dessous :

SM : “Mais comment je peux faire pour changer le comportement de l’équipe pendant la mêlée ?”

Moi : “Quel est le comportement qui te dérange le plus ?”

SM : “Je dois dire aux personnes de venir quand c’est leur tour”.

Moi : “Que pourrais-tu faire le plus simple pour changer cela”

SM : ” Tu m’as déjà dis de ne pas intervenir, de laisser l’équipe faire son daily”

Moi : “Oui effectivement, peut-être pourrais-tu rappeler à l’équipe ce que tu attends pendant le daily : qu’ils fassent un statut vers l’équipe, en répondant aux 3 questions puis les laisser continuer sans intervenir, en laissant des blancs, des silences s’il y en a. Je t’inviterai à le faire rapidement sans forcement attendre une rétrospective.”

SM : “C’est vrai, je pourrais faire ça, mais ils ne répondent pas aux 3 questions”

Moi : “Les connaissent-ils, peut-être ont-ils besoins que quelqu’un rappellele ces questions”

SM : “Pour qu’ils les voient les questions ont pourrait les afficher”

Moi : “C’est une très bonne idée ça, avoir les trois questions affichées ça permet de se les mettre en tête à chaque mêlée”

Et nous avons continué la conversation encore quelques minutes.

Finalement, le bureau qui gêne devant le tableau va être poussé un peu, les questions vont être affichées, la SM va répéter le comportement attendu lors du daily et laisser l’équipe aller. Les résultats dans un prochain billet

Dans vos organisations ou dans vos équipes, comment se passent vos mêlées quotidiennes, observez vous d’autres symptômes ?

Si vous êtes coach ou ScrumMaster, comment intervenez vous pour que l’équipe prenne conscience et règle ces symptômes ?

It feels good to have a common enemy, someone or something to hate or discredit. What this usually does is create a sense of unity between individuals who share a common view. We do this with programming languages (Java vs. .Net), philosophies (Waterfall vs. Agile) and even within those philosophies (Scrum vs. DSDM vs. Crystal vs. …).

One of my preferred antagonists was the all mighty monolithic Project Management Institute (PMI) and its PMP disciples. In an attempt to keep my friends close and my PERCEIVED enemies closer, a colleague and I decided to attend the PMI bootcamp – a five day course to prepare for the PMP certification.

As an Agile coach, helping medium to large organizations transition away from traditional methodologies, I am continuously confronted and challenged by Project Managers armed with a PMP certification. Don’t get me wrong, I like being challenged! It actually makes my job easier and greatly increases the chances of a successful transition. That said, I’d like to understand where he or she is coming from. What is the driving force behind a PMP certified Project Manager? Do they have their own manifesto and maybe Project Management Charter? And who knows…Maybe this five day course would offer some additional tools to work with within an agile context.

One of my preconceived notions was that the PMI trainer’s underlying message would have been: “You must plan software projects exactly the same way as you would a high rise project” You must plan the living daylights out of the project, execute that plan and all we be fine in lala land. With my past experiences with PMPs, can you blame me?

I was very disappointed!

What we saw and heard as not an evil empire headed by an evildoer with acute asthma, but an open minded, experienced project manager coupled with a great deal of common sense. Mind you that this refers only to our first day and we get a different trainer every day (BTW, I like the “different trainer every day” concept and thinking we could do this with our Certified ScrumMaster Training – Food for thought and maybe a future post)

What we saw is a slide similar to this one…

…and the trainer actually said: “In I.T., we don’t even know what we are doing next week so don’t start planning to much ahead”.

I almost got teary eyed!

On the other hand, there is also the strong notion that the project manager is fully responsible for the success of the project. As an Agile coach continuously working to establish shared responsibility between the ScrumMaster, Product Owner and development team members, this notion rubs me the wrong way.

Some of the things I did like were:

• Project versus Product Life Cycle
• The Rolling Wave
• Progressive Elaboration: “Continuously improving and detailing a plan… ”
• The 9 knowledge areas
• Process assets (Lessons learned)
• Including “Expert judgment” in most processes

So I guess Project Managers who keep telling me that their sound PMI practices does not allow them to adopt an “Agile” way of doing things are just pulling my leg – some kind of bad joke. Next time it happens I’ll be ready with a full hearted laugh and a high five. Hopefully he/she doesn’t leave me hanging

I’ll be elaborating on the Knowledge Areas and Process Groups in future posts, but for now, suffice to say that I’m prudently putting aside my perceived dichotomy between PMI and Agile.

Stay tuned…

Vendredi 12 mars 2010 à 13h30

Venez participer à une session  « XP Game » lors de la conférence Confoo.ca qui se tiendra à Montréal les 10, 11 et 12 mars 2010.

Avec mon coéquipier Mathieu Bérubé nous serons vos hôtes et les maîtres du jeu! La session « XP Game » se déroulera le vendredi 12 mars 2010 à 13h30.

Vous expérimenterez, grâce à cet atelier ludique, la planification agile : priorisation par valeur d’affaire, estimation de user stories. Vous découvrirez le cycle des itérations et  les livraisons fréquentes et régulières de fonctionnalités. Vous mesurerez la vélocité et vous mettrez en existance le principe d’amélioration continue par l’inspection et l’adaptation de votre processus d’équipe.

Nous serons plusieurs pyxissiens présents pendant ces trois jours. Je vous invite à assister aux présentations et aux ateliers suivants :

• Vincent Tencé présentera deux sessions : « Introduction à l’agilité » mercredi le 10 mars à 9h30 et « Introduction au TDD » jeudi le 11 mars à 14h45.
• Jean-François Proulx et Nicholas Lemay présenteront la session « Simulation Scrum avec prototypage papier » vendredi le 12 mars dès 8h30

Il y a de nombreuses autres sessions passionnantes comme celle de Benoît Lapointe : « Expérience pratique du Kanban chez IBM Bromont ». Je vous encourage à consulter l’horaire complet de la conférence.

The Experiment

I attempted a small experiment with my kids a few weeks ago – get them to voluntarily help clean the house. If you have children between 7 and 10 year-old, I’m pretty sure having your kids help with cleaning is nothing short of a nerve-wrecking experience. If you don’t have kids, the process typically goes like this:

• You – “Timmy, can you please pick up the toys in your room.”
• Timmy – “Why?”
• You – “Because your room is a mess and I break my face every morning when I come wake you up.”
• Timmy – “OK, I’ll clean up.”

30 minutes later, you go see Timmy.

• You, slightly annoyed – “Timmy, what are you doing?”
• Timmy, looking up – “I’m building a castle, daddy. You want to play with me?”
• You – “Yes, I’d like to play with you as soon as I’m done cleaning up. Why didn’t you pick up your toys like I asked you too?”
• Timmy – “OK, I’ll clean up”

30 minutes later, you go see Timmy

• … (you can guess the rest)

So, back to my experiment. A few weeks ago, while my wife was grocery shopping I decided to use an adapted version of Scrum. I called my son and his twin sister and told them we would do a little activity. To their enjoyment, they were wondering what I had in mind. They sat next to me at the table while I the took 4 x 6 index cards and on each of them, I wrote a task: pick up the toys, put your clothes in your drawers, empty the garbage cans, bring the recycling to the garage, put the Tupperware away in the drawer, vacuum the floor, etc.

• My son – “Daddy, why are you writing these down?”
• Me – “We’ll play a little game.”
• My daughter – “Can I play too?”
• Me – “Of course. Here’s how it goes. I wrote 8 cards and each card has a little task. I need you to help me clean up the house while mommy is doing grocery.”
• The twins – “OK, what do we do with the cards?”
• Me – “You will each select the cards (the tasks) you would like to do. You then decide in which order you want to do them.”
• My daughter – “Daddy, some tasks are longer than others. What do we do about that?”.
• Me – “It’s up to you to decide.”
• The twins – “It doesn’t matter. We’ll decide which ones we pick.”
• My son – “Do we get a reward for doing the work?”
• Me – “Mmmm, good question. I know you like to read. How about I give you tokens for each task? Once you get 50 tokens, I’ll buy the book you asked me.”
• My son – “OK.”
• My daughter – “Can I buy a beeds set instead of a book?”
• Me – “Sure.”
• The twins – “Can you write how many tokens each task gives on the cards?”
• Me – “Good thinking! Picking up the toys is 3 tokens, bringing the recycling to the garage is 1 token, …”
• The kids – “OK, but who picks first?”
• My son – “Let’s do rock – paper – scissor.”
• My daughter – “Yes, let’s do rock – paper – scissor.”
• The twins – “ROCK, PAPER, SCISSOR…”

After determining who would start, they quickly picked the cards and started doing the assigned task. At their own pace, they executed on the cards. Then, something cool happened.

• My son – “Daddy, can we add a card? We need to water the plants.”
• Me, laughing – “Of course. Who’s going to take this one?”
• The twins – “Me, me, me!”
• Me – “I guess we’ll have to write another card so you are even.”
• My daughter – “Can I dust the bureau? I saw mommy do it the other day and I’d like to do that.”
• Me, with a big smile – “OK, if you’d like to do that. I’m OK with this.”

Together, they successfully completed all their tasks. All of their tasks! No fighting, no screaming. That was a “proud moment” Imagine when my wife got back home after the grocery…

With the Xmas Holidays and the broken routine, I was pleased to see my kids grabbing the cards by themselves this past Saturday and starting to execute on the routine. “Wow, this self-organization thing really works! Even with kids…”, I told myself.

The Take-Away

If you want people to carry out a task, here are a few suggestions:

• Describe the task;
• Let the team self-organize;
• If the team needs help, you may suggest tools or a process – but do not impose them;
• Get out of the way;
• If possible, make it fun;
• That’s it.

You might be interested in these related posts:

1. Some companies are like 8 year-old boys
2. New Year's Resolution
3. The kids are having a great time at Sportmax