Tout va parfois trop vite au bureau et il n’y a pas de pause pour approfondir ce qui vous passionne: programmer !

Alors, venez à la première retraite du programmeur (ou Code Retreat en anglais) qui aura lieu à Québec le samedi 21 mai 2011. Une retraite est une journée complète où des programmeurs passionnés se réunissent pour apprendre et pratiquer leur métier tout en s’amusant.

Les changements fréquents d’équipe et les six sessions permettent d’échanger et d’apprendre de vos pairs en utilisant différents langages. Ceci donne tout son sens à l’expression “artisans programmeurs” (Software Craftsmanship).

Pour notre première édition, nous avons la chance d’accueillir à titre de facilitateur (animateur) Corey Haines, un des initiateurs de réputation internationale de la formule Code Retreat.

En raison de la présence d’invités internationaux, la journée se déroulera en partie en anglais. Cependant, rien ne vous empêche de discuter en français avec vos partenaires de code pendant la journée.

Consulter les pages de ce site pour les détails:

• Comment ça marche ?
• L’horaire
• Le lieu et les commodités
• Autres informations

Pour s’inscrire, aller sur la page de l‘inscription. Ne tardez pas, uniquement 28 quelques places sont disponibles!

Vidéo d’introduction d’une précédente session à Cleveland :

Cleveland Code Retreat Introduction from Corey Haines on Vimeo.

Au fil du temps tout ces morceaux de code qui populent votre application et que plus personne n’utilise finissent par vous ralentir de façon dramatique et vous causent souvent les pires mots de tête. C’est pourquoi il est essentiel, avant de développer de nouvelles fonctionnalités, de vous assurer que celles-ci sont réellement nécessaires et seront utilisées.

Oubliez la “sauce” et les besoins incertains, et mettez votre énergie sur ce qui compte vraiment! C’est une remise en question qui sera bénéfique aux développeurs autant qu’au clients dans le moyen terme.

Just as Taiichi Ohno called overproduction the worst waste in manufacturing, unused features are the worst kind of waste in software development. Every bit of code that is there and not needed creates complexity that will plague the code base for the rest of its life. Unused code still requires unnecessary testing, documentation, and support. It will do its share of making the code base brittle and difficult to understand and change as time goes on. The cost of complexity in code dominates all other costs and extra features that turn out to be unnecessary are one of the biggest killers of software productivity.

An important consideration to bear in mind when schedules become a commitment is that people must always have the time to do the job that they have committed to complete, and at the same time, the details of the job will always change. If you expect teams to meet aggressive deadlines, you must limit work to capacity. [...]

Limit Work to Capacity

Far too often we hear that the marketing department or the business unit, “Has to have it all by such and-such a date,” without regard for the development organization’s capacity to deliver. Not only does this show lack of respect for the people developing the product, it also slows down development considerably. We know what happens to computer systems when we exceed their capacity—it’s called thrashing. [...]

Time sometimes seems to be elastic in a development organization. People can and do work overtime, and when this happens in short bursts they can even accomplish more this way. However, sustained overtime is not sustainable. People get tired and careless at the end of a long day, and more often that not, working long hours will slow things down rather than speed things up. Sometimes an organization tries to work so far beyond its capacity that it begins to thrash. This can happen even if there appear to be enough people, if key roles are not filled and a critical area of development is stretched beyond its capacity to respond.

However you do it, remember that it is impossible to implement responsibility-based planning and control unless you understand the capacity of each team and limit the work expected of a team to its capacity. [...]

Extrait tiré de Being Geek, par Michael Lopp

The Creative

The panic junkie is the person who is addicted to Crisis and, in the absence of it, will manufacture drama in order to create additional Crisis. Their intent was originally good; they wanted to get stuff done quickly and discovered that the umbrella of a Crisis removed traditional organizational roadblocks. Problem is, they’ve become addicted to the power and momentum granted to them by driving the crisis. As soon as the current Crisis appears to have passed, they defate, thinking, “Blah, back to the normal,” and immediately start looking for another Crisis. If they don’t find one, they create it.

I was one of these people and burned a lot of calories getting a lot done, but management by Crisis is a losing strategy. You become a corporate arsonist—burning through people and process in your apparent endless hurry, but not actually building anything.

