Ce titre, façon topito, est plutôt mensonger puisque je vais vous parler de mon expérience de coach agile et des questions auxquelles j’ai été amenée à répondre.
Depuis maintenant 2 ans que je suis chez Thiga, j’ai souhaité évoluer vers un rôle de coach agile “opérationnel” c’est à dire que j’interviens maintenant, lors de missions ponctuelles ou de longue durée, dans des équipes se transformant et qui essaient d’appliquer les préceptes agiles à leur mode de travail.
Toutes les équipes dans lesquelles je suis intervenue m’ont posé les mêmes questions. Je vais vous les présenter et tenter, humblement, d’y répondre.
Plutôt Scrum ou Kanban ?
Dans toutes les équipes au sein desquelles je suis intervenue, cette question est la première à laquelle j’ai dû répondre et malheureusement, j’ai dû avouer qu’il n’y avait pas de bonne réponse.
Pour pouvoir choisir entre Scrum et Kanban, il faut en connaître les différences pour voir laquelle des deux méthodes sera la plus applicable à l’environnement de l’équipe.
(source)
Si chaque “agiliste” a une préférence pour une méthodologie, chaque client, chaque équipe, chaque produit aura des besoins et des contraintes se rapportant à l’une des deux.
Une équipe qui débute avec l’agilité, qui se transforme après des années de Cycle en V a besoin d’être rassurée, de donner de la visibilité, d’afficher un planning et des jalons. Elle se tournera alors vers la méthodologie Scrum et ses notions de “burndown”, d’ “itérations”, de “rôles” et de “Product Backlog estimé”.
Néanmoins elle pourra aussi être attirée par la méthode Kanban qui lui permettra de reprioriser en cours de cadence pour ajouter des éléments devenus prioritaires (comme des bugs) et qui convient mieux à une équipe hétérogène ou spécialisée.
Pour ces raisons, je conseille très souvent une souplesse dans la méthodologie en choisissant le Scrumban qui permet de prendre le meilleur des deux méthodes.
L’agilité ne doit pas être un carcan et doit permettre aux équipes de travailler au mieux pour délivrer un produit de valeur et de qualité.
La méthode doit s’adapter à l’équipe et non l’inverse. Je conseille souvent de commencer par du Scrumban et avec l’expérience et la maturité de choisir définitivement une des deux méthodes ou de garder cet entre-deux.
Pourquoi le burndown ne descend-il pas alors que des tâches sont terminées ?
Quelle question frustrante ! L’équipe travaille et pour autant le burndown, outil de visibilité sur l’avancement du travail, ne descend pas, la vélocité est en berne et es User Stories mettent plus de temps que prévu à être développées.
En creusant et en interrogeant les différents membres de l’équipe on arrive rapidement au problème : Les développeurs travaillent sur d’autres tâches que les User Stories du backlog et ne délivrent plus la valeur attendue.
La frustration est de part et d’autre ; le Product Owner est frustré de ne pas voir ses User Stories fonctionnelles être délivrées. Les développeurs sont frustrés car ils travaillent sur des tâches techniques à haute valeur mais le burndown ne descend plus.
Cette grande frustration est due à un manque de communication, à un manque de visibilité et à une mauvaise organisation.
Une règle très importante est que toutes les tâches doivent être connues du Product Owner et doivent être tracées dans le backlog (dans JIRA, sur le board physique, …). Le Scum Master (ou le tech lead) doit présenter ces tâches au Product Owner qui est le seul garant du backlog.
Le Product Owner pourra choisir d’inclure une ou plusieurs tâches techniques qui seront alors estimées et priorisées comme les autres User Stories. Il pourra aussi choisir de dédier un nombre de points de chaque sprint à ces tâches techniques, libre ensuite à l’équipe de choisir ses sujets.
Dans tous les cas il faudra essayer au maximum de dégager une valeur métier à ces tâches techniques et pourquoi pas de les écrire au même format qu’une User Story classique.
Travailler à améliorer les performances d’une landing page d’un site pour s’écrire sous la forme d’une User Story :
As a visitor of the website
I want to have quick access to the Landing Page
In order to read the content I was looking for
Given 10 visitors on the Homepage of the website
When they click on the call to action to go to the Landing Page at the same time
Then the Landing Page appears in 3 ms for all of them
et pourra ainsi être présentée en démonstration de fin de sprint au même titre que les autres.
Nous passons beaucoup de temps en réunion et pourtant nous devons produire toujours autant de points. Est-ce normal ?
J’adore cette question, elle pourrait prêter à sourire si on me la posait pas à chaque fois.
Non il n’est pas normal de passer du temps en réunion et de devoir produire le même nombre de points que si la réunion n’avait pas eu lieu.
Attention il ne s’agit pas de dire que les développeurs doivent passer leur temps devant leur ordinateur et doivent être privés de réunion sous prétexte que leur rôle n’est que de produire.
Les développeurs, comme l’ensemble de l’équipe, ne doivent pas rester la tête dans le guidon à dépiler le backlog, tout au long du sprint ils peuvent être amenés à aller en réunion. Pour autant il faut essayer de faire en sorte que ces réunions soient le plus efficaces possibles.
On distingue tout d’abord les cérémonies classiques du sprint, que, pour ma part, je soustraie directement de mon calcul de vélocité (= pour un sprint de 2 semaines, sur 20 points de vélocité par développeur, j’enlève entre 1 et 2 points pour les cérémonies) .
Pour les réunions imprévues, deux solutions sont possibles ;
Si, par exemple, on sait que le Product Manager redescend de l’information à chaque sprint, on peut dédier un nombre de points à ces réunions.
Exemple : pour une réunion de 2 heures par sprint pour un sprint de 2 semaines pour une équipe 5 développeurs de vélocité de 20 points, on enlèvera 3 points au calcul de la vélocité.
Si on ne sait pas quand tomberont ces réunions imprévues et combien de temps elles dureront il faudra alors, au cas par cas, revoir le backlog du sprint et réajuster le nombre de points engagés.
Dans tous les cas, je préconise plusieurs choses pour minimiser le coût lié aux réunions et pour faire en sorte qu’elles soient le plus efficace possible.
En amont de la réunion : envoyer l’ordre du jour, les inputs et les outputs de la réunion, spécifier le rôle de chacun à la réunion.
Pendant la réunion : timeboxer. L’idée est de fixer une durée à la réunion et de s’y tenir quitte à ce que tous les sujets ne soient finalement pas abordés faute de temps.
Je vous préviens, si les équipes ne sont pas du tout habituées à ce genre de pratique, les premières fois se feront sûrement dans la douleur ! Mais à force d’être frustrés de ne pas pouvoir aborder tous les sujets prévus, le temps de parole devrait se réguler au bout de 2 réunions sur le même format.
Si vous voulez encore aller plus loin et si l’environnement du projet le permet, vous pourrez proposer de bannir les ordinateurs, téléphones et autres de la réunion pour permettre à chacun de se concentrer au maximum. Cela devrait augmenter l’efficacité des réunions et diminuer leurs durées.
A la fin de la réunion : un R.O.T.I ; Return on Time Invested ; l’idée est que chaque participant à la réunion lève la main pour mettre une note à celle-ci :
Ce retour rapide, à chaud, permet d’avoir le ressenti de chacun sur la réunion et permet de réajuster pour les prochaines en fonction de chacun.
Grâce à ces quelques règles simples, les réunions nécessaires à l’équipe et au projet, devraient s’organiser au mieux sans avoir un coût trop important pour l’équipe.
Mes préconisations peuvent vous paraître évidentes et j’ai sûrement l’air d’enfoncer des portes ouvertes mais pour autant posez-vous la question : pensez à vos réunions de la semaine dernière ; avaient-elles toutes un ordre du jour ? ont-elles fini à l’heure ? chacun des participants avait-il un rôle à y jouer ? qu’en avez-vous retenu ?
Avant de vous laisser voilà une dernière question, la 4ème que l’on me pose à chaque fois ;
Quelle est la différence entre un chef de projets et un Product Owner ?
Je pense qu’elle mérite un article dédié et ça sera pour la prochaine fois ! A très vite.
