Daily flash-meetings

Daily flash-meetings have enabled us to build performing software development teams, to reduce work-in-progress and to improve product quality. Understand how with the following Plan-Do-Check-Act case study.
A problem is the starting point: our former project weekly meetings were inefficient. This problem will be described in terms of symptoms and impacts. The root causes will be identified and the plan to solve the problem will be established. Then, the experiments performed according to this plan will be described. Lastly, the results of these experiments will be measured and the lessons learnt will be provided. 
Flash meetings are also known as daily stand-up meetings in Agile literature, and daily scrums in the particular case of Scrum.

PLAN

We have been unsatisfied with our former project weekly-meetings. 

Duration

With a target duration of an hour, our weekly meetings seemed too long. Many developers just did not like to spend an hour seated in a meeting room. Some felt uncomfortable pausing their development activities during a full hour. Moreover, after some time, long meetings tend to lose dynamism and efficiency. Within a one hour time-box, people do not always manage to stay focused on the highest priority topics. Stakeholders working on their laptop or texting messages during the meeting are a symptom of such loss of focus. Therefore, such meetings ended up by turning into a waste of time and lacked respect for the team's time.

Delay

The meetings could be frustrating. Indeed, problems raised by team members during the meetings (such as desynchronized activities, process, technical or organizational issues) were dealt with too late, on a weekly basis at best. The information reported and monitored was already out-of-date, possibly a week old. The impact of daily work on our goals was not obvious, or was visible too late to enable us to drive our activities and aim for the expected performance. It was like steering a project which a one week delay, or like driving a car with your eyes open an hour per week.

Implication

On the long-term, some team members considered the meeting a waste of time and did not attend systematically. Some attended, but avoided to participate in fear of prolongating the meeting. Individually, the stakeholders reported their status, but the meeting was not a session of teamwork. Team members could feel a loss of interest and of implication in their project. This was mostly the case for long projects (over 3 years). Moreover, projects teams were not performing as expected. 

Root causes

The main root cause of this problem is an issue of frequency and duration. The periodicity of the meeting was low enough to create an accumulation of information and of problems to deal with. The periodicity was low enough to imply out-of-date data and missed synchronization points. In other terms, the frequency of the meeting (1 week) was much lower than the frequency of the problems to solve and of the decisions to take (typically 1 day). Therefore it was impossible to steer the activities with satisfying reactivity. 

In more Lean terms, our organization was building a week-worth stockpile of information every week, and was processing this stockpile only once a week. Unfortunately, some information (such as problems) within the one-week stockpile needed to be processed on a mush shorter notice. 

Moreover, within the one hour target duration, part of the allocated meeting time was wasted on lower priority topics.

DO

To assess the root cause, we have decided to dramatically raise the periodicity and reduce the duration of the meetings. Since 7 years we have been running short daily flash-meetings. Two of our development teams are currently running the following standard:

Current standard

Step #1: Kick-off

The team meets for 15 minutes in the project war-room every day at the same hour. The team members rotate to lead the meeting according to a calendar displayed in the war-room. The daily leader calls the meeting and  makes sure all stakeholders are present. All team members stand in a semi-circle, facing the project charts and task-board. Only the daily leader is seated, however also facing the charts. He edits the iteration backlog spreadsheet on a computer. It contains the prioritized list of development tasks for the current iteration, with status, costs and estimates. Only he sees the screen and the iteration backlog during the meeting.

Step #2: Nightly build

Firstly, the daily leader reports the status of the nightly build. He organizes corrective actions if the build has failed and is not yet corrected. A build failure is considered a problem. Thanks to a long-term problem-solving, the nightly build is now successful over 70% of the time. Among other tasks, the nightly build 

• builds the executable files,

• runs the white-box unit-tests,

• runs the black-box acceptance tests, 

• measures the product quality, 

• ships the product and

• controls the build andon (a green/red light and a bell, green for success and red for failure).

Step #3: Product quality

Then, the team reports the product quality metrics while updating the quality graphs and trends. The team dispatches further analysis and corrective actions if product quality has decreased. A decrease in product quality is considered a problem. 

In fact, the team does not measure product quality, but product non-quality instead. The product non-quality is the sum of

• the number of lines of code not fully covered by tests: instruction and modified condition/decision coverage rates (expected 0), 

• the number of warnings in the code & tests the tests (expected 0), 

• the number of times the coding standards are not fulfilled (expected 0),

• the number of traceability errors (expected 0),

• the number complex operations (expected 0 operation with a cyclomatic number over 6),

• the number of 'todo' & 'fixme' tags in the code & tests (expected 0),

• the number of tickets to estimate (expected 0),

• the number of opened tickets (expected 0).

All of these values are automatically measured by the nightly build. The value the sum makes no sense. However, a negative trend means that the product quality is improving. On the other hand, a positive trend reveals a quality decrease, and therefore a problem to solve.

The number of defects identified by the customer per thousand source lines of code on our incremental deliveries is monitored. However, this metric is too low and stable (below 0.1 per KSLOC) to enable to steer activities.

Step #4: Development tasks

Then, reading the iteration backlog spreadsheet, the daily leader runs through the development tasks by order of priority. By task priority, the developers report their status to the team in terms of time spent, progress, re-estimation of remaining work and problems encountered. They visually update their work-in-progress on the project task-board while reporting their tasks by mowing their task-cards to the appropriate steps of the value-stream-map. The daily leader updates the task status, costs and estimates in the iteration backlog spreadsheet while the team members report their activities. The problems raised are displayed and assessed for immediate action or further analysis.

Once of all of the tasks in-progress have been scanned, the available team members pull new tasks from the iteration backlog by order of priority.

If developers report complex problems or technical issues, the daily leader invites the stakeholders to resume the topic after the daily flash meeting.

Step #5: Team performance

Once all the tasks have been scanned and updated, the daily leader reports the team performance to the team. This performance is measured according to the data provided by the team members and updated by the daily leader in the iteration backlog spreadsheet. The team performance is expressed in terms of costs, progress and product quality. The team members update the metrics on their performance graphs. 

Step #6: Decisions

Lastly the team analyzes the graphs, ends the meeting and shares on the day's challenge over coffee before resuming the development tasks according to their decisions.

Duration

If the team repeatedly doesn't manage to run its flash meetings within a 15 to 20 minutes timebox, then the team measures, displays and monitors the duration of the meeting day after day. The team finds solutions to shorten the meeting and checks that their corrective actions are effective. If the root cause of lengthy meetings is an oversized team, then the team splits into smaller teams. The team is split exactly as code is modularized: according to loose coupling and high coherence. Then each team runs 15-minute daily flash meetings, one after the other. To deal with inter-team dependencies, a team member participates to the flash meetings of the other teams of the same project. Then, a team lead updates and displays the consolidated performance of the teams.

