dcembre 2009Monthly :

De retour après un long mutisme…

Voilà deux ans que je m’adonne à d’autres choses intéressantes. Et comme ce lézard, aujourd’hui je refais tranquillement surface pour partager les idées qui me trottent dans la tête.

Beaucoup de nouveautés depuis! De nos jours, je me consacre presqu’uniquement au développement logiciel sur la plateforme .Net et à l’accompagnement d’équipes qui effectuent une transition agile. La compagnie pour laquelle je bosse est en pleine croissance et de nouveaux défis se profilent à l’horizon. Je vais donc avoir plein de matières à réflexion à vous proposer: Windows 7, .Net 4.0, pratiques d’ingénierie agile…

Je m’approprie, donc les nouveaux outils de blogue à ma disposition et je vous reviens bientôt.
Joyeux temps des fêtes!

Agile lessons learned #5 : Waiting for a superman

As far as he could remember Marc always dreamed of being a pilot. After a few years of service as a bush pilot in the northern most par of the country, he finally got a break working for a regional transporter. In April that year, his engine was due for it’s 3500 hour overhaul. Pat, the senior technician at Aviair Regional Airlines performed the overhaul, a routine job for him by then.

As the FAA later found out, Pat got pressure from management to do the overhauls faster than usual as they really needed to get those planes off the ground during the harsh financial times of the enterprise. This caused him to leave a pressure hose on that was requiring change but that would also have required ordering a new piece and further delays. Unfortunately for Marc, the part gave up mid-flight three weeks later while flying above mountains. He now had to decide whether he would crash in a farmer’s field or in a country road nearby. Marc made a quick decision and decided to head towards the fields.

He managed to pull off a textbook belly landing in a field that was way rougher than anticipated. When the emergency crew got on the site of the crash they found Marc unconscious and half-disfigured. Had he been a lesser pilot, all 13 of his passengers would have died that day.

Later that year, Marc got decorated for his heroic actions, as he saluted his former coworkers in the assistance for a last time. He saw this as his farewell, the accident having impaired his eye sight beyond possible repair, leaving him unable to get medical clearance and thus revoking his pilot’s license.

As the news of his heroic act got around, Marc started to be asked to give speeches about it across the country. Marc was not seeking publicity although he appreciated all the warm feedback he got, he always politely turned the offers down.

One day, he got a call from Peter, a friend of his that was now a project manager at FreeFall inc. After the usual salutations, Peter got around asking Marc for a motivational speech. In his mind he thought, if people met Marc there was no way they would not be positively influenced by him.

“It might even bring out a hero or two out of my employees you know, the project really is in disarray.” Said Peter
“Well I don’t know much about software development actually.  But why do you need heroes ?
“Well everything is wrong. I really need someone to take the lead and fix our major issues. We have quality issues like you wouldn’t believe.” Said Peter, with his voice getting more desperate.
“OK. Why do you need heroes? ”
“Because we have quality issues…I already told you that.”
“Ok. So you wouldn’t need heroes if you had no quality issues right?”
“What do you mean?”
“Well the only reason I’m unfortunately perceived as a hero is that I managed to do my job properly when someone was forced to slack the quality of his work ”
“I was doing my job properly for years prior to my accident, but you never heard of me in the news did you?”
“Of course not but…”
“Now, if their was no quality problem, your staff would only have to do their job and everything would be business as usual right ?”
“Well yeah.”
“Anything you could do to help the quality of the software your guys are building right now ?”
“Well the guys were talking about getting more time to do more unit testing and automated builds the other day, maybe I should give these guys a talk.”
“Who knows, might save you from having to deal with super heroes. Grown men wearing tights usually don’t go over well in office meetings ”
“Point taken, thanks Marc.”

- Nicholas Lemay

Agile lessons learned #4 : The red pill

A man’s life is primarly interesting when he has failed.
For it’s a sign that he tried to surpass himself.

– George Clemenceau

Tim was an Agile coach. One morning, he bumped into Andrew, a senior manager over at FreeFall inc, a fortune 500 company.

