20 attitudes agiles pour travailler en équipe et qui ne demandent aucun talent

20 attitudes agiles pour travailler en équipe et qui ne demandent aucun talent

Personne n’aime travailler avec quelqu’un qui a une mauvaise attitude.

NDLR : La plate-forme de publication de LinkedIn est... limitée. Voici l'original en format PDF. Aussi, les nombres en parenthèses réfèrent à des notes à la fin de ce texte. Désolé pour les hauts et les bas... Ce serait si simple d'implanter des ancres HTML...

Un gros MERCI à Isabelle Gagnon pour sa révision, ses nombreux aphorismes et ses mots choc donnés généreusement au fil des ans!


En 1999, j’ai essayé [et lamentablement échoué] (1) d’implanter une approche agile au gouvernement du Québec. #eXtremeProgramming

Depuis, j’ai travaillé sur des dizaines de projets où la mécanique y était (pratique, outils et processus) mais l’attitude n’y était pas du tout.

Le plus grand facteur de succès de l’approche agile est dans sa façon holistique de penser. C’est aussi là où l’approche est la plus fragile car, tel un tricot de laine, dès que l’on tire sur une maille – on utilise uniquement ce qui fait notre affaire – le chandail se défait et l'on se retrouve avec une belle grosse pelote de laine toute mélangée. #AgileEstFragile

Pour ceux qui utilisent une approche agile depuis longtemps, vous avez probablement intégré ses différents principes et valeurs : collaboration, satisfaction, transparence, adaptation, simplicité… Toutefois, lorsque l’on parle de ces valeurs à une équipe qui ne les connaît pas, ils répondent à l’unisson : « Je ne suis pas contre la vertu mais ça ne me dit rien sur comment je dois agir ».

Peu importe si vous travaillez formellement avec une approche agile, avec une [anti]méthode en cascade (2) ou sans formalité aucune, voici 20 attitudes agiles concrètes pour mieux travailler en équipe.

1. Communiquez immédiatement en cas de blocage, si petit soit-il

Les informaticiens ont la couenne dure et l’égo aussi. Trouver *la* solution à un problème fait partie de notre microcode. Et quand on est bloqué, on peut le rester longtemps. Parfois, la solution semble juste à notre portée. D’autres fois, elle est très loin et on se rabat sur nos vieux réflexes, quitte à aller tout droit dans un cul-de-sac. Pourtant, dans la cérémonie SCRUM des mêlées quotidiennes, une des questions à laquelle il faut répondre est : « quels sont les obstacles qui m’empêchent ou empêchent l’équipe d’atteindre le but du sprint? » Trop de développeurs se taisent au risque de passer pour quelqu’un qui ne connaît pas son métier. En réalité, même si vous risquez de passer pour l’incompétent ou le fatiguant de service, rester bloqué ne nuit pas seulement à vous mais empêche de livrer le produit donc nuit à toute votre équipe et à votre client (3) qui paie pour le développement de votre produit. Ça vous tente vraiment de faire des milliers d’heures supplémentaires et de ne plus voir vos enfants? [ou vos chats, c’est selon] Si tout le monde divulgue ses faiblesses, ça va devenir vite naturel. Mais il faut que quelqu'un commence...

Et pourquoi attendre à la mêlée du lendemain? Prenez vos pattes et sortez de votre bureau. Posez votre question immédiatement à votre voisin ou à quelqu’un de plus expérimenté. #PairThinking

2. Aidez inlassablement.

Évidemment, l’autre côté de la médaille est d’aider son coéquipier. N’oubliez pas que si une personne est mal prise, toute l’équipe est mal prise. Même si la question vous paraît idiote, prenez une grande respiration et répondez à la question, avec un sourire. Gardez en tête le corollaire de l’effet Dunning-Kruger : « une personne avec de grandes habiletés tend à sous-estimer sa compétence relative et présume, à tort, qu’une tâche qui est facile pour elle l’est facile pour les autres ».

Ce n’est pas tout le monde qui est tombé dedans quand il était petit. #Obélix

3. Partagez et communiquez toute décision promptement

Une décision, particulièrement celles qui ont la moindre chance de toucher l’équipe, un de ses membres ou le client, doit être partagée à la première occasion. C’est l’objectif principal (le seul objectif?) de la question des mêlées quotidiennes « Qu’est-ce que j’ai fait hier? ».

