Une équipe Scrum est constitué d’un Product Owner, d’une Equipe de réalisation et d’un ScrumMaster (A distinguer de l’Equipe d’un Scrum). Chercher les pré-requis d’une équipe Scrum nous impose de bien comprendre ce qu’est Scrum. Considérant que la compréhension de Scrum est partagée, nous pouvons chercher des pré-requis dans ses règles de fonctionnement.
Quand un PO est très présent, ce que toutes les équipes n’ont pas le luxe d’avoir, il a tendance à bien aimer faire des modifications en cours de sprint. Quand on est Agile, on veut embrasser les demandes de changement : « La réponse au changement prime sur le suivi d’un plan ». Mais le PO a-t-il vraiment toute la liberté de demander ce qu’il veut, quand il veut?
Si les requis changent tout le temps, le PO souffrira d’un manque de prévisibilité relié à la difficulté pour les développeurs d’estimer le travail à faire. Alors il faut arriver à bien définir le périmètre de chacun des items au backlog, et la dernière limite pour faire ça, en principe, c’est le sprint planning.
Les règles disent ceci :
La réalité apporte des nuances : certains critères ont pu être laissés flous, ou certaines demandes ont pu être formulées seulement en voyant l’application en cours de sprint. La beauté d’avoir des démos en milieu de sprint est d’améliorer les communications et de pouvoir avoir plus rapidement le logiciel dans l’état où il rend le PO heureux… et c’est ça l’objectif, non?
Alors voici les solutions qui pourraient être envisagées si le PO demande beaucoup de modifications:
Cette question revient souvent sur le tapis. Elle peut paraître dénuée d’intérêt de prime abord, mais je trouve qu’elle résume à merveille le bouleversement silencieux que peut représenter l’Agilité. Pour illustrer mes propos, j’en veux pour preuve les fondements du manifeste Agile; vous n’y trouverez aucune solution toute faite, pas de processus, pas d’outils non plus… vous y trouverez tout simplement des VALEURS.
Il est vrai toutefois que ces valeurs peuvent se décliner dans les différentes activités de l’entreprise qui développe du soft: pratiques d’ingénierie, gestion des tests, gestion de projets, analyse du besoin, etc.. il en résulte bien évidemment des outils, des méthodes (comme Scrum), des pratiques (comme celles d’eXtreme Programming) et bien d’autres choses, mais n’attendez pas de pouvoir simplement réutiliser clef en main ce qui marche ici pour l’implémenter là -bas. L’histoire des constructeurs automobiles américains copiant en vain les procédés de Toyota (approche Lean) montre que les richesses d’une entreprise sont parfois invisibles, trop subtiles pour être photographiées. Une culture, un état d’esprit, ça prend un certain temps pour se construire. Aussi, n’attendez pas des résultats immédiats, mais préparez vous à investir aujourd’hui pour demain.
L’Agilité est donc à mon sens plus un savoir-être qu’un savoir-faire. Ce savoir-être peut nécessiter une révolution des mÅ“urs dans l’entreprise! Il faut s’attendre à pas mal de résistance dans les situations suivantes:
Cela vous parait-il ubuesque, démagogique, inapplicable? Ben, j’aime les débats qui pourraient survenir! Attention, je ne cherche pas à dire que l’Agilité est la panacée à tous les maux; je ne dis pas non plus que l’Agilité est meilleure qu’une autre démarche. Je veux juste mettre en garde sur ses conséquences sur l’entreprise, en terme de management, c’est à dire au niveau de la gestion des hommes. Ce management conscient des valeurs (qu’elles soient ou non celles de l’agile) offre – quand il existe l’avantage de pouvoir aligner les forces de l’entreprise dans un même effort.
Beaucoup de courants de pensée (en dehors du développement logiciel) alliant performance, humanisme et écologie m’incite à croire que la complexité grandissante de notre monde nous condamne à nous remettre en question un peu plus chaque jour 
Hier, j’ai été invité à intervenir à un Webinaire interne à Orange Labs (ex France Telecom). L’objet du séminaire était d’introduire et d’expliquer l’agilité avec retours d’expérience à la clef. Il y avait 17 présents dans la salle et 60 en conférence web.
Je remercie Hervé Lourdin de m’avoir proposé d’animer avec lui sa présentation “Agile Démystifiée”. Le principe de cette présentation est de faire participer le public en leur demandant de prioriser les questions qu’ils veulent poser, sachant que les animateurs auront une période de temps fixe pour y répondre. Le public devient ainsi le “product owner” (ou directeur de produit dans Scrum) et doit faire des choix pour rentabiliser au mieux le temps d’animation qu’il a à sa disposition. Marrant le vote à main levée dans la salle, complété par les votes par “chat” pour ceux qui étaient sur le net. Nous avions abordé les sujets suivants
Ensuite Thomas DONY a présenté son retour d’expérience sur un projet d’Orange Labs géré en Scrum depuis 1 an. Le bilan du projet est positif et il est question d’étendre l’expérience. Enfin, j’ai présenté mon retour d’expérience chez Varian après 3 ans de Scrum/XP, discours relativement proche de celui tenu par mon collègue Bruno Orsier à l’Agile Tour 2008 à Grenoble.
Le timing global de l’après-midi était assez serré, ne laissant pas beaucoup de place aux questions/réponses. Parmi les questions soulevées durant les retours d’expériences, j’ai pu relever :
Dommage que nous n’ayons pas pu faire un ROTI (return on time investment) afin de mesurer le degré de satisfaction du public, bien que j’ai su par la suite directement et indirectement que l’après-midi fut très appréciée!
Merci à Rémy et Pierre qui m’ont invité, ce fut un plaisir de contribuer à leur démarche pour faire connaître l’agilité au sein de leur grande société.
Scrum propose de confier la responsabilité des priorités et du retour sur investissement à une seule et même personne. Cette personne doit avoir l’autorité d’exercer cette responsabilité dans son organisation. L’unicité de cette personne est là pour empêcher les indécisions pour raison de conflit entre plusieurs intérêts contradictoires.
Cela ne veut pas dire que cette personne soit seule au monde. Un Product Owner peut s’entourer d’une équipe qui l’aide dans ses prises de décisions. De fait de nombreux Product Owner le font dans le cas de produits complexes, difficiles à appréhender par un seul individu.