There’s always a Crisis in progress. It’s a statistical fact that in any decent-sized group of people there is one person who needs help with some part of a Crisis. Get used to it. The question I ask myself each morning as I stare at the day’s selection of Crises is: “Am I going to play in the Crisis or the Creative?” I’m not talking about being Creative about solving a Crisis such that it never occurs again, I’m talking about work that is purely Creative—where you’re actively improving or building a thing. It’s writing that piece of code that nobody but you wants; it’s spending two hours recruiting that guy you’re never going to get; it’s standing in the design room with a variety of dry erase markers and just flling that whiteboard with random. I’m not talking about impossible tasks; I’m talking about Creative ones. I’m talking about inspired investments in an uncertain future. These are often hard tasks to measure, which means they are equally hard to justify to those sitting around you, but they occasionally, infrequently hit. You get the guy. You fnd the idea. You build something new.

Given the constant presence of Crisis and things to do, the act of choosing to devote part of your time to a purely Creative activity can be rough, but if you’re going to grow, there have to be times where you let things go further to hell in the now, because you’re choosing to invest in the Creative for the future.

That’s right. You are going to actively ignore a burning Crisis so that you can hide in the design room and doodle on a whiteboard. The panic junkies are going to be pissed.  They’re going to walk by, laptops in hand, and wonder, “Why the hell isn’t he all over the Crisis? Doesn’t he know it’s, ya know, A CRISIS?”

Yes, it’s a risky move. Yes, there are crises that can’t be ignored. Yes, if you piss off the wrong panic junkie, you’re going to hear about it—quickly—but the bigger risk is a panic-filled career reacting to disasters, instead of one where you’re recognized for what you’ve built versus what you’ve fxed.

Humans suffer from a bright’n’shiny complex, where we’re titillated by the new. Think of it like this: have you actually done anything with that last domain you bought? No. You had the idea for it on Tuesday morning and you got all fred up, so you bought the domain the moment you got in to work. At lunch you furiously doodled your design in your notebook, fully intending to get home and get started on the HTML/CSS, and then you got home…and watched Lost.

Take the bright’n’shiny complex and apply it to your entire group, where everyone is prioritizing their day by their particular inspiration, and it’s shocking that we collectively get anything done.

Management is the art of choosing what not to do

What I’m telling you is that management is the art of choosing what not to do, which means you need to be ready and willing to look at the task at the end of a day and ask, “OK, I made this urgent this morning. A day has passed and I had time, but never got to it. Does it matter?”

Priority is relative. What felt so important last Wednesday loses importance five days later when the larger context of your week, your month, and your career shows up. You need to develop a practice of strategic information shedding where you are constantly and intelligently jettisoning ideas and work.

Bilan :

Arrêtez de vouloir tous trier, tout prioriser, tout associer à des dates de livraisons. La vérité c’est que tout va changer et que ce qui est votre priorité aujourd’hui ne le sera fort probablement pas demain.

Surtout, acceptez qu’il est correct de “détruire” une todo. Il est inutile de conserver 6 ans de tâches prévues d’avance dans un monde où il rentre toujours plus d’ouvrage que nous sommes capable d’en sortir. Rendez-vous service et faites le ménage de vos liste. Si ces tâches sont vraiment importantes, elles vont revenir d’elles-mêmes

Predictable outcomes are one of the key expectations that the marketplace imposes on companies and their senior management, and these expectations eventually flow down to software development. Unfortunately, software development has a notorious reputation for being unpredictable, so there is a great deal of pressure to make it more predictable. [...]

Because we assume that our predictions are facts, we tend to make early decisions that lock us into a course of actions that is difficult to change. Thus, we lose our capability to respond to change when our predictions turn out to be inaccurate. [...]

We forget that the predictions of the future are always going to be inaccurate if they are 1) complex, 2) detailed, 3) about the distant future, or 4) about an uncertain environment. [...]

There are, however, well-proven ways to create reliable outcomes even if we canot start with accurate predictions. [...] Fundamentally, an organization that has a well-developed ability to wait for events to occur and then respond quickly and correctly will deliver far more predictable outcomes than an organization that attempts to predict the future.

Pour réellement arriver � corriger un problème, il est primordial de commencer par bien le comprendre. Il faut en trouver les racines. De plus, l’effort supplémentaire pour bien analyser le problème va se payer de lui même en nous permettant de découvrir une solution qui sera souvent plus simple que l’on envisageait au départ.

Dans le livre Toyota Production System, Taiichi Ohno explique qu’il utilise la technique suivante : Répétez « Pourquoi? » 5 fois