On répond trop littéralement à la question. Parce que dans une équipe qui s’autogère (4), cela devient vite lassant de ressasser les activités passées car on s’attend à ce que tous les membres de l’équipe fassent preuve de professionnalisme, c’est-à-dire avancer dans ses tâches qui sont, on l’espère, à la vue de tous. De toute façon, à la question « Qu’allez-vous faire aujourd’hui? », vous allez soit dire que vous passez à une autre tâche ou que vous continuez une tâche existante... jusqu’à ce qu’elle soit terminée. Et si la tâche est bloquée, vous allez l’annoncer à la dernière question « Quels sont mes obstacles? ». Pour que la question « Qu’est-ce que j’ai fait hier? » soit pertinente, il faut donc que je parle des choses qui impliquent mon équipe ou le client. Donc les décisions qui les touchent. CQFD!

#ÇaNeMIntéressePasDeSavoirCeQueTuAsFaitHierSiÇaNAPasDImpactSurMoiEtSurtoutSiTuFaisLaMemeChoseAujourdHui

4. Abattez [au lance-flamme] les silos liés à notre description de tâches

Depuis plusieurs années, on se surspécialise. Et on est tellllllllement confortable dans nos vieilles pantoufles (5)! 

J’ai trop vu de gens se rabattre sur leurs descriptions de tâches pour éviter de faire le travail ou pour éviter d’avoir l’impression de faire le travail de quelqu’un d’autre. Visez la polyvalence. Et si quelqu’un est frustré parce que vous avez fait votre travail en faisant le sien, dites-lui simplement : « on travaille tous dans le même but : livrer le meilleur produit à notre client ». Et vice-versa. #TasseToéMononcle

Qu’est-ce qui est mieux? Avoir des réunions à n’en plus finir (6) pour planifier et organiser? Présumer que quelqu’un va le faire à notre place ou attendre que le travail soit fait avant de faire le nôtre? #TomberEntreDeuxChaises

Aucune de ces réponses. Arrêter de demander la permission. Just do it [et demandez pardon]!

Vous avez la responsabilité, que dis-je, l’obligation de bien le faire cependant. Et que ça ne vous serve pas d’excuse pour ne pas livrer les choses pour lesquelles vous vous êtes engagés.

5. Écoutez, proposez, améliorez, acceptez, recommencez

Vous avez deux oreilles et une seule bouche… Écoutez [activement] deux fois plus que vous ne parlez.

Une fois que vous avez écouté attentivement, proposez sans avoir peur d’aller à contre-courant si vous avez quelque chose de pertinent (7) à dire. Parfois, on dit des absurdités. Ce n’est pas grave. #ÇaPrendQuelquUnPourCouvrirLeChampGauche

En contrepartie, écoutez toutes les propositions des autres, sans juger. Tous ensemble, l’idée de génie va émerger. #PairThinking^2

Quel est le risque? Que notre idée se fasse améliorer par celle d’un coéquipier? Que l’on améliore celle d’un autre coéquipier? Que notre idée soit carrément rejetée? Que l’on ait à recommencer?

Comme un de mes collègues me dit souvent, on n’envoie personne dans l’espace! Et même si on le faisait, n’est-ce pas mieux, encore une fois, de livrer le meilleur produit possible à notre client pour qu’il ne meure pas de froid en chemin vers la Lune? #Apollo13

6. Gardez un détachement face à vos idées

Celle-là est difficile.

Les idées appartiennent à tout le monde. C’est le corollaire du point précédent. Par détachement, j’entends le sens bouddhiste de la chose. On doit rester responsable de ses idées mais il faut aussi les laisser grandir sinon, elles vont toujours rester à la maison et vous allez être pris avec plein de Tanguy! #TerminéLaLiberté55

Si votre idée est si bonne mais qu’elle est rejetée, écrivez un livre ou un article! Développez-la à côté de votre projet. Mais, s’il vous plaît, partagez-la! Personne ne peut vous la voler car c’est vous qui en avez fait tout le raisonnement. #NDAsAreForNonTrustingPeople #CardsAgainstHumanity

De toute façon, si vous avez une équipe avec de bonnes attitudes, les gens vont vous attribuer naturellement le crédit. La coopétition (8) est payante pour vous et pour votre équipe si elle est saine mais le lâcher-prise est aussi très payant.

7. Analysez, oui. Mais, de grâce, agissez! (9)

La paralysie de l’analyse.

Ce fléau nous guette tous. C’est de notre *devoir* d’analyser. Quand on connaît vraiment très bien notre métier, cette analyse est là simplement pour éviter de trop se tromper (extinct by instinct). Car se tromper tu feras. #Jedi

