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
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.