“Hey Tim! How about that Agile thing? Do you guys still have a daily Scrum in the morning?
“How’s that coming along?”
“I don’t know how to put this Andrew, but we don’t ‘do the Scrum thing’ in the morning.
Being Agile is way more than doing daily meetings.”
“Oh really? What else is there to be Agile?”
“You might wanna grab a doughnut with that coffee, I’ve got a few things to show you.”

Tim went on explaining the different aspects of scrum, the roles and the different ceremonies. But he knew the selling point to the manager was the continuous improvement brought by the frequent inspection and adaptation the team puts itself through.

You see, with Scrum all you problems will become apparent. Think of the problems as cream being poured into a coffee. If you just keep on pouring and stirring all the time everything stays in a confused mess. But if you take time to stop stirring your mess, the cream will rise to the top and you’ll get a clearer view of what’s going on.

To achieve this here are some important steps:

Courage:
You can call yourself Agile if you want to. For that matter, you can call a cat a dog if you want to. But you are not Agile without frequent introspection and a true and deep desire to be better tomorrow than you are today.

This all start with courage. Courage to admit that you can be wrong. Courage to tell someone else that he/she was wrong. Courage to truly listen when someone is criticizing you. Courage to take what is on the table and make yourself a better you. A better team starts with a better you.

Desire:

Why do you desire to become better today than you were yesterday? What is your source of motivation? Are you so disgusted by your current situation that you wish not to have to experience it in the future? Have you seen better and want to recreate it? Do you see change as a desirable thing? As a source of motivation?

Failure must be an option:
If you are now allowed to fail, you cannot become better. You must be allowed to fail in order to be able to freely admit your failure in order to get feedback to help yourself get better. You should never seek failure, but you should not fear it.

Awareness of consequences:

Once you start into this continuous self-introspection game you will be cursed. Cursed for life. You see, most people have exactly the same problems as you and might still go through for the rest of their life. But you WILL see them. Just like Neo in the Matrix can see the code of the Matrix, you will see the problems when people within the mess have no idea how deep they’re in.

So you have two choices. To quote Morpheus talking to Neo:

“You take the blue pill, the story ends, you wake up in your bed and believe whatever you want to believe. You take the red pill, you stay in Wonderland, and I show you how deep the rabbit hole goes.”

So what’s it gonna be? The red pill or the blue pill? Because once you take the red pill, there is no turning back.

- Nicholas Lemay

A Christmas Retrospective



‘Twas the night before Christmas
And Santa was busy
Trying to understand
Why things got so crazy

But the plan was perfect
Created by experts
But the elves on the floor
Knew so much more

What if they’d Scrumed it
Santa as P.O.
Maybe a burndown
And of course a retro

Sprint 0 in March
And a start in April
A review every month
And see if we’re able

But Agile it wasn’t
And waterfall it was
Santa found out too late
That he wouldn’t make the date

Next Christmas will be different
It will be in December
And we won’t have to wait
For our toys in September

Merry Christmas! ;)

La première descente du 24 hrs

Midi, à la Tour de l’horloge plus de 225 participants, avec leurs skis, prêts à traverser le village Tremblant pour atteindre les gondoles. Partout dans le village des supporters encouragent les partipants du 24 heures, l’ambiance est survoltée.

Je dois admettre que ça fait plusieurs mois que je ne me suis pas entrainé et la course en ascension me fait un peu peur. Mais qu’est-ce qu’on ferait pas pour la cause? Ouf, ça pas été facile, mais j’y suis arrivée, merci à mon équipe d’avoir été là pour me supporter.

Les conditions sont excellentes, bravo aux équipes techniques pour avoir fait autant de neige. Le soleil est parmi nous, quelle belle journée. La première descente est géniale et mémorable! C’est un immense honneur de participer à cet événement organiser pour supporter une si belle cause. Déjà 1 200 000$ d’ammassé pour venir en aide aux enfants!! Il reste quand même 23 heures:-) Go Pyxis Snow Team!!!

Que penser des méthodes Agiles plus lourdes?