Cependant, si cette analyse nous handicape, c’est peut-être parce qu’on est bloqué (voir la première attitude)? Il y a des centaines de truismes à ce sujet. (10)

Si c’est parce que l’on manque de connaissances, pourquoi ne pas l’essayer quand même par une petite preuve de concept? Une validation par nos pairs va nous permettre d’apprendre et de voir si nous sommes sur la bonne voie sans avoir à imaginer toutes les possibilités, même les inimaginables. #PairThinking^3

C’est incroyable comment on a peur de se tromper. Mais tout le monde se trompe – sauf le pape, il l’a dit lui-même! #InfaillibilitéPontificale

Si j’agis pour le bien 1) du client 2) du produit 3) de l’équipe (11) et que je fais une courte validation, quel reproche peut-on me faire d’avoir agi trop vite?

Et n’oubliez jamais qu’une mauvaise décision est toujours mieux qu'une non-décision. Même au risque de faire mourir quelqu’un (!). Sinon, jamais il n’y aurait eu de progrès. #MaitriseDuFeu

8. Assumez pleinement vos décisions, individuelles et collectives

Cette attitude découle directement de la précédente.

Quitte à les remettre en question, il faut assumer nos décisions et être en mesure de les expliquer : « à ce moment, nous avons pris la décision de […] parce que […] même si on savait que l’on pouvait/pourra faire mieux. ».

Si on s’est trompé, on reconnaît la faute, on priorise le carnet de commandes à nouveau et on promet [sincèrement] de faire mieux la prochaine fois. De toute façon, si on ne se donne pas le droit à l’erreur, on est aussi bien de rester dans notre lit toute la journée. C'est notre expérience et le travail d'équipe qui diminuent le risque. #LeRisqueZéroN’existePasSaufSiOnNeFaitRien

Mon expérience m’a toujours démontré que la pire décision possible n’est jamais une perte totale. Au minimum, on va avoir appris quelque chose. #ExceptionFaiteDeDonnerUnArsenalNucléaireÀUnIdiot

9. Visez la perfection… pragmatique!

Il faut s’engager à livrer le meilleur produit qui soit : pour le présent et pour son évolution future. Ne pas oublier que c’est nous tous (équipe et utilisateur) qui allons vivre avec les coins ronds. #YouBuildItYouRunIt

Cette attitude semble en contradiction avec les points précédents. Mais le mieux n’est pas l’ennemi du bien si ce mieux améliore la vie de l’utilisateur (et de son porte-monnaie) ou celle de mon équipe. #ApplicationAuServiceDeLHumain #ProcessusAuServiceDeLHumain #OrganisationApprenante

Il faut agir (le côté pragmatique) mais il faut aussi améliorer le produit continuellement. Parfois, cette amélioration aura de grandes répercussions. Il faudra même tout recommencer. Mais si ce nouveau départ améliore l’indice du bonheur collectif, pourquoi s’en empêcher?

Dans la mesure où l’on respecte les budgets et les échéanciers? Je ne suis pas d’accord avec les contraintes du saint trialisme de la gestion de projet (coût, vitesse, portée/qualité). Il faut toujours dire au client que s’il est seulement prêt à payer pour de la semelle de botte, qu’il ne s’attende pas à avoir un filet mignon. Néanmoins, sa semelle de botte va quand même être la meilleure semelle de botte possible! #PolishingTurd

10. Demandez constamment des éclaircissements si quelque chose n’est pas clair

Voici un bon réflexe à développer pour arriver à la perfection.

Une chose pas claire est *toujours* un symptôme d’un problème qui pourrait coûter cher.

Si les explications sont obscures et absconses pour vous, elles le seront sûrement pour d’autres membres de votre équipe ou pire, pour l’utilisateur. Qu’y a-t-il de mal à poser des questions? Et, au risque de me répéter, la présomption est la mère de tous les emmerdements.

Le besoin est mal défini? Il est peut-être superflu.

11. Posez infatigablement la question si c’est vraiment nécessaire

YAGNI! En as-tu besoin? En as-tu vraiment besoin? Ah oui? Certain? Pourquoi?

Ce qui est demandé, peu importe par qui, est-il vraiment nécessaire pour livrer le produit? Un client doit toujours savoir pourquoi il demande quelque chose. #LeFardeauDeLaPreuveAppartientAuDemandeur

