Dans une session old time, une “tune” (un titre) dure entre 10 et 20mn…c’est long. Cette musique est en plus très répétitive (sorte de trance). Mais du coup on apprend le morceau pendant que les autres le jouent. C’est une montée en compétence par la pratique au sein du groupe (on avoisine entre 6 et 20 personnes dans une session, voire plus…). Si on ne connait pas un morceau, les 5 premières minutes on va écouter. Les 5 minutes suivantes on essaye de jouer les bases du morceau. Avec un peu de talent on peut commencer à enrichir notre prestation les minutes suivantes. A la fin du morceau, on le connait, et on est prêt à le transmettre à d’autres un autre jour. On est proche de l’idée de compagnonnage (“ réseau de transmission des savoirs et des identités par le métier “, même si ce nom peut en braquer certains) portée par craftsmanship ou XP. En tous cas ces groupement de personnes qui mèlent apprentissage et plaisir qu’il s’agisse d’une session old time ou d’un code retreat me semblent très proche (et il doit y avoir de nombreux autres exemples…mais bon mon dada moi c’est le old time…).

les sessions old time se pratiquent depuis le XVIIIème siècle.

Voyons donc si nos règles (de “old timey”) pour les sessions pourraient vous inspirer pour vos code retreat (je ne code pas assez pour m’inclure):

(il y a de nombreuses règles de sessions old time mais elles se ressemblent toutes plus ou moins, je me suis donc basé sur celles -10- du site “old time seattle”).

1. Tout le monde, peut importe sa compétence musicale, est invité et encouragé à rejoindre le cercle de la session, mais s’il vous plait essayez de vous entrainer et d’avoir pratiquer avant. (“Every one, regardless of musical ability, is invited and encouraged to join the jam circle, but please try to come practiced & prepared”).
2. Gardez un oeil ouvert (pour voir les nouveaux entrants ou faire de la place pour), laissez de la place que les nouveaux entrants se sentent à l’aise pour entrer dans le cercle à n’importe quel moment. (“Keep your eye out – make room for new players so they can enter the circle at any time and feel welcome to do so”).
3. Un instrument est trop présent ? Laissez votre place durant quelques morceaux et proposez à un quelqu’un autour du cercle de venir prendre votre place (il est aussi possible de faire un deuxième cercle, à valider avec le meneur de la session).(“Too many of the same instruments? Take turns by leaving the circle after playing a few tunes and encourage a sideliner to take your place. Sometimes it’s possible to make a second circle, check with the jam leader”.)
4. Si vous n’êtes pas familié avec un morceau. Ne jouez pas, mais écoutez le quelques minutes puis commencez doucement à le jouer jusqu’à que vous vous sentiez à l’aise. (“If you are unfamiliar with a tune, DON’T PLAY AND JUST LISTEN a few times through, then play along quietly until your sure you’ve got it”).
5. Faites attention à votre volume, soyez sur que la personne qui mène le morceau est entendue par tous. De même si vous menez un morceau soyez sur que chacun vous entende. (“Pay attention to your volume, make certain the person leading the tune can be heard by everyone. Likewise, if you are leading a tune, try to play loudly”).
6. Soyez sûr d’être bien accordé. Utilisez un accordeur électronique si besoin et vérifiez fréquemment. (“Make sure you’re in tune. Use an electronic tuner & check yourself frequently”).
7. Quand vous menez un morceau annoncez la tonalité au préalable. Et annoncez la grille si le morceau est méconnu. Si le joueur à vos côtés ne connait pas le morceau prenez le temps de le renseigner tranquillement (“When leading a tune, announce the key before starting each tune or song. And announce the chords if the tune is more obscure. If a the player next to you does not know the chords and you do: offer to tell them quietly”).
8. Les sessions sont une grande expérience d’apprentissage mais ne sont pas des leçons gratuites. Si vous avez besoin de beaucoup d’informations n’hésitez pas à demander à la ronde si quelqu’un donne des cours privés ou demandez quels disques écouter pour progresser. (“Jams are a great learning experience, but are not meant to be freebie music lessons. If you’re looking for a lot of pointers, feel free to ask around to find others that offer private lessons, or ask for recommended recordings to listen to at home”).
9. Concernant les danseurs : ils sont encouragés à rejoindre la session. Merci cependant d’aider les musiciens en attendant que le morceau joué est assez en place pour lancer la danse. Merci aussi de vous coordonner entre vous afin d’éviter trop de danseurs (ce qui génère une cacophonie terrible). (“Dancer etiquette: Step-dancers are encouraged to come to jams! Please help out the musicians by waiting to dance until the tune is played a few times through the form and is being well-grasped by the majority of the musicians. Also, coordinate taking turns if there are multiple dancers, as too many feet gets awfully cacophonic (you can take turns on the same tune).”)”
10. Si la session se déroule au boulot, faites en un évènement ludique ! Achetez des boissons ou des encas !, invitez vos amis à venir écouter, essayez d’être bon : meilleure sera la session le plus de personnes reviendront et nous aurons de plus en plus de support à ce que nous faisons. (“If the jam is at a business, keep the business happy! Buy a beverage/snack & tip the staff (alcoholic-free drinks are available at bars if you don’t drink alcohol), invite your friends to come listen, & try to play your best as the better the jam sound the more people will listen and gain an interest and support what you’re doing!”)

