PARTIE VISIBLE ET PARTIE INVISIBLE

Dans notre organisation, nous constatons que la partie visible de nos pratiques de développement séduit les décideurs. Cette partie visible correspond aux pratiques de pilotage de projet de développement. Dans notre cas, il s'agit de la pratique de Scrum complétée par le Lean avec le Value-Stream-Mapping et les Kanbans.

LA PARTIE VISIBLE

Ces pratiques séduisent les décideurs pour plusieurs raisons.
D'abord l'équipe développe le bon produit grâce au rôle joué par le Product Owner, grâce à la construction itérative et incrémentale et en évaluant les incréments de produit lors des démonstrations d'itération.
Ensuite, l'avancement est transparent grâce à l'identification, à la priorisation et à l'estimation du restant à faire dans le Product Backlog et l'Iteration Backlog, grâce à la visualisation du restant à faire par les Burndown-Charts, grâce à la mesure de la vélocité et enfin grâce aux incréments de fonctionnalité présentés en démonstration d'itération.
La complexité est maitrisée par la construction itérative et incrémentale du produit.
L'équipe se responsabilise pour tenir l'objectif en planifiant les itérations, en pilotant quotidiennement les activités lors des Daily-Stand-Up-Meeting et en présentant leur travail lors des démonstrations d'itération.
L'équipe améliore ses pratiques en menant les rétrospectives d'itération, en portant un regard critique sur la cartographie du flux de valeur et en traitant les goulots d'étranglement révélés par les Kanbans.

Toutes ces pratiques sont pleines de bon sens. Elles ont aussi le grand avantage d'être visibles et touchent des décideurs n'ayant pas un profil technique.

LE CHAOS

Le développement logiciel est une activité assez chaotique. Or ces pratiques permettent de s'accommoder du chaos car elles se mènent en cycles très courts, permettent de collecter de l'information et apportent de la transparence.
Par contre, ces pratiques génèrent également du chaos. Il s'agit du chaos lié à l'instabilité du produit construit par incrément en cycles très courts. La construction itérative et incrémentale amène à faire évoluer la conception et à reprendre le code déjà écrit. Si cette instabilité n'est pas maitrisée, elle conduit à des régressions. Et tout s'écroule ...

LA PARTIE INVISIBLE

Le chaos lié à l'instabilité du produit est maitrisé par la partie cachée des pratiques de développement. Ces pratiques ont le désavantage de ne pas être visibles. Il s'agit par exemple de l'intégration continue, du développement piloté par les tests, de la programmation par contrat, de la programmation orientée-objet, du strict respect des grands principes de conception orientée-objet et de l'exception visible: le Pair Programming. Ces pratiques combinées et la recherche de l'excellence technique permettent de maitriser l'instabilité d'un produit en train de "pousser" par incréments. Malheureusement, le fait que ces pratiques ne soient pas visibles les rend plus difficiles à valoriser auprès de décideurs et des équipes de développement.

OU EST LE PROBLÈME?

Le risque est que décideurs et équipes de développement n'adoptent que la partie visible des pratiques de développement. Ces projets souffriront beaucoup du chaos et de l'instabilité du produit. L'adoption des nouvelles pratiques sera tenue responsable des échecs. Malheureusement, un échec cuisant peut avoir plus d'effet que plusieurs succès quand à la promotion d'une nouvelle démarche au sein d'une organisation.

DES SOLUTIONS?

Communiquer auprès des décideurs et des équipes en démontrant les pratiques visibles est très efficace pour séduire et convaincre. Cependant, il faut également insister lourdement sur l'absolue nécessité du socle technique.
Aussi, nous avons remarqué que nos équipes qui ont pris le virage avec succès ont commencé par adopter les pratiques techniques. Peut-être qu'il est plus sûr de débuter par la partie invisible et d'attendre que les bienfaits se fassent sentir?