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

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…

L’an dernier, nous avons souvent eu l’impression de pédaler dans le vide et de ne pas avancer assez vite � notre goût, � force de toujours travailler sur 10 000 choses en même temps. L’équipe grandit rapidement, et la recette magique d’organisation et de coordination des ressources n’est toujours pas parfaite…

Je ne ferai pas parti directement de l’équipe qui exécutera le premier projet Scrum des 3 prochaines semaines car je vais m’occuper d’éteindre les feux et de “goaler” les urgences mais j’ai bien hâte de voir comment le tout va se dérouler. C’est une approche qui a réglé bien des problèmes dans une multitude de compagnies.

Pour en savoir plus sur cette méthode agile de développement, je vous suggère les liens suivants :

http://fr.wikipedia.org/wiki/Scrum

Explication rapido en 5 minutes »

Explication longue, pour les plus courageux »

ou encore, la version vidéo :

http://video.google.com/videoplay?docid=-7230144396191025011