L’idée derrière ces fortunes est de donner aux équipes des éléments de réflexion pour les aider à la réussite de leurs projets (qu’ils soient agiles, classiques, ou autre).

Vous trouverez donc ici :

http://www.areyouagile.com/wp-content/uploads/2011/11/areyouagile_fortune_0_3.pdf

Les fortunes et une proposition de mode opératoire, mais sur ce dernier point je fais surtout appel à votre imagination, et je serai friand de vos retours.

ps : l’image du “make love, not bugs” vient de là.

En effet le “chef de projet” est mis à mal par l’organisation agile. A des gens a qui on n’a pas cessé de demander d’être (un peu) bon sur 3 domaines à la fois : en management, sur les aspects fonctionnels, et sur les aspects techniques, on demande soudain de choisir entre l’un des 3 domaines (management, soit le scrummaster, aspect fonctionnel soit le product owner, aspect technique soit l’un des membres de l’équipe). Drame.

Il faut comprendre que le fait d’être “chef de projet” est souvent un cheminement de longue haleine. Beaucoup de chefs de projet sont des gens avec pas mal d’ancienneté qu’il a fallu récompenser. Et délivrer le statut de chef de projet est aussi une façon de mieux rémunérer certaines personnes. Une abhérration qui fait que certaines personnes qui raffolent de la technique sont devenus bon gré mal gré chef de projet pour enfin pouvoir franchir des échelons (c-a-d augmenter son salaire). Le mieux aurait été d’avoir un cursus technique digne de ce nom (j’y reviens).

Petite parenthèse : c’est normal de vouloir être récompensé, c’est normal de vouloir gagner plus d’argent.

Et donc le drame agile c’est que l’on va dire à ces personnes : soit tu actes définitivement que tu souhaites manager et tu deviens scrummaster (mais fini le code, les estimations, etc.), soit tu valides que la technique est ton dada et tu réintègres l’équipe. Aïe. Là tout le monde râle. L’ex chef de projet qui a l’impression de “rentrer dans le rang” (et comment va-t-il négocier son salaire, ses augmentations, son rang ! etc.) et l’équipe : pourquoi lui serait-il plus payé que nous ? Le troisième cas de figure : le “chef de projet” devient product owner est plus rare car le rôle de product owner est souvent attribué (bonnes ou mauvaises raisons) a des gens hiérarchiquement plus gradé que le “chef de projet”.

Si le “chef de projet” souhaitait s’orienter vers le fonctionnel et qu’il devient product owner, les choses se déroulent généralement bien.

Si le “chef de projet” souhaitait s’orienter vers le management et qu’il devient scrummaster, les choses se déroulent généralement bien.

Dans tous les autres cas des tensions et des difficultés apparaissent.

Pour palier à ces difficultés l’une des principales solutions que je préconise : acter de la réelle existence d’une carrière technique senior bien rémunérée au sein de la société. Cette voie manque cruellement dans les entreprises françaises. On doit pouvoir faire partie d’une équipe tout en se prévalant d’un échelon de carrière élévé et technique, et donc bien rémunéré. Les gens intéressés par la technique doivent pouvoir faire une vraie carrière dans cette branche. Ne pas hésiter au niveau RH (et donc concernant la rémunération) de mettre en avant des profils senior, expert, technical lead, etc. qui permette un avancement “de profil” (avec salaire en adéquation) et pas nécessairement un avancement hiérarchique.

Car quoi qu’il en soit nos hiérarchies sont assez plâtes et si vous souhaitez progresser encore après avoir été “chef de projet” quelles sont les solutions qui s’offrent à vous ? Disons pour les SSII : Directeur de projets, puis directeur d’agences, etc. Ou pour les éditeurs : Directeur technique, puis.. Beaucoup de candidats, peu de postes. Pas de secret là dessus soit vous êtes la bonne personne, soit il faudra changer de boite pour gravir les échelons plus vite, ou gravir les échelons tout simplement.  Agile ne parle pas de cela, car il n’a rien de plus à promettre à ce sujet (si ce n’est un véritable épanouissement au sein d’une équipe, ou d’un groupe de personnes, ce n’est pas rien finalement).

