Pages - Menu

mardi 18 avril 2017

Mon premier projet agile ... sans le savoir !

Ayant été développeur et chef de projet sur de nombreux projets pour des grands comptes, comme beaucoup, je me suis vite aperçu qu'il y avait toujours des problèmes récurrents avec le cycle en V traditionnel.

Dès mes débuts dans le développement, j'ai essayé de trouver des solutions.
Au début, avec 2 collègues de ma premier SSII, nous avions identifié un problème avec l'expression des besoins. Nous avons donc créé une société dont le but était de réaliser un logiciel d'aide à l'expression des besoins. C'était une piste, mais ce n'était pas suffisant. Plus tard j'ai repris mon activité de chef de projet pour les grands comptes.

Puis un jour, chez un grand organisme du service public, j'ai commencé un projet en tant que chef de projet. J'ai suivi le plan établi par le commercial et les livrables tels que les spécifications fonctionnelles basées sur le cahier des charges établi par le client. Puis le développement a commencé avec les aléas techniques, les imprévus, les demandes floues.

J'ai commencé à faire des aller retours ininterrompus dans le bureau du chef de projet client. En lui expliquant en tout transparence les problèmes rencontrés par certaines fonctionnalités ou ergonomie décrite dans le cahier des charges. Nous avons assez rapidement mis en oeuvre un mode de fonctionnement basé sur la négociation. Nous retirions certaines fonctionnalités trop complexes pour en ajouter d'autres plus utiles, ou n'étant pas prévus au départ.

Croyez moi ou non, ce fut le seul projet que je vis fini dans les délais et budget prévu !

Il m'a fallut connaître Scrum et une pratique d'au moins une année pour m'apercevoir de ce que j'avais fait à l'époque.

jeudi 23 février 2017

Basculez vers l'agilité

Je suis tombé sur un tweet qui montrait cette illustration :



Je l'ai trouvé très intéressante à deux titres. Premièrement, elle exprime de manière très claire quels sont les signes de l'agilité ou non chez une personne. Et deuxièmement, je pense que, pour un ScrumMaster From Hell, montrer cette illustration à une personne qui montre notoirement des signes de non agilité pourrait s'avérer être un outil terriblement efficace. 

Attention, à ne pas mettre entre toutes les mains ;)

mercredi 22 février 2017

Pourquoi ScrumMaster From Hell ?

"Le ScrumMaster de l'Enfer"

D'où peut bien venir ce titre effrayant ?

Il vient d'un petit surnom affectueux qui m'a été donné par un client, devenu un ami.

Le ScrumMaster From Hell, c'est le ScrumMaster dont on imagine les penchants diaboliques et sournois.

En fait, derrière ce sobriquet, se cache une idée très concrète, qui oriente notre façon de partager les principes fondamentaux de l'agilité.

Lorsque nous avons fait nos premières armes dans le domaine, et sensibilisé nos premiers clients à Scrum, il nous est vite apparu qu'il existe un fossé entre la théorie et sa mise en pratique.

Les principes sont faciles à expliquer, mais subtils à mettre en oeuvre. Et la théorie doit impérativement être complétée par des cas concrets, qui bien souvent évitent de gratter la surface. Or, c'est précisément en creusant les sujets qu'on va marquer les esprits, et communiquer plus efficacement la philosophie de l'Agilité.

C'est bien connu, on n'apprend jamais autant que quand on se trompe. L'apprentissage par l'échec, si répandu outre Atlantique, reste un sujet minoritaire en France.

C'est là qu'intervient le ScrumMaster From Hell : en mettant l'accent sur les problèmes classiques que peuvent rencontrer les équipes Scrum, en les poussant à l'échec et en leur donnant les moyens et les reflexes pour les contourner. Ayant été confronté à ce type de situation, l'apprenant se remémorera d'autant plus facilement la situation qui l'a contraint à trouver des solutions pour s'en sortir.

Un cas classique : lors d'un atelier de Lego For Scrum, où l'objectif pour l'équipe est de construire les bâtiments d'une ville en Lego, le ScrumMaster From Hell - ou SMFH pour les intimes - restera très flou sur les différentes Stories du premier sprint. L'un des principes Agile est de privilégier l'interaction et le dialogue entre le PO et l'équipe, ne l'oublions pas.
Il attendra donc patiemment que les apprenants viennent lui poser des questions. Questions qui, en général, ne viendront pas.
A la fin du sprint, il démolira consciencieusement toutes les stories réalisées, arguant qu'il fallait lui demander des précisions avant de construire les bâtiments. "Celui ci aurait du être rouge, pas bleu. Celui là est trop haut. Et cet autre là, trop petit."
Narquois, il demandera à l'assemblée : "Pourquoi ne m'avez pas posé des questions ? J'étais pourtant disponible, vous ne m'avez pas vu ?"

Tel est le ScrumMaster From Hell. Agaçant, parfois, mais pertinent, souvent.