J’ai besoin de votre avis sur un truc. On le sait bien Scrum est très minimal. Est-ce trop minimal pour nos clients “corporatifs”?

Ceux chez qui le département de TI s’est développé autour d’un processus très lourd avec plusieurs rôles et biens livrables s’y retrouvent-ils?

Pourrait-on mieux les encadrer?

On sait que l’Agilité c’est une façon d’être et qu’au delà du processus il y a les individus (et leurs interactions). Cependant, je me retrouve dernièrement devant des clients qui recherchent désespérément des réponses à plusieurs questions auxquelles Scrum ne répond pas. La théorie du leadership de situation me dit qu’il faut être plus directif avec ses clients. Je crois qu’il faut jeter les bases pour eux et ensuite leur apprendre à développer une culture d’amélioration continue où les bases jetées ne sont que le point de départ de l’amélioration.

Dans ce contexte, pouvons-nous (devons-nous) aller plus loin que le simple Scrum?

Je vois 2 solutions :

1) Piger dans leur processus actuel (pour des définitions de rôles et des biens livrables) et l’encadrer à l’aide de Scrum.

ou

2) Mettre en place un processus Agile plus lourd tel que OpenUp ou DSDM.

J’ai l’impression qu’appliquées avec la bonne attitude (ce qui est aussi vrai avec Scrum) ces méthodes ont beaucoup de sens.

Qu’en pensez-vous?

Allez n’aillez pas peur, jetez un oeil sur OpenUp … elle ne vous mangera pas

OpenUP is a lean Unified Process that applies iterative and incremental approaches within a structured lifecycle. OpenUP embraces a pragmatic, agile philosophy that focuses on the collaborative nature of software development. It is a tools-agnostic, low-ceremony process that can be extended to address a broad variety of project type?

François Lapointe :

Je crois que l’idée est bonne, les entreprises fortement hiérarchisées, politisées (ce qui est, entre nous, le propre de toutes les grandes entreprises) et bourrées de contrôles de toutes sorte ne peuvent, malgré toute la bonne volonté sautée dans l’Agilité. On pourra au plus avoir un projet de temps à autre en Agilité, mais ces projets resteront des ‘curiosités’ malgré le succès incontestable de ces projets .
En fait je crois même que l’Agilité comme on la connaît, n’est pas viable en grande entreprise.
De ce fait, une approche Agile ‘structurée’ ou ‘lourde’ est une excellente option.

Mathieu Szablowski :

 

J’ajouterais à la réponse de François que ces ‘grandes entreprises’ sont en général nombrilistes et que leurs dirigeants voient dans la méthode et les processus un façon d’innover en reprenant des briques de choses existantes pour les accommoder à leur sauce. Maintenant si on regarde les autres méthodes proposées, en quoi différent-elles de Scrum? Je pense qu’elles ajoutent du formalisme (guidance, process…) là où Scrum réclame du bon sens (ex. : processus de livraison même si rien n’est défini mais que l’on a déjà livré en logiciel jusqu’en production, on a un processus de livraison…). Les entreprises à qui tu proposes ces méthodes n’ont pas l’air d’être des ‘start up’s’. Personnellement, je me dirigerais plutôt vers l’étude de leur processus interne et tenterais de ‘fusionner’ ce qu’ils ont déjà avec un processus plus Agile (notamment dans la conduite de projet). Tu obtiendrais par ailleurs ce qu’ils veulent, c’est-à-dire un processus rien qu’à eux

Jean-René:

Bon point… c’est exactement ce qu’on a proposé à un de nos clients. Étude du processus en place (bien livrable, rôles, étapes,…) à partir duquel on dégagera un Scrum Type version 0 qu’on améliorera au fil des itérations.

Isabelle Therrien :

Le danger des méthodes lourdes est d’avoir à faire des choix en début de projet sans trop connaître ce dans quoi on s’embarque.

“Choisissez entre les 40 rôles proposés et les 56 processus”, ce n’est pas facile, et ils se retrouvent donc avec des méthodes trop lourdes qui ne font que déplacer les problèmes, plutôt que de les révéler.

