Un kit de la maitrise d’ouvrage Agile

Il y a quelques années j’ai fait de la maitrise d’ouvrage en cycle en V. Et je ne le vis pas mal. Je n’avais juste pas en tête que je pouvais faire autrement. Par contre, je ne pourrais plus aujourd’hui retravailler ainsi parce que je crois beaucoup plus à l’utilisation d’une méthode adaptive. Je me propose de décrire comment il est possible de travailler autrement et ce que cela veut dire pour la maitrise d’ouvrage.

Cet article donne des pointeurs pour approfondir chaque sujet. C’est une vision de l’évolution du métier de maitrise d’ouvrage. Je suis d’ailleurs convaincu que le passage de maitrise d’ouvrage cycle en V à maitrise d’ouvrage agile est plus une question de motivation que de complexité technique.

Agile

Tout d’abord, qu’est que l’Agile et dans quels cas cela peut être utile : A quel Agile allez-vous être mangés ? Côté méthode, Scrum est le framework dominant avec l’émergence de Kanban souvent par des équipes plus matures techniquement. Dans les 2 cas, l’autonomie des équipes est mise en avant avec décentralisation de décisions au niveau bas. Et donc, cela pourrait être intéressant de savoir prendre des décisions sans un chef pour trancher. J’ai nommé les protocoles de prise de décision.

Tout ce qui tourne autour du produit

En mode Agile, j’utilise souvent un artifact qui permet de faire le lien entre problème et solution dans le but de délivrer le plus de valeur. Mais au fait, c’est quoi la valeur ? L’artifact en question s’appelle le product backlog et voici de quoi il est constitué : C’est quoi un product backlog?

Pour réussir à créer et suivre le product backlog, cela demande d’autres techniques que celles utilisées en cycle en V. Voici donc un peu d’entrainement. Il sera question de compréhension, d’exploration, de décision, de construction et de validation. Ces exercices sont fortement inspirés des pratiques UX.

Le BDD ou spécification par l’exemple

Dans la série DD, voici le Behavior Driven Development (BDD) pratique autour des tests fonctionnels aussi connu sous le terme de spécifications par l’exemple que je me propose de présenter par les impacts. L’erreur classique quand on commence à faire du BDD, c’est d’en faire tout le temps et de se retrouver avec beaucoup beaucoup de scénarios. Je propose donc d’expliquer quand faire du BDD. Comment écrire des scénarios au format Gherkin ? L’explication par l’exemple de comment faire du BDD.

Autour de la créativité

Un sujet légèrement annexe mais de plus en plus d’actualité, il est question de la capacité à sortir du cadre. Une fois que vous avez généré beaucoup d’idées, il ne reste plus qu’à faire le tri.

Plus proche du marketing

C’est un clin d’oeil à la conférence de Michel Yakovleff lors du dernier Lean Kanban France autour de la gestion du risque et de la prise d’initiative. Il est question de prendre l’initiative dans le développement produit ou si vous ne l’avez pas comment la reprendre.