Agile : des standards pour changer et s’améliorer !
Posté par jc-Qualitystreet le 28 septembre 2009
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 !