Le nouveau cadre Ensemble est intéressant aussi, on pourrait quasiment dire que c’est une “méthode lourde”. Ça met une couche de gouvernance sur la méthode Scrum. En fait, tout le monde crée la sienne, et je commence à penser que c’est nécessaire, surtout dans les gros projets ou les grosses entreprises.

Mais pour plusieurs raisons, dont la gestion du changement beaucoup plus facile, et aussi parce que je le fais par réflexe, je préconise d’introduire les valeurs et pratiques Agiles dans la méthode “actuelle” en place chez le client.

Avec un suivi constant, il est possible de leur mettre en lumière des changements à faire “à mesure”… enlever ceci, puis cela, et au bon moment, ils vont s’apercevoir qu’ils sont beaucoup plus efficaces qu’avant, qu’ils collaborent mieux et qu’ils livrent du logiciel de meilleure qualité.

Vincent Tencé :

Je travaille avec un client depuis le début du moi du juin pour les aider à proposer une approche de développement officielle basée sur Scrum et qui respecte leur SLC (Software Lifecycle) corporatif. Notre dernière rencontre a eu lieu la semaine dernière et j’attends leur présentation qui me permettra de documenter les résultats. En quelques mots, nous avons une approche compatible CMMI niveau 3 et qui s’arrime sur les jalons de leur cycle de vie R&D.

Je crois que çe sera utile dans les situations que tu décris Jean-René de proposer une approche qui cadre mieux avec leur culture corporatif sans compromettre les principes et valeurs de l’agilité. Comme me le disais Bob hier, ça fait moins « révolutionnaire » et ça nous permet d’être entendu.

Sylvie Trudel :

Mon expérience à essayer d’adapter un processus générique (de type RUP) à une organisation qui appliquait autre chose :

- Ça prend plus de temps que de définir un processus “from scratch”.

- Ça a peu de chance d’être adopté par les équipes qui ne s’y reconnaissent pas.

Par contre, prendre ce qu’ils font déjà (processus, biens livrables, rôles et responsabilités) et les adapter, fait en sorte que l’organisation adhère plus vite aux changements parce qu’ils ne font qu’ajouter ou moduler ce qu’ils connaissent et maîtrisent déjà. Plus facile. Dans ce contexte, conserver une processus de développement pour ses biens livrables en le découpant en sprints devient relativement simple. Au pire, il faudra commencer par la conception/programmation avant de pouvoir remonter à l’architecture. Compromis acceptable quand la marche est trop haute. Faut quand même pas oublier qu’on travaille d’abord avec des individus; les processus sont un side effect

Mathieu Szablowski :

Sylvie, quand tu dis : “Au pire, il faudra commencer par la conception/programmation avant de pouvoir remonter à l’architecture”, tu ne crois pas que le plus important sera d’engager les utilisateurs (ou un PO) dans le développement?
Les équipes techniques sont impatientes de tester les pratiques et les concepts Agiles mais s’essoufflent rapidement si aucun retour n’est effectué sur leur production. C’est aussi leur donner un but, un objectif voire une certaine pression parce que la présentation régulière est ce qui coûte le plus cher à l’organisation.

Sylvie Trudel :

Dans un contexte où la hiérarchisation des rôles est carrément calquée sur la métho (P+, pour ne pas le citer) et que l’architecture relève d’une vice-présidence séparée qui détient l’exclusivité de la communication avec un pilote (représentant des utilisateurs qui appartient à la ligne d’affaires et qui détient l’exclusivité de la communication avec les utilisateurs), et que notre mandat nous vient de la vice-présidence de la réalisation, notre carré de sable se limite à la portion conception/programmation/tests (cas vécu dans une grosse boîte l’an dernier, 200 développeurs, plus de 3000 utilisateurs). C’est par là qu’on peut commencer à agir. Quand j’ai suggéré d’inclure la portion “architecture” dans la démarche d’amélioration, je me suis vite butée à une guéguerre politique entre les 2 VP.