This standard is our current best way of running flash-meetings. We are confident in the fact that the teams will continue to improve it.

CHECK

We have noted and measured the following results:

Frequency

We run flash-meetings every working day since 7 years (which represents over 2500 meetings). Five of our project teams have practiced or are still practicing daily flash-meetings. The context ranges from a typical 7-member to one 50-member cross-functional project team. For this large project, the team was split into 4 cross-functional teams, each running its own daily flash-meeting.

Duration

With 15 to 20 minutes per daily flash-meeting, the overall time spent in status meetings stands somewhere between 1h15 and 1h40 per week. Therefore, compared to our former weekly meeting situation, the overall time spent in status meetings has not been reduced. 

Focus

With a target duration of 15 minutes, the team members remove all unnecessary information from the meeting. By reducing the duration of the meeting, they focus on what is most important. The focus is set on steering, performance and problems. Because the team members stand up during the meeting and because the meeting remains short, laptops and cellphones are naturally excluded from the meeting.

Visible team performance

Progress, costs and product quality graphs are displayed and are up-to-date. Problems are displayed and corrective actions or further analysis are in progress. The team members share a common vision of the development tasks to perform and of their priority. They share a vision of their performance in terms of costs, progress and product quality. 

The work-in-progress is visualized on the task-board, revealing flow, problems, dependencies and bottlenecks. Software development is now visible and displayed in total transparency.

Work-in-progress and product quality

The amount of work-in-progress has been reduced to 2 scales: the day and the iteration (a timebox of 10 work-days). Product quality has been raised, as each iteration visibly improves the quality of the product.

Implication

The team members attend and actively participate every day. The meeting leader rotates every day among the team members. All the team members get to act as the daily leader.

The meeting is a session of intense and focused teamwork. The team members are very concerned by the project costs and milestones and by the product quality. This is obvious because the performance graphs are up-to-date and commented. We notice that this rigor remains for long projects (over 4 years). 

Continuous improvement

The meetings have a standard that is displayed in the war-room. It has changed several times: it is improved and adapted to the problems the team is currently facing.

ACT

We have learned many things by practicing daily flash-meetings.

The war-room

A dedicated war-room is very useful when several teams share a common workspace. Because all the team members get to talk during the meeting, the level of noise can be quite disturbing for neighbors. Visual management is used to display the performance graphs, the task-board and the problem-board. These information radiators are made of paper and magnetic boards, all updated by hand during the meeting.

The schedule

The meeting must not occur too soon in the morning as team members need to gather information for the meeting (such as the status of the nightly build and quality metrics computed by the build). Also, they need to investigate any build or product quality issues. However, the meeting must be scheduled early enough to plan the day. Our meetings are typically scheduled to start between 9AM and 10AM.

Because the meeting takes place at the same time every day, the schedule should be booked for all the team members on their calendar to avoid conflicts with other meetings on the same slot.

Computers and screens

Only the team leader must use a computer during the meeting (in order to update the costs and progress of the tasks). The team must focus on the large visual task-board and on reporting and sharing information. Running the meeting in front of a large screen has been a failure, as team members focus on updating the iteration backlog spreadsheet instead of focusing on updating the status of their activities. This is why only the daily team leader sees the iteration backlog file.

PDCA

We have learned that a daily flash-meeting defines the conditions of success for the day. This is the first step to success! Then, team members take action to meet success. Indeed, each day can be seen as a short Plan-Do-Check-Act cycle. The team starts the day by defining the today's challenge. Then, the team members plan the activities of the day in order to finish the agreed-upon tasks (Plan). The action resumes after the meeting (Do). Tomorrow, the team will check their performance (Check) in order to adjust their behavior to succeed tomorrow's challenge (Act). 

Work-in-progress

Combined with the nightly build, the daily flash-meeting enforces a daily cycle within which tasks are done. This greatly helps to reduce work-in-progress. It also helps to steer the project, as daily tasks enable to visualize daily progress.

Product quality

A problem that is not visible does not exist. Thanks to the product quality graph (updated on a daily basis and displayed with the other performance charts) any decrease in product quality becomes a visible problem and a visible challenge for the team. The impact of corrective actions led to raise product quality will be visible the following day. Thanks to this visible impact of a day of work on product quality, the team visibly improves the product quality, day after day.

Visible impact and motivation

With visible daily feedback on performance, the team visualizes the impact of their day of work on their common goals. Therefore, the team sees that they can make a difference, and that they have results. We believe that this is a great motivator and enhances autonomy.

Project steering

The daily flash meeting can been seen as a daily short session of project steering. After such practice, we now believe that a single iteration burndown chart is not sufficient to steer the activities of the iteration during the meeting. A single iteration burndown chart (as practiced in Scrum) mainly focuses the team on completion of work within the milestone. Little focus is set on costs and product quality. Also, a single burndown chart enables to visualize that the team has a problem: for example that progress is slower than expected. However, it does not help the team to visualize why it has a problem. 

This is why we have standardized the use of several performance charts during flash-meetings. We use one product quality chart, several progress charts and several cost charts. 

The progress charts are burndowns which focus on the completion of work within the milestone. We have a global "progress burndown" for the full iteration scope, and one per goal of the iteration. 

The cost charts are burndowns which focus on the completion of work within the allocated budget. We have a global "cost burndown" for the full iteration scope, and one per goal of the iteration. 

This set of charts reveals which task is setting (or risks to set) the iteration into trouble. For such a task, the charts reveal if the issue concerns progress and/or costs. By visualizing all this information, the team takes decisions and steers its activities. In fact, the project war-room is more of a project cockpit.

Learning

The practice of flash-meetings enables the team members to develop skills. They learn to lead the meeting by following and improving the meeting standard. They learn to organize self-directed work with pull systems such as prioritized tasks lists (the iteration backlog) and task-boards in order to gain autonomy. They learn to identify and solve problems by defining their standards, by visualizing work-in-progress and by practicing problem-solving. By measuring and analyzing performance on a daily basis, the team members learn to take action based on facts and charts. They also share knowledge at least once per day. The team learns teamwork. This organization of learning aims for what Daniel Jones calls "the capability of the team to sustain and improve once you leave".

Continuous improvement

We have learned that rotating among team members to lead the flash meeting is a great way to involve everyone in the continuous improvement of the meeting. The improvement of the daily flash meeting is a great case-study for learning and practicing continuous improvement. Indeed, it is a short activity performed every day according to a standard. This know-how may then be reused for other activities. Indeed, as Daniel Jones says: "The lasting value is the capability to solve the next set of problems".

Discipline

The practice of daily flash-meetings implies a lot of discipline. The meeting must occur to establish the development tasks to perform that day. The meeting must start and finish on time, as several similar meetings follow each other in sequence. Each developer must focus on reporting only relevant information as all developers must manage to report their status and steer their activities within a 15 to 20 minute time-box. Typically, technical issues and complex problems must be set aside to be dealt with after the meeting among the relevant stakeholders.

