Category : Scrum

in Développement logiciel, Scrum

Une belle réussite de Pyxis à CAE Santé

Dernièrement, CAE Santé annonçait le déploiement d’un système de gestion de centre d’entraînement médical avec le CHU Sainte-Justine.

Saviez-vous que Pyxis a collaboré à ce projet?
Pyxis est très fière des résultats de la mise en place de Scrum pour la réalisation de ce projet. Trois collaborateurs ont participé au projet. Marc-André Filion-Pilon occupait le rôle de Scrum Master, veillait à la gestion du projet et agissait à titre de facilitateur. Erik Lebel et Éric de Carufel ont agi à titre de développeurs .NET. Leur expérience a permis d’aider l’équipe dans l’application de pratiques Agiles d’ingénierie logicielle.

Ce que Scrum a permis à l’équipe de CAE Santé
L’emploi de la méthode Scrum pour la réalisation du projet a permis d’atténuer plusieurs risques, notamment en favorisant des cycles courts de développement (sprints de 2 semaines). Ceci a permis la révision en continu des priorités et l’adaptation du processus en fonction des succès et problèmes rencontrés. De plus, nous avons utilisé plusieurs artefacts simples et efficaces de Scrum pour assurer la visibilité relativement à l’avancement du projet (carnet de tâches du sprint et de la livraison, graphiques d’avancement, etc.).

Au niveau des besoins, il était essentiel de les clarifier et de les prioriser conjointement avec le client et les utilisateurs finaux. Le rapprochement avec les utilisateurs et une plus grande implication de leur part ont permis de gérer les attentes tout en assurant une grande transparence.

Défis techniques
Un des plus grands défis d’un projet de développement ayant un délai très court et un important périmètre est de ne pas couper dans la qualité (perçue ou interne). Or, ce risque a été pris en compte en favorisant des déploiements rapides, ce qui a permis de faire des tests et de recevoir du feed-back rapidement. De plus, l’utilisation de patrons et de cadres transversaux dans l’application permet du développement plus rapide, uniforme et fiable.

Bravo à toute l’équipe qui a réalisé ce beau projet!

Voir le système en action

in Agile, Scrum

#scrum release burndown chart

PM: I want to see increase the velocity of the Team
PO: I want to see decrease the remaining work

PM: If the velocity increases, the remaining work will decrease
PO: No, new work could be added at the same time

PM: I don’t like when the Team updates an item with a smaller effort estimation because the velocity could decrease
PO: I like when the Team updates an item with a smaller effort estimation because the remaining work decreases

PM: You don’t track the velocity in a velocity chart?
PO: No, I track the remaining work in a release burndown chart

in Agile, Scrum, Sur le terrain

Joy of Agile – On the plane!

Attached are excerpts of the internal news bulletin of an organization we started coaching in 2008. They had the courage to do things differently and are now reaping the benefits.  Being in the avionics industry, the challenges in adopting an Agile approach were immense.  But the highly capable team members and management at CMC Electronics were able to surmount those challenges and come up with new and ingenious ways to get closer and closer to the coach’s (me) one simple rule: “I want this on the plane at the end of the Sprint”

But don’t take my word for it. Read on here :

Page 1

Page 2

Cheers!

Share/Bookmark

in Scrum, Sur le terrain

Definir “Terminé”

Résumé
Les axes de réflexion que je considère pour construire une définition de Terminé :

  • qualité externe
  • qualité interne
  • autorisations
  • déploiement
  • exploitation

Lorsque je travaille avec une équipe à établir ou modifier notre définition de “Terminé” (le Done de Scrum), je ne leur propose pas d’exemple comme point de départ de la discussion. Par contre je leur propose les différents axes de réflexion dans lesquels nous allons identifier les points pertinents pour eux.

Pour démarrer la discussion, je propose de commencer par explorer les axes qualitatifs :

  • qualité externe
  • qualité interne

Qualité externe
Cette notion de qualité externe nous parle de notre capacité à construire le bon logiciel, celui qui rend les services souhaités, à un niveau de performance satisfaisant, à un niveau d’ergonomie qui fluidifie sa prise en main et son utilisation. C’est la qualité perçue lorsqu’on utilise le système.

Pendant cette réflexion, nous partageons alors comment nous comprenons cette idée de qualité externe et nous décidons quels types de tests nous souhaitons construire notre confiance dans notre code : des tests automatiques qui exercent le système dans son ensemble avec des données réalistes, des tests qui spécifient les conditions aux limites des services rendus, des tests de performance, des tests de sécurité, des tests de traduction, …