Donc, la question que j’ai dû me poser a été “veut-on avoir raison, ou veut-on avoir du succès?”. La réponse est venue assez vite merci. On a eu du succès en se limitant à notre carré de sable, mais avec beaucoup d’impact sur la formation du VP. Ça a fait des p’tits en un an et demi, à un point où Pyxis est solicitée pour “alléger” leur méthode. Faut être prudent et très patient parfois avec les grosses boîtes. Ils ne vivent pas dans notre “espace-temps”. On dit que les paquebots ne virent pas sur une pièce de 10 centimes.

De toute façon, l’idée est qu’ils se mettent à développer des réflexes d’inspection/adaptation de leurs façons de faire. Quand on y arrive, on a déjà accompli beaucoup et le reste va finir par suivre. Il ne faut juste pas s’attendre à ce que ça se fasse à notre vitesse, mais à la leur.

Vincent Tencé:

Très juste. On ne peut pas brusquer le changement, simplement créer les conditions pour qu’il prenne le moins de temps possible.

Stéphane Lécuyer:

My 2 cents…

Personnellement, dans un premier temps, je préfère mettre l’accent sur les “valeurs et principes” de l’Agilité et essayer de trouver, avec les gens en place, ce qu’ils font de bien et qui est en accord avec ces valeurs et principes. Une métho plus lourde ne ferait, selon moi, que déplacer le problème d’une métho à une autre.

En mettant systématiquement l’accent sur les valeurs et principes, j’ai découvert que les organisations tendent à trouver eux-mêmes leurs bonnes pratiques tout s’obligeant souvent à remettre en questions leurs pratiques courantes. De plus, ca les force à s’ouvrir au monde extérieur et à garder un esprit ouvert vs tout ce qui pourrait les aider à faire du meilleur logiciel tout en misant sur le facteur humain.

Ultimement, ce qu’on essaie de faire avec Agile, c’est d’exploiter tout le potentiel de l’humain en l’incluant systématiquement à chaque étape du développement. En mettant l’accent sur l’humain, on “force” les entreprises à re-considérer chacune de ces étapes en tentant de découvrir comment on peut maximiser celles-ci à partir de ce qui existe déjà dans l’entreprise…. soit les individus, la hiérarchie et l’implication du client.

Agile, c’est un gros changement pour les grosses boîtes et le problème majeur que je rencontre très souvent, c’est la résistance au changement et la peur de la perte de pouvoir de la direction. Si on met l’accent sur ça, je crois que les gens, en général, arrivent très facilement à trouver les bonnes réponses (le bon process). Je crois que la réponse est plus dans le type d’accompagnement et qu’on arrive à leur faire comprendre que tout le monde (y compris la direction) peut gagner si ils respectent les valeurs et principes de l’Agilité et que ce n’est pas seulement une affaire de développeurs.

Moins de 3 jours avant l’événement 24h Tremblant!

Venez retrouver le Pyxis Snow Team durant le 24h Tremblant, encouragez-nous pendant nos descentes et profitez de votre visite pour assister à des spectacles. La  programmation est incroyable et met en vedette entre autres : Jonas, Yann Perreau, Boom Desjardins, Izia, Dj Champion et ses G-Strings, Stefie Shock et Ariane Moffatt!

Il est encore temps de supporter l’équipe et par le fait même la Fondation Centre de cancérologie Charles-Bruneau en faisant un don au pyxis-tech.com/24h-tremblant.

Au plaisir de vous voir à Tremblant!

Agile lessons learned #3 : Adult day care

Henry had been working for FreeFall for the past 7 years. A bachelor in software engineering, he had first joined up for an internship as a software developer, or has he later learned, as a code monkey.
Along the way he and his friend Pete got promoted to managerial roles in the IT department.

Three years had gone by since he got promoted and Henry had become borderline depressive. He was just coming off a full month’s vacation with his wife.
As with most monday mornings, Henry was late. He dreaded mondays. He never came in on time. But he couldn’t have cared less. None of his employees did.
Neither did his superiors. Actually, it was expected for the higher ups to come in late. They called it working in the boss’ timezone.
As Henry dreadfully packed his frozen lunch into his reusable bag, he kissed his wife goodbye.