Respect

Finally, the daily flash-meetings are a framework within which the team members share goals, responsibility and success; and develop skills and autonomy. This defines an environment of respect for people, their work and their time.

Customer satisfaction

Daily flash-meetings enable to develop teams, who improve their way of working day after day, to build higher quality products on-time for their customers.

THE PRICK, LE SCRUMMASTER ET LE COACH (V3)

Dans une de ses conférences, Ken Schwaber dit avec humour que le ScrumMaster d'un projet est aussi appelé le "prick". Il hérite de ce surnom peu envieux car il est la personne la moins aimée du projet. Il est mal aimé car il harcèle l'équipe pour maintenir la discipline et la qualité. Il ne lâche pas car il est le garant de l'application du processus et de la qualité du produit.

PUSH / PULL

Pour ne pas tomber dans ce travers dans notre organisation, le ScrumMaster est aussi un développeur de l'équipe. Il devient légitime car il applique ce qu'il demande des autres. Il montre le chemin en étant exemplaire dans son respect des pratiques. Il ne cherche pas à pousser les équipiers vers un niveau mais plutôt à les tirer vers le niveau qu'il s'efforce d'atteindre et de conserver. Concrètement, il est plus facile de faire adhérer à la pratique du test-first lorsqu'on l'applique soi-même et qu'on binôme pour l'enseigner.

MANAGEMENT / LEADERSHIP

Nous rejoignons la nuance qu'il existe entre manager et leader. Un ScrumMaster développeur ne fait pas que proposer ("y a qu'à, faut qu'on") . Il entraine les autres par son exemple en montrant une voie. Attention, il ne dicte pas la voie. L'équipe choisit les pratiques. Mais pour exiger légitimement des autres qu'ils appliquent leurs pratiques encore faut-il commencer par les appliquer soi-même.

SCRUMMASTER / COACH

Du coup, le ScrumMaster développeur ressemble beaucoup au Coach XP. Il est un praticien expérimenté qui enseigne par l'exemple.

UN JOB A TEMPS PLEIN?

Sur nos projets, nous constatons d'ailleurs que les activités du ScrumMaster pour une équipe atteignant 9 développeurs ne constituent pas un plein temps. Au delà de 9 personnes, l'équipe se scinde en sous-équipes donc le problème ne se pose pas. Alors, que peut faire le ScrumMaster le reste du temps? Le ScrumMaster peut-il s'investir sur d'autres équipes? Afin d'être légitimement accepté par l'équipe, nous choisissons de ne pas diviser la disponibilité d'un ScrumMaster entre plusieurs équipes. La deuxième partie de son temps est accordée au développement. ScrumMaster développeur est un job à temps plein.

SCRUMMASTER(S)

Dans notre organisation, nous avons une autre particularité. Nous avons plusieurs ScrumMaster développeurs dans l'équipe. Ils ne se marchent pas sur les pieds. Aux contraire, ils se relayent. Ainsi, il y a toujours un garant de la discipline des pratiques et de la qualité, malgré les congés et les moments de fatigue. Il suffit de passer le relai. C'est aussi une manière d'investir sur les équipiers en formant des ScrumMasters praticiens au sein de l'organisation.

SCRUM MOU / SCRUM + XP

Scrum doit se pratiquer avec de solides pratiques techniques. Chaque sprint doit fournir un incrément de produit potentiellement livrable, donc testé et documenté. Avoir un ScrumMaster développeur sur un projet est aussi un moyen de s'assurer que les pratiques techniques ne seront pas délaissées à la faveur des pratiques d'organisation.

A LA MANIÈRE DE TOYOTA

Cette conception du leadership rejoint les principes du Toyota Way:

Principe 9: "Grow leaders who thoroughly understand the work, live the philosophy, and teach it to others."
Les leaders, scrummasters ou coachs (choisissez votre terme préféré) viennent de l'équipe et font partie de l'équipe. Ils font le même travail que les équipiers et sont sur place pour les former.

Principe 12: "Go and see for yourself to thoroughly understand the situation".
Les leaders, scrummasters ou coachs (choisissez votre terme préféré) font partie de l'équipe. Ils comprennent la situation puisqu'ils sont en situation sur le terrain.

EN CONCLUSION

Si vous n'êtes pas le client ou son représentant et que vous contribuez au développement d'un logiciel, alors développez!

NIKO-NIKO

C'est un article qui nous a donné l'idée de mettre en place un calendrier Niko-Niko.

LA PRATIQUE

Chaque soir en quittant le travail, les membres de l'équipe collent une pastille de couleur sur le calendrier dans la case du jour révolu.

Une pastille verte indique que le développeur a passé une bonne journée sur le projet.
Une pastille jaune représente une journée neutre.
Une pastille rouge marque une mauvaise journée.

Une tendance de pastilles jaunes et rouges signale que l'équipe doit se réorganiser pour redistribuer les tâches ou repenser sa manière de travailler. Cette pratique permet également de suivre un indicateur sur le « sustainable pace ». Elle permet enfin à l'équipe de fusionner en la rendant maître de sa propre gestion.

LES ENSEIGNEMENTS

Pour le moment, nous ne savons pas encore ce qu'il faut concrètement retirer de cette pratique en cours d'expérimentation. En tout cas, elle permet de vérifier la corrélation entre la santé de l'équipe, la santé du projet et la qualité du logiciel. Ceci confirme l'exactitude de l'équation "Equipe = Produit". Enfin, le Niko-Niko permet aussi à chacun de s'exprimer sur la manière dont il vit le projet, sans avoir à attendre la rétrospective d'itération mensuelle.

VERS UNE AUTRE PRATIQUE

Lors de la 2ème réunion du CARA à Valence, j'ai fait une présentation à base de photos sur les pratiques de notre équipe. Les discussions autour du Niko-Niko m'ont permis de revoir cette pratique sous un nouvel angle.

Plutôt que de signaler le ressenti de la journée, les pastilles pourraient indiquer l'efficacité de la journée.
Une pastille verte indiquerait une journée très efficace.
Une pastille jaune représenterait une journée de production conforme.
Une pastille rouge marquerait une journée gaspillée.
Une succession de pastilles rouges avertirait qu'une action corrective doit être menée pour revenir à un travail efficace. Il faut alors rechercher la cause racine de cette perte de productivité. Une telle tendance ne se détecte pas forcément par une remontée de la pente du burndown chart de l'itération. En effet, le burndown chart mesure la vélocité globale de l'équipe. Cette moyenne peut masquer l'enlisement de certains équipiers. Les difficultés des uns peuvent être compensées par la performance des autres. Certes, un développeur en difficulté signalera sa perte de productivité lors du stand-up-meeting quotidien. Son alerte risque de passer pour une anecdote sans conséquence durable alors que l'historique du Niko-Niko révélera un enlisement dans la durée.

