Agilité et standards : certains n’y croient toujours pas … et pourtant…
Travailler dans une équipe Agile, c’est accepter de travailler avec les standards. Des standards non pas pour contraindre, mais pour challenger, changer et s ‘améliorer. Des standards non pas centralisés, mais construits, partagés, intégrés par les équipes.
Les enjeux sont énormes car la standardisation est un vrai facilitateur de travail source de productivité, de qualité, de confort et de satisfaction. Les standards réduisent la complexité. Ils sont aussi et surtout la première brique de toute démarche d’amélioration continue … De l’humain, pas du documentaire !
Bon je le répète une dernière fois : « TRAVAILLER AVEC » et ne pas subir !
Le poids de la culture d’entreprise est important sur cette question, et selon les organisations c’est toute la philosophie autour de ceux -ci qui est à revoir, tant au niveau de la définition des standards que de leur exploitation.
Le taylorisme a laissé des traces… la conception des standards est bien souvent laissé à des experts loin, bien loin des préoccupations et des réalités du terrain des projets. De l’autre côté, on peste, on râle, on se soumet, parfois on ne cherche même pas à challenger, et on bride tout son potentiel créatif …
Ce qui plait dans les projets agiles, c’est que l’équipe se met autour de la table est discute ensemble avec ou sans le soutien du coach, de ces bonnes pratiques, de ces standards…
Le sprint 0 est bien souvent le moment idéal pour les initier ! Chaque fin de sprint est quant à elle, le moment idéal pour les challenger et les améliorer !
J’ai tendance à dire que le premier de ces standards est le process de développement lui même.
Scrum par exemple est un excellent cadre de travail pour les projets IT. Le process Scrum, c’est cette difficile balance entre les règles que l’on peut doit respecter et l’adaptation au contexte. Beaucoup d’éléments relèvent du Shu (« Suivre les règles ») ; j’aide donc l’équipe à s’approprier ces règles de base. Dans cette posture, et en toute transparence, je facilite l’adaptation au contexte avec le ScrumMaster, l’équipe, le Product Owner, et différentes parties-prenantes.
Toutefois, le message est clair :
- Ne considérer jamais ces standards comme acquis
- Envisager ces standards comme soutien de votre activité
- Faites évoluer ces standards dés que vous en éprouvez le besoin avec comme objectif de les améliorer, pour vous améliorer
Une règle d’or :
INFOMER, IMPLIQUER puis FORMER sans contraindre, quel que soit le standard !
Ensemble, on doit construire notre process Scrum standard, notre façon de bosser ensemble. Ensemble, on doit définir ce que revêt le FINI (c’est le fameux : « definition of done » !), la clés de voute du sprint et de la collaboration Product Owner / Développeurs / Testeurs. Ensemble avec le concours d’un ergonome ou spécialiste de l’expérience utilisateur, on définit progressivement les standards d’interface ou on s’appuie sur les standards d’accessibilité…
Pour certains (praticiens eXtreme Progeramming), la question des standards fait partie des habitudes. Une pratique forte existe, celle des normes de codage. Il s’agit de standards de développement que l’équipe doit fixer pour le projet,. C’est aussi un préalable à d’autre pratiques XP : la propriété collective du code et le pair programming. Le travail en équipe n’est en effet possible qu’à condition d’utiliser des règles communes de conception technique et de développement.
Sur quoi s’appuyer pour construire ses standards ?
En premier lieu sur l’équipe et sa connaissance du contexte de travail, mais aussi sur toute communauté qui se met en place pour travailler telle ou telle question. Check-lists, revues de code sont précieux. On peut s’appuyer également aussi sur un coach maitrisant l’agilité et capable de bien analyser la situation de travail, le projet et le contexte organisationnel.
La rétrospective de fin de sprint est décisive. C’est un moment fort, très concret. La pensée Lean est enfin une vraie source d’inspiration. Son influence est sur ce sujet très forte :
- Les standards appartiennent à l’Histoire du TPS (Toyoya Production Ssytem) depuis 50 ans; Taiichi Ohno son inventeur, y était très attaché
- «Standardiser les tâches et processus»est l’un des 14 principes du Lean Management (base de l’amélioration continue et de la respnsabilisation des employés …
- Des outils du TPS très connus, comme les 5S poussent dans ce sens. L’un des 5 S est «Seiketsu qui signifie Standardiser.
Bref, ne craignez pas les Standards, servez-vous en et faites les évoluer !
J’abonde dans le même sens. Le standard est plus généralement le langage de réalités commune qui permet d’être agile. Un puzzle, un jeu de Lego permettent de construire plus facilement un certain nombre d’objets qu’une matière hétérogène. Le standard fini aussi toujours par devenir une limite à la créativité. Dans certains cas, il faut savoir faire évoluer le langage. Notre langue n’est pas la même qu’il y a deux siècles. Dans un monde qui évolue vite, il faut une gouvernance aux standards.
Trés juste et trés bien dit !
Le standard doit toujours rester en construction et être challengé en permanence.
Bonjour,
Je ne connais pas Agile mais en lisant ce post je m’aperçois que cela est bien proche du CMMI dans certains domaines.
Personnellement je considère que la qualité doit être un support, une aide, un service et pas une contrainte. La qualité, au sens large, ne doit pas être subie. Tous ceux qui considèrent l’approche TOP DOWN au lieu de BOTTOM UP pour la qualité sont, à mon sens, dans l’erreur.
Les standards, normes, procédures doivent prendre en compte le quotidien des équipes. Il faut en ressortir les bonnes pratiques – qui pourront être encore améliorées par la suite (via un PDCA) – pour construire ces documents.
Un des principes du CMM/CMMI qui m’a beaucoup plus c’est qu’il est possible (même recommandé) de s’écarter de ce qui a été défini (norme, standard, recommandation) – quel que soit le niveau de maturité – du moment où cela est justifié (contrainte client, technique par exemples) et tracé dans un document (en général le Plan Projet). Au sens ISO, c’est une dérogation mais c’est bien plus « lourd » à obtenir.
Une importance capitale – à mon sens – doit être donnée au bilan de projet (ou de version majeure) car c’est au travers de celui-ci que l’on pourra vérifier si les normes, standards, recommandations à appliquer peuvent être améliorés ou, pourquoi pas, complètement retravaillés.
> INFOMER, IMPLIQUER puis FORMER sans contraindre, quel que soit le standard !
J’adhère à 100%. Il est nécessaire d’avoir une bonne communication autour de ces documents. Pour donner un exemple : nous avons un référentiel méthodologique;
– tout nouvel entrant suit une présentation de ce référentiel (présentation adaptée à la fonction : développeur, CP, DP).
– toute modification *majeure* d’un standard de ce référentiel entrainera une présentation aux responsables (CP, DP, Lead technique) pour communication aux équipes.
– les évolutions mineures sont présentées au travers d’un wiki (qui contient également les modifications majeures)
Si sur la base des indicateurs projets, on s’aperçoit qu’il y a un défaut majeur de tests unitaires (cause d’origine d’anomalie en production) alors une session spéciale « Tests Unitaire » est construite et présentée à l’ensemble des collaborateurs. L’analyse des indicateurs montrera si cette présentation de sensibilisation a été bénéfique ou pas.
Une implication forte des responsables qualités dans la gestion de ce référentiel, dans la communication, dans l’aide aux équipes, dans le retour d’expérience des équipes, … est nécessaire pour faire adhérer les collaborateurs et les valoriser. Quoi de plus valorisant que de voir sa proposition de méthode, outil ou que sais-je encore, devenir une préconisation pour l’ensemble des équipes ?
A mon grand regret, on trouve encore trop de managers qui considèrent la qualité comme une contrainte ou qui ont une approche TOP-DOWN…
Cdt