Déséquilibre et conduite du changement

Quand Brian Marick a achevé sa keynote à Madrid (XP2011) il a conclu par “gardez l’agile étrange” (keep agile weird). Il entendait par là dire que l’agile était une forme de résistance et qu’il fallait donc lui garder cette étrangeté vis à vis du monde extérieur, indicateur de sa bonne santé. Cette phrase a eu un autre écho en moi que j’ai essayé d’exprimer à Brian Marick dans les couloirs juste après son intervention. En fait cette étrangeté me faisait penser à quelque chose que je défend et aime depuis toujours : l’absurde, et le déséquilibre qu’il engendre. J’ai essayé de lui expliquer que sa phrase me faisait penser aux Monty Python, c’est absurde, c’est étrange, c’est déséquilibré, le déséquilibre produit une force qui permet le changement. Vo‍ilà mon mojo. Bon, il a vaguement acquiescé pour pouvoir rapidement s’éclipser vers le buffet.
(more…)

This entry was written by pablo, posted on July 5, 2011 at 2:34 pm, filed under gestion projet, management, méthodes agiles and tagged marx brothers, monty python, wcfields. Leave a comment or view the discussion at the permalink.

La dette technique selon Uderzo & Goscinny

Hello, après avoir rapidement jetez un oeil du côté de la loi de Parkinson, voyons aujourd’hui la notion de dette technique. Pour l’historique de cette notion assez simple mais ô combien efficace : wikipedia. Grosso modo l’idée est que, à chaque fois que vous réalisez “à la vite” du développement (généralement parce que quelqu’un exige une date de livraison trop difficile à tenir et donc que la qualité disparaît, ou parce que vos pratiques de développement ne sont pas assez pointues -TDD, Unit Test, Pair programming, refactoring, etc-.) ce même code vous demandera de payer des intérêts à terme. A chaque fois que vous reviendrez sur ce code, une somme de travail supplémentaire due à sa mauvais qualité sera -en plus- nécessaire. Comme une vraie dette, celle-ci peut s’accumuler jusqu’à rendre complètement inerte une solution, un produit, etc. Rappelez vous bien que votre code n’est pas un capital mais est un coût : les plusieurs millions de lignes de code d’un code ne sont pas une richesse mais une contrainte.

Comme le montre ce diagramme (de Agilitrix 2010, ça tombe bien avec le thème… ) si vous ne résorbez pas la dette technique, vous obtiendrez un “dead core”. Un produit foutu.

Je viens de passer quelques jours en Suisse en mission, j’en profite afin de mieux exprimer cette idée de dette technique de faire appel aux idées de Uderzo & Goscinny : à chaque que vous laissez filer votre bout de pain, votre code, sans faire attention, vous accumulez du fromage partout dans votre application qui va -peut à peut-  l’empêcher d’avancer, jusqu’à un immobilisme certain (c’est l’application que vous jeterez dans le lac). Il est toujours difficile de convaincre les décideurs mais il est parfois nécessaire d’investir la résorption de la dette technique. (merci encore à Frédéric pour son inspiration). Cliquez sur l’image pour y accéder de façon lisible.

This entry was written by pablo, posted on April 12, 2011 at 1:48 pm, filed under gestion projet, management, méthodes agiles, technologies, XP and tagged asterix, dette technique, goscinny, obelix, uderzo, XP. Leave a comment or view the discussion at the permalink.

La loi de Parkinson par Astérix & Obélix

La loi de Parkinson…  ou les gaz parfaits… veut que “le travail s’étale de façon à occuper le temps disponible pour son achèvement”. Qui dans un projet classique n’a pas vécu cette expérience étrange ? Donnez 3 jours à un “réalisateur”, il consomme les 3 jours pour réaliser ses tâches, donnez lui 10 jours, c’est 10 jours qu’il utilisera… Oui on évite cela avec Scrum au passage ou plus globalement avec l’agile, mais fallait-il le préciser ?  Je vous laisse déguster l’explication éminement efficace de Uderzo & Goscinny dans Astérix en Corse. (Cliquez sur l’image pour profiter des dialogues…)

