Entretient de système, Scrum avec Kanban, Kanban seul ou approche #NoFramework

Communauté Scrum Life
,
1

Bonjour,

J’ai besoin de vos lumières, de vos commentaires et pourquoi pas, de vos retours d’expériences.

Je suis à la phase 2 de mon implémentation de l’agilité dans une équipe.

Cette équipe a deux grands types de projets, les projets de développements et les projets d’entretiens de système.

L’implémentation qui fut choisi pour les projets de développement (Phase 1), est Scrum et jusqu’à maintenant avec un certain succès. L’équipe doit prendre encore de la maturité.

Nous voulons aussi réorganiser l’entretien des systèmes, notre phase 2. Car, pour le moment ça ressemble plus à une approche de dépilage de tickets sans grand suivi possible et dont, l’arrivée de ces tickets provient de plusieurs sources (Système de tickets, Courriel, Appelle directe et Cie) , sans nécessairement en garder une trace pour le suivi.

Je regarde pour l’instant trois pistes possibles ou plausibles. La première serait d’implémenter de Scrum avec Kanban pour gérer un peu mieux le flux.

La deuxième option serait d’implémenter Kanban seul pour gérer la charge de travail. En même, temps cela apporterait peut-être un peu plus de maturité à l’équipe en leur apprenant à mieux contrôle de leur le flux entrant et leur gestion de capacités. Une manière de briser certaines mauvaises habitudes.

La troisième option, une approche #NoFramework. P.S. j’ai volontairement choisit d’exclure ScrumBan pour différentes raisons.

Car, en plus, d’éviter le simple d’épilage de ticket.

La gestion ou la hiérarchie veulent pouvoir évaluer leur capacité et l’utilisation de celle-ci. Il serait intéressant de savoir aussi leur disponibilité présente ou à venir des membres de notre équipe.

Il s’annonce de gros projets à venir dans organisation. Donc, savoir quand ou comment, sera la disponibilité des ressources de notre équipe. Je sais certain, vont déjà entendre résonner « Agilité à l’échelle. » Oui, il y a dans ma direction des initiatives SAFE. Mais, j’aimerais bien que mon équipe sache bien marcher avant d’essayer de courir ou de conduire un bulldozer :slight_smile:

MERCI à l’avance de vos commentaires ou conseils… P.S. Je prends aussi les plus folles idées, tant que c’est fait dans le respect de tout monde.

Je garde XP, pour la phase 3 partie de l’implémentation. OK je rigole un peu, parfois, il faut revenir à certaines bonnes pratiques de XP et de ce qui en découle.

Bruno Larouche
Empêcheur de tourner en rond !

2

Hello,

Spontanément, je m’interroge sur les raisons qui vous poussent à garder la gestion de la maintenance corrective séparée de la maintenance évolutive. Pourquoi ces demandes ne sont pas centralisées pour être analysées et priorisées dans un backlog unique par le PO ? C’est comme ça qu’on est censés s’organiser dans Scrum : un produit = un backlog = un chef de produit. Cela permet au PO de maîtriser la répartition de l’effort entre évolutif et correctif en fonction des objectifs poursuivis. On peut par exemple investir dans le correctif pour améliorer l’image de marque du produit, ou au contraire dans l’évolutif pour élargir l’assiette du marché.

La difficulté c’est que les tickets de correctifs ne peuvent pas être intégrés de manière « brute » au backlog. Il faut les garder tels quels dans un ITSM pour bien communiquer l’avancement avec les demandeurs, tout en les convertissant en product backlog item avec la vision business. Cela permet par exemple de mutualiser plusieurs demandes similaires en un seul élément de backlog. Mais surtout, ça permet de passer du « quoi » au « pourquoi » et donc d’aborder le sprint non pas comme une pile de tickets à dépiler mais comme des objectifs (sprint goal) à atteindre.

C’est assez comparable à l’articulation entre le processus de gestion des incidents et celui de gestion des problèmes dans ITIL.

3