Les RH m’ont confirmés que effectivement un chef de projet pouvait démissionner et se pourvoir aux prud’hommes pour gagner, car le fait de changer ainsi sa “feuille de route” était une raison valable de rupture de contrat.

Rassurez vous aucun des chefs de projet n’a démissionné et ils apprécient les nouvelles conditions de travail.

Bon sang que ce billet a du mal à sortir. Il a été démarré en février 2011, repris en août. Et je sèche j’ai juste l’impression d’écrire un truc totalement inutile. Mais j’ai besoin d’exprimer ces idées, et je ne sais pas comment cela sera compris. “Tout le monde s’en fout pablo crache ton truc”. ah ok voilà qui me rassure. allons-y donc.

Passe ton cycle en V d’abord

Pour encadrer des équipes agiles ou faire du coaching il faut de l’expérience (oui j’ai décidé d’enfoncer des portes ouvertes).

Et mon avis est que l’on est probablement plus efficace en agile si on a une expérience du projet classique, ou disons celui qu’on appelle en V (peut-être à tord : voir les billets de Claude là et là), car celui-ci constitue un socle non négligeable en terme d’expérience (dans tous les points de vue).

On est bien plus à même de comprendre certaines orientations de l’agile en ayant un retour d’expérience sur des projets “traditionnels”. Nous percevons mieux la différence entre ces deux façons de faire et donc les choix opérés par l’agile. N’oublions pas que ce mouvement a été lancé en réponse à la façon de faire des projets classiques, le manifeste agile veut montrer “comment mieux développer des projets”. Notre compréhension de l’agile est meilleure car nous en percevons mieux les fondements et les raisons en ayant connu son point de référence (ce à partir de quoi il se positionne): le projet dit classique, en V, en cascade, etc. Comme le fait un mouvement musical, artistique, etc.

Mais est-ce suffisant pour dire qu’il faut avoir passé son cycle en V d’abord avant d’entamer l’agile ? Que les gens qui n’ont jamais connu les projets “classiques” sont handicapés pour faire de l’agile ? Finalement je doute sérieusement de la validité de mon raisonnement. Ne serait-ce pas là une réaction de mon système immunitaire de consultant (vieux ? j’ai eu 40 ans en juin) face à cette marée dépareillée de jeunes loups ? Toutes ces personnes qui feront de l’agile sans avoir connu d’autres alternatives ne vont-ils pas garder une spontanéité rafraîchissante ? Pas de “mémoire du muscle” qui se rappellera à eux (“merde merde je suis en train d’être trop directif et d’étouffer ces gars”). Oui d’accord ils n’auront pas de référence, ni d’expérience, mais peut-être que cela va leur laisser une liberté d’action que nous n’avons peut-être plus ?

Oui oui et oui …mais aussi non :  je parle d’encadrement, d’accompagnement, de coaching.  Pour ces rôles la spontanéité etc. sont des qualités plus dangereuses qu’il faut savoir maîtriser. Donc oui pour participer à des projets agiles, mais je suis beaucoup plus mitigé pour les encadrer et les accompagner. Et en fait je ne fais donc effectivement qu’enfoncer des portes ouvertes : c’est un plus si on a de l’expérience pour accompagner ou encadrer des projets agiles. Cette expérience est peut-être encore plus utile si il s’agit d’avoir réalisé dans le passé des projets classiques.

Je rebondis sur un autre débat qui va me ramener à la même source :

Ah mes amis l’agile n’est plus ce qu’il était !

Bon ben mon avis là dessus c’est qu’il ne faut pas trop être critique. Ce succès est un succès. Ah cette honte : c’est devenue la mode, beurk. Nous sommes plus l’élite underground, gasp ! Vous ne voulez tout de même pas que l’agile reste une chose isolée et connue d’un seul groupe d’élus ? (C’est presque ce qu’a sous-entendu Marick lors de sa keynote à XP2011 Madrid, et donc même si son discours se voulait anarchiste, sur ce point c’était très conservateur à mon avis, enfin c’était ma compréhension de sa keynote).

Naturellement les choses évoluent et l’agile ne fait pas exception à la règle (cf par exemple la nouvelle version du scrum book, -que je n’ai pas encore lu-). De part son succès il est confronté a beaucoup plus de choses et il doit y faire face. Oui.

Et oui il doit garder son identité naturellement (mais ne pas s’enfermer).