Ainsi, n’acquiescez jamais à une demande parce que quelqu’un vous dit : « c’est parce que c’est comme ça ». Si vous avez ce genre de réponse, c’est que la personne est bien souvent une poule (12) [ou pire, une moule zébrée] (13) et qu’elle n’est pas imputable de ce que vous devez livrer. Vous pouvez donc l’envoyer caqueter (#EnvoyerPaître) dans un autre coin de la basse-cour.

Par ailleurs, n’acceptez pas trop vite de réaliser un besoin utilisateur ou une commande. Étudiez le scénario d’utilisation dans son ensemble. Plus 30 % des besoins initiaux sont des « tant qu’à » (14) et un autre 30 % peuvent souvent être éliminés en généralisant un tant soit peu le 40 % de besoins véritables. Une autre statistique? Seulement 20% des fonctionnalités sont utilisées 80% du temps. Dans le cas de certains logiciels, ce dernier nombre avoisine les 95%. #MakeThingsAsSimpleAsPossibleButNotSimpler

Ce qui est toujours nécessaire est, par contre, de toujours avoir une bonne attitude. Ne lésinez pas! #C’estMoiQuiVousLeDit!

12. Pensez invariablement à l'utilisateur de votre produit, pas à vous-même

En contrepartie, pour faire vite #LeClientVeutToutToutDeSuite, parce qu’on pense que l’on fait la bonne chose pour lui #LeVraiAltruismeNexistePas, parce que nous « on sait » et lui non #UnBonUtilisateurEstUnUtilisateurMort, on lui demande de faire des pirouettes parce qu’on est nous-mêmes des super gymnastes olympiques!

Informaticiens que l’on est, on ne se place que très rarement dans la peau de notre utilisateur.

Arrêtez de présumer de ce dont l’utilisateur a besoin et la façon dont il va utiliser le produit. La présomption est la mère de tous les emmerdements. Posez des questions. Mettez en doute vos paradigmes. Allez voir ce qui se fait du côté des meilleures pratiques en ergonomie cognitive et en développement d’interfaces personne-machine. Testez et retestez votre produit. Dites à vos utilisateurs qu’ils seront vos cobayes (15) et lancez votre produit. Vous allez être surpris des réponses. Le désir de participer à créer un monde meilleur est inné chez l’humain. #LicorneEtArcEnCiel

13. Trouvez les moyens les plus efficaces pour livrer

Quitte à changer vos façons de faire, soyez efficace dans ce que vous faites. Soyez impitoyable sur ce qui n’a pas de valeur (muda) et la surcharge de travail causé par des outils et des processus mal adaptés (muri). Si vous savez que vos façons de faire laissent à désirer, améliorez-les. Fin de la discussion.

L’excuse habituelle : « on n’a pas le temps » n’est jamais bonne. Vos estimations initiales n’ont pas pris en compte la mise en place de vos outils et de vos pratiques? Révisez vos estimations. Si vous ne le faites pas, cela risque fort de coûter plus cher de toute façon.

Si vous êtes entrés malgré tout dans votre budget/échéancier, soit que vous avez tourné les coins ronds, soit vous avez manqué l’occasion d’améliorer vos façons de faire pour les prochains sprints ou les prochains projets. #IlYAToujoursDeLaPlaceALAmelioration

Une courte analyse coûts-bénéfices prouvera rapidement que vous sauverez du temps avec de meilleurs outils.

Qui en profitera? Votre client (coûts, qualité), bien sûr, mais vous aussi en diminuant les frustrations liées aux basses besognes et à la multiplication des erreurs – il n’est jamais intéressant de se faire blâmer, même si l’on assume pleinement nos décisions.

Et l’autre excuse « nous n’avons pas le contrôle » n’a jamais été valable. Si vos processus contreviennent à la maxime « you build it, you run it », vous et votre client êtes morts! Les gens qui ne sont pas impliqués dans le développement seront des boulets à vos pieds car ils vont toujours vouloir se protéger les fesses. #DevOps

Ça n’a aucun sens de forcer la délégation de responsabilités à une autre équipe qui a des comptes à rendre mais à laquelle on n’offre aucune garantie. #NiveauxDeService Il n’y a pas d’adhésion possible sauf en demandant un niveau de qualité quasi impossible à atteindre.

Et tout le monde en souffre. Le client paie plus ou vos estimations initiales sont tellement grosses que le client n’a pas les moyens nécessaires pour réaliser son produit. Et vous souffrez vous aussi puisque vous ne pouvez pas agir sur ce qui vous rend inefficace.

Une seule chose a de l’importance : est-ce que l’application fonctionne tout en répondant aux besoins et aux exigences?

Agile n’est pas seulement des outils et des processus. C’est une façon de penser généralisée.

14. Soyez autonome

Dans la même veine, l’autonomie va de pair avec l’efficacité. Être autonome au premier jour demande de garder ses connaissances toujours à jour. Être autonome en cours de projet demande de l’aide ou de l’autoformation. Encore une fois, si vous ne pouvez pas être autonome, votre client et vous allez en souffrir.

Pourquoi ne pas demander de ralentir le projet pour un peu d’autoformation ou de mentorat? Ça serait tellement intéressant de posséder un port USB pour téléchargements instantanés de connaissances et de techniques. #JeSuisHumainPasUnRobot

Autonomie ne veut pas dire de faire cavalier seul mais simplement de pouvoir choisir par soi-même. Toutefois, si on n’a pas assez d’informations, on ne peut pas faire de choix libre et éclairé.

Donc exigez d’avoir du temps pour parfaire votre autonomie. On ne court pas en venant au monde. Et on doit toujours...

15. ...Embrassez le changement

Dites oui au changement, avec un grand sourire! Courez-lui après! Peu importe d’où il vient : équipe, utilisateur/client, parties prenantes, collaborateurs, etc. Quoi de plus vivant que la nouveauté! Pas de changement, pas d’agrément comme on dit.

Et j’ai une bien triste nouvelle à vous annoncer. Si le changement vous fait peur, vous n’êtes pas dans le bon métier. L’innovation, c’est positif, non? Je ne parle pas uniquement des changements à l’endroit de vos connaissances, de vos pratiques et de vos techniques mais aussi les changements à votre processus de développement, à vos outils et même à vos coéquipiers.

Sans oublier les changements constants aux besoins et aux exigences : un produit dont les besoins ne changent pas est un produit mort.

De toute façon, tout change, tout le temps. Aussi bien embrasser ce changement! #LaSeuleConstanteDansLUniversEstLeChangement

16. Montrez le bon exemple en restant toujours positif

Toute réaction négative à un bloquant ou à un changement coûte 1$ pour le party de fin d’année. Ainsi, si vous ne contribuez pas dans l’immédiat au bonheur de votre équipe, vous allez y contribuer plus tard! #GrosPartyDeNoël

Au pire, faites semblant ou taisez-vous. Et le sarcasme (≠ du cynisme) n’est pas une échappatoire. #1DollarsDansLePotParSarcasme

Et vous savez? Le client ne veut pas entendre des « oui mais » (ce qui équivaut à un non). Il sait très bien que ça va coûter plus cher. Restez positif!

17. Projetez de l'énergie et de la passion

Soyez intense dans votre intérêt envers votre métier et… le produit. Comme s’il vous appartenait [dans le détachement(!)] et que c’était la 7e merveille du monde.

La passion sert de moteur à l’action. Elle permet la réalisation de grandes choses. Et l’énergie alimente ce moteur. Sa projection devient vite contagieuse. Si une chose mérite d’être faite, elle mérite d’être bien faite.

Sans passion et sans énergie, il n’y aura ni enthousiasme ni intérêt. Et la qualité de ce que vous produisez sera fort probablement mise en doute.

18. Faites-en toujours un peu plus, gratuitement

Mettre de l’effort à sa tâche est une chose. En faire un tout petit peu plus permet souvent d’ajouter un peu de lubrification dans l’engrenage et de provoquer des sourires.

Vous savez, faire la petite chose de plus. Bien souvent, elle ne paraît même pas. Mais, au moins, vous aurez la satisfaction personnelle du devoir accompli.

Et pas besoin d’en faire à l’excès (16). #JusteUnPetitExtraPourLeBonheurDuClient #JusteUnPetitExtraPourLeBonheurDeLEquipe

19. Ayez une éthique de travail irréprochable

Un professionnalisme impeccable fait de vous quelqu’un d’agréable. Ça ne demande aucun talent :

  • d’être à l’heure,
  • de respecter ses collègues dans ce qu’ils sont et dans ce qu’ils disent,
  • de garder la tête froide – ne pas laisser son égo ni ses émotions prendre le dessus,
  • d’avoir les réflexes de faire la recherche nécessaire
  • d’être toujours préparés
  • de ne pas faire preuve de paresse intellectuelle
  • de rester ouvert aux idées et aux opinions, mêmes si elles sont amenées tout croche,
  • d’être patient,
  • d’être clair.

Combien de programmeurs m’ont demandé ce qu’ils doivent faire pour devenir concepteurs? La réponse n’est qu’à 50% sur le savoir-faire : habiletés pour l’abstraction (25%) et se tenir à jour sur tout, tout le temps (un autre 25%). L’autre 50%? L’attitude et l’éthique.

20. Souvenez-vous que personne n’aime travailler avec quelqu’un qui a une mauvaise attitude

Laissez votre égo à la maison. Allez au-delà de votre personne. C’est le meilleur moyen pour travailler en équipe.

Notes :

1) Avertissement : ce texte est rempli d’évidences! Alors pourquoi ce n’est pas toujours facile de travailler en équipe?

