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.

A VOS MARQUES, PRETS, PARTEZ!

Nous démarrons une itération (nous ne les comptons plus!). Nous avons 2 types d'activités à réaliser en 16 jours, donc 2 value-stream-maps différents, donc 2 Kanbans différents (à gauche). Les tâches priorisées et estimées sont sur les colonnes de départ (TODO). Les jetons de ressources sont regroupés au milieu (en jaune). Nos 5 indicateurs de performance vierges sont affichés (à droite). Le standard décrivant l'utilisation du Kanban et des indicateurs de performance est également affiché (à l'extrême droite).
C'est parti!

ETRE BON

A l'occasion du précédent billet, j'ai evoqué que mener son équipe impliquait (entre autres) de mettre les équipiers en difficulté pour qu'ils se développent.

Deux soirées passées avec mon coach officieux m'ont permis de travailler cet aspect du leadership.

Il est intéressant de demander à l'équipe ce que "être bon" signifie dans le cadre de leur activité: "Pour vous, qu'est ce que cela signifie d'être bon?" (petite mise en difficulté :o)

• La première étape de cette réflexion amène à se rappeler de la raison d'être de l'équipe. Quelle est sa mission, quels sont ses objectifs? En quoi est-ce que l'équipe contribue à l'organisation? A cette étape, nous connaissons le but à atteindre.
• Ensuite, il s'agit d'identifier les critères de réussite de l'équipe. Quels faits, quelles métriques, quels indicateurs permettent objectivement d'affirmer que les objectifs sont tenus? A cette étape, nous savons identifier si nous avons atteint le but.
• Puis, il s'agit d'identifier où nous en sommes dans la poursuite des objectifs. Pour cela, il faut mesurer les résultats actuels et les comparer aux résultats cibles. A cette étape, nous savons identifier où nous en sommes par rapport au but.
• Enfin, il "reste" à mesurer l'historique des résultats pour révéler la performance et la comparer à la performance cible. Cette étape permet à l'équipe de mesurer l'effet de l'amélioration continue de ses pratiques. A ce stade, nous savons estimer le moment où nous atteindrons le but.
• A la question "qu'est ce cela signifie d'être bon?", on peut répondre objectivement en connaissance de cause, en s'appuyant sur des faits collectés par la démarche ci-dessus. C'est pour cela que les résultats de la démarche ci-dessus sont visuels, affichés, à jour et commentés. Ainsi, à l'aide d'un affichage visuel, on peut synthétiquement désigner et chiffrer l'objectif, montrer le résultat actuel, la tendance, l'estimation d'atteinte de l'objectif et présenter les actions en cours pour améliorer la performance.

Si l'équipe est en mesure de répondre ainsi à la question "qu'est ce cela signifie d'être bon?", c'est qu'elle pilote son activité. Cela révèle aussi qu'il faut la remettre en difficulté pour qu'elle se développe encore! En attendant, il reste du travail: la mise en pratique n'est pas encore au point :o)

MENER SON EQUIPE

Après plus de 5 ans de pratique des démarches agiles et lean, ma pratique du rôle de scrummaster a largement évoluée pour s'éloigner de sa définition initiale.

A une phase tournante de mon engagement sur mon projet actuel, j'en profite pour faire un point sur le rôle initial de scrummaster et ce qu'il est devenu après plus d'une vingtaine d'itérations mensuelles. Cette évolution me semble si significative que le rôle strict de scrummaster me parait désormais sous-optimal.

SCRUMMASTER

Selon les fondateurs de Scrum, le scrummaster se doit de

• retirer les obstacles qui gênent l'équipe dans sa poursuite des objectifs d'itération;
• agir comme un tampon entre l'équipe et les influences perturbatrices;
• se mobiliser pour que la démarche Scrum soit mise en pratique conformément à sa définition;
• garder l'équipe concentrée sur les objectifs d'itération et les tâches en cours;

GESTIONNAIRE

Le rôle de scrummaster est bien loin du gestionnaire d'équipe (alias manager) qui pratique souvent un pilotage solitaire et analytique sur la base de métriques et d'indicateurs. Le manager gère des ressources sans forcement avoir recours à la pratique du leadership.

MENEUR

