Quand une équipe agile a une bonne partie de ses membres matures en agilité, ils peuvent sans soucis créer leur propre méthode agile ! En général, c’est un coach agile qui va se charger d’aider l’équipe à mettre cette méthode agile en place.
Sachez que cette façon de faire peut également permettre de mettre des méthodes agiles dans d’autres pôles que l’IT. Cela peut permettre à une équipe de faire évoluer sa méthode ou de lancer un nouveau projet sous une forme plus adaptée.
Pourquoi ne pas utiliser l’existant ?
Dans le monde de l’agilité, l’existant ne répond pas forcément à l’ensemble des besoins de l’équipe ou de son contexte. Les méthodes comme le Scrum se veulent volontairement évasives sur le contenu et préfèrent proposer un cadre léger.
Pour rappel, si les user-stories et le poker planning sont utilisés massivement par les équipes Scrum, il ne faut pas oublier que ces pratiques ne viennent pas du Scrum. C’est une adaptation massivement reprise par un grand nombre d’équipes.
Et c’est une bonne chose car elles apportent à priori beaucoup à ces équipes.
Cependant, le Scrum ou l’Extreme Programming apportent un cadre utile pour aider les équipes peu matures à se lancer ; c’est un premier pas utile pour se lancer dans les méthodes agiles. Il ne faut pas dénigrer ces méthodes qui ont permis de faire des avancées extraordinaires en agilité.
Par où commencer ?
Il est important de commencer par deux points :
- analyser les besoins organisationnels de l’équipe
- regarder ce qui existe sur le marché en terme de méthodologies et pratiques
Au niveau pratiques et méthodologies, vos coachs agiles vous seront d’une grande aide surtout si vous n’êtes pas anglophone, car il y a très peu de blogs qui traitent de l’ensemble des méthodes agiles existantes dans le monde francophone.
Le sujet se lance souvent dans une salle remplit de boards et de post’it pour se mettre dans une capacité de brainstorming de qualité.
Il n’est pas rare que les équipes partent sur des bases :
- part-on d’un scrum ?
- part-on d’un kanban car on ne peut pas prévoir 2 semaines d’objectifs en amont ? En gros, travaillons-nous en sprint ?
C’est un repère simple pour démarrer en général bien qu’il existe des hybrides comme scrumban ou xanpan. D’ailleurs la création de ces deux dernières méthodes viennent d’une démarche similaire. Il faut savoir que le Scrumban est devenue une méthode très utilisée aujourd’hui.
Les questions se posent ensuite sur différents sujets :
- faisons-nous une daily le matin ? Qui est concerné par cette daily (que les devs ou toute l’équipe) ?
- faisons nous une rétrospective ? Si oui, est-ce en fin de sprint ? Est-ce à la demande ? Ou mettons-nous ce concept de reflexion qui est un point d’équipe dès qu’un problème est rencontré ?
Je ne vais pas forcément mettre toutes les questions à se poser mais ça vous donne une idée de la démarche à avoir pour obtenir une méthode 100% adaptée au besoin de l’équipe.
Pas d’inquiétude mais si un choix s’avère ne pas être idéal, l’équipe saura adapter celui-ci pour le rendre plus optimal. Tester, c’est apprendre soit c’est avancer dans la bonne direction.
Notre méthode Kanbride (kanban+hybride)
Une équipe que j’accompagne a décidé de partir d’un kanban classique. A partir de ce kanban, elle a décidé de créer des itérations par rapport à la livraison de petites releases ; vous comprendrez ainsi que ces itérations sont variables contrairement à un scrum.
Je parle d’itération car l’équipe a décidé de baser des cérémonies sur ces itérations :
- vision et objectifs en début d’itération
- démo de release une semaine après le développement de la release (semaine importante pour déplacer tous les acteurs nécessaires)
- rétrospective en fin de release
- mise en place de réflexion dès qu’un problème survient
Certains pourraient juger cette méthode peu fiable mais elle s’adapte vraiment au contexte du projet : projet très technique dans un contexte compliqué
Le projet a aussi décidé de se baser sur des points intéressants assez différents de ce qu’on peut trouver dans un grand nombre d’équipes :
- définition des MMF et 1 release par MMF (pour au final livrer un MMP en production).
- démo à chaque MMF pour s’assurer d’avoir des feedback sur chaque petit bloc applicatif
- construire les MMF avec les utilisateurs clés de l’application en suivant leurs besoins
Article : Quels liens entre le MVP, MMF, MMR et MMP ?
Je ne suis pas rentré dans le détail mais une démarche très intéressante ; avoir la méthode adaptée à son environnement est souvent idéal. Le principal est de ne pas oublier cette « culture » agile qui doit amener à la construction de la nouvelle méthode.
Avez-vous des méthodes hybrides à nous partager ?
Soyez le premier à commenter