Et oui il y a des dérives, des tentatives de récupération etc etc il faut être vigilant. Mais de là à crier aussi fort au loup, je ne sais pas.

Pourquoi autant de craintes ? Probablement car le “ticket d’entrée” de l’agile est très bas. C’est sa force et sa faiblesse. Lisez un ou deux ouvrages, emparez vous de quatre grandes valeurs, et vous voilà le maître de la mêlée ! Et ça oui c’est très dangereux. Beaucoup d’apprentis sorciers probablement. Et donc, c’est aussi plein de gens très volontaires et optimistes qui souhaitent apprendre et aider. Parmi ces gens il y aura des gens très doués qui font faire des merveilles très rapidement. Ils sont cependant une minorité il ne faut pas se raconter des histoires.

Donc je retourne à mon idée première : la force de l’agile est la facilité son apprentissage par son approche “compacte” (pas la peine de lire Guerre & Paix) mais il faut compenser ce revers de la médaille en plaçant des gens expérimentés aux postes clefs : accompagnement, encadrement, évangélisation, etc.

So, are you experienced?
Have you ever been experienced?
Well, I have

Let me prove you…

Si vous déployez l’agile au sein d’une entité vous savez que la conduite du changement, la réussite du changement, est un facteur clef. Nulle pérénnité pour votre action agile si le changement n’est pas global. Le vrai challenge est donc de provoquer un changement durable.Une des techniques est ainsi de déséquilibrer les habitudes en place. Ce déséquilibre produit une force dont on se sert pour provoquer le changement. Il faut que le déséquilibre soit assez fort pour éviter de revenir dans le positionnement initial. Il ne faut pas que le déséquilibre soit trop violent, au risque d’être rejeté (et vous avec).

C’est K. Levin qui a réalisé des études au milieu du XXème siècle à ce sujet nous disent Anzieu & Martin dans Dynamique des groupes restreints. Les recherches de Levin expliquent que le changement (social). Levin évoque une marge de voisinage : c’est à dire un espace dans lequelles des forces modifient le groupe, la société, mais sans provoquer un changement : une marge de fluctuation. Pour introduire le changement il faut introduire une force opposée supérieur à la résistance initiale (dont le but est de ramener l’équilibre au niveau antérieur), qui fasse franchir cette marge de voisinage. Levin explique : “En décristallisant peu à peu les habitudes par des méthodes de discussion non directives, jusqu’au point de rupture, de choc, ou une recristallisation différente peut s’opérer“.

En 1943 Levin mène une expérience pour essayer de convaincre plusieurs groupes de personnes à changer leurs habitudes alimentaires (à manger des abats). Il utilise plusieurs moyens pour essayer d’opérer le changement. Premier enseignement : la méthode qui fonctionne le mieux est celle où l’implication des acteurs est la plus élévée (celle où des discussions entre les acteurs sont nécessaires) et où les acteurs sont libres de leur décision. les acteurs doivent se convaincre eux-mêmes ou sont convaincus par des pairs. Deuxième enseignement : la prise de décision en groupe amène plus à l’action qu’une prise de décision individuelle. Il faut donc changer des groupes et pas des personnes.

Je reviens sur les étapes évoquées par Levin sur la conduite du changement : décristallisation, changement, cristallisation. Sans surprise la phase de déséquilibre apporte avec elle une tension. Deux forces entre en conflit : la résistance au changement et le déséquilibre. Comprenez donc que souvent cette tension est nécessaire, mais qu’il ne faut pas la faire rompre.

Petit aparthé et de façon très grossière : Bergson, Kant, Freud ou autre estiment que le rire provient d’un déséquilibre dans nos forces internes. On s’attend à quelque chose et soudain autre chose se produit : un homme digne marche, mais il glisse sur une peau de banane. Dans ce cas plus la variation entre la dignité et le ridicule de la chute est grande, plus la force nouvellement disponible le sera, le rire provient de ce surplus de force, d’énergie. Autre exemple : on s’attend à quelque chose et surprise autre chose arrive : cet écart génère une énergie qui peut se déverser dans le rire (selon les situations). C’est souvent le cas de l’absurde comique (Monty Python, Marx Brothers, WC Fields ou autre, etc.), on s’attend à quelque chose et quelque chose de très différent arrive (un ministère des démarches stupides par exemple : la distance entre l’idée d’un ministère “normal” et l’idée d’un dédié aux démarches stupides : voilà un écart, un gap, un espace). De cet espace néé une énergie qui se dissipe en rire.

