Quel thème racoleur?
Quel thème provocateur?
Cette année pour l’Agile Tour Montpellier, j’ai proposé ce thème comme Lightning Talk (40 min) avec pour seule arrière pensée que celle de comprendre avant de s’engager.
Avant de comprendre quelque chose, il est important de comprendre son opposé. Est-ce bizarre? Schizophénique?
Bien sûr que non.
Que veut dire absurde? Des oxymores sont absurdes, des syllogismes…
Donc, l’Agile est-ce absurde?
Si l’on reprend les bases dont toute la communauté agile se réfère: le Manifeste Agile.
»
Manifeste du Développement Agile de Logiciel
Nous découvrons de meilleures façons de développer des logiciels en le faisant et en aidant d’autres à le faire.
Grâce à ce travail, nous sommes venus à valoriser:
- Davantage les individus et leurs interactions que les processus et les outils
- Davantage des logiciels opérationnels qu’une documentation complète
Davantage la collaboration avec les clients que les négociations contractuelles
Davantage la réponse au changement que la suivi d’un plan
Autrement dit, s’il y a une valeur dans les articles de droite, nous valorisons les articles sur les plus à gauche. »
Et derrière ce Manifeste se cache les 12 principes que je me permets de décortiquer devant vous:
-
Notre priorité majeure est de satisfaire le client grâce à la livraison précoce et continue de logiciel de valeur.
Mon constat:
- Précoce? est-ce que 6 mois c’est précoce? est-ce qu’un mois c’est précoce? Après un nombre incalculable d’interventions auprès de tout type de client, je m’aperçois que l’on joue souvent sur les mots. Les sprints délivrent des éléments pas finis pour livrer à trois mois une version. Livrer souvent cela signifie de livrer à chaque fois quelque chose de livrable. Donc oubliez les sprints de « qualification », les sprints de « préparation », les sprints de « développement » et les sprints de « test » (vécu entre décembre et avril 2015).
- Satisfaire le client? La majorité des équipes que j’ai pu côtoyer recevait un ticket « Jira » ou au pire devaient piocher dans HPQC. Les seuls clients étaient les « MOA ». C’est une catastrophe.
- Livraison continue de valeur? (voir plus haut sous « précoce ».
2. « Bienvenue à l’évolution des besoins, même tardive dans développement. Les processus agiles exploitent le changement pour l’avantage concurrentiel du client. »
Mon constat:
- Changement? est-ce que le changement de projet est un changement? est-ce que le changement de périmètre est un changement d’exigence? Un changement ne doit jamais être « gratuit ».
- Avantage concurrentiel du client? avez-vous déjà vu une MOA cherchant un avantage concurrentiel? Un chef de projet, une MOA cherchent avant tout à respecter « le contrat » au détriment de la réalité du développement.
3. Fournir des logiciels opérationnels fréquemment, à partir de quelques semaines à quelques mois, avec une de préférence à l’échelle de temps plus courte.
Mon constat:
- En fait, on peut livrer quant on veut? Dans les équipes les plus avancées (je pense à celles de Dimitri), les développeurs livrent tous les jours. Les versions, les livraisons ne sont plus que des actes « administratifs » de cloture de tickets. Voilà ce que cela devrait être.
4. Le métier et les développeurs doivent travailler ensemble tous les jours tout au long du projet.
Mon constat:
- Euh! tous les jours? Ben oui. L’Agilité c’est réduire la distance. Les meilleurs équipes créent à chaque une nouvelle équipe en fonction des projets avec un représentant du métier assis autour de la même table. Essayez voir, vous serez surpris. Cela évite d’avoir des équipes gérant un portefeuille multi-projets. En pratiquant de la sorte vous installerez quelque chose de stupéfiant: l’efficacité.
5. Construire des projets autour d’individus motivés. Donnez-leur l’environnement et le soutien dont ils ont besoin, et leur font confiance pour faire le travail.
Mon constat:
- Motivés? Etes-vous déjà allé sur un plateau de développement? Cela ressemble à des poulets en batterie qui ont peur de s’exprimer.
-
L’environnement? MDR, c’est le client qui fournit l’environnement.
-
Confiance? un grand débat…. alors pourquoi tant de Team Leader, Chef de Projets, PMO, Tech Lead?
- Bref, ici je parle principalement des grands projets où les développeurs sont principalement des prestataires emprisonnés dans une relation client/fournisseur malsaine. Dans ces projets, ce sont les achats et les commerciaux qui font la loi. Quel gaspillage!
6. La méthode la plus efficace et efficiente de transmettre des informations vers et dans une équipe développement est une conversation en face-à-face.
Mon constat:
- donc…. pas de Video Conférence, pas de tickets Jira, pas de mails, pas de Chat?
- en fait, rien de tel qu’une réunion brève où l’on explique pourquoi et l’équipe annonce comment. On appelle cela… un sprint planning. Vous savez cette réunion où toutes les parties prenantes sont présentes (utilisateurs, clients, management, l’équipe agile)
7. Un logiciel opérationnel est la principale mesure de progrès.
Mon constat:
- Opérationnel, cela signifie que vous le donnez au client, aux utilisateurs de sortent qu’ils puissent donner un retour d’information pertinent. Et cela à chaque fois! Dans le temps d’un sprint bien sûr!
- Si vous ne livrez rien cela crée de la confusion, de l’opacité. Cela crée un stress négatif pour le développement du projet. C’est inutile. Simplifiez-vous la vie et livrez.
- Jean-Pierre De Jongue explique que ses équipes digitales utilisent le processus suivant: Proto, proto, proto, code. Faire simple et être efficace.
- Challenger et piloter est un peu grotesque. La seule mesure acceptable est de livrer…. à chaque fois.
8. Les processus agiles promeuvent le développement durable. Les commanditaires, les développeurs et les utilisateurs devraient être en mesure de maintenir un rythme constant indéfiniment.
Mon constat:
- Donc… pas d’heures supplémentaires…. pas de week-ends…
- Le temps de travail est fixé de manière collégiale et on s’y tient? Parce que si l’on déborde, c’est que nous sommes mal organisés et que les heures supplémentaires ne sont pas facturables.
- Du temps aménagé, du travail à distance….
9. Une attention continue à l’excellence technique et un bon design améliore l’agilité.
Mon constat:
- Nous avons ici une grande marge de progression.
- Quel est le budget formation/ateliers/conférence de votre entreprise? Le mieux que j’ai vu est de 1.350 euros par an et par salarié.
- Où se trouve la bibliothèque dans votre espace de travail?
- Bon, d’accord, de temps à autre, on peut voir quelque chose d’affiché après une rétrospective. Mais pas à chaque fois.
- Est-ce que vos coachs agile ou vos scrum masters recensent les leçons apprises et les actions d’amélioration? A chaque fois?
10. Simplicité – l’art de maximiser le montant de travailler pas fait – est essentielle.
Le constat:
- alors celle-ci faut la comprendre?
- regardez votre code, est-il simple?
- regardez vos exigences, sont elles simples?
- allez vous à l’essentiel ou passez vous du temps à analyser et décortiquer à l’infini
- quelle tête à votre architecture?
- est-ce que vous priorisez votre travail tous les jours?
- est-ce que vous avez une business value définie par le business (métier, client)?
11. Les meilleurs architectures, exigences et designs émergent d’équipes auto-organisées.
Le constat:
- Pas d’Architectes en chef ou cabinet de conseil en stratégie qui vous disent comment faire?
-
Pas de MOA ou d’Analystes métiers qui vous disent quoi faire?
-
Auto-organisées, jusqu’où?
- Est-ce que les architectures sont revues chaque fois ou sont-elles définies une fois pour toutes?
- Est-ce que les exigences sont revues chaque fois ou sont-elles définies une fois pour toutes?
12. À intervalles réguliers, l’équipe réfléchit sur comment devenir plus efficace, alors elle règle et ajuste son comportement en conséquence.
Mon constat: voir ci-dessus
L’Agilité est quelque chose de fantastique, de simple. Alors pourquoi uniquement en parler et pas en faire?
Quelques images pour réfléchir:
La bise
Pierre
The Scrum Coach 