“What’s wrong honey ?” she said
“Nothing special honey, it’s Monday you know.”
“Don’t worry about it sweetheart, you’ll be be back in no time”
“Yeah”, he said with dispair in his voice. “Right after adult day care…”
“Adult day care?” she said “What do you mean ?”
“That’s a phrase the guys coined up at work.”
“You know, just like when we were young our parents would drop us to day care ” he asked
“Yeah…”
“Well our job is just like it. The difference is barely noticeable really…”
“You’re kidding me right” she said with a puzzled face
“I’m not joking around. When we were kids our parents would drop us there in the morning and pick us up in the afternoon. At work, we take the commune and it drops us there
in the morning and they pick us back up in the evening”
“Ok and ?”
“At day care, the lady would drop each of us in our own little parks with a bunch of toys so we wouldn’t bother each other”
He took a break to see if she was still following him.
“Well you see at work we each have our own little cubicles or closed offices and we have our computer to play with until our time is done and we can go back home”
She clearly had heard enough.
“Enough with your childish stories. You’re just trying to get late to work. The sooner you leave the house the sooner you’ll be done with it.”
“Off to work you go ” She said as she kissed him on the cheek.

That afternoon, Henry had a meeting with Tim, a former schoolmate who later became an agile coach after completing his major in human psychology.

Henry spent his entire morning Googling details about that Scrum thing and the Extreme Programming practice.

Henry figured, one of the major problems at work was based on communication problems. All his team members were dispatched throughout the office floor in small cubicles with sliding doors.

The entire place was so quiet you sometimes felt like screaming just to see if someone was still alive. Actually, some days you actually felt as if somebody had actually died.

By the end of the week, he couldn’t get his discussion with Tim out of his mind and he booked a dinner between the two on Friday. After a couple of beers, they concluded a deal where Tim would come in at
FreeFall for a couple of month and coach the Agile transition. The team got off to a slow start, but eventually they saw the value of what they were doing popping out of everywhere and they
were really sold on the entire thing.

Eventually, they even got carried away and Tim had to step in and show them how to take the time to learn everything at a proper pace

“Baby steps, baby. Baby steps, that’s the only way my boys ” Tim said. As Henry tried to conceal his laughter.
“What’s so funny ? ” asked Tim.
“Oh nothing.”
“No seriously?”
“Well I find it amusing that you’re telling the boys to take baby steps, while they’re in day care”
“Day care ? ”
“Well you know, we’ve got this running gag about FreeFall being a daycare center for adults and our cubicles play the role our parks did when we were young.”
“I get the picture.” said Tim slightly amused. “Wonder if those Ruby on Rails developers ever thought they were actually building adult rattles….” continued Tim.
“But seriously about them cubicles, can we talk about those in private.”

Tim took Henry to the coffee machine to have a little talk. Tim got Henry to talk about the communication problems the team was having prior to their Agile transition.
They also noted the ameliorations that had occurred.
“You see dude” Tim called Henry “We’ve just made a small dent into the damn that was blocking the communication in your team. Now there’s a little water trickling.” he said passionately.
“Now then, do you want to keep the damn or do you want to bust the damn wide open” said Tim as Henry’s eyes opened up widely.
“Alright let’s do this”.
“You’re giving me “carte blanche” Henry ? ”
“Yeah man.”
“Cool, get ready for a flood come Monday morning.”

On Monday, Henry came in earlier than usual but he still managed to get in last. Five minutes in and he was already purple in the face and storming towards Tim.
“Are you out of your bloody mind ?”
“Pardon me ?”
“You just tore our entire team’s cubicles and replaced them with folding tables ? Are you freakin nuts ? Some of my employees have lost their Window privileges
and are now sitting together with the interns. How am I supposed to justify this to my boss. The union guys will tear me a new …”
“Come on Henry. These are just silly cubicles. Give me a chance to prove that what I’m doing has value. I’ll meet up with the team after the daily scrum and I’ll commit myself to two things :”
“Which are ?”
“First : I’ll do my damnest to make this work for the next two weeks”
“Second : If the results don’t come and they don’t like it, they can have they old ways back and I’ll put my head on the log”
“Fine Tim, two weeks, max. I’m all for this scrum thing, but don’t you make a fool out of me.”
“Promise I won’t Henry”