Le rôle de scrummaster s'apparente d'avantage à celui du meneur d'équipe (alias leader) même s'il n'en prend pas toute la force. En effet, le scrummaster est souvent présenté comme un facilitateur ou un animateur recherchant à tout prix le consensus au sein du projet. Ce rôle mou et peu engagé à mon avis n'est pas encore celui du meneur d'équipe.

Le meneur d'équipe mène son équipe (pléonasme).

S'ENGAGER

Mener son équipe c'est s'engager avec elle dans la poursuite de ses objectifs. Que cela soit bien clair: le leader échoue si l'équipe échoue. Le leader est bien dans la même barque que ses équipiers. Le leader doit donc contribuer à la poursuite des objectifs de son équipe. Il doit mettre ses compétences et son action au service de la réussite des équipiers.

Quelles sont ces compétences et cette action?

MONTRER L'EXEMPLE

Le meneur d'équipe doit montrer l'exemple. Il ne s'agit pas de dire ce qu'il faut faire, mais de montrer ce qu'il faut faire. Pour cela, il faut faire! On y revient encore: le leader est dans l'action. Il doit pratiquer pour montrer la voie à suivre. (Que penser du scrummaster facilitateur et non développeur?)

PRATIQUER

Un leader ne peut exiger de ses équipiers un comportement que lui-même n'a pas. Si le leader exige de ses équipiers que leur code soit testé, sans duplication, explicite et le plus court possible, alors lui-même se doit d'écrire du code testé, sans duplication, explicite et le plus court possible (j'en imagine certains qui sourient et d'autres qui grincent des dents). C'est à ce prix que le leader sera légitime et que ses équipiers accepteront de mettre en pratique les standards.

Ainsi, mener l'équipe c'est ouvrir la voie pour que l'équipe la prenne à sa suite.

ENSEIGNER

Il ne suffit pas au leader de pratiquer pour montrer la voie, puis d'exiger de ses équipiers qu'ils suivent cette voie. Le leader doit absolument enseigner le métier. Il doit enseigner

• la pratique en expliquant comment nous travaillons dans l'équipe (quels sont les standards?).
• la philosophie en expliquant pourquoi nous travaillons de cette manière dans l'équipe. L'enseignement de la philosophie est primordial car nous pratiquons de manière d'autant plus efficace que nous comprenons pourquoi nous pratiquons ainsi. L'objectif est de faire adhérer aux pratiques. Aussi (et surtout!), comprendre pourquoi est un pré-requis pour améliorer les pratiques.

Le pair-programming est une manière très pertinente d'organiser l'enseignement. Dans un tel cadre, le leader doit binômer et il doit s'assurer que les anciens binôment.

Petit rappel pour le plaisir: Pour enseigner il faut pratiquer.

FAIRE REUSSIR

L'objectif du meneur est de faire réussir ses équipiers. Une manière d'y parvenir est de mener les équipiers à l'autonomie, de les pousser à se perfectionner et à donner du sens à leur travail.

MENER A L'AUTONOMIE

L'autonomie a un impact positif sur la motivation, l'efficacité et l'engagement. Le leader se doit de pousser les équipiers à devenir autonomes.

Par exemple, il s'agit de ne pas de donner la solution à un problème posé, mais de mettre sur la voie, d'accorder du temps pour traiter le problème, puis de s'assurer que le problème est en cours de résolution.

Le meneur d'équipe doit pousser ses équipiers à le remplacer. Ainsi, les plus anciens participent à former les plus jeunes; chacun pilote un chantier de résolution de problème (et donc d'amélioration!); les daily-stand-up-meetings, planifications et rétrospectives peuvent être préparés et animés de manière tournante, etc.

Il est important d'organiser le travail pour que les équipiers puissent décider par eux-même de leurs activités. Les backlogs (priorisés par définition!), les faits techniques priorisés, les kanbans et taskboards, les standards et modes opératoires, les indicateurs visuels de pilotage, les andons sont des outils d'aide à la décision dont la bonne utilisation engendre l'autonomie.

En matière d'autonomie, les objectifs du leader peuvent être les suivants:

• s'il s'absente, l'équipe assure l'intérim;
• s'il quitte l'équipe, un équipier peut prendre son rôle;
• les équipiers identifient les tâches à mener;
• un équipier motivé peut mener une autre équipe.