CONCLUSION

Nous pourrons discuter de l'intérêt de cette pratique alternative du Niko-Niko lors de notre prochaine rétrospective d'itération. Enfin, ces réflexions me démontrent l'utilité de présenter son travail. Cette autre pratique du Niko-Niko résulte des échanges menés lors d'une réunion du CARA. Merci aux participants pour ce nouvel éclairage!

OU SONT LES GOF?

J'ai noté une mutation dans mon entourage. Peut-être l'avez-vous également remarqué autour de vous.

Il y a quelques années, nous avions tous un exemplaire du GoF sur notre bureau. L'ouvrage Design Patterns de Gamma, Heml, Johnson et Vlissides (le Gang of Four) était Le Livre. Pour nous, ce catalogue était La Référence des programmeurs compétents. Il trônait fièrement sur nos bureaux et nos architectures étaient enrichies de ses enseignements.

Puis, il nous a fallu plusieurs années pour graduellement et efficacement mettre en pratique l'Extreme-Programming. Curieux constat, aujourd'hui le GoF ne trône plus sur aucun de nos bureaux. Le mien est à la maison.

Comment expliquer cette lente mutation? Voici quelques causes possibles:

1. Nous ne concevons plus, nous codons comme des coyotes (alternative sauvage du cowboy-coding);


2. Nous maitrisons les Design Pattern et les mettons en musique de manière intuitive et inconsciente (rien que cela);


3. Nous concevons autrement, piloté par les tests;


4. Nous connaissons suffisamment les design-pattern et nous les faisons émerger avec parcimonie à mesure de la conception pilotée par les tests (fromage et dessert).

Alors, est-ce un abandon, une digestion, une révolution ou une mutation?

Sur plusieurs projets d'affilée, j'ai remarqué que je me fais moins de nœuds au cerveau concernant l'architecture. Avant, nous réfléchissions pas mal avant de nous mettre sérieusement au code. Nous dessinions de nombreux modèles au tableau et nous potassions le GoF à la recherche d'élégantes solutions.

Désormais, nous sommes plus directs. Nous cherchons la solution la plus simple à tester tout en respectant le principe de séparation commande/requête. Les associations, abstractions, héritages et implémentations viennent naturellement sur des critères de testabilité. Une fois que les tests passent, nous remanions notre travail pour réduire le volume de code, notamment en chassant les duplications. Au passage, nous nous assurons que l'organisation des classes respecte les principes de l'Oncle Bob. Et le plus incroyable est qu'au fur et à mesure des projets, il est de plus en plus aisé d'ajouter des fonctionnalités par incrément. Je trouve même que nos architectures sont élégantes. Elles ont l'élégance de la simplicité. Au passage, nous constatons que nos critères d'une bonne architecture sont par ordre de priorité: testabilité, simplicité, pas de dupplication, clarté.

Je ne pense pas pour autant que nous négligeons les patterns du GoF. Après en avoir abusé, nous les appliquons avec plus de parcimonie. En effet, dans nos architectures nous retrouvons toujours une séparation claire des responsabilités de fabrication des instances, d'utilisation des instances, de séquencement des instances et de gestion des états. Par contre, les Singleton sont toujours une vraie plaie pour les tests.

Ainsi, nous n'avons pas brulé nos GoF. Nous avons pris le temps d'en assimiler les enseignements et de les appliquer sans en abuser. Mais, je reconnais que pour nous, le GoF n'est plus La Référence. Nous n'en conseillons plus la lecture aux nouveaux arrivants. Ainsi, nous nous reposons peut-être trop sur l'expérience de ceux qui l'ont lu et l'ont trop pratiqué pour enfin apprendre à bien le pratiquer.

Et vous, il est où votre GoF?

AGILITE ET CRITIQUES COURANTES - V3

Concernant les démarches agiles de développement logiciel, j'entends souvent les critiques suivantes:

1. Ces démarches manquent de rigueur et de discipline.
2. Ces démarches abolissent la conception.
3. Ces démarches n'offrent pas de vision à long terme du déroulement du projet.
4. Ces démarches engendrent une reprise perpétuelle du travail fini.
5. Ces démarches ne permettent pas de s'engager sur un contour fonctionnel fixe.
6. Ces démarches ne sont pas adaptées aux produits critiques.
7. Ces démarches échouent comme les autres.
8. Ces démarches sont peu adaptées pour le développement géographiquement distribué.
9. Ces démarches sont peu adaptées aux grosses équipes.
10. Ces démarches sont adaptées pour des développeurs compétents et motivés.
11. Ces démarches risquent d'élaborer des architectures non-évolutives.
12. Ces démarches vivent sur l'utopie du consensus dans l'équipe.

A l'occasion de cours, de rencontres, de conférences, de présentations et du travail au quotidien, je suis souvent confronté à ces critiques et je suis amené à argumenter à leur encontre.
Cet article est une tentative de mettre par écrit ces argumentaires afin de les réutiliser plus aisément. Les publier permettra peut-être de les enrichir sur la base de l'expérience d'autres praticiens.
L'article est disponible ici.

La 2ème édition de cette note répond à la critique numéro 11.
La 3ème édition reformule l'argumentaire de la critique 5.

FRAGILITÉ

On nous demande fréquemment quelles sont les limites à la pratique efficace d'une démarche agile. En dehors du périmètre de l'équipe de développement, qu'est-ce qui peut nuire à la productivité de l'équipe? Au-delà de la contraposé de chaque valeur, principe et pratique agile, voici quelques contextes de développement inadéquats.

LA MULTIPLICATION DES FRONTIÈRES ET DES CONTRATS

La multiplication des relations contractuelles et des frontières au sein d'un projet (entre équipes, entre métiers, entre lieux géographiques, entre bureaux, entre langues, entre l'organisation et ses sous-traitants) entraine un effort d'organisation. Cet effort peut-être vu comme un gaspillage (au sens du Lean) puisqu'il n'apporte aucune valeur au client.

LE MANQUE DE CONFIANCE ACCORDE AUX ÉQUIPES

Si l'organisation n'accorde pas sa confiance aux équipes de développement, elle gaspillera de l'énergie à planifier en détail les travaux (qui ne se dérouleront pas conformément aux détails), à formaliser et standardiser en détail les procédures (que les développeurs souhaiteront adapter à plusieurs reprises) et à contrôler les activités (au lieu de supprimer les obstacles). Aussi, elle démotivera les équipes et freinera la prise d'initiative et de décision.
Cet état d'esprit, qui consiste à vouloir séparer penser et faire, se concrétise souvent par des procédures très détaillées, des outils complexes et une planification microscopique et à long-terme.

LE MANQUE DE MATURITÉ DE L'ORGANISATION

