Chokoban: Kanban & Chocobon

Voici le Chokoban: le Kanban de l'avent où un ticket passé à "done" donne droit à un Kinder Chocobon.

Ce n'est pas du pilotage à la carotte, mais une régression bénigne (c'est à dire qui ne fait pas échouer de test).

Enjoy :o)

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!