The end of the two weeks coincided with the end of the sprint and thus the sprint review. At the retrospective, the team had an activity where each member could give out a symbolic flower to a team member
for an extraordinary performance. Some of the team members decided to give one to the ScrumMaster for taking out the cubicles, which most recognised was an impediment to the team’s success.

On the last Friday of the following sprint, the entire team decided to head out for lunch and beers at the local terasse. The sun was warm, the beer was cold, the staff was lovely and the discussions were great.
After a few suds they realized they had seriously busted their lunch time. They could not have cared less. The team spirit was great and they were ahead on schedule.

They came back to work laughing and on their way in you could hear some of the employees grunting because of the distraction.
“Who are those slackers coming back from lunch in the middle of the afternoon ?” asked some of their fellow employees.

They were starting to look like outcasts. Eventually the lunch and beer became a staple of this team and even as the team members came and went, the tradition seemed to hold on.

The following spring, Maurice, the senior member of the team and John the new inmate as they liked to call him decided to organize a fishing weekend for the entire team. Surprisingly, the entire team accepted the invitation.

When they left the office that day, the entire place went back to it’s dead silent state. Had he kept his manager office’s door open, you could of heard senior manager Pete cussing his current director.
Pete was besides himself. How could the director cut off his budgets like that ?
His team had been dysfunctional for as long as he could remember and now things were starting to get personal.

Pete thought he had the perfect plan. He had been working for the past few weeks on a secret team building activity.

All it took to fix his teams’s spirit he thought, was a 4 hour activity which his boss would not finance. Yeah right.

-Nicholas Lemay

Agile lessons learned #2 : In Peter we trust(ed).

Tim came over to Chris’ house the other morning. Chris is a professional fishing guide. He actually gets paid to do what men work all year round to get to do for a single week. They both packed their gear before the sun had even lifted.

By 5:30 they were hitting the water. The lake was so calm you could the see the the reflection of the mountains as clear as in a mirror while the morning fog lifted off the ground. As they arrived to their first spot, it looked as though the boat was cutting waves through a sea of mercury.

By 7h30 they both had caught their quotas and started chilling in the back of the boat looking for catfish.

“Man is that the life or what ?” – said Tim.
“You betcha!”
“Man can you believe I actually get payed to do this ?”
“Yeah, ain’t that a shame ?”
“So are you still the Master at your job?”
“If you mean, SCRUM master then yes, I still am.”
“Oh excuse me, oh master of scrum”
“So when are you getting promoted to being God ?” Chris laughed.

“Oh you mean just like Peter right ?”

Peter was their former boss when they both were working in a warehouse back in college. The guy had no manners, no formal education but a truckload of ambitions. He went from broom-boy to foreman on the night shift within his first year. Within five years, he was in charge of the entire shipping department.

Before he hit age thirty, he was in charge of the entire regional section of the now multinational enterprise. He used to have the following saying : “When I wake up, I tell God He can go back to sleep. I’m in charge now.”. He repeated this phrase so often that he started believing his own hype.

“Actually, I’m not in charge of anyone” said Tim.
“Really ? ”
“Actually, I don’t even have what you’d call a superior ? ”
“You’re serious?”
“Yeah. In scrum all you have are self-organizing teams where each members has a crucial role in the entire process.”
“Actually, baring similar talent, experience and other qualities, not a single one member is more important than the other one. ”
“Wow, if Peter heard of this idea he you blow a gasket!”
“Damn straight.”

Tim went on explaining the finer advantages of self-organizing teams :

-> Members are more committed to the success of the project since they were all deeply involved in the decisions process. Feeling they have a certain amount of control of the projects destiny they gradually get more and more deeply involved and connected to the project.