CONDUIRE LE PERFECTIONNEMENT

Le leader doit pousser ses équipiers à se perfectionner. Des équipiers performants résolvent les problèmes et établissent des standards efficaces qui permettent de bien développer de bons produits. Le perfectionnement est également une grande source de motivation personnelle.

La mise en situation, le pair-programming et la résolution de problèmes sont des outils efficaces pour aider les équipiers à se perfectionner. Le leader peut utiliser ces moyens pour entretenir un rythme de perfectionnement.

DONNER DU SENS

Le leader doit expliquer aux équipiers quels sont les bénéfices pour l'entreprise, pour les clients, pour leurs collègues et pour eux-mêmes de leur travail et de leur manière de travailler. La conscience des bénéfices de son travail impact positivement la motivation et l'engagement.

CONDUIRE LA RESOLUTION DES PROBLEMES

Le scrummaster doit retirer les obstacles qui gênent l'équipe dans la poursuite de ses objectifs. En résolvant lui-même ces problèmes, le scrummaster ne mène pas ses équipiers à l'autonomie et il ne conduit pas leur perfectionnement. Lui seul développera ses compétences.

C'est pourquoi le meneur d'équipe doit conduire la résolution des problèmes. Il s'agit

• d'enseigner une démarche structurée de résolution de problème;
• d'expliquer en quoi cette pratique développe les compétences des équipiers;
• d'expliquer en quoi cette pratique améliore la performance de l'entreprise; puis
• d'allouer les chantiers dans l'équipe (ou de s'assurer que les équipiers s'allouent des problèmes à résoudre); et
• d'animer ou suivre l'avancement des chantiers de résolution de problèmes.

Pour montrer l'exemple et pour développer ses propres compétences, le leader se doit de mener lui-même des chantiers de résolution de problèmes.

La pratique en continue de la résolution de problèmes est un outil très performant pour développer les compétences. En effet, elle exige des équipiers qu'ils comprennent en profondeur les problèmes (avec symptômes, impacts et causes racines) et qu'ils identifient et mettent en place des contremesures efficaces.

AMELIORER LES PRATIQUES

La pratique en continue de la résolution de problème est également un outil très performant pour améliorer les pratiques (ou standards) de l'entreprise. En effet, ces chantiers font évoluer les standards pour intégrer les contremesures identifées.

Donc, là encore, le leader doit conduire la résolution de problèmes. Il doit tout particulièrement s'assurer que les équipiers enrichissent les standards avec les enseignements de leur chantiers.

RECHERCHER LE CONSENSUS

Bien sur, le meneur d'équipe doit en priorité rechercher le consensus au sein de l'équipe. L'adhésion aux décisions sera d'autant plus aisée.

Par contre, par moment, le consensus ne sera pas obtenu et c'est normal. Si je finançais mon projet avec mon argent propre, je ne laisserai pas les experts et les anciens ramer pour obtenir un consensus alors que leur expérience leur révèle la solution. Le prix d'un expert et d'un ancien est le prix de son expérience. Il se doit d'utiliser son expérience pour empêcher les plus novices de commettre les mêmes erreurs. Certes, nous apprenons par nos erreurs, mais si nous pouvions éviter d'en faire trop, ce serait tout même préférable pour le projet. Dans un tel cas de figure, une solution issue de l'expérience et imposée sans consensus doit être expliquée afin de rechercher au mieux l'adhésion des équipiers.

ET RECURSIVEMENT

Tout ce qui a été dit pour le meneur d'équipe me semble également valable pour le meneur de l'équipe des meneurs d'équipes. Et ainsi de suite ...

A méditer!

RÉSOUDRE LES PROBLÈMES UN A UN POUR AMÉLIORER LES PRATIQUES

Lorsque nous abordions le Lean pour le mettre en pratique sur nos projets de développement, nous l'abordions selon les axes suivants:

• la définition de la valeur,
• la cartographie du flux de valeur,
• le flux continu,
• le flux tiré et
• le perfectionnement.

Cette approche, très centrée sur le process, nous a amené à reprendre des outils issus du Lean qui ont été efficaces chez d'autres et à les mettre en oeuvre chez nous: value stream mapping, kanban, just in time, autonomation, jidoka, andon, etc ...

