AGILE SOFTWARE DEVELOPMENT WITH SCRUM, by Ken Schwaber and Mark Beedle

I read this book to improve our current practices, which are already very close to Scrum.
I particularly appreciated:

• the emphasis on continuously removing impedents to effective work;
• the tips to deal with scaling projects, organizations and teams;
• the comparison between organizations and software. Organizations must emerge and grow in increments, just like software.
• add all tasks to the backlog, not only the functional requirements. However, each Sprint must contains a functional increment.
• the fact that requirements remain complicated even if they are understood by the domain and business analysts as long as they are too complicated for the developpers.

However, I do not agree with the fact that code is own forever by the programmer who wrote it. I prefer the collective ownership approach of eXtreme Programming.
Also, I still find that 30 calendar day Sprints are too long ... I prefer shorter iterations, mostly because of the the queueing theory. Smaller items go faster in the workflow. I believe a project will be faster completed if it is managed into shorter iterations.
But, I do really recommend this book. It made me want to read Agile Project Management With Scrum, also written by Ken Schwaber some years later.

CHAOS AND DISCIPLINE

On our current project, the team has just spent four days of work on a requirement, to finally throw the code over and start again. We got glued into some never ending refactoring which never gave satisfaction as the code never seemed testable. What a waste! We've been through the same experience already a couple of times - and hopefully we are learning from our mistakes.

We develop near chaos. This isn't a bad thing. We follow practices very close to eXtreme Programming and Scrum, so unclear requirements and emergent systems are our lot. So, why has the team suffered so much lately?

We lacked discipline. In fact, we let go just a little on two major and very constraining disciplines. The problem is that when you develop near chaos, you cannot afford to let go of these two disciplines.

By the way, some people really misunderstand agile development. They believe agility means lack of discipline and chaos. Isn't it just the contrary? To develop in a chaotic environment (such as any software development) you need to be so extremely disciplined! Isn't eXtreme Programming such an extremely disciplined methodology?

So, what are these two so important disciplines? Very frequent synchronisation and test-driven development.

On several projects, we've noticed that shortly after a pair or a single developper gets late to synchronise and deliver his code, he gets stuck in painful code and test merging. The system emerges so quickly that members of the team must keep the rhythm. Stock of undelivered code just slows you down and requires energy to catch-up. Stock means waste! Unfortunelty, it is very difficult to learn how to develop in baby steps. Developers often assert that their current task cannot be cut into small increments.

We've also noticed that developpers tend to slowly let go of test-driven-development. The problem is that they take several successive design decisions to finally discover that their code is difficult to test! Therefore, the design is inadequate and must be refactored and tested.

OK, developers gradually let go of frequent synchronisation and test-driven-development. How do you improve your habits and maintain discipline?

The solution we try is to spread good pratices and systemize checking.

• First, the team shares the same office. Therefore, everyone detects a developper or pair struggling on painful merges. Help and advice is naturally provided.
• The team attends a daily short and focused stand-up meeting. Lack of progress and painful struggling is detected. Again, help and advice is quickly provided.
• Pairing is very frequent. The teammate is there to remind the pair to work in baby steps and write tests as it writes code.
• We have a coach on the team. He's responsible for having the practices applied, training the teammembers and helping the team to continuously improve its practices. The coach detects pairs or single developers struggling in merges or falling late to deliver. He must provide advice and help. He visits the pairs and reminds them to synchronise.
  

In a world of chaos, you just can't let go on discipline! But discipline must not be imposed on the team. The team must reflect on its struggles, understand the cause of their pains and agree on trying disciplined practices to provide scaffolding. This is another subject. For more information on continuous improvement, read this post.

PRESQUE

ARCHITECTE

OBSTINATION

LE RESPECT

L'INTEGRATION SUR SITE

L'AUGMENTATION

METHODE DE RESOLUTION DE PROBLEME

CHAOS

LE MOINE CODEUR

BUREAU EXTREME PROGRAMMING

Nous développons des logiciels temps-réel critiques, embarqués pour l'avionique.

Une nécessité de travailler en équipe

La complexité des besoins des clients, le volume des développements à réaliser et la rigueur imposée par les exigences de sécurité ne peuvent être appréhendés que par un travail d'équipe.

C’est en confrontant les points du vues, en partageant les expériences et en parallélisant certains travaux que nous pouvons développer des logiciels de qualité dans les délais attendus.

Un environnement physique adapté au travail en équipe

Praticiens du développement logiciel agile, nous avons trouvé dans l'eXtreme-Programming des recommandations pragmatiques pour organiser bureaux et postes de travail afin qu’ils favorisent le travail en équipe.

L’espace projet

Notre équipe de quatre développeurs logiciel partage un même bureau. Il est directement voisin de notre salle de réunion et du bureau partagé par le chef de projet et les experts métier. Cette proximité nous permet de privilégier la communication orale de face à face et renforce la cohésion de l’équipe.