Dans mon cas j’essaye d’utiliser cette théorie ou conception dans mon travail, je dois générer ce déséquilibre, cet écart entre une réalité, et celle vers laquelle on doit tendre. La mise en évidence de l’absurde des situations m’aide : il faut rendre visible ce gap aux yeux de tous car comme exprimé plus haut : ce n’est pas moi qui vais convaincre, mais les acteurs qui vont se convaincre (ou pas). Enfin si en plus je peux utiliser ce déséquilibre pour rendre les choses comiques cela me permet de faire tomber cette tension lié à la conduite du changement évoqué plus haut. J’ai bu du petit lait lors de cette discussion avec l’un de mes clients : l’un de ses projets n’avançait pas du tout. Je viens aux nouvelles :

- Le burndown indique que le projet fait du surplace depuis un bon moment, que se passe-t-il ?

- Nous avons de nombreuses autres priorités, et ce projet est la dernière de nos priorités.

- C’est tout à fait recevable, le mieux ne serait-il pas de suspendre ce projet le temps que les choses prioritaires soient achevées ?

- Ah non, il est impensable de ne pas travailler sur ce projet !

Cela m’amène à une deuxième discussion lancée par Oana J. Faut-il des coach agiles “héros”, “bulldozer” (on m’a dit ça un jour…), dans un mode très consultant, ou des coach agiles “fée” (faerie) ou “djinn” (si fée porte atteinte à votre masculinité), sous entendu qui murmurent à l’oreille des gens et laissent bourgeonner leurs idées pour qu’elles réapparaissent comme par magie (d’où les fées). On se rêve tous “djinn,fée”, mais dans la réalité on est souvent “héros” : le temps, les délais, et aussi souvent notre nature propre nous y contraignent.

Pour résumer : un déséquilibre pour apporter le changement. Attention ce déséquilibre va apporter son lot de tensions, elles peuvent être amoindries par un effet comique (je dis cela sans rire). C’est un groupe que vous allez changer, pas des individus. Le changement aura lieu si le groupe se convainc lui même ou est convaincu par ses pairs. A vous d’amener cette réflexion, là encore la mise à nu de l’absurde d’une situation, de l’écart amené par le changement, est un moyen de sensibiliser les acteurs, de générer, d’initier cette force vers le changement.
Soit votre montre est arrêtée soit cet article est fini*.

* adaptation d’une phrase de Groucho Marx dans A Day At The Race, je m’essaye au non-sens…

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.

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.

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…

Bref tu as la sage intention de réaliser tes projets stratégiques à la maison, prêt de toi, avec des gens que tu connais, en un mot : en régie.

La régie est historiquement une administration de bien (comprendre de valeurs ?)

Mais la régie t’inquiète. Tu associes cela à une sorte de mission sans fin, sans but, à un bataillon de prestataires qui viennent épauler ton “middle-management” (Est-ce la régie qui l’a rendue apathique ?, ou lui en étant apathique qui a déclenchée la régie ? Est-il réellement apathique, ou le contraints-tu à ne pas pouvoir être dynamique ? Cela pourrait être une autre question). Et parfois tu n’as pas tort.

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

L’agile va te permettre en axant son action sur la production de valeur à intervalles réguliers et rythmés de te donner rapidement de la visibilité, des certitudes, des acquis. L’agile va te proposer une cadence claire qui te donnera une réelle prédictibilité sur la suite de ta réalisation. Si le projet va dans le mur ? Eh bien tu vas t’en rendre compte rapidement et économiser les longs mois inutiles qui auraient servis à masquer cet état de fait.

- Oui mais avec la régie, me dis-tu, le projet ne finira jamais.

- Au contraire, en produisant ce qui a le plus de valeur au début, tu vas pouvoir arrêter celui-ci plus tôt.

- Alors tu me dis que tu ne sais pas ce que cela va te coûter ! (si tu n’as pas de budget défini)

- Et tu as raison ! Mais le contrat agile devrait te permettre d’avoir le mieux possible pour le budget investi, le meilleur rapport valeur/prix.

- Avec le forfait j’ai des certitudes !

- Hum… est-ce vraiment le cas ?

PS : autant sur la forme que sur le fond Yassine me balance que je suis à côté de la plaque sur ce coup.! gasp, il va me falloir m’interroger encore.

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.

Je suis en train de penser à un billet qui s’intitulerait “passe ton cycle en V d’abord” et qui souhaiterait mettre en évidence l’intérêt (l’importance ?) d’avoir pratiqué d’autres formes de gestion de projet pour mieux appréhender la gestion agile. Je repense à une pétition sur le web, signée il y a quelques temps, un très juste rappel de Alistair Cockburn : le serment de non allégeance.

http://alistair.cockburn.us/Oath+of+Non-Allegiance

Je promet de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.

A méditer et mettre en pratique.