Cette démarche s'est greffée sur notre déjà longue pratique du développement logiciel agile, centrée sur l'eXtreme-Programming (d'abord!) et Scrum (pour la forme). Naturellement, le terrain de rencontre de ces deux démarches a été le Lean Software Development.

Nous sommes fiers d'avoir obtenus de très bons résultats sur de gros projets, dans des domaines à priori peu réceptifs à ces pratiques et d'avoir été félicités par nos clients pour la tenue des jalons, la qualité des produits et notre transparence.

Pourtant nous traînons encore des problèmes de longue date (en terme d'années!) qui nous ralentissent, réduisent notre performance et attaquent notre moral.

Comment cela est-il possible alors que nous pratiquons un développement logiciel agile et Lean qui a lentement évolué pour s'adapter à notre domaine? Sommes-nous réellement sur la bonne voie?

Des aides extérieures et des recherches nous ont permis de prendre conscience que nous pratiquions un Lean scolaire. Cette pratique consiste à enrichir notre démarche issue de l'eXtreme-Programming et de Scrum avec des outils du Lean qui ont fait leurs preuves, sans pour autant assimiler le coeur du Lean.

Depuis, nous essayons d'aborder le Lean de la manière suivante:

• visualiser le production pour révéler les problèmes,
• réagir immédiatement,
• puis résoudre les problèmes un à un
• pour améliorer les pratiques.

Nos précédentes initiatives nous ont déjà conduit à "visualiser la production pour révéler les problèmes et réagir immédiatement". Nous continuons à peaufiner cette pratique. Par contre, nous essayons désormais de sérieusement nous attaquer au pan du Lean que nous avons trop négligé, c'est à dire résoudre les problèmes un à un pour améliorer les pratiques.

Attention, il ne s'agit pas là de la rétrospective d'itération ou de la collecte des obstacles par le ScrumMaster lors des réunions quotidiennes dans l'objectif d'aplanir la route devant l'équipe!

Il s'agit d'une discipline de tous les jours, pour tous, à tous les niveaux, qui consiste à avoir toujours un problème à résoudre. Ce problème doit être analysé, décortiqué et compris pour être éventuellement résolu si le retour sur investissement le justifie.

Pour les problèmes coriaces, la démarche est structurée. Par exemple pour nous, cela consiste à suivre les étapes suivantes:

• décrire le problème tel qu'on le perçoit;
• identifier et quantifier les impacts du problème pour notre client et pour notre organisation;
• décrire comment les choses devraient se dérouler, puis décrire comment elles se déroulent réellement. Décrire l'écart entre les deux.
• identifier les causes racines du problème et pondérer leur impact sur le problème;
• pour chaque cause racine, identifier des solutions candidates qui l'élimineraient;
• classifier les solutions candidates en fonction de leur coût de mise en oeuvre et de leur impact sur la résolution du problème;
• mettre en oeuvre les solutions par retour sur investissement décroissant jusqu'à ce que le retour sur investissement n'en vaille plus la peine;
• si elles ont été efficaces, standardiser les nouvelles pratiques mise en oeuvre;
• communiquer les leçons.

Cette discipline individuelle et d'équipe nous aide en ce moment à résoudre (entre autres) un problème que nous traînons depuis un an. Pour la première fois depuis longtemps, nous constatons une réelle amélioration du phénomène et ce pour un très faible investissement. Ceci nous ouvre de belles perspectives d'amélioration!

Le plus motivant à mon avis est que cette discipline est une école d'experts. En effet, puisqu'elle exige de passer par une profonde et complète compréhension des problèmes, elle pousse les acteurs de la démarche à développer leur expertise. Même si la résolution du problème n'est pas déclenchée par manque de retour sur investissement, les acteurs sauront ne pas commettre la même erreur à la prochaine occasion. Puisque tous sont concernés par cette discipline, tous sont amenés à développer leurs compétences.

Finalement, il se s'agit pas plus d'appliquer "un bon processus qui fait un bon produit" mais plutôt "d'appliquer une démarche qui développe des experts qui sauront mettre au point un bon processus qui fait un bon produit" (vous me suivez toujours?). L'effet premier recherché est l'implication et le développement des compétences. L'effet secondaire est l'amélioration des pratiques.

Avec cette nouvelle perspective, nous essayons de passer d'une démarche d'amélioration discontinue faite d'initiatives personnelles basées sur des intuitions à une démarche collective d'amélioration continue rigoureuse et disciplinée.

Cette discipline clarifie également le rôle des "leaders". Pour eux, il s'agit d'enseigner la démarche à leur équipe et à "challenger" leurs équipiers pour qu'ils analysent et résolvent leurs problèmes. Le "leader" est lui-même "challengé" par son leader/coach/manager/mentor, et ainsi de suite ...

Un prochain billet sera d'ailleurs consacré au rôle de leader, tel que décrit par Scrum, par l'eXtreme-Programming, par le Lean et tel que nous le pratiquons.

Merci encore pour l'aide extérieure!

VISUALISER LA PRODUCTION POUR REVELER LES PROBLEMES

UN RAPPEL A L'ORDRE

Il y a quelques semaines, notre équipe projet a eu la chance de recevoir la visite d'un coach Lean, pionner de l'eXtreme Programming en France. Nous avons eu la chance de travailler ensemble une journée sur nos pratiques de développement.
J'ai attaqué la journée plein d'enthousiasme et je l'ai terminé avec le moral dans les chaussettes. J'avais honte des problèmes qu'il nous a fait voir ... Ceci dit, il était bénéfique de prendre conscience de nos obstacles et d'être remis sur la bonne voie. En tout cas, je n'oublierai pas le rappel à l'ordre suivant:
Le Lean, c'est

• visualiser la production pour révéler les problèmes;
• réagir immédiatement;
• puis résoudre les problèmes un à un;
• pour améliorer les pratiques.

Ce billet est consacré au premier point:

VISUALISER LA PRODUCTION POUR RÉVÉLER LES PROBLÈMES

Prendre conscience d'un problème est la première étape de sa résolution. Voir un problème est une manière efficace d'en prendre conscience. L'afficher pour que tous le voient est une manière de s'engager dans sa résolution. Reste à organiser la production pour que les problèmes se voient.

C'est ici que les choses se compliquent pour le développement logiciel. En effet, il s'agit d'un métier dont la production ne se voit pas de manière évidente. C'est aussi ce qui rend le défi plus amusant en nous obligeant à devenir créatifs.

Voici quelques exemples de pratiques déployées par notre équipe pour visualiser la production pour révéler les problèmes.

PROBLÈME: RETARDS

L'équipe affiche ses burndown chart. Cela lui permet de voir une mesure de sa production. Si la courbe tracée est au dessus de la droite descendante à 45°, cela révèle un problème: la production est en retard par rapport à la planification.













PROBLÈME: PRODUIT NON OPÉRATIONNEL

L'équipe a connecté un iBuddy au poste d'intégration continue. Dès que l'outil d'intégration continue détecte une modification dans le dépôt de code et lance un build, l'iBuddy agite les ailes et sa tête change plusieurs fois de couleur. Cette chorégraphie, répétée plusieurs fois par jour, permet de visualiser le flux continu des contributions dans le dépôt de code. Tant que le build est réussi, la tête de l'iBuddy reste verte. Sa tête devient rouge pour révéler un problème: le build est en échec et donc le produit n'est plus opérationnel!










PROBLÈME: STOCKS, GOULETS D'ÉTRANGEMENT ET REWORK

L'équipe pilote la production en utilisant des Kanbans. Cela lui permet de voir la production en cours. Les kanbans révèlent plusieurs problèmes: la discontinuité du flux avec l'apparition de stocks et de goulets d'étranglement et le rework avec les produits défectueux collectés dans le bac rouge.












PROBLÈME: FLUX DISCONTINU

L'équipe utilise un sémaphore d'intégration pour mener l'intégration continue du produit. Chaque fois qu'un développeur se synchronise et délivre ses modifications dans le dépôt de code, il place un unique marqueur (une peluche, alias Guizmo) sur son écran. Cela permet de voir le flux continu de production qui enrichit le produit. Cette pratique révèle également deux problèmes: un sémaphore qui ne circule pas dans l'équipe signale un flux discontinu et un sémaphore bloqué sur un poste révèle une intégration douloureuse.















PROBLÈME: NON QUALITÉ

Quotidiennement, l'équipe affiche la quantité de non-qualité automatiquement détectée dans le produit. Cela permet de visualiser l'évolution de la qualité de la production. Cela permet aussi de révéler lorsque le produit n'a plus la qualité attendue.















Ces quelques exemples de pratiques permettant de visualiser la production pour révéler les problèmes. Elles sont adaptées à la nature particulière de notre projet et de notre équipe: logiciel critique et grosse équipe auto-organisée. L'étape d'après est de réagir immédiatement lorsqu'un problème est révélé. Cela sera l'objet d'un billet à venir.
A bientôt!

5EME SEMINAIRE LEAN & SI

En collaboration avec Fujitsu et l’Institut Lean France, Télécom ParisTech organise la cinquième séance du séminaire « Lean et Système d'information ». Ce séminaire aura lieu le Jeudi 10 Juin 2010 de 9h00 à 12h30 (café accueil à partir de 8h30) à Télécom ParisTech (46 rue Barrault, Paris 13e).
Les interventions prévues pour ce jour sont:

• « Mise en oeuvre des démarches agiles et Lean pour la construction des systèmes critiques », Emmanuel Chenu, Thales
• « Lean et IT: des logiciels au service du client », Régis Médina, Operae Partners
• « Retour d'expérience sur une démarche de formation itérative selon les principes du TWI », Marie-Noelle Ninteya et Elodie Aidan, Nokia Siemens Network.

Chaque exposé sera suivi d'un débat avec l’assistance.

Pour plus de détails, consultez le programme.

RYTHME (IN)SOUTENABLE

Sur son blog, sur les mailing list XP France et FrenchSUG, David Brocard a relancé la discussion sur la mise en pratique du principe agile du rythme soutenable.

LE RYTHME SOUTENABLE

"Les processus agiles promeuvent un rythme de développement soutenable. Commanditaires, développeurs et utilisateurs devraient pouvoir maintenir un rythme constant indéfiniment." (Agile Manifesto)

Ce principe est très louable:

• Il privilégie les objectifs à long terme sur les objectifs à court terme.
• Il assure un flux continu et constant de création de valeur qui maintient la qualité du produit, assure l'avancement et améliore la prédictibilité du développement.
• Il instaure un rythme permettant de mettre en place la résolution systématique des problèmes et l'amélioration continue.
• Il rappelle que le développement est réalisé par des hommes et qu'il faut respecter leur rythme de travail - dans leur intérêt, dans celui du projet et des clients.
• Il permet d'enchainer les projets, les uns après les autres, car les développeurs restent disponibles (en bon état ...).

LE PROBLÈME

• En revenant sur plusieurs années de projet, est-ce que le rythme soutenable a été appliqué?
• Est-il compatible de la mise en pratique des autres principes du Manifeste Agile?
• A t-on au moins gagné un rythme plus soutenable qu'auparavant, lorsque nous utilisions des méthodes plus théoriques et (faussement) prédictives?
• Après 150 jours ouverts de développement sur un même projet, j'avais écrit que nous étions passé de l'itération au sprint sur notre projet en perdant le rythme soutenable (voir billet). Qu'en est-il après 350 jours ouvrables de développement sur ce même projet?

LE PLUS DUR EST A VENIR

Avant l'adoption de démarches de type agile, le rythme sur les projets était soutenable le long du V descendant. Pour tenir un jalon intermédiaire (spécification, conception, codage) il suffisait presque de décréter que l'activité était terminée. Concrètement, il était impossible de prouver objectivement le contraire puisque qu'aucune preuve n'était pertinente. Aussi, on savait sans trop oser le dire que le travail serait repris et terminé lors des phases remontantes du V.

Puis, le rythme devenait bien plus désagréable lors de la remontée du V. L'intégration du code tournait au vrai cauchemar et les heures s'accumulaient pour mettre au point (et réécrire) ce logiciel. Cette phase était le point culminant de la fatigue et du stress sur le projet. Le plus pénible était que la durée de cette phase était imprévisible ...

Tout cela pour dire qu'avant l'introduction des méthodes de type agile, le rythme des projets était déjà insoutenable, mais essentiellement sur la branche remontante du V.

C'EST DUR TOUT LE TEMPS

Avec la pratique du cycle de vie itératif et incrémental court, le stress et les heures de travail n'ont pas disparu. Ils ont été lissé assez uniformément le long du développement (il reste des pics lors des itérations qui précèdent une livraison formelle). Aussi, le stress et le surcroit de travail apparaissent très tôt dans le développement.

Ce changement est dû à la nature même du cycle itératif et incrémental qui installe un rythme court pendant lequel toutes les activités du développement sont menées, levant les problèmes tôt et souvent.

Avec les revues d'itérations et les démonstrations d'incrément, le stress de la livraison devient périodique. La mise à disposition très tôt et en continu de la vélocité (et d'autres indicateurs) peut conduire à une course à la productivité, entretenue par les attentes toujours plus ambitieuses des managers.

Ainsi, les méthodes agiles ne semblent pas générer un rythme plus soutenable ou plus insoutenable. Par contre, elles lissent tôt et tout au long du projet le stress qui culminait auparavant vers la fin (théorique) du développement.

Notez que la technique du Heijunka dans la Lean recherche spécifiquement ce lissage de la charge de travail et du stress.

SANS PIC NI RELÂCHE

Certes, avec une approche de type agile, il n'y a plus de gros pic de travail et de stress. Par contre, il n'y a plus non plus de relâche. Avec les démarches plus théoriques, les pauses n'existaient pas formellement, mais il était possible de calmer le rythme lors de la descente du V. Par contre, avec un daily-stand-up-meeting, avec le burndown chart actualisé quotidiennement, avec un build publié et avec des tests de recette automatisés mesurant l'avancement, il devient très difficile de calmer le rythme sans que cela soit perceptible. Et cela s'enchaine itération après itération. Nous en sommes à 18 itérations de 20 jours ouvrés sur le même projet - et cela use!

Pour calmer le jeu, nous avons essayé de prendre une journée sans incrément fonctionnel entre la revue d'itération et la planification de la suivante. D'une part, cela passait mal auprès du management, d'autre part cela ne rattrapait absolument pas un sprint de 20 jours ouvrés précédant un autre sprint de 20 jours.

LA COURSE A LA VÉLOCITÉ

Pour maintenir un rythme soutenable, il faut de viser une vélocité moins élevée en planification d'itération. Cela semble évident. C'est sûrement applicable dans le meilleur des mondes, dans les entreprises éclairées, chez Google et chez les Bisounours. Malheureusement, cela n'est pas envisageable avec des managers qui pensent que les développeurs consomment le temps qu'il leur est alloué (loi de Parkinson). Ce modèle de management reste appliqué. Par extension, il s'agit de fixer des objectifs intenables pour être "sur" que les développeurs se donnent à fond. Changer ce schéma de pensée peut être une révolution culturelle pour certaines organisations.

STRESSANTE TRANSPARENCE

Au rythme s'ajoute le stress de la transparence. Il faut du courage pour afficher sa courbe de productivité et sa courbe de non-qualité. Il faut du courage pour mettre une lumière qui devient rouge lorsque le build est cassé. Il faut du courage pour montrer ses problèmes. Donner des indicateurs, cela peut aussi être donner le bâton pour se faire battre. Être transparent, c'est aussi accueillir la critique: "Quand on a perdu ses clefs la nuit, on les cherche sous le lampadaire" (François Brun).

NOUVEAUX SYMPTÔMES

Avec la pratique des démarches de type agile, nous constatons que les équipes deviennent plus soudées. Avec le stress, elles développent un riche folklore d'équipe. Par exemple, notre équipe passionnerait un sociologue tellement elle a développé des pratiques telles que "le Gizmo", "le Perfect", "le saut de la troisième corde", "le J'off" et bien d'autres encore.

Ce riche folklore d'équipe est bien moins séduisant si on l'interprète comme étant des mécanismes collectifs de protection contre la souffrance au travail. Malheureusement, c'est un fonctionnement très classique étudié par la psychodynamique du travail. Avec les équipes soudées, nous sommes passé de mécanismes individuels de protection à des mécanismes collectifs.

Le fait qu'une équipe soit soudée et développe un riche folklore peut être un signe d'une souffrance au travail ressentie par les équipiers. Cela peut être un symptôme du rythme insoutenable. Le pire est quand ces symptômes sont mal interprétés et qu'ils sont reprochés à l'équipe comme étant de mauvais comportements. Cela revient a réprimer le symptôme du malêtre.

QUEL QUE SOIT LA MÉTHODE

Quel que soit la méthode, le travail en mode projet est éprouvant. Tant qu'il y aura des jalons, ils seront ambitieux (pour des raisons économiques) et il sera éprouvant de les tenir. Ceci n'est pas propre au développement logiciel. Chez les créatifs, les publicitaires, les journalistes, les écrivains et les architectes cela s'appelle les périodes de charrette (période intense de travail pour terminer à temps une commande, une tâche sous contrat).

NÉANMOINS

Les démarches de type agile ont la particularité de lisser cette charge de travail dans la durée et de monter très tôt le rythme. Ce rythme est sans pic ni relâche. A cela s'ajoute le stress de la transparence. Clairement, il faut du courage pour pratiquer une démarche du type agile.

La variable d'ajustement reste le curseur de la vélocité. Après, cela se joue à la culture d'entreprise et au style de management. Le rythme insoutenable n'est pas dans le patrimoine génétique des méthodes agiles mais dans l'utilisation que les commanditaires, les développeurs et les utilisateurs peuvent (très facilement) en faire.
Ces démarches sont diablement efficaces et motivantes mais elles ne peuvent bien sur pas tout résoudre.

RESOUDRE LES PROBLEMES

C'est bien bien sympa de voir les problèmes. Ceci dit, l'objectif reste de les résoudre!

Alors, ces problèmes identifiés et exposés à la vue de tous, sont-ils traités?

1. PETIT RAPPEL

Rappelez-vous: l'équipe prend conscience que pour apprendre, progresser et gagner en efficacité, elle doit résoudre systématiquement les problèmes qu'elle rencontre.
Alors,

• on développe la détection systématique des problèmes;
• on affiche les problèmes pour les rendre visibles;
• on résout les problèmes de manière structurée.

Cette attitude et cette démarche sont décrit dans un précédant billet.

2. EST-CE PRATIQUÉ?

Afin de s'assurer que ces beaux principes sont devenus des pratiques, nous affichons un indicateur révélant le nombre de problèmes résolus (le bas des barres) et le nombre de problèmes non-résolus (le haut des barres). Cet indicateur est actualisé à chaque itération (voir photo ci-dessus).

3. EST-CE EFFICACE?

C'est bien joli de mettre en place de nouvelles pratiques - encore faut-il qu'il y ait un retour sur investissement ... Et là, il faut reconnaître qu'il est difficile de mesurer l'impact de la résolution systématique des problèmes.

Difficile n'est pas impossible: les burndown-chart et la courbe de non-qualité révèlent les gains en productivité et en qualité de cette démarche.
Notamment, la courbe de non-qualité révèle de sévères réductions de la non-qualité correspondant à des chantiers mis en place suite à un problème levé. Ensuite, les paliers qui suivent une chute de cette courbe montrent que l'action corrective "coup de poing" s'est efficacement transformée en pratique continue.
Puisque le burndown-chart ne souffre pas d'une augmentation ou d'une stagnation du "restant à faire", c'est que la résolution du problème a contribué positivement au développement.

4. EFFET SECONDAIRE

Nous avons remarqué un autre effet secondaire bénéfique de cette démarche. Il s'agit d'une très forte augmentation de la standardisation.
En effet, la résolution d'un problème résulte généralement en:

• une contre mesure automatisée (scriptée dans le build, dans le commit, ...);
• une contre mesure manuelle décrite par une petite procédure textuelle;
• l'amélioration d'une procédure existante.

Ainsi, nous avons constaté que notre wiki s'est enrichi de beaucoup de petites procédures pragmatiques. Il s'agit de l'officialisation des meilleures manières de faire à ce moment pour ce projet. Cela constitue un standard léger et évolutif, partagé par les équipiers.

Je pensais que la standardisation étaient une démarche formelle, lourde et ralentissant l'évolution. Je suis désormais convaincu du contraire.