2) Vous saviez que la méthode en cascade est un exemple de ce qu’il ne faut pas faire, non?

3) Le terme « client » désigne le propriétaire de produit (PO) et son financier.

4) Une équipe qui s’autogère est une équipe qui n’a pas de chargé de projet. Elle rend des comptes à ses coéquipiers et, surtout, au client. Par contre, une équipe autogérée a quand même besoin :

  • d’une direction produit : le client
  • d’une direction technique, un « lead » qui aura la responsabilité d’éliminer les obstacles techniques,
  • d’organisation, un facilitateur qui aura la responsabilité de protéger l’équipe et d’éliminer les obstacles de nature plus... administrative (!). #LubrifiantSocial

5) Vos pantoufles ont des trous? Il est grand temps de les jeter et d’en acheter des nouvelles! #SeRecycler #PersonneNenVeutDeVosViellesPantouflesTrouées

6)

7) Pertinent : Qui sert a autre chose qu’à montrer votre compétence (aussi appelé « à vous rendre intéressant »).

8) Coopétition : compétition coopérative.

9) OODA, OPDCA

10) Paradoxe de l’âne de Buridan, « Le mieux est le mortel ennemi du bien » [Montesquieu], « Vaut mieux une bonne décision tout de suite qu’une meilleure décision trop tard » [Harold Geneen], le regret de l’acheteur, le perfectionnisme, le problème de la princesse, la leucosélophobie, etc.