L'organisation doit faire preuve de maturité et de sang-froid pour accepter et traiter les problèmes qui seront identifiés tôt par la pratique des démarches agiles. Une organisation immature sera tentée d'agir sur la démarche qui a révélé les problèmes et non sur la cause racine des problèmes.

LE GIGANTISME ORGANISATIONNEL

L'équipe doit croître de manière itérative et incrémentale pour éviter de démarrer le projet avec de trop nombreuses ressources ou d'ajouter des ressources à un moment où le projet prend du retard. Conduire un grand projet avec de nombreux développeurs n'est pas une fatalité. Cette vision des grands projets est souvent liée à la planification par homme/mois. La synchronisation de nombreux intervenants est un effort. Cet effort peut être vu comme un gaspillage (au sens du Lean) puisqu'il n'apporte aucune valeur au client.

UN LANGAGE DE PROGRAMMATION INADAPTÉ

L'utilisation d'un langage de programmation orienté-objet est un atout pour construire une application de manière incrémentale et pour rendre le logiciel testable. Faire l'impasse sur la programmation orientée-objet rend les applications plus laborieuses à tester et à construire par incréments.

ET LA LISTE N'EST PAS FINIE ...

Tous ces contextes réduiront les bénéfices d'une démarche de développement agile. D'ailleurs ces freins à l'efficacité ralentissent tous types de projets, agiles ou non. Malheureusement, il ne s'agit sûrement pas d'une liste exhaustive.

PRATIQUES D'EQUIPE - 6EME EDITION

Et voici la 6ème édition de l'article sur les pratiques de notre équipe. Il y a quelques nouveautés dues au fait que trois équipes développent désormais en parallèle sur le même projet.
Consultez la 6ème édition de l'article ici.

Je prévois de proposer une conférence sur le thème de l'article aux prochains évènements (XP Days?, Agile Tour?) pour varier avec ma précédante présentation ("Agilité et avionique").

MODEL-DRIVEN ET AGILITE (MDE2)

Suite à mon précédant billet en réaction à un article sur la démarche de développement piloté par les modèles, je souhaite revenir sur la cohabitation de l'agilité et du MDE. Le développement piloté par les modèles et les démarches agiles sont-ils compatibles? Peut-on envisager un MDE agile? Pourquoi ai-je été si déçu par mon expérience du MDE et si motivé par ma pratique du développement agile?

DÉVELOPPEMENT PILOTE PAR LES MODÈLES

Entendons-nous, par MDE, je parle d'une démarche de développement où les modèles UML sont les principaux artefacts élaborés et maintenus par les développeurs. Par exemple, le code est généré par transformations de modèles.

MDE ET MANIFESTE AGILE

Pour sonder une éventuelle compatibilité, on peut commencer par se demander si le MDE est compatible des valeurs du Manifeste Agile.

Il me semble que le pilotage par les modèles met fortement l'accent sur les outils. L'éditeur UML, les transformations de modèles et les générateurs de code sont autant d'outils sur le chemin critique du développement. Ces outils particuliers viennent s'ajouter aux incontournables outils tels que le gestionnaire de versions, le compilateur, le framework de test, l'IDE, etc. D'ailleurs, on constate que cette démarche est essentiellement poussée par des vendeurs d'outils. Aussi, le MDE est souvent cité dans le cadre des fameuses "usines logicielles" avec leurs processus fortement automatisés. Tout ceci semble aller à l'encontre de la première valeur du manifeste: "Individuals and interactions over processes and tools".

Les modèles sont-ils assimilables à un logiciel opérationnel ou à une documentation exhaustive? Par transformations de modèles, on peut générer à la fois une documentation et un logiciel exécutable. Mais, est-ce que ce logiciel exécutable est pour autant un logiciel opérationnel? Le fait qu'une application apporte une valeur opérationnelle est lié au fait qu'il réponde correctement aux besoins des utilisateurs. Cette satisfaction passe souvent par la sanction de tests. Pourtant, il me semble que le test est peu traité par le MDE. Ainsi, je serais tenté d'émettre des réserves sur le fait que le MDE privilégie "Working software over comprehensive documentation".

Enfin, rien dans une démarche pilotée par les modèles ne me semble aller à l'encontre des deux dernières valeurs du manifeste, à savoir "Customer collaboration over contract negotiation" et "Responding to change over following a plan". De même, les douze principes du Manifeste Agile semblent pouvoir s'appliquer dans le cadre d'un tel développement.

MDE ET SCRUM

Dans la répartition des rôles, dans le cérémonial et dans la démarche de Scrum, je ne vois rien qui soit incompatible avec un développement piloté par les modèles. Scrum porte sur le pilotage du projet alors que le MDE adresse essentiellement les activités techniques. Il me semble qu'il doit être possible de conduire un développement piloté par les modèles avec une démarche Scrum, pour peu qu'on s'assure de livrer un produit opérationnel potentiellement livrable à la fin de chaque itération et pas seulement des modèles.

MDE ET EXTREME-PROGRAMMING

La confrontation du MDE et de XP me semble plus pertinente car les deux démarches adressent les aspects techniques du développement.

XP insiste sur le fait que le code et les tests sont idéalement les seuls artefacts à maintenir. Les autres artefacts doivent être générés à partir du code et des tests. Nous sommes à contrepied de la génération de code. Si le code est au centre du développement, c'est qu'il est primordial. C'est le code qui est transformé en logiciel exécutable ou interprété. C'est aussi le code que l'on déroule sous le débogueur pour les problèmes sérieux.

Le remaniement n'est pas pleinement efficace si le code ne peut être modifié directement, car généré. Certes, le modèle peut être remanié, mais cela ne garantit pas un code de qualité. Ne l'oublions pas, c'est le code qui est interprété ou compilé pour produire le logiciel exécutable, pas les modèles. C'est aussi le code qui est débogué. Le débogueur ne s'interface pas avec les modèles. Lorsque les choses finissent fatalement par se compliquer, il faut que les développeurs se plongent dans le code. C'est alors qu'un code remanié prend toute son importance. La suppression des duplications, la simplification du code et le gain en lisibilité résultant du remaniement facilitent l'assimilation du code par les développeurs.

Le cycle très rapide de test, codage et remaniement perd son rythme dynamique s'il faut passer par une étape supplémentaire de génération de code. Le passage très rapide des artefacts principaux au logiciel opérationnel est un fondamental d'XP. L'ajout de l'étape de génération de code va à l'encontre de ce fondamental.

L'intégration continue n'est possible que sur des artefacts pouvant être mergés. Or, comme nous l'avons vécu à nos dépens, à l'inverse du code, les modèles sont des artefacts dangereux à merger. Le développement concurrent et intégré en continue me semble impossible si les modèles sont les artefacts principaux. Ceci est très regrettable car une intégration continue efficace est un sacré atout pour réussir un projet.

Bref, il me semble impossible de conduire un développement piloté par les modèles avec une démarche XP.

