On trouve beaucoup de théories sur le web sur les différents cadres Agile.
Chaque contexte d’entreprise est différent et certes un cadre doit être appliqué, mais c’est également un espace de liberté pour l’adapter à ses besoins.
Afin de mieux comprendre cela voici un exemple d’organisation : le nôtre.
Le contexte
Nous sommes dans un service informatique d’une PME de taille conséquente avec de nombreux besoins clients et devant donc adresser de multiples projets simultanément.
Chaque équipier se retrouve donc sur plusieurs projets à la fois, cas inéluctable mais plus complexe à gérer qu’avec des équipes dédiées à un produit.
Le cadre choisi
Nous avons choisi Scrum pour les raisons suivantes :
- Un rythme cadencé par des sprints : moins de chances de se faire happés
- Très cadré : les rituels facilitent le travaillé ensemble, permettent de bien se comprendre
- Force à capitaliser : Stand up et surtout rétrospectives permettent de ne pas passer à côté de problématiques et de leurs traitements.
- Casser le management directif : Besoin d’un véritable esprit d’équipe, et stopper la notion de chef qui posait des problèmes de fonctionnement dans le service.
- Certains collaborateurs déjà formés : Il faut le noter, nous avions au démarrage 1 équipier déjà formé, cela aide!
- Un outil déjà expérimenté : Nous avions déjà eu un premier aperçu de Azure Devops et il semblait répondre à de nombreuses problématiques.
Fonctionnement général d’un projet
Dev team
Les équipiers de la dev team peuvent être dédiés au projet mais sont la plupart du temps sur 2 projets en simultané.
2 projets = 2 backlogs avec des tâches différentes.
Pour bien répartir la charge de travail, nous jouons avec :
- Le planning des disponibilités
- Les Proxy PO négocient la répartition des jours par projet mois par mois
- Adaptation des efforts des stories en fonction des points 1 et 2.
Inconvénient de cette solution ? les débats entre Proxy PO pour la répartition des charges entre projets peuvent être plutôt houleux!
Concernant l’organisation du temps de travail des développeurs, ils ont la liberté de gérer l’agencement d’un projet par rapport à l’autre. Les priorités sont discutées en stand up meeting.
Il en retourne de la responsabilité collective de ne pas débuter un développement à la fin du sprint!
Nous avons essayé de caler en début de semaine le planning de la dev team, mais cette méthode était jugée trop dirigiste et pas assez flexible.
Le Scrum Master
Le Scrum Master est transverse à tous les projets.
Il doit donc gérer son temps entre les différents projet et évaluer là où il doit être plus présent (projet qui débute, équipe nouvelle, manque de maturité…).
Inutile d’indiquer que le travail est dense et la tâche ardue!
Le gros avantage réside dans le fait qu’il peut plus facilement généraliser le cadre, les différentes méthodologies et l’usage des outils.
Régulièrement le Scrum Master fait des audits de projet afin de mesurer le gain de maturité. Cela consiste en un rapport sur le backlog, les rituels… , suivi d’actions à mener dans le cadre des sprints.
Ainsi le Scrum ne peut pas être présent à tous les rituels de tous les projets, mais va devoir se positionner au bon endroit au bon moment.
Cependant, il est toujours disponible pour répondre aux questions, promulguer des conseils et former sur tel ou tel aspect.
Le Proxy PO
Non prévu dans le cadre Scrum, nous avons ajouté, comme beaucoup, ce rôle.
Dans l’article ci dessous , vous pourrez trouver tout ce qui a motivé notre choix.
Pour résumé, le Proxy PO forme un duo avec le Product Owner et assure une interface privilégiée avec la Dev Team.
Pour notre organisation, les Proxy PO sont rattachés au service informatique. Ils se côtoient constamment et forment une équipe soudée qui peut gérer potentiellement plusieurs projets à la fois.
Nous avons remarqué qu’un Proxy PO peut au grand maximum gérer 2 gros projets à la fois. En dehors de cela, c’est rapidement l’implosion.
Le Product Owner
Deux possibilités :
- Soit le Product Owner est directement rattaché au service client
- Soit le Product Owner est transverse
Le choix se fait en fonction de la transversalité des projets. Mais le deuxième choix s’impose de plus en plus, pour les raisons suivantes :
- Nos produits répondent de plus en plus à des besoins qui touchent plusieurs services (transversalité de l’organisation)
- Avoir un PO directement intégré au service client le rend au final trop juge et parti.
Encore une fois, plus d’informations sur le Product Owner sur cet article.
Les rituels et le cadencement:
Stand up meeting :
Nos stand up meeting ne sont pas journaliers.
Pourquoi ce choix? Parce que chaque équipier est sur plusieurs projets et enchaîner les stand up tous les jours ne convenait pas à l’équipe.
C’est une liberté que nous avons pris sur le cadre, en fonction de notre contexte de travail.
Nous avons donc en général 2 stand up par semaine par projet. L’équipe détermine et bloque ainsi les mêmes créneaux toutes les semaines.
Le format est classique, autour d’un tableau. Le Proxy PO est présent et en profite pour rappeler les prochaines échéances ou challenges à relever.
Présents : Dev Team, Proxy PO, Scrum Master
Sprints :
Nos sprints sont en général de 4 semaines. Avec une volonté de les caler au maximum sur les mois, afin de pouvoir facilement matcher avec le planning des disponibilités et de répartition des charges.
La durée des sprints est cependant adaptée en fonction des projets et selon les conseils de notre Scrum Master.
Nous appliquons à la lettre Sprint Planning, Sprint Review, Démo, Rétrospective.
Revue de portefeuille projets
Ce rituel a pour but de partager avec les différentes équipes projet l’avancement global.
Devant un tableau, ou a défaut un fichier, l’équipe passe en revue les points marquants de chaque projet : atteinte des objectifs, alertes diverses, difficultés, interactions entre projets….
Plus d’information dans l’article dédié.
Comité de pilotage
Le comité de pilotage est un moment essentiel à la vie du projet.
Participants : DSI, Sponsor, Product Owner, Proxy PO.
La fréquence est en générale tous les 2 à 3 mois.
Nous présentons et révisons durant cette instance
- les résultats,
- le point budget
- les orientations stratégiques
- le planning
Le comité de pilotage va ainsi officiellement orienter les prochains sprints, apportant une vision moyen terme au projet.
Bilan
Nous avons une organisation basée sur Scrum avec certaines particularités propre à notre entreprise.
Encore une fois, mieux vaut adapter qu’appliquer à la lettre des principes qui ne trouvent pas de sens pour les collaborateurs.