Repeating Why Five Times

When confronted with a problem, have you ever stopped and asked why five times? It is difficult to do even though it sounds easy. For example, suppose a machine stopped functionning :

1. Why did the machine stop? There was an overload and the fuse blew.
2. Why was there an overload? The bearing was not sufficiently lubricated.
3. Why was it not lubricated sufficiently? The lubrication pump was not pumping sufficiently.
4. Why was it not pumping sufficiently? The shaft of the pump was worn and rattling.
5. Why was the shaft worn out? There was no strainer attached and metal scrap got in.

Repeating why five times, like this, can help uncover the root problem and correct it. [...] By asking why five times and answering it each time, we can get to the real cause of the problem, which is often hidden behind more obvious symptoms.

Depuis le début de l’année, nous avons joué avec la métho Scrum, et en avons constaté des points positifs et négatifs chacun de notre côté. Lors de la présentation du Kanban, Marc (notre nouvel Architecte Senior) et moi avons vraiment eu l’impression que cette approche collerait mieux � nos processus de maintenance habituel et de priorités toujours changeantes.

Nous sommes donc en implantation du Kanban depuis mardi dernier. Comme l’implantation de n’importe quel processus de travail dans une équipe ne se fait pas sans douleur, j’ai décidé de partir � la recherche d’articles et de présentations écrits par du monde plus éloquents que moi et expliquant les “pourquoi” du Kanban afin de m’appuyer sur de bonnes bases pour vendre ma salade et aider tout le monde � mieux saisir les objectifs visés.

Henrik Kniberg a rédigé ce document que je suis en train de lire et qui me semble être la meilleure introduction :

Kanban vs Scrum – how to make the best of both

From his blog :

• Jim: “Now we’ve finally gone all-out Scrum!”
• Fred: “ So how’s it going?”
• Jim: “Well, it’s a lot better than what we had before…”
• Fred: “…but?”
• Jim: “… but you see we are a support & maintainance team.”
• Fred: “yes, and?”
• Jim: “Well, we love the whole thing about sorting priorities in a product backlog, self-organizing teams, daily scrums, retrospectives, etc….”
• Fred: “So what’s the problem?”
• Jim: “We keep failing our sprints”
• Fred: “Why?”
• Jim: “Because we find it hard to commit to a 2 week plan. Iterations don’t make to much sense to us, we just work on whatever is most urgent for today. Should we do 1 week iterations perhaps?”
• Fred: “Could you commit to 1 week of work? Will you be allowed to focus and work in peace for 1 week?”
• Jim: “Not really, we get issues popping up on a daily basis. Maybe if we did 1 day sprints…”
• Fred: “Do your issues take less than a day to fix?”
• Jim: “No, they sometimes take several days”
• Fred: “So 1-day sprints wouldn’t work either. Have you considered ditching sprints entirely?”
• Jim: “Well, frankly, we would like that. But isn’t that against Scrum?”
• Fred: “Scrum is just a tool. You choose when and how to use it. Don’t be a slave to it!”
• Jim: “So what should we do then?”
• Fred: “Have you heard of Kanban?”
• Jim: “What’s that? What’s the difference between that and Scrum?”
• Fred: “Here, read this article!”
• Jim: “But I really like the rest of Scrum though, do I have to switch now?”
• Fred: “No, you can combine the techniques!”
• Jim: “What? How?”
• Fred: “Just read it…”

Kanban vs Scrum – a practical guide

Ce fût une journée vraiment excellente qui m’a permis de me requestionner sur plusieurs accrochants auquels nous faisons faces � tous les jours dans l’équipe de développement web.

J’ai trouvé particulièrement intéressant les sujets suivants :

• La philo TDD (Test Driven Development)
• L’utilité évidente des tests unitaires (Unit Tests) automatisés et leur impact sur la productivité
• L’approche d’intégration continue
• La métho Kanban
• Les estimés T-Shirt
• La règle « Pull , don’t push »
• La liste des « 7 wastes of Software Development » et l’analogie de l’Empire State Building par Mary Poppendieck

Je vais essayer de détailler certains de ces points dans les prochains jours pour partager et pour m’aider � décanter tout ça…

D’ici l� , si vous avez participé � la journée, j’aimerais bien connaître vos « highlights ». Qu’avez-vous appris de neuf? Qu’est-ce qui fonctionne ou qui ne fonctionne pas dans votre contexte de travail?

