« Le développement agile de produit est devenu la norme dans de nombreuses industries.

Cela signifie que les produits sont développés par des équipes réduites, auto-organisées, transverses, livrés en petits incréments et améliorés constamment en fonction des feedbacks de vrais utilisateurs.

C’est-à-dire, en gros, selon ce qui est décrit dans le [manifeste agile]((http://agilemanifesto.org/iso/fr/) – mais en remplaçant “logiciel” par “produit” (parce que cela n’est pas vraiment spécifique au domaine du logiciel).

C’est une très bonne chose en soi.

Toutefois lorsque les choses deviennent plus importantes, avec des douzaines d’équipes collaborant au-delà des frontières organisationnelles, les choses devient évidemment plus complexes et plus douloureuses.

Même si la totalité de l’organisation est correctement structurée en équipes scrums, vous pouvez quand même vous retrouvez dans un bordel innommable !.

Comme le montre cette image qui pourrait vous sembler familière :

Avant d’essayer de “gérer” cette complexité, demandez-vous d’avord “est-ce qu’il est vraiment nécessaire que cela soit aussi gros et aussi compliqué ?”.

Peut-être que vous êtes en train d’essayer d’accoucher d’un éléphant entier d’un seul coup d’un seul.

Peut-être que vos équipes sont organisées par fonction, créant du même coup beaucoup de dépendances.

Peut-être que votre architecture est-elle trop rigide, trop fragile, ou trop couplée.

Par conséquent, commencez par simplifier les choses.

Un sage a dit “Ne faites pas escalader pas l’agilité – désescaladez votre organisation”.

Peut-être pouvez-vous réorganisez une ou deux équipes pour avoir uniquement le bon équilibre de compétences, co-localisées et 100% concentrées sur le contact direct avec le client et 100% concentrées avec le client.

Elles peuvent être tout à fait capables d’élaborer le même produit (ou même un meilleur) en la moitié moins de temps et pour la moitié moins de budget !

Ne tombez pas dans le piège de croire que plus de monde = mieux.

Dans certains cas, avoir plus de monde pourrait être mieux mais la seule chose dont vous pouvez être certain à ce sujet est que plus de monde = plus de budget et plus de complexité.

Les bénéfices potentiels sont uniquement des bénéfices potentiels !.

Mais d’accord.

Quelques fois vous avez vraiment besoin d’avoir beaucoup d’équipes et de départements et de commerciaux pour collaborer sur quelque chose de gros et de complexe.

Disons simplement que c’est le cas.

Je vais être gentil et vous donner le bénéfice du doute.

Si c’est le cas, vous aurez besoin probablement d’un leader !

Quelqu’un qui se focalisera complètement sur la coordination des différentes équipes, s’assurant que les différentes parties restent synchrones, et qui gardera un oeil sur la vision d’ensemble.

Et c’est justement le sujet de cet article.

L’agilité repose sur l’auto-organisation, qui est super-efficace (lorsqu’elle est bien faite).

Mais avec plus que quelques équipes à gérer, l’auto-organisation a besoin d’une main secourable – quelqu’un pour créer et maintenir un environnement permettant tout d’abord la mise en place de l’auto-organisation – des choses comme avoir un objectif clair, un circuit court de feedback, des canaux de communication efficaces, etc.

Il s’agit essentiellement de faire “1+1=3” (grâce aux synergies) à la place de faire “1+1=1,5” (à cause d’un mauvais alignement).

Appelons-le un leader agile. Et son job principal est de créer de l’alignement !

Au niveau de l’équipe, les méthodes agiles incluent déjà des rôles de leadership tels que le Product Owner et le Scrum Master.

Mais au niveau de plusieurs équipes, il n’y a pas aucun rôle formel de leader unique désigné.

Notamment parce que des efforts moindres ne nécessitent pas généralement de leader designé – le succès de Scrum nous a montré qu’un leadership efficace peut se produire sans avoir un leader unique désigné.

Toutefois, plus il y a de personnes impliquées, plus il est probable que vous ayez besoin d’un leader dédié, une personne à plein temps qui se focalise seulement là-dessus – peu importe que l’effort des multiples équipes se fasse dans un “projet”, un “programme”, un “pari”, un “produit” ou quoi que ce soit.

Le leader ne doit pas nécessairement être une seule personne, cela peut être un binôme, ou une équipe soudée – aussi longtemps qu’ils collaborent étroitement et qu’ils parlent d’une seule voix.

Dans le cadre de cet article, je partirai du principe qu’il s’agit d’une seule personne.

Exemple : À Spotify, la plupart des initiatives moyennes à importantes sont conduites par un “trio TPD” – une équipe réduite dédiée au leadership, comprenant une personne de la Technique, une du Produit, et une du Design. De cette manière, chacun des trois points de vue est toujours pris en compte. Toutefois, pour de vastes efforts allant au-delà de la technique et du produit et du design, ce trio est insuffisant. Devrions-nous étendre le trio, ou devrions-nous avoir un rôle de leader supplémentaire ? Et comment devrions-nous appeler un tel rôle ? Nous continuons à expérimenter là-dessus.

Pensez au libellé “leader agile” comme d’une étiquette pour le rôle et ceci quelque soit le nom par lequel vous décidez de l’appeler.

Si cela dépend quelque peu de la manière dont vous organisez votre travail, choisissez n’importe quel titre qui convient à votre contexte – ingénieur en chef, scrum master suprême, ingénieur du train de livraison, pilote du chaos, responsable de la route, maître zen, coordinateur, conducteur, coach projet, catalyseur, ou quoi que ce soit.

Peu importe comment vous l’appelez, c’est une fonction critique et elle doit être présente pour tout effort complexe à caractère transverse impliquant plus que quelques équipes.

La/les personne(s) ayant ce rôle doit/doivent être motivée(s), dévouée(s) et compétente(s).

De manière intentionnel, je l’appelle leader agile dans le présent article.

Le mot “agile” est employé pour mettre en avant que le sujet de cet article porte sur le contexte de développement agile de produits, ce qui est très différent d’un contexte en cascade.

J’utilise le terme “leader” plutôt que manager parce que, eh bien, dans une organisation agile qui fonctionne bien, la plupart du “management” est prise en main par les équipes elle-même.

Par conséquent, le premier objectif de ce rôle est de donner du leadership, pas de faire du management.

Mais bien sûr, cette distinction n’est pas binaire.

L’objectif de cet article est d’esquisser l’image de ce qu’un grand leader agile fait, que vous puissiez par conséquent, trouver, faire grandir ou devenir cette personne — et soutenir les efforts de vos multiples équipes pour mieux réussir !

Il ne s’agit pas d’une définition formelle, il s’agit juste de mon point de vue dessus.

Alors, pour faire court : essayez de minimiser le besoin d’efforts importants, complexes avec plusieurs équipes.

Si vous ne pouvez pas faire autrement, soyez certain d’avoir sous la main un super leader agile !

Ne s’agit-il pas d’un chef de projet ?

Peut-être mais pas nécessairement.

Un “projet”, c’est seulement une des multiples manières d’organiser le travail, et qui se révèle souvent inappropriée pour le développement de produit.

Toutefois, si vous travaillez sous la forme de projet, et que les projets sont suffisamment importants et complexes et impliquent la synchronisation de plusieurs équipes et organisations, alors le leader agileest effectivement un leader agile de projet.

J’ai écris un article dédié à ce sujet et intitulé Qu’est-ce qu’un leader agile de projet ? comportant quelques sujets de discussions sur le modèle projet en général.

Mais pour la description réelle du rôle de leader agile en tant que tel, ce deuxième article re-pointe par ici.

Ne restez pas coincé dans la boucle 🙂

À nouveau, le choix de la manière d’appeler ce rôle est grandement contextuel. L’objectif de cet article est juste de clarifier quel type de leader vous aurez besoin pour le remplir d’une manière agile.

Que fait un leader agile ?

Utilisant le sport comme métaphore, mon collègue Babar de Spotify en donne un résumé séduisant :

  1. À quoi ressemble la victoire ? Vision / Mission
  2. Quel est le plan ? Stratégie et tactiques
  3. Quel est le score ? Progrès, statut, boucles de feedbacks
  4. Qu’est-ce qui nous empêche de gagner ? Amélioration continue, personnes, équipes, stratégie, tactiques

Savons-nous tous pourquoi nous sommes ici, à quoi ressemble la victoire ?

Connaissons-nous le plan, la stratégie ?

Avons-nous une manière de voir où nous en sommes maintenant ?

Voyons-nous les obstacles, les choses qui nous ralentissent ? Essayons-nous constamment d’enlever les obstacles ?

La réponse la plus probable est “non” à certaines de ces questions (autrement, félicitations, continuez ce bon boulot).

Donc, c’est ça le boulot de leader agile – faites tout ce qui est possible pour transformer cela en “oui”.

Cela ne garantit pas la réussite, mais cela en accroît certainement les chances.

Avec peu efforts grâce à l’utilisation de Scrum, ce travail est assuré par les rôles existants et par la collaboration ascendante et transverse.

En déployant beaucoup efforts, nous sommes confrontés à la discordance entre les équipes, et les choses tombent entre les mailles du filets des différentes parties de l’organisation.

Par conséquent, le leader agile se concentre beaucoup sur la communication et la création de la clarté.

Si toutes les personnes impliquées ont la vision de là où nous en sommes, là où nous allons, et pourquoi, alors nous aurons plus de chances à travailler ensemble pour aller dans cette direction.

Euh, soyez plus spécifique. Qu’est-ce qu’un leader agile fait vraiment ?

Qu’est ce que cela signifie donc en pratique ? Qu’est-ce qu’un leader agile fait vraiment ?

Je déteste dire cela, mais…. cela dépends ! Ça y est. Je l’ai dit.

Cela dépends du contexte, et de ce qui fonctionne bien aujourd’hui et de ce qui ne fonctionne pas.

Posez-vous continuellement la question : “Que doit-il se passer qui ne soit pas déjà produit ? Qu’est ce que je peux faire pour que cela se produise, sans que je devienne moi-même un goulot d’étranglement ?

Exemple : Vous remarquez que cette version n’est vraiment pas une sinécure, et que nous devons mieux coordonner la livraison de cette version entre les équipes. Au lieu de courir à droite et à gauche en essayant de coordonner cela vous même, vous remontez le problème avec certaines des équipes — vérifiez s’ils sont d’accord qu’il s’agit bien d’un problème, et discutez de comment le gérer. Ensemble vous décidez de mettre en place une réunion où les gens ayant des choses à livrer se synchronisent les uns avec les autres, et initiez un document commun mis à jour constamment où vous pouvez voir et modifier les livraisons à venir. Au début vous faites la facilitation de la réunion vous-même, mais après quelques temps elles deviennent auto-organisées. Vous encouragez les équipes à automatiser autant que possible la gestion des livraisons. Avec le temps, la réunion récurrente ne devient plus nécessaire, parce que les équipes se parlent entre elles directement et la coordination de livraison n’est plus un problème.

Bien que je ne puisse pas vous dire exactement ce qu’un leader agile devrait faire, je vais donner une liste d’exemple.

Pensez-y comme à différentes casquettes que vous pouvez porter en tant que leader.

Vous pourriez faire certaines de ces choses vous-même, mais pour la majeure partie vous devriez créer un contexte où ces choses sont faites sans votre implication.

NOTE : J’utilise le terme “s’assurer” ci-dessous.

De manière évidente un leader ne peut forcer ces choses à se produire, par conséquent dans ce contexte “s’assurer” = “faites tout ce que vous pouvez pour créer un contexte où cela peut se produire”.

En pratique, cela peut impliquer la facilitation, l’encouragement, l’argumentation, la mise au défi, l’organisation de réunions, la création de documents, la visualisation de choses, des conversations de couloirs informelles, etc.

Voici donc la liste. Prenez une profonde inspiration :

  • Vision / mission. S’assurer que le travail à faire a un objectif clair, des hypothèses claires, un périmètre clair (“ce que nous ne faisons PAS”) et des métriques de réussites claires basées sur les impacts métiers plutôt que sur les livraisons. S’assurer que c’est clair comme du cristal pour toutes les personnes impliquées, aussi bien les équipes que les clients et les autres parties prenantes.
  • Livraison itérative et incrémentale. S’assurer que le travail est scindé en sous-livraisons, pour permettre la livraison itérative et incrémentale plutôt qu’en big bang. Éviter les gros projets autant que possible, essayer à la place de scinder le travail en série de plusieurs petits projets lorsque cela est possible.
  • Planning adaptable. S’assurer que les plans sont crées et communiqués à toutes les personnes impliquées. S’assurer que les plans sont adaptable plutôt que prédictif, et mis à jour au fur et à mesure que nous apprenons. S’assurer que les jalons sont communiqués et les prévisions soient faites si nécessaire, et mis à jour sur la base de données empiriques au fur et à mesure que le travail avance. Soyez certain que toutes les contraintes (date ou périmètre) sont claires pour tout le monde.
  • Feedback. S’assurer d’un circuit court de feedback avec une étroite communication et fréquente entre les équipes et les clients. Planning collaboratif, démos, etc. S’assurer que les hypothèses et les présomptions sont testées sur le terrain et que l’apprentissage se produit constamment. S’assurer que le progrès est mesuré sur des livraisons réelles, du feedback et sur l’impact métier, pas sur la conformité à un plan.
  • Amélioration continu et partage de connaissances. S’assurer que l’apprentissage et l’amélioration ait lieu continuellement au fur et à mesure de l’avancée du travail (pas simplement à la fin), et que les apprentissages clés soient partagés dans les équipes ainsi qu’au-delà dans les différentes parties de l’organisation.
  • Focalisation et alignement. S’assurer que les participants focalisent leur attention et sont y dédiés (pas de multitâches), et alignés sur la même liste de priorités. Bousculer les silos. S’assurer que les gens focalisent leur attention sur la réalisation sur l’élément métier le plus important avec le minimum d’effort et de travail (travailler intelligemment est plus important que travailler dur).
  • Suppression des obstacles. S’assurer que le gâchis et les obstacles soient visualisés, priorisés et systématiquement supprimés. Encourager les équipes à prendre la responsabilité et de supprimer leur propres obstacles dès que possible. Collaborer avec les autres responsables et prenez la responsabilité des obstacles qui sont escaladés.
  • Habilitation à la prise de décision. S’assurer que les décisions sont prises en juste-à-temps et par les personnes qui ont la meilleure perception du dossier, et autant que possible de manière décentralisée. S’assurer que personne (y compris vous) ne devienne un goulot d’étranglement. Minimiser le nombre de décision que vous devez prendre.
  • Visualiser le statut et l’avancement. S’assurer que tout le monde puisse voir “la vision d’ensemble” — des tableaux de bords et ce genre de choses montrant où nous allons et pourquoi, où nous en sommes, les obstacles, etc. Laissez-les à grosses mailles, laissez-les détails aux équipes.
  • Flux. Optimisez le flux de valeur de bout en bout, pas l’utilisation de ressources. Cherchez les goulots d’étranglements et les queues, et appliquez la théorie des systèmes et les principes leanspour simplifier la livraison de la valeur métier.
  • Auto-organisation et autonomie. Rendez l’objectif et la situation actuelle claire afin que les personnes puissent penser et agir de manière autonome sans avoir besoin de leur dire quoi faire. Assurez-vous que les personnes aient des problèmes à résoudre plutôt que des tâches à exécuter. Mettez à profit l’intelligence collective du groupe plutôt que d’essayer d’être un super cerveau vous-même.
  • Recrutement et planning de capacité. Travailler avec les mangers pour s’assurer que les bonnes personnes et les bonnes équipes sont disponibles au bon moment pour maximiser la vélocité et les chances de succès.
  • Budgets et estimations. S’assurer que toutes les contraintes budgets et contractuelles soient connues et gérées. S’assurer que les estimations soient faites par l’équipe la plus proche du travail en cours, uniquement à grosses mailles, et ajustés si nécessaire. S’assurer que les estimations soient traitées comme des estimations, pas comme des promesses. Rendre les coûts transparents.
  • Dépendances. S’assurer que l’équipe et les contraintes transverses soient connues et gérées de manière efficace, et que les équipes ne soient pas bloquées en s’attendant les unes les autres.
  • Collaboration transverse. Utilisez des techniques comme la co-location et les canaux de communication transverses pour réduire les silos et la sous-optimisation.
  • Communication. Créez un environnement qui facilite une communication à large bande passante : en face-à-face ; et minimisez le besoin d’avoir des documents, des emails, et d’autres moyens de communications à faible bande passante inutiles. Les documents devraient être utilisés pour supporter la communication, pas pour la remplacer.
  • Échec rapide. Créez un contexte où de petits échecs peuvent se produire rapidement et souvent, réduisant ainsi le risque d’un gros échec à la fin.

Point spécial : Motivation. La motivation est l’élément clé pour tout effort créatif et complexe — bien plus important que les jours-hommes.

Des personnes motivées construisent de meilleures choses plus vite.

La différence peut être assez ahurissante !

Mais la motivation n’est pas un point particulier — vous ne pouvez pas simplement “motiver les personnes”.

À la place, les gens seront motivés intrinsèquement par des choses comme l’Autonomie, la Maîtrise, et l’Objectif.

Un bon principe de guidage est “Ne motivez pas les personnes — re-motivez les démotivés”.

Si les personnes vous voient supprimer les vrais obstacles et créer un environnement de confiance qui leur permet de travailler efficacement — cela les motivera probablement plus que des choses comme les chemises hawaïennes du vendredi, les boissons gratuites ou les tables de ping-pong.

Euh, c’est une loooongue liste ! Par où, est-ce que je commence ?

Distillez-la en une liste plus courte dans votre contexte !

Par exemple, rassemblez-vous avec quelques personnes, notez chaque item basé sur “quelle est son importance pour nous” et “comment se passe la journée de travail aujourd’hui ?”.

Puis réduisez la liste aux 5 choses les plus importantes et qui ne fonctionnent pas bien aujourd’hui.

Utilisez cela comme d’une base pour trouver le leader agile qui convient (ou pour prioriser votre travail, si vous êtes ce leader).

Qu’est-ce qu’il en est de la responsabilité ?

Est-ce que le leader agile est par conséquence le seul point de responsabilité ?

Est-il le seul à qui l’on peut tordre le cou en cas d’échec (quelque soit la définition d’“échec” …) ?

Non, certainement pas !

Toutes les personnes impliquées sont responsables. Mais les personnes devraient être responsables pour leurs comportements, pas pour les résultats.

Cela peut sembler fou au premier coup d’œil, mais pensez-y pendant un moment …

Un produit peut échouer à réussir en dépit des meilleurs efforts déployés par l’équipe — il peut échouer pour tout un tas de raisons, il peut échouer à cause de choses qui sont dehors du contrôle de l’équipe.

Et vice versa, un produit peut réussir en dépit des médiocres efforts de l’équipe et de ses leaders, il peut réussir par chance ou parce qu’il n’y a pas de concurrents.

C’est d’autant plus compliqué que l’échec ou le succès sont difficiles à définir de part l’existence d’une grande zone grise entre les deux.

Un leader agile devrait s’assurer que, lorsque les choses échouent, elles échouent rapidement !

Il fait cela en mettant en place un circuit de feedback rapide (livraison fréquente aux clients, apprentissage validé, etc).

Il s’assure que nous apprenons des échecs et que nous utilisons cet apprentissage pour le prochain produit, ou la prochaine itération de ce produit.

Si nous punissons l’échec, nous incitons les gens à cacher l’échec, et par conséquent minimiser l’apprentissage.

Si nous punissons l’échec, nous incitons les gens à éviter tous les risques, et par conséquent nous tuons l’innovation.

L’échec (et l’apprentissage associé), devrait être célébré, pas puni ! Jusqu’à une certaine limite, bien sûr.

Conservez le circuit de feedback court, afin que les échecs ne soient pas fatals …

Donc, même si le leader agile peut être présenté comme le “visage” du projet/programme/produit/quoi que ce soit d’autre vis-à-vis des parties prenantes, il n’est pas personnellement tenu comme responsable des succès ou des échecs.

Il est, toutefois, tenu responsable pour se comporter d’une manière qui maximise les chances de succès. Et cela s’applique à tous les participants, pas uniquement au leader agile.

Quelle genre de personne convient-elle pour ce rôle ?

Au minimum, le leader agile doit être (à mon avis) :

  1. Passionnée à propos du produit, des clients, des utilisateurs, et des impacts métiers
  2. Être enthousiasmé par le rôle de leader agile et volontaire pour s’y consacrer à 100%
  3. Adhérez à la majorité de ce qui est décrit pour le rôle ci-dessus, et vouloir grandir dans ce sens
  4. Avoir au moins quelque réelle expérience de leadership (dans n’importe quel contexte)
  5. Avoir au moins quelque réelle expérience avec les façons de travailler en agilité (dans n’importe quel contexte)
  6. Être volontaire pour obtenir de l’entrainement/du coaching/du mentoring dans les compétences qui sont à renforcer ou qui sont manquantes
  7. Être volontaire pour passer du temps à apprendre et à améliorer constamment ses compétences en tant que leader agile

Il n’existe pas évidemment pas de leader agile “parfait”, mais vous trouverez ci-dessous une “définition du génial”.

Je ne m’attends pas que quiconque puisse remplir tous ces points, mais le plus sera le mieux :o)

Dans un monde parfait :

  • Vous avez l’esprit d’entreprise et vous êtes passionné par faire en sorte que les personnes soient focalisés vers un objectif commun
  • Vous avez l’expérience de gérer d’importants efforts en transverse (ex des fonctions transverses tels que l’ingénierie, le marketing, la production, le juridique, et d’autres encore). Agile ou non. Certains des meilleurs leaders que j’ai pu voir viennent de gros projets ayant échoués — ils savent comment ne pas mener un projet
  • Vous êtes flexible et pragmatique sur les méthodes et les processus, et vous êtes capable d’utiliser votre jugement pour appliquer le modèle et l’approche qui ira le mieux par rapport au contexte
  • Vous avez une connaissance et une expérience approfondie de la pensée agile et lean, et quelque expérience avec des cadres de travail et des techniques concrètes tels que ScrumKanbanLean Startup et la livraison continue
  • Vous évitez clairement les projets en cascade, mais vous comprenez aussi que l’agilité ne signifie pas nécessairement pas de planning ni pas d’architecture
  • Vous savez comment donner un leadership fort et un guidage fort, sans devenir un goulot d’étranglement
  • Vous avez comment faire en sorte que les personnes soient inspirées et se rallient à un objectif plus grand
  • Vous comprenez que les personnes sont des personnes, pas simplement des ressources, et que cette consécration et cette motivation compte plus que des jours-hommes
  • Vous comprenez que les personnes sont plus motivées et plus efficaces lorsqu’un problème leur est soumis à solutionner, plutôt qu’une solution à implémenter
  • Vous savez comment faire en sorte que les personnes se parlent les unes aux autres entre les départements et au-delà des frontières organisationnelles. Vous n’êtes pas effrayé par les politiques
  • Vous savez comment permettre l’auto-organisation dans le cadre d’efforts globaux pluri-fonctionnels, et comment mettre en œuvre en pratique la réalisation de travaux planifiés en mode tiré
  • Vous savez comment rendre les choses importantes visibles
  • Vous avez le don pour repérer le superflu et le désigner
  • Vous comprenez que les plans sont importants, mais qu’ils sont un outil et non un objectif, et qu’ils doivent mis à jour au fur et à mesure que vous apprenez
  • Vous comprenez que l’incertitude est un fait de la vie lorsque l’on innove, et il est mieux géré avec un circuit court de feedback plutôt qu’avec un planning détaillé défini dès le début
  • Vous tenez les personnes responsables pour leur comportement plus que pour leurs résultats. Vous récompensez les personnes plutôt que les punissez pour leurs échecs.

En conclusion

J’espère que ce doc vous aidera à améliorer vos chances de succès dans vos importants efforts en transverse.

Mais n’oubliez pas — l’escalade est en dernier ressort.

L’escalade blesse peu importe comment vous la menez, gardez donc les choses aussi petites que possible (mais pas plus petites …).

De grands merci à Alistair Cockburn, Mary et Tom Poppendieck, Anders Haugeto, et à des tas de Spotifyers et de Crispers qui m’ont aidé à améliorer cet article.

Je suis honoré d’avoir un groupe de conseillers aussi géniaux !

Remarquez bien qu’il s’agit de mon avis personnel, ma vision de ce qu’est un leader agile (ou devrait être). Certaines personnes peuvent ne pas être d’accord, cela me va.

Je suis aussi heureux d’avoir du feedback, même si je n’aurai pas la même disponibilité pour y répondre.

Quelques lectures pour approfondir le sujet (il y a un nombre infini d’ouvrages sur le leadership agile, mais voici certaines choses que j’ai pu lire et apprécier) :

  • Becoming a Technical Leader (un livre étonnant et intemporel de Jerry Weinberg)
  • Management in Mayberry (le meilleur article sur le leadership que j’ai pu lire)
  • Lean-Agile leaders (tiré de SAFe)
  • Le manifeste agile (nouveau en agile ? d’un point de vue historique, commencez par ici)
  • La déclaration d’interdépendence (un manifest pour les leaders de project)
  • Agile Software Development – the cooperate game (un livre pour approfondir l’agilité par Alistair Cockburn)
  • Drive – the surprising truth about what motivates us (tous les leaders devraient voir cette vidéo !)
  • …. ou cherchez dans votre moteur de recherche préféré “Qu’est-ce qu’un leader agile” et vous trouverez un tas d’articles intéressantes, qui pour la plupart, diront la même chose qu’ici. Du coup, je me demande pourquoi je me décarcasse 🙂 »

Texte original de Henrik KNIBERG (What is an Agile Leader ?), publié le 10 Novembre 2015, traduit par Nicolas Mereaux le 15 Décembre 2015.

Publicités