MDE ET CODE

Un des avantages fréquemment cités du MDE est la possibilité de s'affranchir du code en élevant de niveau d'abstraction. Mais, il me semble qu'il ne faut pas se leurrer: pour générer du code, il faut saisir dans le modèle tout un tas d'informations non-graphiques utilisées par le générateur pour produire le code. Bref, cela revient presque à coder avec une autre notation.
Et puis, qu'on ne dise pas que les modèles affranchissent le développeur du code: le débogueur ne s'interface pas avec les modèles. Lorsque les problèmes deviennent sérieux, il faut bien en venir au code. A ce moment là, on espère avoir conservé quelques compétences en programmation.

Enfin, pour ce qui est du logiciel opérationnel, il va bien falloir en passer par les tests, même si on édite des modèles. Comment sont implémentés les tests? En code ou en modèles? Et si les tests sont modélisés, comment sont exprimées les assertions? En code.
Bref, je pense qu'il est un leurre de croire que les modèles permettent de s'affranchir du code pour développer une application. Cela est peut être vrai pour l'exemple pédagogique de la machine à café ou pour des applications simples. Le problème est qu'on ne paye pas des professionnels du développement logiciel pour construire des machines à café et des applications simples.

EN CONCLUSION

En fait, je pense qu'un développement piloté par les modèles gagne à être conduit dans une démarche agile, comme Scrum. Ainsi, le projet gagnera en transparence et du logiciel opérationnel sera régulièrement disponible.
Par contre, je ne vois pas ce qu'un projet agile gagne en utilisant les pratiques techniques pilotées par les modèles. Il me semble que centrer le développement sur le code et les tests va dans le sens de la simplification, de l'accélération du développement et de la production d'applications opérationnelles. Bien sûr, cela ne veut pas dire que l'équipe ne modélise pas. Il est très efficace de communiquer à l'aide de modèles utilisant une notation unifiée. Simplement, des marqueurs, des tableaux blancs et des appareils photos peuvent suffire (voir photo).

MODELISATION, GENERATION ET AGILITE (MDE1)

Je souhaite réagir à l'article "Productivité, agilité, industrialisation : même combat?" paru ce mois dans le numéro 113 du magazine PROgrammez. Cet article fait parti d'un dossier spécial dédié à la productivité.

L'auteur y défend l'efficacité de la démarche Model-Driven avec génération du code. Il utilise certains arguments pour lesquels j'ai d'autres points de vue.

Tout d'abord, l'auteur affirme que "[la maintenance des modèles] est moins coûteuse que celle d'un code car celui-ci est dépendant de la technologie, des évolutions des outils, etc."
L'auteur a en tête les Platform-Independant-Models qui ne dépendent pas de la plateforme technologique. Par contre, il ne faut pas se leurrer: le modèle est très dépendant de la technologie MDE, de l'outil de modélisation, des outils de transformation de modèles et de l'outil de génération de code. Ainsi, les modèles restent dépendants de la technologie et des évolutions des outils.

Ensuite, l'auteur affirme que "L'éclectisme du code résultant des cultures et sensibilités diverses et variées des programmeurs se paye aussi comptant au moment du calcul des prix de revient des applications." Par expérience, j'ai remarqué qu'il existe autant de manières de modéliser une idée que de manières de la coder. Malgré un standard commun, j'ai pu constater que plusieurs développeurs au sein d'un même projet modélisent de manières différentes. UML n'est qu'une notation. De même, plusieurs rédacteurs rédigeront une même histoire de façons multiples.

Puis, l'auteur donne un avis avec lequel je suis fortement en désaccord: "Comment faire pour qu'un programmeur maintienne sans effort conséquent le code d'un autre? Comment faire pour qu'un programmeur retouchant celui d'un autre n'introduise pas, par simple incompréhension, des bogues? Réponse : le transformer en créateur de modèles et générer le code à partir de ses modèles!" La pratique du pilotage par les tests, le remaniement en continu, la suppression systématique des duplications et l'adoption de la solution la plus simple qui soit viable sont des voies pour modifier du code à moindre effort. Surtout, le pilotage par les tests (systématiques et couvrants) offre la seule garantie concrète que l'application ne régresse pas suite à une modification de code. La génération de code à partir de modèles n'offre pas de telles garanties. Qu'est-ce qui vous garantit que les défauts n'ont pas été introduits dans le modèle? Pourquoi les diagrammes n'exprimeraient que des idées justes? Pourquoi un modèle serait-il correct à priori? Seule l'exécution du logiciel permet d'affirmer qu'il est correct. Ne croyez pas que je dévalorise les modèles. En équipe, nous modélisons tous les jours ... avec des marqueurs et sur des tableaux blancs. Et puis, si nous modélisons en mode esquisse, c'est aussi parce que nous avons échoué en approche MDE ...

Plus loin dans son article, l'auteur avance que "maintenir un logiciel c'est raisonner sur des modèles UML sans présumer d'une technologie spécifique." Pour toutes les raisons vues précédemment, je ne suis d'accord avec aucune partie de cette affirmation. Nous maintenons efficacement des logiciels sans avoir recours à des modèles électroniques. Aussi, la modélisation électronique présume de technologies spécifiques.

Enfin, un leitmotiv flotte à travers l'article. Il est dit qu'il n'est pas toujours possible de développer avec "du personnel d'excellence", des "programmeurs hors-pairs". Parfois, il faudrait se contenter de "simples développeurs". Et puis pourquoi parle t-on si souvent de programmeurs et non simplement de développeurs? La modélisation et la génération de code seraient-ils des outils permettant de tirer le niveau vers le bas? Ces pratiques permettraient-elles de ne pas développer les compétences des équipes? Clairement, il me semble que l'auteur ne fait pas confiance aux développeurs et que la programmation est considérée comme une tâche ingrate.

Mais, pourquoi le mot "agilité" est-il utilisé dans le titre?

SCRUM ET ICEBERGS

Le dernier billet de Bruno Orsier m'a beaucoup plu. Notamment, il m'a fait découvrir la passionnante vidéo d'une conférence donnée par Ken Schwaber à Google.

Parmi les sujets abordés par le co-créateur de Scrum, il y en a un qui me touche beaucoup en ce moment. Il y a peu, je l'ai abordé à l'occasion d'un billet sur les conflits qui apparaissent tôt lorsqu'on pratique une démarche agile.

Ken Schwaber affirme que la pratique de Scrum par une organisation est un test de sa capacité à accepter les problèmes qui seront soulevés souvent très tôt.

Ces problèmes sont dévoilés tôt par les démarches agiles car elles visent à livrer très tôt un produit partiel et potentiellement livrable. Livrer au plus tôt un produit oblige à exercer au plus tôt toutes les formes de collaboration, de communication et de travail d'équipe nécessaires à la création de valeur pour le client. Exercer au plus tôt toutes les activités révèle au plus tôt les obstacles à la création de valeur.