Si la stratégie est de scinder développement et entretien, je conseille vivement le Lean/Toyota Production System/Flow System/Kanban pour la partie entretien. Ce n’est pas juste du ticketing. Il s’agit quand même de développer une expertise et un savoir-faire (artisanat). Le but n’est pas non plus d’appliquer un framework tel quel, mais de s’en inspirer. Si toi et/ou tes collègues ont suffisamment d’expérience, il faut que vous aidiez l’organisation à concocter ses propres plats à partir des ingrédients et ne plus utiliser les recettes de cuisine toutes faites (https://youtu.be/AEf1BCffimA). D’ailleurs, je résisterais le plus possible contre SAFe. L’agilité à l’échelle n’a pas de sens dès lors que toutes les équipes n’ont pas le même contexte et que l’agilité ne s’applique pas partout (Product Management Contextuel | William Bartlett | Oct, 2023 | Medium).

Il faut s’assurer que l’entretien séparé ne concerne que les composants logiciels stables. Lorsque le composant évolue encore beaucoup et que l’équipe itère rapidement et apprend encore bcp de choses, il vaut mieux que l’équipe qui construit soit également en charge de l’entretien.

4

Bonjour M. Hupond,

Merci de me donner l’occasion de préciser un détail que j’avais oublié. Mon intension n’a jamais été de diviser la maintenance corrective de celle évolutive. C’est que les systèmes touchés, ils n’ont pas d’évolutions majeurs prévue dans les prochaines années. Ceux qui en avaient besoin, surtout par désuétude technologique, ont passé par un processus de refonte dans une nouvelle technologie, en partie que je parlais dans la partie Scrum (Développement).

J’ai aussi prévu, peu importe la solution d’encadrement choisi qu’il est forme de Product Owner, justement pour avoir siens gestions de l’arriver des demandes,

P.S. J’ai souris en voyant : " ça permet de passer du « quoi » au « pourquoi »" je viens de passer ma PSMII tout récemment. Donc, ça fait partie du processus.

Toute la gestion du support niveau 1, ne fait pas partie de ma direction. Donc, je ne peux pas intervenir dans leur cours. A ce que j’en sais, ils ont déjà des processus ou gestions de l’escalade d’incident.

J’avoue aussi bien volontiers que je suis loin d’être un Expert ITIL.

MERCI de vos commentaires et suggestions.

Bruno Larouche

5

Bonjour M. Barlett,

Je partage aussi beaucoup votre avis que parfois. Il faut jouer au chef de cuisine.

Avec les années, j’ai identifié une série de bon ingrédient Agile. Mais, même si mon livre de recette commence avoir plusieurs chapitres. Le chapitre pour l’entretien et évolution de système, n’a pas encore beaucoup de pages. Malheureusement, j’ai plus intervenue dans des projets de développement et très peu en entretiens de système. J’étais, il y a pas encore si longtemps un consultant. Donc, je passais de projet en projet, le contexte Québécois, c’est qu’on donne les projets à des consultants et on laisse l’entretien des systèmes aux équipes internes. Je rendu interne maintenant et impliqué dans des équipes d’entretiens et évolutions.

Quant à Safe, je n’ai pas le pouvoir de décision, seulement d’influencer au niveau de mon équipe. et d’écouter, les autres équipes qui ont été embarqué dans le train. Je travaille fort pour leur apprendre à bien marcher pour que le jour qu’ils devront courir, ils ne trébuchent pas au 2e pas.

Je sais aussi que j’ai TRÈS résumé la problématique, voir mit un voile volontairement sur certaines problématiques. Mais, j’essaie d’appliquer à moi, le principe qu’il faut apprendre à marcher avant de courir.

MERCI de vos réflexions, ça m’aide beaucoup dans ma réflexion.

Bruno Larouche

6

Si je reformule, la partie développement/évolution a fait l’objet d’une migration vers ce qui est devenu un nouveau produit (dont le pilotage est assuré via Scrum) ; et il reste la maintenance de la partie historique qui n’a pas migré et pour laquelle vous cherchez le processus le plus adapté. Est-ce correct ?

La gestion des incidents correspond au support niveau 1. Chaque fois qu’un utilisateur rencontre un problème, cela correspond à un incident. Plusieurs incidents peuvent avoir la même cause racine, qu’on appelle problème. Les problèmes peuvent rester ouverts très longtemps et ne jamais être corrigés, par contre tous les incidents doivent être clôturés, ce qui consiste parfois à expliquer à l’utilisateur qu’on ne corrigera pas le problème (mais qu’on peut lui fournir un service de contournement par exemple).

D’expérience, Kanban fonctionne très bien dans un contexte de TMA où les travaux impliquent un travail principalement individuel et bien maîtrisé. Scrum s’adapte plutôt à un contexte qui nécessite que plusieurs développeurs, avec des compétences complémentaires, s’associent pour élaborer une solution complexe, en particulier si ça nécessite un travail de nature exploratoire.

1 « J'aime »
7

Merci de votre reformulation, elle précise plus de mes idées. Comme je dis souvent à mes amis, « si je pourrais exprimer clairement et simplement ce que j’arrive à analyser. Je serais un génie. » Malheureusement, il me reste encore du travail pour être ce génie.

1-ITIL, j’ai fait une comparaison entre Scrum (et l’Agilité), j’ai beaucoup d’années de pratique et des plusieurs certifications en agilité. Mais, malgré que je comprends les grands principes d’ITIL. Je navigue moins facile que dans l’agilité en générale.

2-C’est la maintenance des applications « Historiques » comme vous dite que je dois appliquer aussi un cadre Agile. Je maitrises les limites de Scrum et implémenter dans des équipes à plusieurs reprises.

C’est plus Kanban, je le connais depuis longtemps. Mais, je n’ai jamais eu à faire d’implémentation. Donc, ça reste une connaissance théorique. Donc, possiblement certaine limites mes restes inconnues.

Ce que j’aime bien dans Kanban, est la gestion de capacité (WIP au sens large), c’est en gérant cette capacité pourra me permettre par voie détourner connaitre la disponibilité des ressources.

En analysant, certaines données historiques, attrapées de gauches et de droite. Il y avait de période, que les ressources avaient certaine disponibilités (Manque de travail). On veut identifié aussi ces périodes. Pour être, capable de dire, oui on peut prendre un nouveau projet de développement ou non. Ou encore, aux autres équipes qu’on une ou des ressources qui pourraient leur venir en aide.

J’espère cette fois-ci de vous clarifier mes idées, mes problèmes et les solutions possibles.

Bruno Larouche

8

Bonjour,

Qu’est ce qui ne marche pas concrètement dans la partie entretien des systèmes existants ?

Vous évoquez la problématique du suivi à cause des multiples sources des tickets. Est ce juste ça ?

Cette problématique n’est pas suffisante pour aiguiller un choix entre Kanban, Scrum ou autre il me semble
On pourrait simplifier en disant que Scrum apportera du focus sur un objectif de sprint, Kanban une meilleure optimisation du flux mais ni l’un ni l’autre ne pourra être efficacement implémenté sans une centralisation et une priorisation des demandes clients

9

L’agilité n’est pas applicable partout !

1 « J'aime »