Nous entamons actuellement le 5ième sprint de l’année et l’instauration de la méthode se déroule relativement bien, mais certes pas sans générer certaines frustrations au sein de l’équipe et des gens qui gravitent autour.

Après 4 sprints, je me suis dis qu’il était temps de faire une rétrospective et d’essayer de comprendre ma propre opinion sur le sujet. À savoir : est-ce que j’aime ou je n’aime pas la méthode Scrum?

Les bons points :

Le matériel. Ça peut paraître niaiseux, mais c’est plaisant. Les cartes de planning poker, les grands tableaux blancs, les petits aimants en forme de post it, je dois dire que Sam nous a bien équipé dès le départ.

Pouvoir prendre son temps. Pour bien faire les choses. Pour se consulter. Pour être au courant de ce que tout le monde fait et des implications sur son propre travail. Pour bien penser les features en équipe plutôt que chacun de son côté enterré par ses propres urgences.

La carapace. Les développeurs dédiés au sprint sont quasi imperméables aux urgences pas si urgentes que ça qui ne manquent jamais de survenir normalement et qui empêchent d’avancer leurs dossiers principaux. Une fois la structure installée, c’est le/les développeurs responsables de la garde qui écopent.

La planification et l’ordre des priorités. À partir du moment ou les semaines sont gelées en blocs, le rôle et la responsabilité du Product Owner est multipliée par 10. Les demandes sont accumulées par sujets, et il n’y a plus de place pour les projets pas si importants que ça. Le travail devient automatiquement plus planifié (un peu) � l’avance et réfléchi.

Aide � comprendre. En se rencontrant � tous les jours et en voyant au tableau la progression des projets, il est beaucoup plus facile de voir les dérapages et de comprendre ce qui les cause. Ça aide � comprendre pourquoi un projet n’est pas encore fini après X semaines alors que d’habitude on a juste l’impression de tourner en rond et d’avoir des développeurs qui se pognent le steak…

Intègre l’équipe et mets en relation. Les démos avec les gens de la compagnie permettent une interaction particulièrement intéressante et du feedback qui n’était pas aussi présent lors des autres projets. L’équipe s’en trouve mieux intégrée � l’entreprise.

Les mauvais points :

Le mot Scrum. Ça sonne comme Scrotum. Bon… Ça a l’air de rien, mais ça n’aide pas � faire aimer la structure � ton boss quand il veut te balancer une urgence et qu’il ne peut pas � causes des méthodologies agiles…

Le livre dit de faire ça. Comme dans toute structure, il arrive des moments ou tout le monde a l’impression qu’on fait quelque chose qui sert � rien mais que la structure dit de le faire. Ceci dit, on est pas plus fou que d’autres et on sait très bien qu’il ne s’agit pas d’appliquer une recette exacte sans l’adapter � notre réalité. Il arrive quand même que certains intervenants ne voient pas la pertinence de chacune des étapes… Surtout dans les premiers sprints.

Un solide coup de pied dans les couilles de l’innovation. Le fait de savoir 6 mois d’avance les projets qui s’en viennent permet certes de mieux les planifier, mais ça élimine également presque complètement la place pour les dérapages et les bons flash. Ces concepts innovateurs qui mènent plus souvent qu’autrement sur une fausse piste, mais qui permettent aussi parfois de tirer dans le mille et de garder sa compagnie en avant des compétiteurs.

Ce qui est bien, c’est que DuProprio alloue du temps aux développeurs � chaque semaine durant lequel ils peuvent travailler sur ce qu’ils veulent. C’est ce qui nous a permis de créer la section Twitter il y a quelques semaines d’ailleurs…

Agile? Je crois que je ne comprends pas la signification du mot agile. Je veux dire… 3/4 des irritants qui ont été ressentis durant l’implantation de cette structure étaient liés au fait que l’on devenait moins agile… Moins apte � se revirer sur un dix cennes au gré des idées et des brainstorming.

On a jamais planifié autant que cette année (même si de l’avis de plusieurs nous ne le faisons toujours vraiiiiiiiiiiiment pas assez!). DuProprio a toujours été une compagnie excessivement agile, qui agit d’instinct, qui se trompe, qui se relève et qui score. Ça a toujours été notre point fort, mais aussi notre point faible… Alors bon, les choses changent, on vieillit et on devient plus sage j’imagine…

Chez DuProprio, Scrum n’est pas une méthodologie agile. C’est une méthodologie de développement réfléchi…