La question des anomalies est parfois abordée à ce moment dans la discussion. Cette discussion peut être difficile parce que chargée d’un historique peu flatteur pour les programmeurs. On distingue ici deux types d’anomalies: les anomalies que l’on découvre après la mise en production et celles que l’on connaît avant la mise en production.
Pour les premières, il s’agit de définir comment nous allons les prendre en compte, c’est à dire comment leur découverte va impacter le travail en cours. La démarche stop the line du Lean est la démarche la plus cohérente avec une approche empirique, même si elle représente des défis importants.
Pour les secondes une attitude cohérente avec ce que l’on vient de dire consiste à ne jamais déployer un système avec des anomalies connues. Cela demande souvent beaucoup de courage dans des environnements qui ont malheureusement appris à supporter des systèmes avec beaucoup d’anomalies.

Qualité interne
Cette notion de qualité interne nous parle de notre capacité à construire correctement un logiciel. Par correctement, on entend ici un logiciel que l’on peut faire évoluer durablement. Plusieurs outils aujourd’hui sont capables de construire des indicateurs qui, lorsqu’on les améliore, nous aide à construire un logiciel que l’on peut faire évoluer durablement. Par exemple le pourcentage de couverture de code par des tests unitaires et d’intégration, la compléxité cyclomatique, le taux de duplication… Certains outils, comme Sonar, vous permettent même assez simplement d’implémenter votre propre règle.

Les tests automatiques sont des indicateurs de qualité assez simples à construire car ils se basent sur une analyse statique du code, c’est à dire sur une photo du code à un instant donné. Or il se trouve que l’on a constaté que le fait d’écrire un test avant d’écrire le code de production qui le fait passer a un impact majeur très positif sur la qualité du logiciel construit. On parle ici d’un indicateur de qualité dynamique qui nous renseigne sur la manière dont le logiciel a grandit. La plupart des équipes mettent en place cette idée simplement en ayant la discipline de toujours écrire un test avant d’écrire du nouveau code.

Vient ensuite, dans l’ordre chronologique des étapes à passer pour être prêt à déployer un système en production, la question des autorisations nécessaires.

Autorisations
Certaines industries contrôlées imposent aux créateurs de logiciels de faire la preuve de certaines caractéristiques dans un format imposée par une convention. C’est le cas par exemple dans l’avionique ou la pharmacie, pour en citer deux à priori assez éloignées. D’autres normes, internes celles-ci s’imposent parfois aux équipes.

La plupart du temps, ce besoin d’autorisation déclenche la rédaction de document dans un format souvent imposée à l’équipe. Le travail récurrent d’une itération à l’autre consiste alors selon les cas à les créer ou bien à les tenir à jour.

Déploiement
Le déploiement par incréments successifs suppose que plusieurs déploiements vont être effectués pour mettre à jour un système. Dans ce contexte, il est pertinent de ne pas considérer le premier déploiement comme un cas particulier mais bien comme le déploiement d’un incrément qui part d’un état précédent vide.
Des éléments de différentes natures sont à considérer. Sans ordre d’importance, on peut citer : un moyen d’interdire l’accès au système pendant le déploiement du nouvel incrément, la modification de l’environnement, la modification des configurations réseaux, la modification de la structure de données, la migration des données, … Disposer de tests automatiques de déploiement s’avère encore une fois très utile pour être capable de déployer chaque incrément sans détruire le système déjà en place.

Exploitation
Ce qui précède concerne la préoccupation de mise à jour d’un système existant. Il faut aussi considérer les activités qui tournent autour de l’utilisation du système en place. Selon les cas il s’agit de choses aussi variées que des scripts de redémarrage, la formation des utilisateurs, la formation des équipes travaillant à la hot-line du système, …

Si le développement incrémental est nouveau pour vous et que vous avez des difficultés à établir votre définition de Terminé avant de commencer, rassurez-vous c’est normal. Explorez pendant une première discussion les différents axes de réflexion qui vous semblent sensés et établissez vos premiers indicateurs en fonction de la vision du produit. Faites une itération et pendant la revue d’itération posez vous la question: est-on prêt à déployer cet incrément en production ? Si oui, faites le. Si non, améliorez votre définition de Terminé pour la suite.

in Nouvelles et événements, Scrum

Devil’s Project

Don’t update that burndown chart
Close your eyes and stay in the dark
If the ghouls and goblins were to see
It would mean trouble for you and me

Those demons are really scary
Filling the Backlog with all kinds of stories
Scope is increasing by the hour
If they don’t stop soon, their heads they will devour

Transparency is evil when facing complexity
Mischief is easier under the cover of opacity
They hate the daylight, “it’s no fun”, they say
Turn off those lights so they can run and play

But Devil’s project is almost over
The sun will shine sooner or later
If the ghouls and goblins weren’t sacred before
Just you wait ‘til they open that door

Happy Halloween! MooHAHAHAHA!