Merci encore à Frédéric S. pour son inspiration, ce gars fourmille d’idées farfelues et donc drôlement intéressantes.

This entry was written by pablo, posted on April 2, 2011 at 8:29 am, filed under gestion projet, management, méthodes agiles and tagged asterix, obelix, parkinson. Leave a comment or view the discussion at the permalink.

L’agile pourrait-il redonner à la régie ses lettres de noblesse ?

Cher client, cher acheteur,

Si je t’écris cette lettre c’est pour te souhaiter de réussir tes projets.

Naturellement il ne t’aura pas échappé que réussir un projet “au forfait” est une entreprise incertaine, malgré le contrat qui te lie à ton prestataire. Je me doute que si tu es mature tu as déjà compris que les projets importants, les projets stratégiques, tu ne vas pas les confier à une société externe. Ce “forfait” qui va partir avec tes demandes et revenir quelques temps plus tard avec un résultat plus qu’incertain ? Un “forfait” dont tu ne connais pas les intervenants, peut-être même que tu ne connais ni leurs visages, ni leurs noms, à ces gens qui vont travailler sur ton projet. Même si il y a de nombreux projets au forfait qui fonctionnent bien, les projets importants, stratégiques, tu les soignes, tu ne les confies pas à des inconnus. Tu souhaites être proche de leur réalisation.

Le forfait est historiquement un crime commis avec audace…

(more…)

This entry was written by pablo, posted on March 18, 2011 at 3:53 pm, filed under gestion projet, méthodes agiles and tagged agile, contrat, forfait, régie. Leave a comment or view the discussion at the permalink.

Management agile : le modèle Tannenbaum & Schmidt

En étoffant un de mes supports de cours je suis tombé par hasard (il faut le dire) sur le “Modèle de délégation et de développement d’équipe” de Tannenbaum & Schmidt chez Business Balls (nom évocateur au demeurant).

On fait souvent allusion lorsque l’on traite des questions d’équipes et de management avec l’agile du modèle de Tuckman concernant l’évolution de l’équipe. En quelques mots trop courts :

forming : l’équipe se forme, elle se découvre

storming : l’équipe se structure avec douleur, compétition, rivalité, etc.

norming : l’équipe s’est calibrée, elle sait comment travailler ensemble pour atteindre un objectif commun. (Ce stade n’est pas forcément atteint un jour…)

performing : La capacité de l’équipe est supérieure à la somme des capacités des individus qui la constitue. L’équipe excelle. (Celui-là non plus…)

Oui c’est vrai, on le vit tous les jours, et c’est très intéressant et cela concerne le développement de l’équipe en elle-même. Ce  modèle de délégation et de développement d’équipe de Tannenbaum & Schmidt que je découvre aujourd’hui complète cette approche du développement d’une équipe agile notamment dans sa relation -extrêmement importante- avec le management. Qu’est ce que ce modèle nous dit ? Comme l’indique l’image en haut à gauche : que plus l’équipe à d’autonomie et de liberté, et plus le manager laisse l’équipe s’émanciper, plus celle-ci peut donner des résultats remarquables (à évoquer aussi peut-être dans sa relation avec le product owner).

Tannenbaum & Schmidt décrivent 7 stades (je vous invite à vous reporter à l’article en lien ici pour avoir plus de détails) :

1. Le manager décide et annonce la décision

2. Le manager décide et “vend” la décision au groupe

3. Le manager présente la décision avec des idées générales et invite à la réflexion

4. Le manager suggère une décision et invite à la réflexion

5. Le manager présente la situation, écoute les suggestions et décide

6. Le manager présente la situation, défini les contraintes et demande à l’équipe de décider

7. Le manager permet à l’équipe d’identifier le problème, développer les options, décider de la solution. Le manager est informé des contraintes par l’équipe.

En alliant les deux on a vraiment une visibilité sur la cible des équipes agiles. Je me permets un petit diagramme et vous souhaite bonne continuation.

This entry was written by pablo, posted on December 20, 2010 at 3:52 pm, filed under gestion projet, management, méthodes agiles and tagged agile, schmidt, tannebaum, team, tuckman. Leave a comment or view the discussion at the permalink.