«Pourquoi [la diversité des connaissances] serait-ce un enjeu?» En fait je me rend compte qu’au moment où j’ai écrit mon commentaire, il y avait deux aspects auxquels je m’interrogeais. L’environnement et les limitations du nombre. Il m’apparait maintenant nécessaire de rectifier le tir – disons que c’est une pensé en évolution.

D’une part, je me questionne sur l’environnement – l’équipe. Plusieurs qualités humaines doivent être présentes chez chacun des membres de l’équipe. (À ce sujet j’ai bien aimé la présentation «Trial, error and the God Complex». Et aussi «Les cinq dysfonctions d’une équipe» de Patrick Lencioni) Oui, l’humilité, mais aussi un bon égo. Il n’y a pas beaucoup de place à l’auto-censure dans une équipe agile. On doit aussi accepter que la meilleure solution n’apparaisse pas du premier coup. Mon point, c’est surtout que tout ça n’est souvent pas acquis. On ne nous apprend pas nécessairement à être un bon “team-player” ni ce qu’est un bon “team-player”.

Pour ce qui est de «limitations du nombre», après mûres réflexions, c’est la mauvaise question que je me posais (Est-ce que le nombre d’individu est important?). «Comment puis-je aider l’équipe?» serait peut-être une meilleure question (je la trouve trop vague, mais pour le moment elle sert mon propos). Ce qui je crois remmène à votre commentaire initiale. Dans un coin nous avons ceux qui disent «oui», et en quelque sorte ils disent aussi «Voici où je veux être.» Et dans l’autre coin il y a ceux qui disent «non» ou «Je ne me sens pas bien là dedans». Au bout du compte, chacun doit lui-même être interpellé. Les méthodes empiriques peuvent-elles vraiment « s’adapter à n’importe quelle équipe.»?

Si les individus n’acceptent pas les principes d’introspection et d’adaptation inhérent aux méthodes agiles, celles-ci ne sont d’aucun secours. Je parle ici «d’introspection» parce que je crois que pour s’adapter, il ne suffit pas de regarder le résultat obtenu (comme j’interprète le terme “Inspect”) pour pouvoir s’adapter. Il est aussi nécessaire de comprendre pourquoi nous avons obtenu ce résultat. Et que pour obtenir un résultat différent, notre comportement doit être modifié.

Donc, pour moi, tout part des individus. Pas de la méthodologies. Il doit y avoir une prise de conscience. Et à partir de là «ça prend de bons guides. Des empêcheurs de tourner en rond.» pour montrer le chemin; les comportements qui favorisent le changement.

J’espère avoir mieux tenu mon propos… Et si on ne peut pas « les amener tous « on the edge » afin qu’ils soient challengés de façon constante », on peut piquer leur curiosité pour qu’ils osent au moins jeter un coup d’oeil dans cette direction.

Votre questions sur la diversité des connaissances est intéressante. Pourquoi serait-ce un enjeu? En agile, nous avons des équipes pluri-disciplinaires, ce n’est pas l’opposé de la diversité. Au contraire, je pense qu’une équipe parfaitement homogène n’arrivera probablement pas à avoir une vision globale suffisante pour prendre des décisions bien éclairée. Je ne saisis peut-être pas bien votre point?

Et pour la vision commune, je crois en effet que c’est un pré-requis à tout démarrage de projet. Un propriétaire de produit, une équipe et une vision partagée. Tout le reste se construit après!

Je suis encore nouveau à la discipline agile et je crois que c’est tout un défi: il faut beaucoup de rigueur pour arriver à briser le moule, à «continuellement» se poser des questions, mais surtout à mesurer l’impacte de nos décisions.

Étrangement – ou non – il y a deux livres que je lis présentement qui me ramène continuellement à l’agilité.

The Smart Swarm de Peter Miller où il est question de quelque chose qui me semble centrale à l’agilité: Diversity of Knowledge. Mais à quel point «The Smart Swarm» s’applique vraiment à l’agilité m’est encore obscure, peut-être même qu’il n’y en a pas – surtout si on parle d’une équipe de développement logiciel… En lien avec votre billet, je me demande quelle est la place de la diversité de connaissance dans une équipe agile? Ou plutôt, jusqu’où peut-on pousser et profiter de la diversité de connaissance des membres d’une équipe? Étant limité en nombre de membre d’une équipe agile (7 ± 2), l’erreur ne pouvant pas être annulé par le nombre, y a t’il un danger dans le modèle de développement logiciel agile? Dans «The Smart Swarm» le nombre est tout aussi important que la diversité de connaissances.

Le deuxième livre, Pragmatic Thinking & Learning de Andy Hunt, présente entre autres le modèle de Dreyfus et ces 5 stades; de novice à expert. Chaque membre d’une équipe agile peut être à l’un ou l’autre de ces stades dans une ou plusieurs compétences nécessaires dans le fonctionnement d’une équipe – qu’elle soit agile ou non. Je ne parle pas nécessairement de compétences techniques, mais sociales aussi/surtout. «L’agile» est un réacteur de compétences sociales – littéralement où fusion et fission peuvent survenir.

«Et ça prend de bons guides.» Et comment!!! J’ai cru que l’agilité venait de soit… Mais l’agilité, pour fonctionner, demande une vision commune.

Comment générer une vision commune? Comment savoir qu’une vision commune existe? Si t’en est qu’une vision commune est un pré-requis à la réussite d’une équipe, est-ce que cette question ne devrait pas prévaloir à toutes les autres?

Si la question est plus importante que la réponse, nous devons savoir se les poser. Cela tient-il plus du savoir ou du courage? Et si on ne peut pas changer les autres, qu’est-ce qui peut amener les autres à vouloir changer? À vouloir adopter les «mêmes valeurs»?

Question: Does the Sprint Extender support an infinite duration?

Also, I couldn’t see anything about Automated Continuous Improvement or a Random Retrospectives Report Generator . Do you have something that does the same thing? My customer does not want to worry about that..

Thanks for the comment!

The presentation is light. The message and consequences are not.

Feel free to distribute as you wish.

This is a very light post that I’m sure many Product Owners will enjoy. I would really like to publish your post on PM Hut, where many people interested in project management will be able to read it.

Please either email me or contact me through the “Contact us” form on the PM Hut website in case you’re OK with this.

To answer directly or indirectly to the comments above; I see it as an evolutionary process. If you’re a Product Clerk, you can learn to become a Product Owner, if you choose to do so. It’s not easy. Actually it’s really hard.

If you know little or nothing about the requested product then use one like it! Buy it, play with it, make it crash. Subscribe to your competitor’s service and invest time and money to understand it. Join discussion groups on LinkedIn, Yahoo, etc. Immerse yourself in the product and have fun with it. In a nutshell – get to deeply understand the essence of the problem we are trying to solve. One of two things will happen : You’ll realize that this can be a truly valuable product for your clients or you just won’t get it, maybe for good reasons.

One is never condemned to staying a Product Clerk.