Ces problèmes ne sont pas dûs à la pratique de Scrum. Ils existaient bien avant, cachés et ignorés. Par contre, l'application de Scrum (ou d'une autre démarche agile) révèle vite la partie immergée de l'iceberg. La transparence, le retour d'information et le cycle itératif et incrémental contribuent à identifier au plus vite les obstacles.

Révéler les freins à la productivité est un test pour l'organisation. Aura t-elle la maturité et le recul pour accepter ces obstacles en son sein? N'est-il pas plus confortable à court terme de revenir à une ancienne démarche et de se rassurer en pensant que tout va bien pour le moment?

Au sein d'une même organisation, considérons deux projets. L'un travaille en cycle en V alors alors que l'autre avance en agile. Immanquablement, le deuxième projet révèlera plus tôt des difficultés. Quelle conclusion hâtive est si aisée?

Comme j'ai déjà eu l'occasion de le dire lors d'un précédant billet, nous avons déjà vécu cette situation. Sur un projet d'envergure, nous avancions en mode eXtreme-Programming au sein d'un programme plus large travaillant en cycle en V. A l'époque, on nous a reproché de révéler trop tôt et trop fréquemment des problèmes. Notre équipe dénotait car elle butait déjà sur des obstacles. Notre organisation n'avait probablement pas la capacité de reconnaitre que nous déterrions tôt certains problèmes en son sein.

De même, lorsque tôt dans le projet les mesures de vélocité montrent que le produit ne pourra être livré à la date anticipée, l'organisation sera tentée de penser que l'équipe est inefficace alors qu'elle ne fait que révéler tôt que le planning initial est intenable sans réorganisation. Alors, plusieurs choix sont possibles: refuser d'admettre les faits, trouver une organisation projet mieux adaptée, revenir à une ancienne démarche de travail ou exiger une plus grande vélocité, ce qui se fera immanquablement au détriment de la qualité et donc de la date de livraison.

Face à une telle situation, l'organisation doit décider si elle veut agir sur le problème ou sur ce qui a révélé le problème. Accepte t-elle de voir la partie immergée de l'iceberg? En effet, l'organisation passe un test de maturité.

PRATIQUES D'EQUIPE - 4EME EDITION

Voici la quatrième édition de l'article décrivant les pratiques de notre équipe de développement.

Cette édition tient compte des remarques de relecture faites par Rémy Sanlaville et par mon chef de service. La principale différence est l'ajout de d'appréciations sur la rentabilité de chaque pratique.

Vous pouvez consulter la nouvelle version de l'article là: http://manu40k.free.fr/articlePratiquesDEquipe.pdf

Attention, le document pdf est assez volumineux car il contient de nombreuses photos de l'équipe "en action".

Une cinquième édition pourra inclure les pratiques de planification d'itération et de rétrospective d'itération, ainsi que les pratiques techniques.

PROGRAMMEZ PAR CONTRAT!

Vous avez sûrement entendu qu'il est peut être efficace de favoriser la collaboration avec le client plutôt que la négociation du contrat?
Et bien, je vous assure qu'il est efficace de programmer par contrat!

Cela n'a rien avoir avec la dualité collaboration/contrat du Manifeste Agile, mais cela a peut-être suscité votre curiosité. Pour découvrir en quoi la programmation par contrat contribue à la mise en pratique des principes agiles et du Lean, lisez le court article suivant: Programmez par Contrat!

ANALOGIES ENTRE L'EQUIPE ET SON LOGICIEL (2NDE EDITION)

La récente conférence de Géry Derbier à l'Agile Tour à Valence et les conflits que nous avons vécu il y a peu sur notre projet m'ont amené à ajouter d'autres dualités dans mon article sur les analogies entre une équipe et son logiciel.
La seconde édition de l'article est consultable ici.

VERIFICATION STATIQUE ET EXTREME PROGRAMMING

Christophe Baillon de la société SOGILIS (http://sogilis.com/) m'a transféré la publication Static Verification and Extreme Programming (www.praxis-his.com/pdfs/svandxp.pdf). L'article parle notamment de l'étonnante cohabitation entre le développement de logiciels critiques et la pratique de XP.

Christophe a bien vu de me faire connaitre cette publication. En effet, cet article m'intéresse à plusieurs égards. D'abord, je développe en équipe des applications très critiques tout en appliquant une forme adaptée de l'eXtreme-Programming. Aussi, j'ai publié un article sur la criticité et XP (Agilité et Avionique) et j'ai présenté une conférence sur ce thème aux XP Days 2008 et à l'Agile Tour Grenoble 2008 (Agilité et Avionique). Enfin, lors de ma session à Grenoble, Bruno Orsier m'a interroge sur notre éventuelle utilisation des outils de vérification statique. J'aurais mieux fait de lire l'article transmis par Christophe bien avant pour mieux répondre à Bruno!

J'écris ce billet pour réagir à certaines affirmations de l'article.

Tout d'abord, l'auteur explique qu'un outil de vérification statique est en partie assimilable à un relecteur dans la pratique du pair-programming. En effet, un tel outil saura efficacement déceler certaines erreurs mieux et plus rapidement qu'un humain. Néanmoins, cette comparaison me semble se fonder sur une vision très réductrice du binômage. En effet, en plus d'une relecture en continue, la pratique du pair-programming offre un moyen efficace d'assurer la propriété collective du code et permet d'homogéneiser la conception et le code au delà des règles de nommage et de constructions élémentaires. Aussi et surtout, la conception et le code convergent vers un bon produit grâce à la confrontion de deux points de vues (et même plus, puisque le binômes permutent).

Ensuite, l'auteur montre que la vérification formelle permet de détecter des régressions introduites lors d'un remaniement. L'exemple donné est très proche d'une utilisation de la programmation par contrat, mais non compilable. Fort heureusement, depuis la sortie de l'article, AdaCore (http://www.adacore.com/home/) nous a gratifié d'un compilateur Ada2005 incluant un sous ensemble très efficace d'une véritable programmation par contrat (pré-conditions et post-conditions compilées et exercées à l'exécution). Cette nouvelle manière d'utiliser Ada n'exige même pas d'employer un sous-ensemble du langage comme la vérification statique de SPARK l'impose. Bref, la vérification formelle est sûrement un outil puissant, mais un peu moins lorsque la programmation par contrat est pratiquée.

De plus, je pense que l'auteur a tord de suggérer d'éviter de remanier pour les cas ou cela dégraderait la couverture structurelle du code par les tests. Sur nos projets nous remanions sans retenue car l'analyse de la couverture du code par les tests est automatisée dans le build complet activé par l'intégration continue. Les branches non pertinentes sont systématiquement éliminées par les développeurs ou alors les tests sont complétés. Ces pratiques permettent au code de rester malléable.