Le bureau du logiciel

Les développeurs logiciel sont tous installés autour d'une grande table afin que personne ne se tourne le dos. Nous communiquons toujours de face à face, sans avoir à interrompre les activités en cours. Ainsi tout membre de l’équipe peut aisément solliciter ses collègues pour le moindre conseil.

De plus, partager le même bureau favorise la communication passive: chacun est à tout moment au courant des activités des autres, même s’il n’est pas directement impliqué.

Dans cet espace, chaque poste est adapté au travail en binôme et aux relectures de code. En effet, chaque table peut accueillir deux développeurs qui s'échangent le clavier et la souris devant le même écran.

Tableaux blancs et post-it géants

Nous modélisons beaucoup en groupe et au marqueur en utilisant la notation UML. Les conceptions sur lesquelles nous sommes en train de travailler sont ainsi affichées en grand format. Ceci nous permet de revenir fréquemment sur nos décisions de design pour les conforter ou les remanier au fur et à mesure des informations que nous collectons en codant et en testant.

Un des tableaux est un grand kanban représentant notre flux de travail. Lors de réunions quotidiennes de moins de dix minutes, nous faisons avancer les tâches, représentées par de petits post-it répartis le long des cases du kanban.
Cela nous permet de ressentir quotidiennement l'avancement de l'équipe et de l'afficher en toute transparence.

Un autre tableau est dédié aux améliorations potentielles. Chaque idée de remaniement de code, de test ou d’automatisation de procédure manuelle est résumée sur un post-it dédié collé sur le tableau. Les idées applicables peuvent être élues pour traverser le kanban du flux de travail.

Des post-it représentant les jalons du projet sont collés sur un grand calendrier affiché au mur. Ainsi, l’équipe ressent en un regard le temps qui les sépare de ces moments clés.

Au centre du bureau commun, un panier à courrier contient les numéros de [Pro]grammez ;o) En effet, nous discutons volontiers des articles qui nous touchent (intégration continue avec CruiseControl, tests de recette avec Fitnesse, développement model-driven avec génération de code contre des pratiques centrées sur le code et les tests, etc ...).

Ah, oui, nous avons un cinquième développeur dans le bureau: le poste d'intégration continue sur lequel tourne CruiseControl ;o)

Un environnement virtuel adapté au travail en équipe

Les développeurs partagent un outil de gestion de configuration, un outil de gestion des faits techniques, un Wiki pour échanger de l’information et un outil d’intégration continue qui publie la santé du logiciel et en notifie l’équipe par mail.

Bien sur, les développeurs utilisent un IDE, connecté à un compilateur natif et un compilateur croisé pour le processeur cible. Nous testons avec la suite xUnit, un outil de couverture structurelle et éventuellement Fit ou Fitnesse pour les tests de recette. Enfin, la panoplie est complétée par des outils de qualimétrie et de traçabilité des exigences.

TESTABILITY, NO-DUPPLICATION, CLARITY AND SIMPLICITY

When we take design and coding decisions, we most value

1. testability, then
2. no-dupplication, then
   
3. clarity, then
4. simplicity.

Applying these principles, we noticed we "grow" change-tolerant code cut into small uncoupled and cohesive classes.

INDICATOR-DRIVEN DEVELOPMENT

Every morning, the first developper to come in to work starts his day with a coffee. Then he checks the build which was automatically performed during the night.
From the generated build status web page, he collects the indicators measured during the night and writes them on our big indicator chart at today's date.
The big indicator chart shows the indicators measured every night by the automatic build.
At 9h15, the team gathers for the short daily stand-up meeting. Before running the work status, we comment the fresh indicators and detect those which have regressed and decide immediate corrective action.
Among the indicators, we track

• the percentage of code covered by tests to check it remains high;
• the number of functional requirements tested to measure progress and calculate our velocity,
• the number of lines of code in our components to check it doesn't grow awkwardly,
• that the requirement to test and requirement to code traceability matrices contain no errors or empty slots.

As these fresh indicators have an impact on the day's work, we can assert that our developpment is also indicator-driven.

ITERATION RETROSPECTIVE

Since two iterations, the team now performs iteration retrospectives.
At the end of each iteration, the team has a short and focused meeting to reflect on the past sprint (like a Scrum sprint retrospective).
The objective is to consign and track actions to establish a lightweight continuous improvement process.
The retrospectives are consigned in the minutes of meetings page of our wiki.

PROJECT LOGBOOK

The important events of the project and the decisions with their justifications are logged into a logbook, last date up.

This helps to integrate new developpers into the project, to find explanations concerning old decisions and to provide proofs for audits.

The logbook is edited in a wiki page to keep it the practice lightweight, share it among the team, keep it alive and enable easy searchs.