Récemment Jurgen Appelo a déclenché une initiative prometteuse : réunir, fédérer les agilistes européens. Je trouve cette action très intéressante. Surtout dans sa forme. Jurgen essaye de laisser le réseau faire émerger sa propre organisation tout en l’accompagnant (et pas en le guidant).

Je ne sais pas si il réussira. On sent de nombreuses tensions derrière (pas de sa part !), mais comme me l’a glissé Laurent B., l’agile devient “un secteur de l’économie du logiciel” (j’aime sa formule), et donc l’agile aiguise les appétits. Chaque initiative, chaque positionnement est observé avec suspicion. (Ah j’oubliais un postulat important : je suis paranoïaque). Jurgen évoque une grosse liste -beaucoup d’agilistes d’Europe-, une petite liste -les agilistes qui se positionnent pour les actions types conférences, etc.- et une mini-liste : les personnes clefs. Oups pardon, Jurgen précise bien que plus la liste est réduite moins elle est importante (en taille comme en valeur), donc il ne s’agit pas de personnes clefs, du moins pas comme on l’entend habituellement. Il faut faire l’effort de le croire sur parole, car d’instinct on imagine l’inverse:  que la mini liste dirige la petite qui dirige la grosse. Jurgen espère -et je l’espère aussi- que la mini liste encadrera la petite qui encadrera la grosse. Encadrer au lieu de diriger. Pas de prévalence.

Très récemment, Jurgen Appelo (Noop.nl) a lancé une réflexion sur un positionnement européen de l’agilité au travers d’une discussion sur LinkedIn.

Ses conclusions et la synthèse des commentaires a pris la forme d’un “post” sur son blog : Agile Europe, entrons en action. Je me propose de le traduire ci-dessous et je vous suggère à tous agilistes de France et de Navarre de prendre contact avec Jurgen. En français ou en anglais, car c’est la première chose que je me suis permis de remonter : le problème de la langue, particulièrement dans notre pays. Je suis sûr que nous avons plein d’agilistes de talents qui ne comprennent rien à la langue de Shakespeare. Cela serait dommage de perdre leur apport. A priori Jurgen Appelo a déjà bien conscience de cette difficulté, inhérente à notre condition européenne.*

Ci-joint le résultat d’une petite réflexion sur les carrières dans une entreprise ou un monde agile. A la remarque : “ok agile d’accord MAIS je suis chef de projet, j’ai été développeur 1, puis développeur 2, et je désirai devenir directeur de projets puis manager de BU… et naturellement ma rémunération est associée à mon poste…”, je n’ai pas de réponse miracle. La première chose serait -en France- de beaucoup mieux apprécier à leur juste valeur les cursus purement techniques, et ne pas considérer qu’une personne de 45 ou 50 ans souhaitant rester développeur est une abhération ! Un grand expert technique est une ressource inestimable qui se paye à sa juste valeur. Vouloir devenir un guru technique n’est pas une maladie mentale.

Ceci est un article de Jenea Hayes sur Cooper que j’ai beaucoup apprécié et que j’ai souhaité faire partager aux non anglophones.Merci Thomas de m’avoir mis sur la piste de cet article.

Jenea a écrit :

Considérations sur l’expertise

Vous n’êtes pas un expert

Vous rappelez-vous la première fois que vous avez essayé de conduire une voiture ? C’est une expérience exaltante et terrifiante que de tenter de coordonner plusieurs parties de son corps !  Et pendant que notre attention est focalisée sur cet effort de coordination, difficile de ne pas s’écraser sur quelque chose et de garder le contrôle du véhicule !

En voyant Mammuth, film pittoresque qui voit Depardieu en motard débonnaire partir à la recherche de ses justificatifs de travail pour toucher sa retraite à taux plein, je suis tombé sur une séquence de mise en oeuvre des 5 pourquoi. Du “Root Cause Analysis” entre Depardieu & Siné !

Je rebondis sur l’occasion pour évoquer cette méthode que j’encourage chacun à pratiquer régulièrement.

Tout le monde évoque toujours (ou presque toujours) le même exemple en citant cette méthode : celle du Washington Monument (et encore, le monument en question change souvent !) : L’obstacle n’est pas toujours celui que l’on croit : en se demandant 5 fois “pourquoi ?” (ou 4, ou 6, mais 5 est généralement significatif) on obtient souvent une réponse bien plus pertinente que la réponse envisagée de prime abord.

Je débute l’année par un coup de gueule contre certaines formations agiles. Je ne les citerai pas car je me permets ce coup de gueule sans avoir participé à l’une d’elles, sans connaitre les formateurs, ni la société qui les parraine (prenez donc ce coup de gueule avec les pincettes qui vont plairont). Je me permets ce coup de gueule en raison des feedback réguliers que j’obtiens des stagiaires qui y participent depuis la fin d’année 2010. Coup de gueule contre des formations où les gens sortent avec plus de troubles et de questions qu’avec une vraie réflexion ou un vrai apprentissage, et surtout le sentiment d’avoir un peu été mené en bateau (quand on plus on sait qu’il s’agit de formations certifiantes, chères, et que l’on connaît la valeur de la certification …. délivrée automatiquement en fin de session…). Coup de gueule contre les formateurs qui planent et qui répondent sans aucun sens commun, sans aucune mise en situation, qui trônent dans leurs éthers.

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