Share/Bookmark

in Agile, Développement logiciel, Scrum, Vie @ Pyxis

De la théorie à la pratique

Cela fait maintenant 4 mois que je travaille à Pyxis et les bancs de l’Université me semblent déjà bien loin. Pas forcément en terme de temps, mais plutôt d’un point de vue pratique.  Lors de mes études en management et communication j’ai trouvé la transition entre la théorie et la pratique évidente et facile mais en ce qui concerne cette transition dans le domaine de l’informatique, c’est une autre paire de manche.

Qu’est ce qu’on nous apprend au département informatique de l’université? Des langages de programmation majoritairement, des mathématiques, de l’algorithmie, des notions de sécurité ainsi qu’une approche du montage vidéo et des outils de DAO. Évidemment c’est un passage obligé et comme la plupart de ces concepts étaient nouveaux pour moi, j’ai pris beaucoup de plaisir à me plonger dans ce milieu qui m’avait toujours attiré. Je buvais donc les paroles des professeurs qui me disait que Java était un langage émergent, que l’abondance de commentaires dans du code était synonyme de qualité et que de prévoir la conception d’un projet sur le long terme évitait les surprises désagréables.

Étape numéro 2 : j’arrive à Pyxis. Tiens, c’est bizarre les gens autour de moi parlent de concepts légèrement opposés à ce que j’ai appris précédemment. “Java? C’est dépassé, trop lourd et pas assez élégant! Oriente toi plutôt vers Ruby, d’ailleurs apprend le on en a besoin pour le store d’Urban Turtle :) “. D’accord, c’est parti pour la programmation artistique alors. “Des commentaires dans ton code? Ca veut dire que ce que tu écris n’est pas clair, epic fail!” Oui c’est vrai en fait, ça parait logique. On va faire des micros classes et fonctions et du code ultra explicite. “Préparer et prévoir des projets sur le long terme? Va falloir que tu t’intéresses de près à Scrum!” En effet, le concept est fascinant. “D’ailleurs le TDD tu connais?” A moins que tu parles de Tranches De Dinde fumées non pas vraiment, mais je vais m’y intéresser!

Actuellement je baigne dans ces nouveaux dogmes, et en apprends tous les jours sur ces sujets passionnants. Notamment grâce aux cours de ScrumMaster et ScrumProfessional Developer offert par Pyxis qui m’ont permis de beaucoup progresser. Néanmoins, appliquer et intégrer tous ces schémas demandent du temps et du travail et il aurait été souhaitable qu’ils fassent partie d’une manière ou d’une autre des formations informatiques proposées à l’Université. Dans un domaine autant versatile que le développement logiciel, je pense qu’il est nécessaire d’adapter les formations proposées à la réalité du marché et que les responsables de programmes devraient se remettre en question régulièrement pour fournir à leurs étudiants un bagage complet correspondant aux attentes des entreprises les plus avant-gardistes comme Pyxis.

Gaël Luisier

in Management, Scrum

You need a ScrumMaster to change the old style

There seem to be a confusion between the role of the ScrumMaster and one of a team facilitator. Jason Little recently wrote that you might need a coach, not a ScrumMaster:

So what is a coach going to give you compared to a Scrum Master? Scrum talks about a Scrum Master as the team facilitator, someone who is there to protect the team, remove obstacles and help the team function better. Essentially the scope of a Scrum Master is local optimization for the team.

A coach, on the other hand, will be focused on optimization of the organization. Often they are working and thinking on multiple levels and deeper when team output is exposing other organizational dysfunctions.

I disagree. This is a misinterpretation of the role of the ScrumMaster. Scrum is a tool that an organization can use to address hard problems. It is a tool to foment change. An organization that decides to use Scrum to address its issues is choosing very hard work. Only few organizations will fully take advantage of Scrum. The remaining organizations will try to use Scrum and run into ScrumButs. ScrumButs are the reasons why they cannot take full advantage of Scrum to solve their problems and realize the benefits. Each ScrumMaster is responsible for fighting ScrumButs by maintaining the integrity of the Scrum process, even if it is in conflict with the organization. This is much more than a facilitator role, right?

Of course, when a ScrumMaster starts working with a team, he or she might act as a parent, teaching the team how to self-organize. As the team gets more mature though, the ScrumMaster will spend more time working with management on the ScrumBut backlog to remove the dysfunctions of the organization. The ScrumMaster is not a team facilitator, it is a secret change agent!

in Scrum

Agenda cyclique

J’étais récemment chez un client pour faciliter une journée de planification de release et encore plus récemment en Belgique pour animer une session de formation Scrum pendant laquelle je décrivais cette journée. Ce retour d’expérience s’est avéré être de valeur pour les participants alors je tente une version écrite ci-dessous.