-> No hierarchy means the people accountable for the success of the project are the ones working on it. This removes the pressure sent on the teams superior who’s usually the person that’s accountable for the teams success, yet is the person who has the less influence on the actual day-to-day work being done.

-> Self-organizing teams lets creative mind break loose, whereas in teams where the job in imposed, the creative people in a team are stuck waiting for their boss to tell them how to do things instead of letting the ideas emerge from the most imaginative people of the group, whoever that may be.

-> In a traditional team, communication is centered around the superior. He/she is the communication bottleneck of the entire team.

He also went on explaining how scrum as a process is so well suited for self-organizing teams:

-> Frequent inspections means the members skill progress more rapidly and by doing so the members build more confidence in themselves and do so at a much faster rate.

-> Frequent releases means rapid adjustments. Teams do experience failures. But they are short lived and since they come from a short time investment, do not take as long to recover from.

-> The roles are well defined and the development team is at center stage.

-> Communication is encouraged through daily stand up meetings, sprint reviews, demos and retrospectives. Also, working in open space areas and pairing is heavily promoted from many scrum practitioners through XP engineering methods.

“Wow that looks great said Chris. Too bad I never experienced self-organized teams when I was working … I mean when I had a real j…You know what I mean.”
“You think it would of made things different”
“Maybe. Wonder how a guy like Peter would fare in such an environment. That guy must have been promoted to King of the free world by now”
“Actually Peter got fired the other week”
“REALLY?!”
“Yeah saw his profile on LinkedIn. He was looking for a new job.”
“Wow. Must of stepped on too many toes.”
“Hehehe. Ever heard of the Peter principle?”
“Can’t say I have.”
“It came from a guy named DR Laurence J Peters. He wrote a whole book on the subject. It can actually be summed up to this: “In a Hierarchy Every Employee Tends to Rise to His Level of Incompetence” meaning that in a hierarchy, the best member of a certain level is usually the one promoted to a superior level. Thus someone will keep on getting promoted until he his no longer good enough to be promoted any further. Thus reaching his own level of incompetence.
“Damn, Peter sure did have the right name.”
“Indeed he did, indeed he did” said Tim laughing

-Nicholas Lemay

I just want my coffee!

My current client is located near a McDonald’s so it has become my office away from the office. The main features of this location are wireless internet connection and of course, lots of coffee. To my surprise, the coffee at McD’s is pretty good! But getting a cup of it is a tad bitter.

The procedure to “efficiently” serve clients is quite evident. The cashier takes the order, punches it in the register, the bill comes out and adds it to a queue of orders on the counter, either on a tray, on a take-out bag or stand alone (when you order a coffee). A copy of this order is printed out in the back and another employee is responsible for assembling it. Sounds like a pretty good set-up.

My “beef” with this is… I just want a coffee!

I order a java but it won’t arrive until Joe gets his Egg McMuffin trio, Joan gets her pancakes and that sweet elderly couple get their whole wheat toasts, no butter. Of course, employees are simply following the plan laid out by management to effectively control the flow of orders –The perfect recipe to control chaos. At this point, the cashier is just standing there or even worse, taking more orders and adding to the queue. Now we are about 10 clients huddle together and waiting for orders that vary from a simple blueberry muffin to the complex Egg McMuffin with no cheese.

Using this time to reflect, I get this shiver down my spine when I remember that my many of my clients are doing exactly this! Ouch!

Instead of following the well defined and linear plan, why can’t the cashier quickly dispense the muffins and the coffees and thus reducing the queue by at least half?

Instead of completing form x, going through the architectural review, finalizing a use case and running a formal peer review, why can’t a development team bypass this and deliver quick value and high return on investment?

I often use the McD’s example by asking teams: Is this a coffee or Egg McMuffin trio…with no cheese? For this specific feature, do we really need to go through the regular channels and overhead or do we have an opportunity to deliver quick value? Not surprisingly, the answers are often to bypass the “normal” procedure. What IS surprising is that the methodology gatekeepers often agree! The result of this is:

  • reduced inventory
  • reduced motion
  • and reduced waiting

Who said reducing waste was difficult? ;)