11) J’ai déjà eu des expériences intéressantes et concluantes où la priorisation était 1) l’équipe 2) le client 3) le produit. #EmployeeFirst #RichardBranson

12)

13) Ahhhhhh! Les moules zébrées. Vous savez ces personnes qui s’inscrustent à notre bateau et, par leur rigidité, l’empêche d’avancer? #Dictats #AyatollahDeLaSécurité #DespotesDeLArchitectureDEntreprise

Une autre utilisation de notre lance-flamme?

14) « Tant qu’à [y être] », la source principale de l’inflammation de la fonction. #FonctionaliteAigüe

15) Contrairement à ce que font trop de spécialistes en design et en ergonomie, il faut dire aux utilisateurs qu’ils seront des cobayes. Ils ne sont pas fous et ils méritent tout notre respect et pas seulement parce que ce sont eux qui paient pour notre produit.

16) Pas comme les Coréens. Plusieurs études montrent qu’ils sont les moins productifs des pays industrialisés. Justement peut-être parce qu’ils en font trop.

Milles mercis pour ton attitude! Ça rappelle des souvenirs les moules zèbrées...

Romain DUSSOLLIER

Propulseur de projets - ACROME -

7 ans

Merci Eric pour cet article. J’apprécie tout particulièrement le cycle OODA présent dans les notes. A mon sens ce cycle présente le bien fondé de l'agilité.

Philippe OZIARD

Conseiller en Stratégie.

7 ans

Un feu d'artifice! mais le problème c'est le point 12, quand on innove (vraiment) il n'y a pas encore d'utilisateurs à qui demander ce qu'il pense de notre produit! donc il faut inventer un utilisateur et ce n'est pas dans la méthode agile..

"Arrêtez de présumer de ce dont l’utilisateur a besoin et la façon dont il va utiliser le produit. La présomption est la mère de tous les emmerdements. Posez des questions. Mettez en doute vos paradigmes. Allez voir ce qui se fait du côté des meilleures pratiques en ergonomie cognitive et en développement d’interfaces personne-machine." 100% d'accord. Par contre plus difficile quand maîtrise d'ouvrage et maître d'oeuvre sont des métiers différents dans des services différents avec des formations séparées. C'est mon ressenti du système "informatique à la française" contre celle à la "hollandaise" ou une personne peut faire les deux, en alternance ou dans le même projet, et donc l'informaticien est en contact direct avec l'utilisateur.

Identifiez-vous pour afficher ou ajouter un commentaire

Autres pages consultées

Explorer les sujets