J’utilise de plus en plus ce que j’appelle un agenda cyclique pour animer ce type de rencontres. Il s’agit d’une part de rendre visible que nous faisons une réunion avec un objectif partagé et que plusieurs activités vont nous aider à l’atteindre. Et d’autre part d’afficher clairement le droit qu’ont les participants de changer d’activité.

Donc ce jour là nous étions réuni pour construire un planning de release. Je commence par le dessin ci-dessous.

Notez au passage que cela permet de garder visible au tableau et clair dans nos têtes l’objectif de notre journée. Puisque le client du jour nous avait demandé de l’aide à la mise en place de Scrum, j’ai commencé à dessiner des activités en utilisant le vocabulaire de Scrum.
Au début de la journée, il n’y avait que les éléments faciles puis au fur et à mesure de la journée, j’ai ajouté les éléments potentiellement plus polémiques qui nous permettait d’avoir les conversations les plus utiles pour la suite.
Comme le pointait récemment Vincent (dans ce blog), l’art de déclencher les bonnes conversations est le coeur du boulot du ScrumMaster. Laisser des places vides dans le cercle de l’agenda vous donne la chance d’être opportuniste pendant la réunion et de focaliser l’énergie des participants en pointant l’élément difficile pour eux, tout simplement en l’écrivant au mur et en proposant d’en parler.
Maximiser l’intérêt de ce cercle réside essentiellement à ne pas reproduire avec lui un comportement de réunion en cascade pendant laquelle les activités s’enchaîneraient dans un ordre établi à l’avance et où implicitement on se revient pas sur une activité passée.

Ici au contraire, itérer sur les mêmes activités pour profiter de ce que l’on a appris a beaucoup de valeur.

Exemples:

Le PO essaye d’estimer une valeur d’affaire relative pour un groupe d’éléments. Il n’y parvient pas. Son sentiment intime est qu’il faut faire l’ensemble ou rien. Il a donc envie de mettre la même valeur relative à chaque élément. Tout le monde l’invite à se forcer à trouver des valeurs différentes. On semble dans l’impasse.
Et si on fusionnait ces éléments et qu’on cherchait un autre axe de découpage, plus orienté valeur ?

Un calcul automatique de ROI nous incite à adopter une priorisation qui semble n’avoir aucun bon sens. Faisant appel à ce bon sens, le PO et la Team priorise le Product Backlog et le résultat frustre les participants car les premiers éléments prioritaires n’apportent aucune valeur et il faudra attendre longtemps avant de pouvoir déployer un logiciel utile.
Et si on effaçait tout le Product Backlog et qu’on se demandait quel logiciel construire en 2 semaines pour rendre service à au moins une personne ?

Dans ces deux exemples, je constate que les participants résistent à cette idée d’effacer ou de remettre en cause le travail déjà effectué. Encore plus surprenant : c’est également le cas pendant une formation, c’est à dire pendant un exercice.

Pour aider les participants à effectuer cette remise en question, j’utilise des time-boxes assez petites pour chaque activité. Cela rappelle aux participants de ne pas tenter de finir une activité, mais de la faire contribuer à l’objectif commun.

A titre d’exemple, ci-dessous une photo de l’agenda cyclique d’un sprint planning. A l’époque je ne notais pas l’objectif de la réunion au centre du cercle mais au dessus. Maintenant je le met à l’intérieur du cercle.

in Développement logiciel, Scrum

Start doing sprint reviews, not demos

There’s a misunderstanding I’ve noticed in quite a few Scrum projects. Teams use Scrum and at the end of their sprint they do what they call a “sprint demo”. It works out like this:

  • They demonstrate their increment of the product to the product owner
  • Product owner seats passively
  • Product owner accepts or rejects the increment
  • No modification is done to the product backlog
  • After a while the product owner is unhappy with the current state of the product and the progress being made

There is nothing like a sprint demo in Scrum. But there is a sprint review.

Scrum is empirical, meaning that there are inspect and adapt points along the way. The sprint review is the inspect and adapt point where the product increment, the most current product backlog and the current conditions are for inspection. The adaptation is the modified product backlog.

During the Sprint Review, the Scrum Team and the stakeholders collaborate about what was just done during the sprint and what are the things that could be done during the next sprints. The presentation of the product increment is not the goal. It is used to understand what should be the next sprint goal. The sprint review provides input to the next sprint planning meetings. One of the possible consequences of this evaluation is the decision to not proceed further with the development of the product. Another possible consequence is the decision to release the existing product.

Consider your next sprint review. If you get out of the meeting without a modification to your product backlog and an insight to your next sprint goal, it’s probably because you’re not inspecting and adapting. You might be suffering from the “sprint demo” syndrome.