Enfin, l'auteur regrette de ne pouvoir disposer d'un client sur site. Je pense qu'il s'arrête à une vision dogmatique d'XP. Certes, l'organisation optimale prévoit un client sur site. Sur nos projets, nous n'y arrivons pas, cependant nous travaillons systématiquement avec des représentants internes du client. Il faut savoir adapter XP à son contexte sans trahir les valeurs et les principes de la démarche.

Je remercie Christophe car il m'a donné certains augments pour défendre la pratique d'XP en milieu critique. Il m'a semblé que cet article a surtout été écrit par des vendeurs d'outils qui cherchent à promouvoir leur solution dans un milieu prometteur qui n'y porte que peu d'attention. Un logiciel critique doit s'exécuter de manière sûr. je crois que je préfère porter l'effort de vérification lors de son exécution plutôt que sur une démonstration statique.

Working software is the primary measure of progress.

LE CHANGEMENT ET LES CONFLITS

IRRÉDUCTIBLES GAULOIS

Je travaille dans une grande organisation dont le modèle de fonctionnement n'est pas agile. Le modèle est assez classique des grandes structures françaises qu'elles soient industrielles, administratives, militaires, scolaires ou universitaires. Il s'agit de structures pyramidales, hiérarchisées, descendantes et élitistes. Le changement y est freiné par l'inertie des grandes organisations. On y pratique la séparation de penser et de faire, tout comme dans le paradigme de la production de masse et le cycle en vie en V. Une élite pense des procédures que les d'autres doivent appliquer pour faire.

Pourtant, il existe un appétit de changement. Différentes initiatives locales cohabitent comme la mise en place de la démarche Lean et l'adoption du développement logiciel Agile. Soutenues par la hiérarchie proche, plusieurs équipes agiles y développent des produits, tels des villages d'irréductibles gaulois.

HOUSTON, NOUS AVONS UN PROBLÈME

En ce moment, l'équipe dont je fais partie est en train de traverser une zone de turbulences. Nous sommes confrontés à des conflits à répétition avec les intervenants en périphérie de l'équipe.
Au sein même de notre équipe et avec le Product-Owner, l'ambiance est mouvementée mais dynamique, constructive et réconfortée par des résultats. Par contre, les relations se dégradent avec les acteurs qui ne sont pas directement et quotidiennement impliqués dans la construction du logiciel.

EST-CE UN CAS PARTICULIER?

Curieusement, dans les conférences auxquelles nous assistons et participons (XP Days, Agile Tour), il y a une part importante des sessions qui traitent de la gestion du conflit et de la conduite du changement. Ce que nous vivons n'est donc pas un cas isolé:

Le travail en mode agile déclenche tôt des conflits dans les organisations qui les mettent en place.

POURQUOI? A CAUSE DU CHANGEMENT!

Ces conflits naissent car les équipes auto-organisées conduisent des changements pour lesquels certaines personnes hors de l'équipe ne sont pas préparées. Les équipes agiles adaptent les standards et les meilleures pratiques du moment, elles s'organisent d'elles-même sans chef directif, elles développent des compétences nées du vrai travail d'équipe qui déstabilisent certains experts, elles sont soudées et acceptent les contraintes si elles sont comprises et non imposées par l'extérieur.

Les équipes agiles ne font pas conformément aux procédures pensées par une élite. Elle n'appliquent pas la séparation de pensée et de faire. Elles pensent ET font.

Tout changement déstabilise, mais ce changement particulier a un effet accentué dans une structure élitiste, pyramidale, hiérarchisée et descendante. Ainsi naissent les conflits entre les équipes agiles et leur entourage.

POURQUOI? PAR MALADRESSE!

Nous sommes pris par l'élan de l'équipe. Nous consacrons plus d'énergie à avancer qu'à communiquer sur notre manière de travailler. Certains se sentent exclus de cette dynamique, de cette solidarité d'équipe et ne se sentent plus respectés.
Nous sommes des techniciens passionnés, plus habiles en amélioration continue de nos pratiques de développement qu'en communication et qu'en conduite du changement.
Ainsi, il me semble qu'une organisation qui souhaite mettre en place des démarches agiles se doit d'investir dans la conduite du changement: communication, formation, sensibilisation ...

POURQUOI? PARCE QU'ON LIVRE TÔT!

Des conflits arrivent si tôt dans un projet agile qu'on entend même dire que les démarches agiles sont plus génératrices de conflits que les démarches descendantes. Est-ce vrai?

Pour analyser ce problème, faisons (encore une fois) le parallèle entre l'équipe et son produit.

Sur un projet précédant, nous avons travaillé en mode eXtreme-Programming au sein d'un programme plus large avançant en cycle en V. A l'époque, on nous a reproché de générer plus de défauts que le reste du programme. Pourquoi? Parce que nous levions les défauts plus tôt! C'est le propre des démarches agiles qui testent tôt et livrent tôt du logiciel opérationnel pour obtenir tôt des retours d'informations sur la satisfaction du client.

Pourquoi dit-on qu'une équipe agile génère plus de conflits qu'une équipe descendante? Parce qu'une équipe agile lève les conflits plus tôt!

A partir du moment où plusieurs personnes partagent un même objectif, des conflits apparaissent. Les points de vue se confrontent, tout simplement. Les conflits accompagnent les équipes.
Dans un groupe travaillant en cycle en V, il n'y a pas de vrai travail d'équipe jusqu'à la tardive phase d'intégration. D'ailleurs, l'objectif de la phase d'intégration est de réunir les travaux menés en parallèle. A partir de l'intégration, les crises apparaissent avec le travail d'équipe. Avez-vous vécu des projets en cycle en V qui ne sont pas devenus des poudrières à partir de la phase d'intégration? Et bien les projets agiles travaillent dès le début en équipe. Les conflits sont donc levés bien plus tôt.

Un conflit est à l'équipe ce qu'un défaut est au produit. Plus il est identifié tôt, plus son impact sera limité.

Pour contenir les défauts, les développeurs utilisent les tests. Si on poursuit le parallèle entre conflit et défaut, comment maitriser les conflits dans les équipes?
Les rétrospectives d'itération sont un moment où l'équipe identifie ses dysfonctionnements et se réorganise pour les corriger.

Si le conflit est à l'équipe ce que le défaut est au produit, alors la rétrospective et l'amélioration continue des pratiques est à l'équipe ce que les tests et le remaniement sont au produit.

Bref, il me semble que:

Il n'y a pas plus de défauts dans un produit développé par une équipe agile que dans un produit développé par une équipe travaillant en cycle en V. Par contre, l'équipe agile lève les défauts plus tôt.
De même, il n'y a pas plus de conflits dans une équipe agile que dans une équipe travaillant en cycle en V. Par contre, l'équipe agile lève les conflits plus tôt.