Automne 2016 - Volume 1Fall 2016 - Volume 1

Scrum a 21 ans et continue de grandir

Le magazine

Dave West, Product Owner de Scrum.org

L’organisation gérée par la valeur

Évoluer en tant que Scrum MasterEnquête sur l’Agilité en 2016Y a-t-il un PO dans la salle?

Scrum turns 21 and it is not done yet Dave West, Product Owner of Scrum.org

The organization managed by value

Evolving as a Scrum MasterSurvey on the status of Agility in 2016Is there a PO in the room?

Auto

mne

201

6 - V

olum

e 1

Fall

2016

- Vo

lum

e 1Magazine

C

M

J

CM

MJ

CJ

CMJ

N

Cover_C1_C4_FINAL copie.pdf 1 2016-10-17 15:18

Visit agileknowhow.com for everything about Agility

webinars • articles • white papers

KANBAN

NEWS STARTUP

AGILE PROJECT MANAGEMENT

LEANMANAGEMENT

PRODUCT OWNER

LEADERSHIP

BACKLOG

AGILE ORGANIZATIONAGILE TRANSITION

SCRUM MASTER

VELOCITYVIDEOS

SOFTWARE DELIVERY FACILITATION

COMMUNICATION

RETROSPECTIVE

SOFTWARE QUALITY

RISK MANAGEMENT

PEOPLE

CHAN

GE

DEVOPS

PRODUCTIVITY

DAILY SCRUM

USER STORIES

Visitez savoiragile.com pour tout ce qui touche à l’Agilité

webinaires • articles • livres blancs

KANBAN

NOUVELLESSTARTUP

GESTION DE PROJET AGILE

LEANMANAGEMENT

PROD

UCT O

WNE

RLEADERSHIP

BACKLOG

ORGANISATION AGILETRANSITION AGILESCRUM MASTER

VÉLOCITÉVIDÉOS

LIVRAISON DE LOGICIELFACILITATION

COMMUNICATION

RÉTROSPECTIVE

QUALITÉ LOGICIEL

GESTION DU RISQUE

INDIVI

DUS

CHANGEMENT DEVO

PSPRODUCTIVITÉ

MÊLÉ

E QU

OTID

IENNE

USER STORIESC

M

J

CM

MJ

CJ

CMJ

N

Cover_C2_C3_FINAL copie.pdf 1 2016-10-17 15:19

3

Magazine Savoir Agile • Automne 2016

savoiragile.com

Depuis plus de 15 ans déjà, Pyxis travaille à faire connaître l’Agilité. En continuant à soutenir les communautés Agiles, nous voulons favoriser l’adoption de ces approches, en approfondir les enjeux et étendre leur application à toutes les facettes des organisations, du volet stratégique au plus tactique, du marketing à la finance.

C’est avec plaisir que nous vous présentons cette première édition du magazine Savoir Agile qui, nous le souhaitons, saura vous inciter à ex-plorer par-delà les frontières du connu. Nous y dévoilons notamment les résultats du premier sondage québécois sur l’Agilité. Sommes-nous aussi Agiles que nous croyons l’être ?

Avec plus de 10 000 « Agilistes » formés par notre campus et quelques centaines d’interventions en coaching Agile, Pyxis a plus que jamais la conviction profonde que l’Agilité a sa place dans toutes les organi-sations et qu’elle n’est pas une panacée. Forts de plusieurs expériences Agiles et Lean, nos clients explorent maintenant les concepts de la gou-vernance Agile, de la mise à l’échelle et de l’Agilité organisationnelle. Que d’effervescence !

La mise en œuvre des approches Agiles pose des défis importants, défis plus humains que techniques. C’est pourquoi nous continuons à explo-rer des approches novatrices de coaching, d’animation, d’intelligence collective et d’auto-organisation, et ce, sans pour autant délaisser la connaissance approfondie du métier, sans laquelle toute Agilité serait illusoire.

Et si l’Agilité était finalement une invitation à innover et à réinventer le contexte social au sein duquel nous œuvrons ?

Bonne lecture !

Déstabiliser le convenu

Daniel Leclair:Président Pyxis Technologies

4

Magazine Savoir Agile • Automne 2016

savoiragile.com

Nos collaborateurs

Collaborateurs invités

Tremeur Balbous, coach Agile, Lausanne:Scrum Master et conseiller d’expérience à Pyxis Suisse, Tremeur accompagne et conseille les organisations dans leur transformation Agile. Il travaille avec les équipes peu importe leur taille et leur emplacement. De plus, il coache les gestionnaires et les équipes de direction. Il est aussi un Professional Scrum Trainer certifié par Scrum.org.

Mathieu Boisvert, directeur général de Pyxis, Montréal:Expert en Agilité depuis maintenant une dizaine d’années, il est un acteur important dans l’établissement de la stratégies d’adoption des approches Agiles et de leur bon déroulement au sein de nombreuses équipes et entreprises. Il a formé et conseillé des centaines de professionnels de différentes industries, tant au Canada qu’en Europe.

Marc-André Langlais, coach Agile, Singapour:Guider les équipes afin qu’elles rayonnent au sein de leur organisation, voilà ce qui passionne Marc-André. Son écoute attentive et sa capacité de bien comprendre les besoins des gens sont des atouts qui lui permettent d’aider les équipes à bien s’outiller. Ainsi, elles peuvent répondre de façon efficiente aux demandes de leur organisation.

Steffan Surdek, conseiller et formateur Agile, Ottawa:Depuis près de vingt ans, Steffan navigue dans le monde du développement logiciel, jouant tous les rôles, de la défini-tion des exigences à l’architecture, en passant par le codage et les tests. Au cours des dernières années, il a travaillé dans de grandes entreprises où il a développé son expertise en utilisation des pratiques Agiles dans des équipes distribuées.

Dave West est le Product Owner à Scrum.org. Souvent invité à titre de premier conférencier, il est l’auteur de nombreux articles. Il est aussi l’au-teur du livre acclamé par le public : Head First Object-Oriented Analysis and Design. Il a dirigé l’élaboration du processus RUP (rational unified process). Il a par la suite travaillé avec Ivar Jacobson à la direction de la division nord-américaine d’Ivar Jacobson International en plus de diri-ger la pratique de livraison de logiciels chez Forrester Research à titre de vice-président et de directeur de recherche. Avant son arrivée à Scrum.org, il était le directeur de produit chez Tasktop où il était responsable de la gestion, de l’ingénierie et de l’architecture des produits.

Facilitatrice, maître zen, auteure et médiatrice douée, Diane Musho Hamilton est une pionnière en matière de dialogues sur la culture, la religion, la race et les relations entre les sexes. Elle est un des principaux membres de l’Integral Institute. De plus, depuis plus de dix ans, elle approfondit la question de la conscience de soi individuelle et collective. Elle est cofondatrice d’Integral Facilitator et aussi auteure du livre Everything is Workable: A Zen Approach to Conflict Resolution.

Richard Martin, coach organisationnel, Québec:Coach organisationnel, Richard œuvre comme agent de changement auprès d’équipes de direction pour définir les meilleures stratégies de transformation Agile. Il possède un riche vécu dans divers contextes organisationnels où il a expérimenté de nombreuses approches de gestion de la performance.

Charles-Louis de Maere, Scrum Master, Charleroi:Charles-Louis s’est joint à l’équipe de Pyxis Belgique en septembre 2015. En tant que coach Agile, il s’éclate lorsqu’il a l’occasion d’accompagner des équipes sur leur chemin de l’Agilité. Pragmatique avant tout, il évite les dogmes et préfère trouver des solutions adaptées à l’environnement.

Dave West Product Owner de Scrum.org:

Diane Musho Hamilton Ten Directions:

5

Magazine Savoir Agile • Automne 2016

savoiragile.com

Nous sommes fiers de vous présenter la toute première édition du magazine Savoir Agile, premier magazine québécois sur l’Agilité.

Ce magazine s’adresse à tous ceux qui souhaitent faire un changement dans leur organisation, qui souhaitent faire les choses autrement. Product Owners, Scrum Masters, coachs, développeurs, agents de changement et bien plus.

Nous espérons que vous serez inspirés tout comme notre équipe l’a été lors de cette aventure.

Équipe éditoriale Relecture, traduction, designGabriel BélangerNathalie GilbertSophie PaquetteMarie-Eve Trempe

Collaborateurs de PyxisTremeur BalbousMathieu BoisvertCharles-Louis de MaereMarc-André LanglaisDaniel LeclairRichard MartinSteffan Surdek

Collaborateurs invitésDiane HamiltonDave West

savoiragile.com:

©2016 Pyxis Technologies inc. Tous droits réservés.

Pitié, ne construisez pas le nouveau pont Champlain en Agilité...:Tous les projets ne se prêtent pas à l’Agilité. Lisez pourquoi.

6

Scrum a 21 ans et continue de grandir:L’évolution de Scrum racontée par le PO de Scrum.org.

14

La valeur reste la mesure la plus porteuse pour les organisations. L’organisation gérée par la valeur:30

Deux de nos coachs répondent à vos questions.La question au coach:18

Développez une approche personnalisée pour avoir du succès.Évoluer en tant que Scrum Master:10

Parfois, il faut sortir des sentiers battus pour voir les choses d’un autre oeil.

Être Agiles au-delà de Scrum:34

Entrevue Savoir Agile avec notre coach Steffan Surdek.Pourquoi si pressé?:20

Comment se porte l’Agilité en 2016 au Québec? Savoir Agile s’est penché sur la question et vous partage les résultats.

Enquête sur l’Agilité en 2016:28

Choisir la bonne personne pour le rôle de PO n’est pas une mince affaire. Découvrez quelques éléments qui peuvent vous guider dans ce choix.

Y a-t-il un PO dans la salle?:38

Collaborer avec différentes personnalités peut créer des tensions et de la fermeture. Restez ouverts!

Développer des équipes exige communication et perspective:

24

Le magazine

6

Magazine Savoir Agile • Automne 2016

savoiragile.com

Pitié, ne construisez pas le nouveau pont Champlain en Agilité… Mathieu Boisvert, directeur général de Pyxis

7

Magazine Savoir Agile • Automne 2016

savoiragile.com

Les approches Agiles ne sont pas la réponse à tous les maux, et il est intéressant de se questionner sur les contextes dans les-quels elles sont les plus pertinentes.

Pourquoi construire un pont à l’aide d’une approche Agile n’est pas une bonne idée ?

Parce qu’un pont est une construction monolithique, dont la portée est peu flexible et où la valeur n’est obtenue qu’une seule fois, à la fin de sa construction. C’est pourquoi on aurait ten-dance à construire le pont à partir d’un plan détaillé qui assure l’intégrité de la structure.

De plus, il est possible de cerner l’incertitude associée au pont Champlain sans avoir à le construire. Je crois qu’en 2016, les ingénieurs maîtrisent bien la construction d’infrastructures. Ils ont une bonne compréhension du fleuve Saint-Laurent et du climat de Montréal et il est possible de prévoir l’utilisation future du pont.

Dans un contexte comme celui-ci, où les informations initiales sont fiables, où il n’y a rien à apprendre pendant la construction, où la portée du projet est peu flexible, ce sont les méthodes de gestion en cascade qui sont les mieux adaptées.

Une gestion en cascade est efficace dans les contextes certains et lorsque l’on n’a pas droit à l’erreur. On commence par une analyse préliminaire exhaustive, qui mesure toute la complexité et l’incertitude d’un problème, on continue par la conception

détaillée du produit, prenant en compte tous les aspects du problème. Une fois la solution conçue, le risque devient alors de livrer cette solution efficacement, dans le respect d’un budget et d’un échéancier. Pour cela, on utilise un plan par activité, comme un diagramme de Gantt, coordonnant l’effort de tous les contributeurs avec la plus grande efficacité possible.

À quels contextes les méthodes Agiles sont-elles les mieux adaptées ?

Il n’est pas toujours possible de réduire l’incertitude d’un pro-blème par la conception d’une solution détaillée. Lorsque les informations de départ ne sont pas suffisantes et que le produit est suffisamment malléable pour permettre l’expérimentation, les approches empiriques, comme les méthodes Agiles, sont les plus efficaces. Les méthodes Agiles abordent l’incertitude d’un problème par la production rapide d’un incrément, le plus révélateur possible, pour valider ou infirmer une hypothèse importante. Cette validation faite, on peut ensuite passer à une prochaine hypothèse avec plus de certitude. D’un incrément à l’autre, on tend petit à petit vers la solution la plus optimale.

Cela dit, on a parfois l’impression que nos projets sont plutôt de nature certaine qu’incertaine, comme celui du pont. Voici quelques perspectives personnelles qui bousculeront peut-être vos convictions et vous aideront à mieux choisir entre une ap-proche en cascade et une approche Agile.

L’implantation d’un ERP : incertitude sur la faisabilité

Du point de vue du fournisseur, l’implantation d’un progiciel de gestion d’entreprise (ERP) est probablement plus certaine qu’imprévisible, car celui-ci maîtrise parfaitement les rouages de sa plateforme. Un fournisseur aurait donc tendance à proposer une approche en cascade pour livrer efficacement.

L’Agilité est maintenant un incontournable du développement de services et de produits. Incontournable ? Vraiment ? Peut-être pas toujours.

Une gestion en cascade est efficace dans les

contextes certains et lorsque l’on n’a pas droit à l’erreur

8

Magazine Savoir Agile • Automne 2016

savoiragile.com

Contextes similaires :

• la recherche et développement ; • l’adoption d’une nouvelle technologie.

Ce qui est incertain, c’est la personnalisation pour le client. Plus les besoins du client s’écartent de la version standard de la plate-forme, plus il serait intéressant de valider certaines hypothèses. Par exemple, est-ce qu’il est vrai que la nouvelle plateforme sera plus utile que l’ancienne ? Que les nouveaux tableaux de bord se-ront plus fiables ? Que l’efficacité des opérations sera améliorée ?

Configurer une seule opération utile ou fréquente permettrait à la fois de valider que la plateforme ERP et l’environnement du client s’intègrent bien et que les avantages attendus sont bien obtenus.

Les résultats de cette expérience permettraient au fournisseur de mieux estimer la personnalisation requise et au client de mesu-rer le rendement de son investissement ainsi que l’effort requis pour l’adaptation de ses processus, l’intégration de la plateforme, le nettoyage de ses données et la gestion du changement à organiser.

D’une opération à l’autre, le client et le fournisseur améliore-raient leur collaboration et tendraient ensemble vers la configu-ration la plus optimale qui soit.

Une campagne de marketing : incertitude quant à l’impact sur le marché

Parce que l’image est précieuse et les campagnes publicitaires coûteuses, les entreprises n’accordent pas beaucoup de droit à l’erreur aux agences. En conséquence, les agences peuvent croire qu’une conception en cascade leur permettra de créer des campagnes à grand déploiement, qui ne laissent rien au hasard. Malheureusement, il est très difficile de prévoir l’impact réel d’une campagne et la réception du public cible.

Un incrément de la campagne, qui teste les messages auprès du marché cible, pourrait réduire l’incertitude liée aux concepts importants de la campagne et permettrait, un incrément à la fois, de produire la campagne la plus percutante possible.

Le devoir de sciences de ma fille : incertitude sur l’expérience et la compétence

Dans le cadre d’un cours de sciences au secondaire, ma fille de 13 ans devait construire un véhicule qui avance seul avec des moyens de traction ou propulsion. Le professeur a guidé la classe à concevoir leur véhicule avec une approche en cascade : d’abord apprendre les concepts physiques de transfert d’énergie (ressorts, engrenages, essieux), ensuite dessiner un véhicule utilisant ces concepts, prévoir l’achat des matériaux et exécuter les étapes de construction. La dernière étape était le concours en classe du véhicule parcourant la plus grande distance.

Ma fille, qui avait une confiance complète dans son plan, a été surprise quand je lui ai proposé d’essayer la voiture avant le concours :- Pourquoi ? Le professeur a validé le plan et je l’ai bien respecté.

L’essai s’est cependant avéré un échec. L’hélice qu’elle avait construite elle-même n’offrait aucune traction ; la voiture n’avançait pas du tout. Catastrophe, il ne restait plus que la fin de semaine pour modifier la voiture avant la compétition.

Contextes similaires :

• le développement de produit ; • l’amélioration des processus; • la conception d’un bâtiment à l’aide du Building

Information Modeling (BIM).

Contextes similaires :

• un programme de formation ; • un programme de gestion du changement ;• le réaménagement d’un espace ; • une stratégie d’embauche ; • la rédaction d’un livre ;• le développement d’un nouveau produit ;• une stratégie de vente.

9

Magazine Savoir Agile • Automne 2016

savoiragile.com

Ensemble, nous avons d’abord changé le mode de propulsion  en remplaçant l’hélice par un système à élastique. Notre incré-ment de base assurait maintenant une première distance pour le concours. Ensuite, nous avons fait des modifications d’un incrément à l’autre pour faire avancer le véhicule de plus en plus loin. Cela donnait l’option à ma fille d’arrêter la construction de la voiture dès qu’elle serait satisfaite de la performance. Résultat, le véhicule a terminé 2e, à la grande satisfaction de ma fille.

Normalement, l’ingénierie est une science plutôt exacte, et il est possible de croire que la conception du véhicule aurait pu suffire. Cependant, le manque de connaissance de ma fille favorisait une approche par incréments, qui lui garantissait une certaine performance pour le concours.

Un travail de session en équipe : incertitude sur la dynamique d’équipe

Avez-vous de bons souvenirs de vos travaux de session en équipe ? Il n’est pas rare que les étudiants, habitués de travail-ler en solo, n’aient pas une bonne dynamique lors de travaux d’équipe. Souvent, une personne se retrouve responsable de l’intégration de tous les contenus la veille de la date de remise.

Dans ce contexte, une approche par incréments permet non seulement à une équipe de réduire l’incertitude autour du produit final, mais surtout d’améliorer la collaboration entre les membres la constituant, en comparant fréquemment leur contri-bution à celle des autres.

L’incertitude n’est donc pas toujours liée au domaine d’affaires ou technique, elle peut aussi être liée aux processus de travail.

Agile ou pas Agile, telle est la question

Les approches Agiles ne sont pas la solution à tous les pro-blèmes. Lorsque les informations initiales sont suffisantes, lorsque le produit n’est pas très malléable ou lorsque nous n’avons pas de souplesse pour l’expérimentation, les approches Agiles sont moins performantes.

Par contre, un domaine dont la complexité nous semble certaine peut s’avérer plus hypothétique que prévu :- Est-ce que la valeur d’affaires ou l’impact de notre produit est

garanti ?- Maîtrisons-nous le domaine technique du produit ?- La dynamique de l’équipe sera-t-elle efficace ?

Lorsque des incertitudes ne peuvent pas se vérifier par l’analyse, mais plutôt par l’expérimentation, les méthodes Agiles sont alors très pertinentes.

Utiliser ou non une méthode Agile n’est donc pas, selon moi, un choix par défaut ; c’est plutôt une décision à prendre avant chacun de nos projets.

Et vous, comment faites-vous pour choisir entre les approches Agiles et en cascade dans vos projets ?

Contextes similaires :

L’intégration des biens livrables produits par différentes personnes ou équipes.

L’incertitude n’est donc pas toujours liée au domaine

d’affaires ou technique

Participez aux webinaires de Mathieu Boisvert sur savoiragile.com.:

10

Magazine Savoir Agile • Automne 2016

savoiragile.com

Évoluer en tant que Scrum Master

Lorsque l’on change de projet, d’équipe ou même d’organi-sation, il y a toujours une période d’adaptation. Quels sont les outils qui peuvent vous servir lors de ces transitions? Pour avoir du succès à titre de Scrum Master, il faut développer sa propre approche, sa propre façon de faire. Heureusement, en plus d’une multitude d’écrits intéressants sur le sujet, le fait d’échanger avec ses pairs permet de bénéficier de leurs expériences variées et ainsi de s’en inspirer pour trouver des solutions aux divers pro-blèmes que l’on rencontre.

En effet, un large éventail de solutions contribue à faire face aux différentes situations qui peuvent survenir sur une base quasi quotidienne. Il est important de savoir innover dans ses façons de répondre aux défis rencontrés pour offrir les meilleures chances de succès à l’organisation.

Dans cette optique, nous vous présentons ici des outils et approches qui peuvent vous être utiles afin de devenir le meilleur Scrum Master possible. De la relation avec les parties prenantes à votre posture de coach en passant par l’établissement d’un rythme soutenable pour l’équipe, voici un survol de ce que de nombreuses années d’expérience ont apporté au métier de Scrum Master.

Tout d’abord, il est important de définir une façon de mesurer votre succès et de suivre votre propre développement comme celui de votre équipe.

Voici des exemples de questions qui peuvent vous aider à définir et mesurer votre succès :

• Avons-nous une vision d’équipe?

• Avons-nous un objectif de sprint clairement défini?

• Est-ce que l’équipe est contente de travailler sur le projet?

• Est-ce que l’équipe a livré l’incrément durant ce sprint?

• Est-ce que tout le monde est satisfait et fier de ce qui a été accompli?

• Avons-nous amélioré notre façon de travailler (livré plus de valeur que précédemment)?

• Avons-nous un tableau de bord pour communiquer le statut de notre produit?

• Utilisons-nous des scénarios utlisateurs de qualité?

• Est-ce que l’équipe souhaiterait travailler de nouveau avec moi comme Scrum Master?

Article Savoir Agile

11

Magazine Savoir Agile • Automne 2016

savoiragile.com

Les questions elles-mêmes ne sont pas aussi importantes que le simple fait de s’en poser et d’y porter attention. Il est primordial de développer vos habiletés et de mesurer ce développement régulièrement.

Notez qu’il est également particulièrement important de prendre du recul pour évaluer si l’équipe s’est approprié le processus et les cérémonies. En effet, c’est la mesure de succès la plus fréquemment utilisée. Mais comment aider l’équipe à s’approprier le processus? Voici quelques pistes de réponses...

Apprendre à coacher une équipe est un des cheminements les plus importants, mais aussi un des plus difficiles. Adopter une posture de coach est une démarche subtile qui nécessite que l’on facilite sans véritablement prendre le contrôle et en acceptant que l’on ne peut forcer personne à faire quoi que ce soit. Il faut seulement clarifier les raisons et s’assurer que l’équipe se les approprie. On en vient donc ici à la notion de pourquoi.

Le comment et le pourquoi

Aider l’équipe à définir son rôle afin qu’elle puisse définir sa propre mesure de succès est une des clés de la motivation et du succès. Sans un but commun clairement établi, l’équipe ne peut coordonner efficacement ses actions en fonction de l’atteinte de cet objectif. Le pourquoi est souvent ce qui définit le succès. Il faut toujours demander pourquoi avant de commencer. Beaucoup d’équipes échouent parce qu’elles se concentrent sur le COMMENT plutôt que sur le POUR-QUOI. Ce n’est qu’en ayant conscience des raisons pour lesquelles elles accomplissent des tâches que les équipes réussissent à donner le meilleur d’elles-mêmes et c’est le rôle du Scrum Master de leur rappeler.

Il est important d’avoir des échanges fréquents en tête à tête et de prendre des notes. Cela peut paraître simpliste, mais les conversations sont un élément central de la relation entre le Scrum Master et les membres de son équipe. Elles permettent en partie d’évaluer ce qui affecte l’équipe et de mesurer son degré de satisfaction par chacun des individus qui la composent. Nous vous suggérons la lecture de How

to Win Friends and Influence People de Dale Carnegie qui analyse ce qu’il faut garder à l’esprit lorsque l’on souhaite faire grandir une relation humaine dans le cadre du travail. Notamment, il suggère de commencer les conversations en discutant d’un sujet qui est important pour la personne et en manifestant un véritable intérêt. Le fait de prendre des notes permet tout simplement de mémoriser ce qui a été appris au cours de ces échanges et d’agir de façon délibérée avec les gens avec lesquels vous travaillez.

Vous devez être confortable avec le fait de vous effacer et de simplement jouer un rôle de facilitateur qui évolue en arrière-plan. Chaque cérémonie est une occasion de laisser la place aux membres de l’équipe afin qu’ils puissent eux-mêmes discuter de leurs priorités. Vous n’intervenez que si c’est nécessaire et qu’ils ont besoin de soutien.

L’équipe avec laquelle vous avez travaillé hier n’est pas la même avec laquelle vous travaillerez demain. Adaptez vos pratiques au stade de développement de chaque équipe. En effet, les stades de développement ne sont pas toujours les mêmes aux mêmes moments. Les étapes identifiées par Tuckman peuvent alors être utiles : formation, confronta-tion, normalisation et production (Developmental sequence in small groups par Bruce Tuckman).

Le coaching se déroule entre adultes consentants. Obtenez le consentement explicite des participants avant de com-mencer. Cela peut sembler évident mais on ne peut forcer une équipe à être coachée. Le fait de partager un but et des attentes permet ensuite de demander à l’équipe de s’y tenir. On établit une sorte de contrat ou plutôt une entente de coa-ching avec l’équipe et on peut par la suite rajuster les efforts en fonction de ce sur quoi on s’est entendu.

Mesurer

Mesurez et prenez des notes à propos de TOUT. Cela vous permettra ensuite de dégager des tendances lorsque vous aurez recueilli suffisament de données. Cela peut aller du

Beaucoup d’équipes échouent parce qu’elles se

concentrent sur le COMMENT plutôt que sur le POURQUOI

12

Magazine Savoir Agile • Automne 2016

savoiragile.com

nombre de tâche complétées au nombre de conversations avec chaque membre de l’équipe en passant par le nombre d’interven-tions lors d’une cérémonie ou le nombre d’interactions avec les parties prenantes. L’important est d’être en mesure de dresser un portrait réaliste de la situation en prenant du recul et en exami-nant des faits.

Observez en particulier les mesures qui vous montrent le com-portement du système afin d’aider l’équipe à comprendre son propre contexte. Les équipes évoluent dans des contextes spé-cifiques et sont affectées par une multitude de facteurs comme les politiques d’entreprise, les technologies utilisées ou encore la culture organisationnelle en général.

Des mesures comme le délai de mise en oeuvre (lead time) ou la durée du cycle (cycle time) vous permettent de comprendre com-bien de temps est nécessaire pour qu’une exigence ou un scéna-rio utilisateur passe à travers le processus. La première indique le temps écoulé entre le moment où la demande est effectuée et la livraison faite. La seconde indique plutôt le temps entre le début du travail et le moment où la fonctionnalité est prête à livrer. Le délai de mise en oeuvre est ce qui est perçu par le client.

Prenons un exemple, si une équipe complète tous les scénarios au cours du sprint durant lequel ils ont été amorcés, mais que le délai de mise en oeuvre est plus long, vous savez que vous devez examiner ce qui empêche les scénarios de parvenir à l’équipe (si le retard est avant le sprint) ou ce qui empêche les fonctionnalités d’être déployées (si le retard se situe après que la fonctionnalité soit terminée).

Un rythme soutenable

Un des buts de l’équipe est de trouver un rythme soutenable et constant dans la durée. Mais qu’est ce qui permet au Scrum Mas-ter de savoir si le rythme est soutenable? Il y a plusieurs pistes de réponses. Une d’entre elles suggère de mesurer le bien-être de l’équipe. Celui-ci est un indicateur du caractère durable du rythme en place.

Le succès se mesure à la production de valeur. Aidez l’équipe à mesurer la valeur qu’elle a produite. Il est tout à fait possible de produire des incréments de logiciel sans véritable valeur. Peu importe à quel point vous êtes efficaces pour produire des logi-

ciels, ce qui importe c’est le succès que ceux-ci rencontrent sur le marché. En tant que Scrum Master, vous devez aider l’équipe à comprendre si ce qu’elle produit a de la valeur. Il faut faire intervenir le Product Owner et le client afin de définir et valider la valeur produite.

La méthode Scrum indique implicitement la définition de valeur dans le carnet de produit (backlog). Si l’équipe n’est pas familière avec ce dernier, la vision et donc la valeur du logiciel demeure cachée. Il ne suffit pas de savoir sur quels scénarios travailler, il faut connaître le contexte qui dicte la nécessité d’une fonction-nalité. Que cherche-t-on à accomplir? Le Scrum Master doit s’assurer que la conversation a lieu régulièrement et que tout le monde s’entend sur la vision du logiciel qui est produit.

La boucle de rétroaction est peut-être l’outil le plus important pour les Scrum Masters. Il leur faut comprendre le type de feed-back qui est le plus utile à l’équipe pour qu’elle puisse accomplir son travail et permettre à cette rétroaction de lui parvenir le plus régulièrement possible. Un autre point important est de prévoir des canaux de rétroaction qui permettent à l’équipe de la recevoir avec l’esprit ouvert, sans y attacher de négativité.

Pour conclure, lorsque l’équipe s’approprie finalement le pro-cessus, on pourrait croire que la tâche du Scrum Master est terminée, mais elle ne l’est jamais complètement. Il peut alors se tourner vers les obstacles organisationnels. Après tout, son rôle est à la fois de contribuer au succès de l’équipe et à celui de l’entreprise dans son ensemble.

Le Scrum Master doit être en mesure de dresser un

portrait réaliste de la situation en prenant du recul et

en examinant des faits

Téléchargez la grille d’évaluation du Scrum Master sur savoiragile.com dans la section « Outils ». :

Choisir les cours de Pyxis, c’est un incontournable pour atteindre vos objectifs et assurer votre réussite.

THÈMES DE NOS COURS

Découvrez nos cours près de chez vous:pyxis-tech.com/formation

• Certifications Scrum • Management et leadership • Méthodes Agiles• Concepts et pratiques de génie logiciel • Gestion de projet et développement de produit

50 dates de cours par année96 % de clients satisfaits10 villes où suivre les cours de Pyxis

2004, l’année d’obtentionde notre certification Scrum

10000 participantsaux cours de Pyxis

5 formateurs certifiéspar Scrum.org

C

M

Y

CM

MY

CY

CMY

K

PubFormation_Option2_R3_NewPic_FR.pdf 1 2016-10-15 16:52:20

14

Magazine Savoir Agile • Automne 2016

savoiragile.com

Scrum a 21 ans et continue de grandir Dave West, Product Owner de Scrum.org

Collaboration spéciale

15

Magazine Savoir Agile • Automne 2016

savoiragile.com

L e 18 octobre 1995, dans le cadre de la conférence Object-Oriented Programming, Systems, Languages & Applications (OOPSLA)1, Ken Schwaber présentait une approche de livraison de logiciels nommée Scrum. Son texte jetait alors les bases d’un mouvement qui allait radicalement changer la façon de livrer les logiciels dans le monde entier. Ainsi, en supposant que 18 millions2 de personnes œuvrent dans la livraison de logiciels, et que 90 % des équipes3 se réclament de l’Agilité sous une forme ou une autre, Scrum étant présent dans 70 %4 des cas, c’est plus de 11 millions de personnes qui utilisent Scrum, au moins en partie. Et même si ces chiffres semblent très gros, il reste que Scrum est de-venu la norme de facto dans l’organisation des équipes et la livraison des logiciels. Comment ne pas parler de succès ?

Pour bien des gens, Scrum n’a pas tenu promesse

Ken Schwaber, cocréateur de Scrum, y va d’un point de vue intéressant : « Scrum a connu plus de succès que je n’au-rais imaginé, mais je suis encore déçu par la plupart de ses implémentations. »

Cette différence entre le succès d’adoption et la manière dont Scrum est adopté faisait l’objet de mon discours présenté conjointement avec Ken au Scrum Day London5. Nous y dé-crivions les problèmes liés aux implémentations de Scrum :

1. Le taux d’échec ou de difficulté des projets continue d’avoisiner les 60 %. Même si les projets Agiles continuent d’avoir trois fois plus de chances de réussir que les projets en cascade, l’amélioration véritable semble toujours utopique. Au cœur de Scrum se trouve la notion que les développeurs de logiciels professionnels se concentrent, à l’aide d’une approche empirique, sur ce qui importe pour créer une relation différente avec les clients et les intervenants, relation qui en retour engendre plus de succès dans les projets, produits et logiciels.

2. Un logiciel terminé n’est pas vraiment terminé. Comme en témoignent la livraison continue et les mou-vements DevOps, pour la majorité des organisations, un logiciel n’est pas « terminé » durant un sprint, mais requiert d’autres actions avant de passer à l’étape de la production. En fait, les développeurs de logiciels pos-sèdent plus de définitions du terme « terminé » que les Inuits n’ont de mots pour décrire la neige. Scrum et l’Agi-lité consistent en des livraisons fréquentes de logiciels fonctionnels à des clients qui donnent une rétroaction. Et lorsque Scrum utilise le terme « fonctionnel », il signifie « aussi près que possible de la production ». Une produc-tion qui, idéalement, procure une rétroaction à l’équipe.

3. Le « cascado-Scrum » est encore une réalité. En tant qu’analyste, j’ai inventé le terme « cascado- Scrum6  » pour décrire la réalité entourant l’adoption de l’Agilité par la majorité des grandes entreprises de TI. Et la tendance se poursuit. Ainsi, une approche comme le Scaled Agile Framework ou SAFe (Agilité dans un cadre étendu), bien que je la déconseille, s’inscrit dans cette mouvance cascaco-Scrum, où Scrum est confiné à de petites équipes, faisant que les entreprises ne profitent pas des avantages de l’Agilité opérationnelle.

4. Tout le monde prétend faire du Scrum. Mais le manque de régularité et de partage d’information engendre de la confusion et réduit les valeurs. Scrum gagnant en popularité, de plus en plus de personnes le pratiquent. Ce qui est bien, en autant qu’elles le pra-tiquent pour vrai. Scrum est un cadre de travail léger qui permet de la flexibilité, mais tout ce qui est léger n’est pas nécessairement Scrum. Le Guide Scrum procure une définition approuvée et définitive de ce qu’est Scrum, mais bien des gens ne l’ont pas lue et ne l’appliquent pas. Des consultants ont ajouté plusieurs bonnes choses à leur manière d’appliquer Scrum, mais ces ajouts l’ont complexifié et ont engendré de la confusion. Il est donc pratiquement impossible de s’assurer que les gens « de la

Le 18 octobre 1995, dans le cadre de la conférence OOPSLA1, Ken Schwaber présentait une approche de livraison de logiciel nommée Scrum.

Scrum a 21 ans et continue de grandir

16

Magazine Savoir Agile • Automne 2016

savoiragile.com

rue » qui disent connaître Scrum ont une vision cohérente de ce dont il s’agit.

En examinant ces quatre problèmes au regard des 20 prochaines années, notre communauté doit travailler à améliorer l’adoption de Scrum par des évaluations, aider les organisations à arriver plus vite à un produit « terminé », étendre la pratique de Scrum dans l’entreprise sans toutefois tomber dans la cascade et favori-ser une meilleure connaissance de Scrum.

L’évaluation doit porter sur la valeur, pas sur la rapidité

Les graphiques d’avancement et de rapidité sont d’excellents outils pour améliorer le rythme de travail ainsi que l’estimation et la planification. Mais ils ne font pas porter les efforts sur le succès du produit et son adoption professionnelle. L’Evidence- Based Measurement (EBM) consiste en un ensemble d’idées développées par Ken Schwaber, encourageant les organisations à se concentrer sur la valeur. L’EBM focalise, en effet, sur trois di-mensions : la valeur actuelle, le délai de commercialisation et la capacité d’innover. En tenant compte de la valeur, non seulement la relation change entre les équipes Scrum, le Product Owner et les intervenants, mais le changement des items du carnet de produit, la priorisation, l’élaboration de rapport et les revues de sprint sont aussi encouragés.

Terminé signifie vraiment terminé, pas presque terminé

Au cours des 21 dernières années, l’expression « potentiellement livrable » a permis aux professionnels de donner leur propre définition au terme « potentiellement ». À l’origine, sa significa-tion devait permettre au Product Owner de décider si un logiciel pouvait être livré, pas d’ajouter de la flexibilité à la définition de terminé ni de permettre à un logiciel non livrable de faire partie de l’incrément. Ajoutez à la confusion que l’incrément et la revue de sprint sont pris pour un processus à paliers7, et le logiciel ne sera pas livré régulièrement par l’équipe Scrum.

La livraison continue et le DevOps sont deux mouvements qui encouragent les équipes à intégrer les capacités de publication et d’opérations et à livrer du logiciel plus fréquemment. Ces mouvements ne sont pas différents de Scrum, mais leurs pra-tiques associées doivent être intégrées à la façon d’implémenter Scrum, en entourant le processus empirique central de Scrum de pratiques d’ingénierie modernes.

Intensifier la livraison de produit avec ScrumÉtendre l’Agilité comprend deux dimensions : la largeur, l’ajout d’équipes Agiles ; et la profondeur, l’ajout de groupes en amont et en aval de l’initiative Agile. Scrum a réussi à changer la façon de fonctionner des équipes en leur apportant une Agilité de manière incrémentielle. Logiquement, la prochaine étape d’intensification consiste à donner un pareil soutien aux équipes qui livrent un produit. Et Nexus8 , un exosquelette de Scrum, procure au cadre de travail Scrum des ajouts qui permettent à de multiples équipes Scrum de travailler ensemble de façon efficace.

Professionnalisme, valeurs et cohérence Scrum

Il y aura toujours des tensions entre l’établissement du processus qui vous convient à vous ainsi qu’à vos équipes et la mise en place cohérente et normalisée de l’approche de livraison de logi-ciels au sein de toute l’entreprise. Scrum favorise l’optimisation locale des équipes, ce qui ne signifie pas toutefois que celles-ci peuvent utiliser une terminologie et une approche incohérentes uniquement pour se démarquer. Dans le Guide Scrum9, la communauté Scrum fournit une définition claire de ce qu’est Scrum. Cette source de connaissance devrait se situer à la base des équipes qui utilisent Scrum, éliminant ainsi toute ambigüité quant à ce qui est ou n’est pas Scrum. Le Guide Scrum présente aussi les cinq valeurs de Scrum : concentration, engagement, ouverture, respect et courage. Toutes ces valeurs renforcent le système social qui soutient Scrum. Elles devraient toutes être au cœur des équipes qui l’utilisent.

La livraison de logiciel professionnel sera toujours empirique

La popularité de Scrum a amené bien des gens à remettre en question sa validité face aux projets modernes. Après tout, « moderne » implique une approche différente de livraison de logiciel, n’est-ce pas ? Mais au cœur de Scrum se trouve la notion que ce processus doit être empirique. Un tel processus empirique s’applique par l’inspection et l’adaptation au changement dans la transparence. Ces concepts se situent au-dessus de la techno-logie ou de la pratique; ils jettent les fondations de la livraison professionnelle de logiciel.

1 Pour lire le texte original : https://www.scrum.org/About/All-Articles/articleType/ArticleView/articleId/1043/Ken-Schwabers-Original-Scrum-Paper-The-Scrum-Development-Process2 D’après des données de 2014 d’IDC : https://www.infoq.com/news/2014/01/IDC-software-developers3 Point de vue relatif à l’adoption de l’Agilité : http://techbeacon.com/survey-agile-new-norm4 Étude de VersionOne sur l’état de l’Agilité : https://www.versionone.com/about/press-releases/versionone-releases-10th-annual-state-of-agile-report/5 Voyez une version de la même présentation faite au Scrum Day Europe : https://www.youtube.com/watch?v=HKrOG30-Xbk6 https://www.infoq.com/news/2011/12/water-scrum-fall-is-the-norm7 https://blog.scrum.org/sprint-review-not-phase-gate/8 https://www.scrum.org/Resources/The-Nexus-Guide9 Consultez le Guide Scrum : http://www.scrumguides.org/

17

Magazine Savoir Agile • Automne 2016

savoiragile.com

Formation et certification Scrum professionnel

Basé sur les principes de Scrum et du Manifeste Agile, Scrum.org offre une formation complète, des évaluations et des certifications en vue d’améliorer la profession du développement de logiciels. Dans le monde entier, nos solutions et notre communauté de formateurs en Scrum professionnel permettent aux gens et aux organisations d’atteindre l’Agilité via Scrum. Créateur de Scrum, Ken Schwaber a fondé Scrum.org en 2009 en tant qu’organisation internationale, se consacrant lui-même à améliorer la profession du développement de logiciels en réduisant les écarts entre travail et produits dans un objectif de fiabilité.

Visitez Scrum.org pour en savoir davantage sur les évaluations et les formations professionnelles Scrum ainsi que la communauté internationale de l’organisation. Suivez-nous sur Twitter @scrundotorg et lisez les billets de notre communauté d’experts sur le blog Scrum.org.

18

Magazine Savoir Agile • Automne 2016

savoiragile.com

Puisque les gens sont des êtres intrinsèquement complexes, comment peut-on décrire un groupe de personnes ou une équipe ? Nous utilisons le terme « équipe » pour nous identifier comme ayant un but, des valeurs ou des objectifs communs. Il s’agit d’une perspective ethnocentrique pouvant agir de catalyseur pour l’atteinte d’un objectif commun. Cependant, dans les orga-nisations, les équipes ne sont pas toujours formées sur une base volontaire, et les gens ne décident pas toujours de faire partie d’une équipe en raison de buts et de valeurs communs.

Il faut s’attendre à ce que des différences émergent. Il y aura des conflits et malentendus. Les comportements passifs-agressifs fe-ront aussi partie de l’équation ainsi que les non-dits. Ces compor-tements ne sont ni bons ni mauvais ; ils sont tout simplement ce qu’ils sont : l’expression de ce qui se passe à ce moment précis.

Parfois, on peut penser que les conflits, les malentendus et les non-dits vont affecter l’équipe de manière négative. Certains peuvent éprouver un sentiment de malaise qu’ils ont de la diffi-culté à supporter lorsque des émotions intenses sont manifestées, par exemple lors de disputes et de conflits. Ce même malaise peut aussi être éprouvé à l’autre extrémité du spectre des émotions. Certaines personnes sont mal à l’aise lorsqu’il y a manifestation de sentiments intenses comme l’amour et le désir.

Certains croient que l’éthique de travail exige que l’on reste calme, que l’on contrôle nos émotions ou même qu’on les refoule et les exprime uniquement à la maison. Mais à quoi cela contribue-t-il vraiment ? Le sentiment que le travail est frustrant et qu’il n’y a pas de soutien pour gérer ces émotions s’intensifie au fil du temps et cela peut mener à la dépression ou à d’autres maladies.

Voici comment guider les équipes dans des conversations teintées d’émotions :

• Mentionnezaugroupequecertainsélémentsousujetsdélicatsont été portés à votre attention.

• Demandezaugroupes’ilaimeraitaborderlaquestion.S’ilrefuse catégoriquement, n’insistez pas. Si vous remarquez une légère hésitation, aidez-le à voir les avantages et désavantages d’aborder le sujet.

• Demandezaugroupelapermissiondefaciliterlaconversa-tion. Ne supposez pas qu’il vous l’a donnée.

• Établissezlesrèglesdebaseensemble.Envoiciquelquesexemples : être respectueux , ne pas interrompre la personne qui parle , être présent pour les autres et écouter.

• Utilisezleformatdelaconversationouverte,encercleetsansaucun obstacle au centre.

• Facilitezlaconversationenlaissantlaplaceàchacund’expri-mer ouvertement son point de vue. Évitez l’utilisation d’outils ou la ludification (gamification) comme moyen de soutenir la conversation.

• Assurez-vousquechacunapudonnersonpointdevue.

• Restezneutre.

• Pratiquezlareformulationetdemandezaussiauxparticipantsde reformuler ce qu’ils entendent afin de s’assurer de bien comprendre les autres points de vue.

• Demandezàl’équipedetirerdesconclusionspersonnellesetde groupe qui pourront lui servir de lignes directrices, valeurs et principes.

Vous pourrez parfois vous sentir perdu ou incapable de soutenir la conversation. Soyez alors transparent et informez-en le groupe. Dans ce cas, il pourrait être plus avantageux pour l’équipe que quelqu’un d’autre facilite la conversation.

Un des atouts les plus importants à titre de facilitateur, c’est d’être à l’aise avec le plus de perspectives possible ; y compris les émo-tions fortes, la divergence, le pouvoir, la dualité, la neutralité et les préjugés pour n’en nommer que quelques-unes. Songez à suivre un cours de facilitateur professionnel qui vous permettra de navi-guer dans une multitude de perspectives sans vous sentir démuni.

Après tout, la facilitation est une des activités les plus récurrentes dans le quotidien des coachs, des Scrum Masters, des directeurs et même des parents.

Mon équipe a des problèmes de communication. Pendant les rétrospectives de sprint, les vrais sujets ne sont pas abordés. Quels moyens puis-je utiliser pour aider l’équipe à mieux communiquer et à progresser ?

La question au coach

Marc-André Langlais, coach Agile

19

Magazine Savoir Agile • Automne 2016

savoiragile.com

• la qualité ;• la satisfaction ;• la valeur produite ;• les relations ;• la capacité à innover ;• la productivité ;

• les résultats financiers ;• le time-to-market ;• l’adéquation de l’outillage ;• les compétences ;• la capacité à arrêter des

projets.

Cette question est très intéressante. On la pose régulière-ment, et chaque fois elle m’étonne pour plusieurs raisons.

En premier lieu, la petite voix dans ma tête se dit : « Mais pour-quoi donc se poser cette question seulement 6 mois après avoir démarré le projet ? N’ont-ils pas choisi l’Agilité et Scrum pour atteindre des objectifs ? N’ont-ils pas envisagé de mesurer leur progrès par rapport aux objectifs fixés ? »

Je m’interroge aussi sur la transparence de l’équipe Scrum. Comment se fait-il qu’elle n’ait pas établi des critères ou indica-teurs lui permettant de s’évaluer et qu’elle ne les ait pas affichés ?

Beaucoup d’autres questions (et souvent même des jugements) émergent !

Ensuite, j’ai envie de décortiquer la question posée, car cette idée de la mesure, de présenter les progrès faits est hautement contex-tuelle et tourne parfois à l’obsession.

Beaucoup d’éléments sont à considérer. Par exemple, qui pose la question ? Qui est le « on » dans la deuxième phrase ? Qui a instauré la démarche Agile ? Pourquoi avoir choisi le cadre Scrum ? Avec quels objectifs ? Il y en a un seul ou plusieurs ? À quel niveau de l’entreprise est portée la démarche ? Qui a besoin d’obtenir une réponse et pourquoi ? Quelle est la culture de l’entreprise en ce qui concerne des sujets comme la mesure, la performance, le droit à l’erreur, la relation au temps ? Dans quelle situation étions-nous au moment de démarrer le projet ?

Bref, vous voyez que nous pourrions passer beaucoup de temps juste à explorer cette question avant même de commencer à donner des éléments de mesure liés à la démonstration du progrès.

Avant de proposer une longue liste d’indicateurs clés de perfor-mance (key performance indicators ou KPI), j’aimerais proposer la démarche suivante à ce « nous » dont il est question :

1. Cherchez à comprendre ce qui est attendu et pour cela réunis-sez les personnes concernées (votre équipe ainsi que le « on » [il s’agit souvent de plusieurs personnes]).

2. Établissez collectivement ce qui est important pour l’entre-prise, le produit ou le projet que vous êtes en train de réaliser

ainsi que pour chacune des personnes impliquées.

3. Déterminez les objectifs de performance, les indicateurs et la façon de communiquer les résultats qui vont permettre à tous de constater l’avancement (transparence).

4. Organisez ensemble une revue régulière afin d’inspecter les progrès et de s’adapter en conséquence. Tiens, on dirait une démarche empirique !

Là, je vous entends dire : « C’est bien gentil ces beaux discours, mon bon monsieur, mais auriez-vous des idées concrètes de mesures à mettre en place ? » Oui, et il y en a beaucoup.

Vous pouvez mesurer l’avancement selon les thèmes suivants :

De plus, pour chaque thème, de nombreux indicateurs peuvent être mis en place et suivis.

Et la « fameuse » vélocité dans tout cela, me direz-vous ? Et bien, ce n’est pas un indicateur de progrès. Alors, utilisez-la, mais à bon escient.

Vous l’aurez compris, pour moi le progrès se mesure en fonc-tion d’objectifs, et pour cela je crois qu’il faut être clair sur le « pourquoi ». Ensuite, vous pouvez établir des objectifs partagés par l’ensemble des acteurs, choisir des KPI utiles et pertinents, mesurer en transparence...

N’oubliez pas de couvrir les différentes facettes de votre contexte (affaires, technologies, humain, processus, etc.) et, s’il vous plaît, ne liez pas ces mesures à l’évaluation annuelle ni aux primes de rendement. Mais c’est un autre vaste sujet !

Maintenant, il ne reste plus qu’à s’inspecter et à s’adapter.

Depuis 6 mois, nous mettons en place Scrum dans l’équipe. On nous demande de présenter nos résultats et les progrès que nous avons faits grâce à cette approche. Que devons-nous mesurer afin de démontrer notre apport ?

La question au coach

Tremeur Balbous, coach Agile

La question au coach

Depuis 6 mois, nous mettons en place Scrum dans l’équipe. On nous demande de présenter nos résultats et les progrès que nous avons faits grâce à cette approche. Que devons-nous mesurer afin de démontrer notre apport ?

20

Magazine Savoir Agile • Automne 2016

savoiragile.com

Pourquoisi pressé?

Steffan Surdek est un de nos contributeurs clés sur Savoir Agile. Il y parle souvent de leadership et pour cette édition toute spéciale de notre magazine, nous avons pris le temps de nous asseoir avec lui pour qu’il nous parle des défis que rencontrent les organisations en matière de leadership et qu’il a pu observer dans le contexte de son travail de coach.

Savoir Agile : Bonjour Steffan, peux-tu nous parler de toi ?

Steffan : Je suis à Pyxis depuis plus de 5 ans. Je suis conseiller principal, formateur, auteur et également conférencier. Chaque jour, j’aide nos clients à faire évoluer leur culture et à adopter des pratiques Agiles dans leur organisation. J’ai toujours été un mordu de leadership et, depuis 3-4 ans, mon travail consiste surtout à aider les leaders à libérer leur potentiel.

Quel est le plus grand défi des leaders dans les organisations où tu travailles ?

La taille et la forme des clients varient, mais ce qui me fascine particulièrement, c’est l’impatience des gestionnaires et des dirigeants quant à la vitesse du changement. Ce qui me fascine encore plus, c’est que plusieurs d’entre eux ne réalisent pas les répercussions de leur impatience sur leurs équipes et leur organisation.

Malheureusement, plusieurs ne semblent pas réaliser que les gestes qu’ils posent en réponse à cette impatience empirent sou-vent le problème plus qu’il ne le résout.

Pourquoi les organisations sont-elles si pressées ?

Je constate que beaucoup de cultures organisationnelles exigent vitesse et résultats. Ces cultures poussent les gens le plus possible et le plus longtemps possible. Dans ces organisations, les leaders exigent beaucoup d’eux-mêmes et de leurs employés.

Lorsque ces entreprises entendent parler de pratiques Agiles de développement logiciel, ce qu’elles comprennent fait parfois plutôt peur. Parmi les fausses idées qu’elles se font relativement à la vitesse, celle que je préfère, c’est que l’on est supposé livrer plus rapidement quand on est Agile. Ainsi, ce qui prenait neuf mois à livrer devrait maintenant en prendre seulement trois.

Dans ce type d’organisation qui cherche une sorte de Saint Graal, on ne perçoit pas la partie de l’équation Agile qui concerne le changement humain et le changement de mentalité. On se concentre plutôt sur les processus et le besoin de les optimiser.

Lorsque j’aborde le changement avec les leaders de ces organi-sations, il semble que ça ne va jamais assez vite, mais je me de-

Entrevue Savoir Agile

Avec Steffan Surdek, conseiller Agile et formateur

21

Magazine Savoir Agile • Automne 2016

savoiragile.com

mande souvent : pas assez vite pour quoi ? Pourquoi faut-il aller si vite ? Le plus curieux, c’est que lorsque je leur pose la question, souvent je n’obtiens pas de réponse claire. Cependant, une chose est sûre, ça ne va pas assez vite.

À quoi ça ressemble des leaders pressés ? Comment agissent-ils ?

Étant donné la nature de mon travail, je rencontre les leaders organisationnels dans des contextes variés comme des cours de formation, ateliers et mandats de consultation. Chacun de ces contextes m’offre une perspective différente de leur culture organisationnelle et de la façon dont celle-ci pousse les leaders à agir. Cependant, là où j’en apprends le plus, c’est lorsque je vois les leaders interagir avec leurs équipes durant des ateliers ou mes mandats de consultation.

Ce que je perçois souvent ce sont des signes physiques d’impa-tience de la part des leaders. Lorsque des conversations semblent stagner, ils interviennent et poussent les gens dans la direction où ils souhaitent aller. Lorsque les conversations ne vont pas dans la direction souhaitée, ils interviennent et intimident leurs employés pour qu’ils se conforment à leur idée (sans le vouloir ou peut-être même volontairement).

Qu’est-ce qui découle de cette impatience ? Comment travailles-tu avec eux ?

Ce qui est intéressant, c’est que lorsque je parle avec ces leaders, que ce soit avant, pendant ou après mon mandat, plusieurs expriment verbalement leur impatience. Certains me disent combien ils souhaitent que leurs équipes « s’activent sinon… », alors que d’autres expriment leurs frustrations relatives à leurs employés en disant qu’ils ne comprennent tout simplement pas.

J’essaie de les écouter attentivement et sans jugement, mais le pattern qui revient souvent, c’est qu’ils ne prennent aucune part de responsabilité sur ce qui se passe dans leurs propres équipes.

Ils ne se rendent pas compte que lorsqu’ils intimident les membres de leurs équipes ou qu’ils imposent leurs idées, ils ne font que détruire tout engagement de ceux-ci. Ils ne remarquent pas que durant les réunions de brainstorming, ils parlent plus que leurs employés, fournissent les solutions, posent des questions fermées et ne permettent pas aux autres de dire ce qu’ils pensent.

Lorsqu’ils me parlent de combien leurs employés ne com-prennent pas, ils expriment rarement la partie qui les concerne, soit le fait qu’ils ne savent pas comment renforcer les capacités de leurs équipes. Ce qui m’attriste, c’est qu’ils reconnaissent rarement que ça fait pourtant partie de leur rôle à titre de leaders dans l’organisation.

À titre de coach, comment te sens-tu quand tu vois les leaders adopter de tels comportements ?

Quand je vois les leaders imposer leurs idées, très souvent je ressens beaucoup d’empathie pour eux. La collaboration et la communication ne sont pas des compétences que l’on acquiert à l’école. Dans la vie et au travail, on est souvent évalué en fonc-tion de notre performance individuelle, alors pourquoi de-vrions-nous collaborer ?

J’ai beaucoup d’empathie pour les leaders, aussi parce que souvent ils appliquent ce qu’ils voient dans leur culture organi-sationnelle respective et, pour être tout à fait honnête, à cause de cela, ils ne savent souvent pas qu’il existe d’autres façons de faire.

Le pattern qui revient souvent, c’est que les leaders ne prennent

aucune part de responsabilité sur ce qui se passe dans leurs

propres équipes

Pourquoisi pressé?

22

Magazine Savoir Agile • Automne 2016

savoiragile.com

Qu’as-tu remarqué d’autre à propos d’eux ?Chez plusieurs clients, je remarque des patterns similaires où les gens ont une vision du monde qui est très égocentrique. L’impor-tant, c’est ce qu’ils veulent accomplir et les besoins qu’ils veulent combler à titre individuel. Lorsque j’essaie d’élever le niveau de la conversation, par exemple à un niveau ethnocentrique, en parlant de ce qui serait le mieux pour le groupe, plusieurs sont désarçonnés. Dans la même discussion, ils continuent de parler de manière égocentrique.

À quoi t’attends-tu d’un leader dans une organisation ? Que de-vrait-il faire différemment ?

Le vrai travail d’un leader, c’est d’élever son discours et son travail à un niveau ethnocentrique. Quelle est la vision que l’on a pour sa tribu ? Comment veut-on qu’elle soit connue ? Quel est le défi

qu’elle rencontre qui fait que tous devraient joindre leurs efforts pour atteindre un but commun ?

Et quand on commence à vraiment habiter cet espace, comment peut-on agir différemment ? À quoi ressemble le succès doré-navant ? Quels sont les résultats que l’on souhaite maintenant atteindre ?

Pour vous donner un exemple concret de ce que je vois souvent, dans une rencontre qui est au point mort parce que les gens ont de la difficulté à communiquer ensemble, comment peut-on tra-vailler à partir de cet espace ethnocentrique et les aider à déve-lopper la capacité dont ils ont besoin pour s’améliorer et aller de l’avant ? C’est facile de bousculer les gens, mais il faut beaucoup plus de compétences et de patience pour créer quelque chose qui va avoir une vie qui lui est propre et durer.

Comment fais-tu pour présenter l’Agilité à tes clients ?

Je ne travaille plus vraiment avec l’intention de faire des trans-formations Agiles. Ne vous méprenez pas, je vais continuer d’ac-compagner les organisations dans leur utilisation des pratiques Agiles et Lean, mais ça fait partie d’un dessein plus grand que nous tentons d’accomplir ensemble.

Lorsque j’aborde le changement avec les leaders de ces organisations, il semble que

ça ne va jamais assez vite, mais je me demande souvent :

pas assez vite pour quoi ?

Assistez à l’une de nos séances de formation Management 3.0.pyxis-tech.com/management30/

C

M

Y

CM

MY

CY

CMY

K

PubManagement3.0_PostIT_FR_V4.1.pdf 1 2016-10-15 11:58:23

23

Magazine Savoir Agile • Automne 2016

savoiragile.com

Simplement dire « nous adoptons l’Agilité », ça ne veut pas dire grand-chose. Je vois des équipes qui tiennent des rencontres de planification de sprint, des mêlées quotidiennes, des revues de sprint et des rétrospectives, alors que peu parmi les personnes présentes comprennent ce qu’elles doivent faire pendant ces réunions.

Le défi, c’est que si on leur en fait part, elles vont dire que tout se passe bien parce qu’elles peuvent cocher les cases se trouvant à côté de chacun de ces éléments. Elles ne savent tout simple-ment pas ce qu’elles doivent savoir, mais elles se conforment aux exigences et tiennent les réunions prévues.

L’existence de telles équipes résulte du fait qu’on veut aller vite. Les leaders veulent prendre des raccourcis. Mais, savez-vous quoi ? Ça ne marche pas ! On peut payer maintenant ou payer plus tard, mais il y a un prix à payer pour bien intégrer le chan-gement.

Comment les leaders peuvent-ils stimuler les gens dans leur organisation ?

Il faut tout d’abord qu’ils soient clairs sur la vision qu’ils ont pour leur tribu. Comment veulent-ils qu’elle soit connue ? Comment lui partagent-ils cette vision et, encore mieux, comment l’im-pliquent-ils activement dans la définition de la vision et dans son application ? Quel est l’avenir sombre auquel la tribu aura à faire face par défaut qui fait que tous devraient joindre leurs efforts pour atteindre un but commun ?

Quels sont les éléments clés que tu aimerais que les leaders retiennent après avoir lu notre conversation ?

Cette année, un des éléments clés que je partage souvent avec les clients, c’est la distinction qu’il faut faire entre conformité et engagement. Dans cette course pour atteindre des résultats, les leaders réalisent-ils l’impact de leur impatience sur leur style de leadership personnel ? Quel est le résultat de leur style de leadership sur leurs équipes ? Est-ce que cela crée un climat de peur en assurant la conformité ou est-ce que cela provoque de

l’excitation et favorise l’engagement ?

Le piège que les leaders doivent éviter c’est de penser qu’on ne détecte pas leur impatience. Les gens comprennent assez vite quand ils voient le leader gigoter sur sa chaise pendant les réu-nions ou quand celui-ci rabroue les personnes qui ne disent pas ce qu’il souhaite entendre. Aussi, lorsqu’il ne prend pas le temps de vraiment écouter ses gens exprimer leurs inquiétudes et d’agir pour dissiper celles-ci ou lorsqu’il ne veut pas écouter leurs points de vue… Croyez-moi, ils le savent.

Par conséquent, si le changement est quelque chose d’important pour le leader, comment peut-il le communiquer à ses équipes ou dans l’organisation ? Comment peut-il amener les gens à prendre part au changement et réussir à exploiter les idées de tout le monde ? Quelle est sa part dans le développement de la capacité des autres à assurer la pérennité du changement ?

Cependant, la question la plus importante c’est comment fait-il pour élever son leadership afin de créer de l’espace pour les gens autour de lui et vraiment les soutenir ?

Le vrai travail d’un leader, c’est d’élever son discours et son travail à un niveau ethnocentrique. Quelle est la vision que l’on a pour sa tribu ?

À propos de Steffan

Depuis près de vingt ans, Steffan navigue dans le monde du développement logiciel, jouant tous les rôles de la définition des exigences, à l’architecture, en passant par le codage et les tests. Au cours des dernières années, il a travaillé dans de grandes entreprises où il a développé son expertise en utilisation des pratiques Agiles dans des équipes distribuées. Il est l’un des auteurs du livre « A Practical Guide to Distri-buted Scrum ».

Steffan est reconnu pour son leadership, son habileté à communiquer ainsi que sa nature hautement collaborative qui contribuent aux succès des projets auxquels il participe.

24

Magazine Savoir Agile • Automne 2016

savoiragile.com

Développer des équipes exige communication et perspective Diane Musho Hamilton, cofondatrice de Ten Directions

Collaboration spéciale

25

Magazine Savoir Agile • Automne 2016

savoiragile.com

En tant que médiatrice, j’ai commencé à m’intéresser au développement des adultes à l’époque où j’animais des échanges sur le système de justice pénale et sa relation avec les gens de couleur aux É.-U. Nos conversations portaient sur des sujets habituellement ardus et complexes – des questions liées aux privilèges des Blancs, à la race et la justice. C’est pendant cette période que j’ai commencé à remarquer les nombreuses aptitudes des gens à parler des différences et à interagir avec les différences.

J’ai remarqué, par exemple, qu’il y avait des gens qui ne pouvaient tout simplement pas distinguer un problème et d’autres qui s’enflammaient à la seule possibilité d’un chan-gement. Certains étaient respectueux et impartiaux, partici-pant de leur mieux, mais sans vraiment prendre de risque. D’autres étaient en colère et dominants.

Puis j’ai remarqué qu’il y avait aussi des personnes d’excep-tion, capables d’être tout ça en même temps. Elles pouvaient être à l’aise avec un état de choses, mais aussi se montrer exigeantes et furieuses, ou encore ingénieuses et ambitieuses.

En même temps, lors des réunions, je notais que certaines personnes pouvaient adopter différents points de vue, alors que d’autres n’en avaient qu’un seul – le même que tout le monde dans le groupe. Ceux qui pouvaient adopter diffé-rentes perspectives me fascinaient, et j’ai particulièrement aimé travailler avec eux.

Peu après, j’ai découvert le travail de Ken Wilber, qui fait référence à de nombreuses recherches sur le développement humain adulte. Ken met particulièrement l’accent sur un as-pect essentiel de ce développement : la capacité d’adopter de plus en plus de perspectives. Il décrit pourquoi la plupart des disciplines – médiation, communication, affaires, médecine, éducation – devraient se pencher plus sérieusement sur la façon dont les humains se développent.

Le développement, ou le désir de continuer à grandir, semble gravé sur notre « disque dur ». Au cours de notre vie, nous tendons vers un plus grand nombre de perspectives et vers la

complexité. Un bébé apprend à marcher et à parler; un enfant qui devient adolescent commence à percevoir le monde de manière différente. En milieu naturel, l’évolution consiste toujours à passer des structures simples aux structures de plus en plus complexes. En tant qu’humain, notre dévelop-pement accroît nos aptitudes à porter attention, à recevoir, à ressentir de l’empathie et à performer. Nos capacités augmen-tent, nous développons plus de compassion. Nous pouvons démontrer davantage d’inclusion et faire de plus en plus de place à la différence sans avoir besoin de considérer la réalité d’un angle unique.

À mesure que je faisais ces distinctions, je constatais que la capacité des gens à se manifester et à réussir en situation de collaboration dépendait de leur habileté à se développer. Jusque là, j’avais étiqueté les gens comme sympathiques ou antipathiques, bien disposés ou désintéressés. Mais d’un angle développemental, je commençais à constater que certaines personnes sont littéralement incapables d’adopter différentes perspectives, tout comme les tout-petits sont incapables de courir.

En un sens, nos points de vue nous ancrent à la réalité. Si pour moi A est vrai, mais que vous dites que c’est B qui est vrai, alors l’introduction de B dans mon esprit ébranle soudainement mon rapport à la réalité. L’incertitude prend forme – il en découle de l’anxiété, un manque de fondement, de l’insécurité. Nous avons alors tendance à nous accrocher à une perspective unique pour que le monde nous semble plus solide. Ce genre de tension se manifeste chaque fois que nous

En tant que médiatrice, j’ai commencé à m’intéresser au développement des adultes à l’époque où j’animais des échanges sur le système de justice pénale

Nous avons tendance à nous accrocher à une perspective

unique pour que le monde nous semble plus solide

26

Magazine Savoir Agile • Automne 2016

savoiragile.com

vivons un conflit ou que nous tentons de rassembler un groupe de personnes autour d’une vision commune, d’une idée sur la façon de progresser.

À un moment donné, il peut arriver qu’on s’intéresse davantage aux différences. On découvre qu’un autre point de vue nous aide à voir le monde à travers un plus grand objectif, même si on en éprouve une certaine instabilité. On commence alors à déve-lopper un goût pour la différence. Plus on s’y habitue, plus on y puise des renseignements. Et bientôt, notre perception du monde est plus riche qu’avant. Dans ce processus, il arrive qu’on perde un sentiment de stabilité, mais on développe une liberté et une ouverture incroyablement gratifiantes. On arrive à supporter un certain manque de fondement, parce que le sentiment de déve-loppement s’avère très enrichissant.

J’ai entendu dire qu’on atteint régulièrement un plateau au cours de nos apprentissages, et ce, jusqu’à ce qu’une difficulté se présente – maladie, perte ou divorce. Bien que douloureuses, ces expériences nous obligent à sortir du statu quo, ce qui engendre une nouvelle énergie, une nouvelle croissance. On peut s’en trouver ébranlé, mais l’intérêt l’emporte. Le même phénomène prévaut dans notre vie de tous les jours et dans notre milieu de travail. À mesure que nous développons nos aptitudes à commu-niquer avec les gens qui ont une perception différente, que nous acceptons la différence au lieu de l’éviter, les choses deviennent plus intéressantes. Notre milieu de travail devient plus créatif et excitant. Des études montrent même que les organisations qui jouissent d’une plus grande diversité sont des leaders en matière d’innovation.

Au cours de mes formations, je propose un exercice dans lequel les gens doivent penser à un moment où leur perspective a changé alors qu’ils voyaient le monde d’un certain angle et qu’un événement s’est produit pour tout remettre en question. Imman-quablement, quand les gens se rappellent d’un tel changement de perspective, c’est pour l’apprécier. Ils sentent que les choses ont changé pour le mieux, même si c’était douloureux à l’époque.

En quoi ces habiletés relationnelles améliorent-elles un milieu de travail ? Il nous suffit de prendre pour exemple une récente étude1 menée par Google sur les qualités des équipes performantes. On a découvert que leur environnement est riche en sécurité psychologique, autrement dit que chaque membre est encore respecté même s’il a fait des erreurs ou pris des risques. Les gens se soutiennent mutuellement. Les conflits y sont perçus comme des générateurs d’opportunités – ils surviennent, ils sont réglés, et tout le monde repart. On ne s’y enlise pas en d’interminables luttes de pouvoir. On n’y trouve pas de combat tacite, de conflit de compétences et de joute politique qui nuisent au plaisir d’être ensemble. En lieu et place, il y a l’aisance, l’efficacité, la créativité et même la joie. Travailler dans un pareil environnement est une source de plaisir qui débouche sur des capacités ainsi qu’une créativité supérieures.

Un autre point de vue sur la valeur de la communication et des relations provient de l’étude à long terme menée par Harvard, la Grant Study2, qui s’est penchée sur le bien-être et le bonheur des diplômés masculins de Harvard. On y a observé qu’à mesure que les hommes vieillissaient, le bonheur des individus correspondait à la persistance et à la profondeur de leurs relations. Les gens qui étaient capables d’accepter l’émotivité, de gérer la douleur et de partager la dimension émotive de la vie avaient tendance à se trouver plus heureux. Plus on vieillit, plus les valeurs profondes liées aux relations et aux contacts prennent de l’importance. Il est évident que ces aptitudes font une grande différence à long terme. À la fois sur notre capacité à performer et à collaborer avec les autres et sur notre bien-être à venir.

Mon travail en formation et en développement suppose essen-tiellement que les gens peuvent grandir et changer. Et je crois que nous sommes tous capables d’en faire plus si on s’en donne la peine. Là où l’on peut faire évoluer notre conception de la réalité par un plus grand nombre de points de vue, il y a du plaisir. Plus on se développe, plus on peut vraiment adopter davantage de perspectives et contribuer à la vérité dans un groupe. Et lorsqu’on peut aider les autres à tolérer la différence et à développer leurs aptitudes à assimiler davantage de perspectives, on favorise le changement de tout le système. Ces aptitudes nous aident non seulement à grandir, mais elles influent aussi beaucoup plus qu’on ne l’imagine sur les autres.

On découvre qu’un autre point de vue nous aide à voir le monde à travers un plus grand objectif. On commence alors à dévelop-

per un goût pour la différence

1 Étude de Google : http://www.theatlantic.com/magazine/archive/2013/05/thanks-mom/309287/2 Étude Grant Study : http://www.nytimes.com/2016/02/28/magazine/what-google-learned-from-its-quest-to-build-the-perfect-team.html?_r=2

27

Magazine Savoir Agile • Automne 2016

savoiragile.com

28

Magazine Savoir Agile • Automne 2016

savoiragile.com

Dans un souci constant d’améliorer nos façons de faire et afin de dresser un portrait fidèle de l’état actuel de l’Agilité en entreprise, Pyxis Technologies a sollicité son réseau pour répondre à quelques questions. Il nous fait plaisir de vous présenter les résultats de notre enquête.

Enquête Savoir Agile

Bien que les approches Agiles existent depuis plus de 10 ans, elles demeurent nouvelles dans la plupart des entreprises. Selon l’enquête, 67,7 % des répondants appliquent ces ap-proches depuis moins de 4 ans.

Nous avons demandé aux gens pourquoi ils ont décidé de prendre le virage Agile. Voici les

raisons en ordre d’importance :

- de 4 ans

+ de 4 ans

Accroître la productivité de

l’équipe de développement

Réduire le temps de mise

en marché Accroître la flexibilité

Augmenter la qualité des

logiciels

Assurer la satisfaction de

la clientèle

L’enquête révèle que Scrum est la méthode Agile la plus répandue. Parmi les répondants, 93,1 % utilisent Scrum.

Par ailleurs, cette méthode est souvent utilisée en conjugaison avec d’autres pratiques, soit :

55,5%

23,4%20,3%

18,3%Ka

nban

Scru

m

Agile

Le

an

DevO

ps

Scru

m d

e Sc

rum

29

Magazine Savoir Agile • Automne 2016

savoiragile.com

L’enquête a été menée par Pyxis du 7 septembre au 11 octobre et 293 répondants y ont participé.Si vous avez des questions ou commentaires concernant l’enquête, n’hésitez pas à communiquer avec marketing@pyxis-tech.com.

Même si l’Agilité amène beaucoup de défis aux grandes entreprises, les approches Agiles sont plus courantes dans les grandes organisations. Ainsi, 68,3 % des personnes ayant participé à l’enquête travaillent dans des organisations comptant plus de 100 employés.

+ de 100

L’adoption d’une approche Agile amène son lot de défis et de difficultés. Les difficultés les plus souvent rencontrées chez nos répondants sont les suivantes :

culture organisationnelle difficile à changer

résistance au changement

76,9%

65,8%

Les répondants de l’enquête utilisent les artéfacts et cérémonies suivants :

89,8%

88,1%

82,6%

79,5%

76,5%

72,4%

71,7%

Mêlée quotidienne

Rétrospective de sprint

Revue de sprint

Carnet de produit

Définition de « terminé »

Estimation en équipe

Carnet de sprint

1234

5

5 choses à ne pas oublier pour réussir vos mêlées quotidiennes :

On se réunit autour du carnet de sprint.

Après 15 minutes, on s’en va.

On reste debout.

On explique à tour de rôle ce qui suit :- ce qu’on a accompli hier;- ce qu’on va faire aujourd’hui;- s’il y a des obstacles qui empêchent d’atteindre l’objectif du sprint.

On arrive préparé pour communiquer efficacement.

Pour connaître les résultats complets, visitez le site savoiragile.com.:

30

Magazine Savoir Agile • Automne 2016

savoiragile.com

Richard Martin, coach organisationnel

L’organisation gérée par la valeur

31

Magazine Savoir Agile • Automne 2016

savoiragile.com

La complexité empêche de bonnes prédictions et l’Agilité suggère des itérations et des réalignements qui optimisent la pertinence de l’action. Aujourd’hui, tout est plus turbulent, plus rapide et plus enchevêtré, et ce, sur les plans organisationnel, budgétaire, technologique, économique et de la clientèle. L’ho-rizon visible et certain est réduit. Une organisation Agile opère sur des postulats d’adaptabilité et cherche tout simplement des moyens pour se mettre en position de réponse globale face aux multiples enjeux.

Les modèles de gestion traditionnels rigidifient les organisationsDepuis des lunes, un penseur joue le rôle d’architecte du futur. Il élabore la vision et donne à un entrepreneur général la mission de faire un plan. Souvent, il va mettre en concurrence plusieurs entrepreneurs pour obtenir le meilleur plan, en fait non, le plan le moins cher. Cela fait, le plan est exécuté tel que spécifié et on suppose que les bénéfices seront obtenus.

Voici le processus :

1) Idée intuitive

2) Détermination des bénéfices escomptés

3) Conception de la solution

4) Analyse de faisabilité

5) Plan de livraison optimisé (coûts, spécifications, délais)

6) Budget

7) Réalisation du plan (coûts, spécifications, délais)

Ce mode est plutôt efficace dans des situations simples qui ont un horizon court. Dans la complexité et la turbulence, il tient moins la route. Le taux d’échec des projets rapporté depuis des décennies le prouve. En fait, tout le monde surveille le plan au lieu de surveiller les bénéfices. La pensée magique, c’est qu’un bon plan garantit l’obtention des bénéfices.

Souvent même, le donneur d’ordre va jouer à l’expert aux étapes 1, 2 et 3 sans bien saisir les contraintes et les opportunités que rencontre l’entrepreneur. De nos jours, cette façon de faire perd bien sûr de son lustre dans la turbulence, la complexité et le changement. Le modèle de gestion par la valeur en AgilitéPrenons comme simple hypothèse que ce qui est important ce sont les bénéfices concrètement obtenus. On demande alors à l’entrepreneur de venir optimiser la conception de la solution avec l’architecte, en simultané, car il connaît son affaire. Vous voyez la différence : le plan est au service de la solution, au ser-vice des bénéfices, et ce, tout au long des étapes.

Cependant, le plan peut changer. Dans la complexité, c’est très utile. On valide les bénéfices tangibles obtenus au fur et à me-sure, quitte à amender la solution selon les apprentissages. Si cela vous importune de changer le budget, maintenez-le fixe et opti-misez la valeur. Si le ratio valeur-budget diminue, stoppez le pro-jet, mais l’idée c’est surtout d’optimiser la solution. C’est un état d’esprit en soit. Il faut mettre les équipes en mode innovation et apprentissage pour qu’elles tendent à produire des solutions qui génèrent la quantité instantanée maximale de valeur tout au long de l’exécution (QIX). QIX est un acronyme employé en hydrométrie représentant le débit instantané maximal que peut donner une rivière. Si votre

La gestion Agile élimine les longues feuilles de route prédéterminées, les plans qui prétendent prévoir en détail les moyens et les résultats.

32

Magazine Savoir Agile • Automne 2016

savoiragile.com

organisation, vos opérations ou vos projets sont des flux de valeur, quel en est le débit maximal ? Quel est le QIX de votre projet, de votre service ? Vous connaissez vos budgets, le nombre de jours-personnes alloué, mais visez-vous un QIX ? En fait, avez-vous une cible mesurable de valeur finale à livrer ? Serait-ce avantageux de mesurer votre débit de valeur par mois ou par itération et d’en discuter avec vos clients et entre vous ? Condui-sez-vous votre voiture en validant toujours la destination et votre vélocité (votre QIX) ou vous concentrez-vous sur la jauge à essence et le parcours initial du GPS ?

La gestion adaptative par la valeur permet de remettre à l’agenda ce qui suit : POURQUOI on fait les choses, quelles sont la raison d’affaires et la valeur concrète… Un indicateur QIX, par un graphique Sunset Agile, nous dégage de la gestion traditionnelle déterministe qui prend la trop forte hypothèse qu’un bon plan bien pensé remplit nécessairement sa promesse. Ce postulat n’est applicable qu’en terrain connu, simple. Dans la turbulence et la complexité, vous devez réagir, réinterpréter les contraintes et les opportunités, réaligner le tir, rester collé au QIX possible.

65 % des fonctionnalités livrées ne seront pas utiles pour le clientCe constat est souvent émis. Même le client sait très peu ce qu’il veut dès le début, surtout s’il doit prévoir à long terme. Se focaliser sur la valeur évite beaucoup de travaux inutiles et est finalement une grande source d’efficience. Se focaliser sur le court terme évite aussi de compter sur des postulats qui risquent trop de changer.

Un autre avantage payantL’industrie de la construction opte de plus en plus pour la modé-lisation des données du bâtiment (Building Information Modeling ou BIM), apparentée à l’Agilité. Ici, on admet que l’architecture détaillée sera imparfaite dans la complexité d’aujourd’hui. On admet que le niveau de détail sera mis à jour en continu au fil de la réalisation en gardant le cap sur la valeur des choses, forçant la repriorisation en cours d’exécution et permettant de miser sur les meilleurs leviers de valeur. On admet surtout qu’il est impé-ratif de mettre à jour le plan pour optimiser sa pertinence selon les enjeux auxquels on fait face. Le réalignement en continu des détails au juste moment par des collaborateurs experts permet d’éviter beaucoup de latences, de reprises et de biens livrables non pertinents ou de mauvaise qualité.

Trois derniers points pour se convaincre des béné-fices d’une reddition par la valeurPremièrement, livrer souvent des choses utiles de façon incré-mentale améliore de beaucoup le rendement de l’investissement. C’est comme décomposer les termes de son hypothèque. Si vos projets produisent de la valeur dès les premiers sprints, vous éviterez d’attendre 18-24 mois pour commencer l’engrangement des premiers bénéfices. De plus, le feedback rapide des clients assurera de meilleurs choix de priorités et de meilleures discus-sions sur la valeur réelle.

En deuxième lieu, assurer des critères stricts de la définition de « terminé » qui seront vérifiés à la livraison de chaque incrément évite les mauvaises préparations et les reprises. Cela permet de corriger les imprévus sur-le-champ et d’éviter plus tard l’accu-mulation de problèmes entremêlés.

Pour finir, un contexte d’autonomisation augmente l’énergie des gens et produit un effet de responsabilisation marqué. On bénéficie de l’intelligence, des connaissances, de l’implication et de la vigilance de tous. C’est vrai en gestion comme dans le sport. Rapprocher les gens des enjeux sur lesquels ils peuvent mieux agir, en fait, rapprocher les gens tout court pour mousser la collaboration et simplifier la coordination, c’est gagnant.

Bref, l’organisation Agile se structure en cellules auto-organisées proches des solutions, évite des plans de projets « prescriptifs », cadence des incréments de livraison, négocie les prochains incréments de valeur prioritaires avec son client en fonction de son expérimentation réelle des livraisons récentes et change ses mesures de suivi. On s’attardera à la progression du ratio % de valeur livrée/% du budget utilisé et non plus à la surveillance des ressources pour s’assurer d’atteindre la portée initialement imaginée.

Certaines pratiques comme la planification des capacités des ressources seront remplacées par la gestion des travaux en cours (work in progress ou WIP) du portefeuille. Et, bien sûr, la reddi-tion de compte de projet se distancera des traditionnels indices

Dans la turbulence et la complexité, vous devez réagir, réinterpréter les contraintes et

les opportunités, réaligner le tir

Pour y arriver, il est nécessaire de créer des équipes Scrum et Agile-Lean, mais aussi de revoir ce qui suit :

• Son mode de sélection et de démarrage de projets ;

• Sa gestion de portefeuille par la valeur ;• Sa gestion budgétaire.

33

Magazine Savoir Agile • Automne 2016

savoiragile.com

de performance des coûts et des délais (IPC-IPD) pour se tour-ner vers la mesure du débit stratégique capitalisée d’incrément en incrément partout dans l’organisation : le QIX de la valeur. La nouvelle cible des équipes de gestion devient donc la trans-formation des rouages classiques de gestion de la performance en un mode de gestion par la valeur. Déterminer les vecteurs de valeur devient conséquemment un élément critique, et quelques modèles seront utiles pour guider la direction en ce domaine.

Voici quelques-uns de ces modèles : Kano, la pyramide des valeurs, le tableau de bord prospectif de Kaplan-Norton, le modèle océan bleu/océan rouge, Cost of Delay (CoD) et WSJF (Weighted Shortest Job First). Un modèle stratégique consolidé existe et permet d’optimiser la gestion de projet et la gestion de portefeuille par la valeur.

Un contexte d’autonomisation augmente l’énergie des

gens et produit un effet de responsabilisation marqué

LA SEULETORTUE QUISPRINTEEssayez-la gratuitement !

urbanturtle.com

Urban Turtle est la seule plateforme applicative Agile externe dédiée à Team Foundation Server de Microsoft.

C

M

Y

CM

MY

CY

CMY

K

PubUrbanTurtle_FR_HiRes.pdf 1 2016-10-14 14:24:59 Pour plus d’information sur l’outil QIX, visitez savoiragile.com dans la section « Outils ». :

34

Magazine Savoir Agile • Automne 2016

savoiragile.com

Être Agile au-delà de Scrum

Réseau de Pyxis, Belgique

Charles-Louis de Maere, Scrum Master

À Pyxis, une de nos richesses et plus grandes fiertés, c’est le réseau que nous construisons. Pyxis compte aujourd’hui des unités d’affaires dans 10 villes partout dans le monde. Pour cette première édition, nous vous transportons en Belgique.

Pyxis Belgique a vu le jour il y a 3 ans

grâce à la passion de Norman Des-chauwer et Pierre-Emmanuel Dautreppe. Pour Pyxis Belgique, les approches Agiles permettent de livrer rapidement et fré-quemment des logiciels de qualité. Le souhait de cette petite équipe était de faire découvrir ce savoir-faire en formant et coachant des équipes de développe-ment et des entreprises afin de maximi-ser leur efficacité dans la réalisation de leurs projets. Depuis, l’équipe a grandi et offre de nouveaux services tels que le développement d’applications de réalité virtuelle.

Dans le cadre de cette première édition

du magazine Savoir Agile, nous vous présentons Charles-Louis de Maere. Charles-Louis s’est joint à l’équipe de Pyxis Belgique en septembre 2015. En tant que coach Agile, il s’éclate lorsqu’il a l’occasion d’accompagner des équipes sur leur chemin de l’Agilité. Pragmatique avant tout, il évite les dogmes et préfère trouver des solutions adaptées à chaque environnement. Dans cet article, Charles-Louis nous donne sa vision de Scrum et de ce qu’il y a au-delà.

www.pyxis-tech.be/ :

Comme beaucoup d’entre nous, j’ai commencé mon chemi-nement Agile en consultant le Manifeste pour le développement Agile de logiciels. Mon équipe et moi avions décidé de tenter d’utiliser Scrum. Le guide nous apparaissait plutôt clair et sensé, et il semblait en plus être concis par rapport à nos méthodes de gestion de projet habituelles.

Puisque notre gestionnaire de projet passait beaucoup de temps avec notre client, il nous semblait évident qu’il deviendrait notre Product Owner. Au cours des mois précédents, j’avais commen-cé à me distancer du code et j’étais plus intéressé et curieux de participer à unir les gens afin de régler certains problèmes. J’ai donc décidé de devenir le Scrum Master de l’équipe.

En fait, a posteriori, le terme pouvait d’abord sembler apeurant puisque j’avais aussi peu d’expérience avec Scrum et l’Agilité que le reste de l’équipe. Alors, comment pouvais-je être considéré comme étant quelqu’un qui maîtrise Scrum ?

Au fil du temps, nous sommes devenus plus confiants dans notre travail collectif en tant qu’équipe Scrum. Le guide nous a beaucoup appris, et c’était notre référence dès que nous nous interrogions sur notre façon de travailler. Les règles de Scrum sont plutôt claires, ce qui nous a beaucoup aidés.

35

Magazine Savoir Agile • Automne 2016

savoiragile.com

Mais vous n’avez rien compris !Cependant, nous avions l’impression d’être passés à côté de quelque chose. Certaines choses ne semblaient pas aller, mais je n’arrivais pas à mettre le doigt dessus.

Les rencontres de planification de sprint étaient plutôt en-nuyantes et l’équipe ne semblait pas se soucier de ce qui était ac-cepté pour le sprint à venir. Puisque l’équipe ne se responsabilisait pas, je me sentais obligé de demander : « Pensez-vous vraiment que nous pouvons nous engager à faire ça ? »

Durant nos rencontres quotidiennes, personne ne semblait véritablement intéressé par ce que les autres faisaient. Les gens faisaient simplement ce qu’ils avaient planifié de faire. De plus, bien que les graphiques d’avancement aient été visibles, il n’y avait pas de véritable intérêt à s’assurer que les objectifs de sprint soient atteints. Bien sûr, les gens faisaient ce qu’ils devaient faire, mais nous ne ressentions pas l’atmosphère des grandes équipes Agiles.

Nos séances de revue semblaient plutôt viciées alors que le Product Owner énumérait les tâches « terminées » sans réelle implication de l’équipe. Et nos rétrospectives ? Elles étaient correctes, j’imagine... J’avais lu qu’il était important de tenir des

rétrospectives et j’avais découvert quelques formats avec lesquels expérimenter.

Néanmoins, nous continuions de rencontrer des problèmes qui allaient au-delà de notre champ de compétence, ce qui nous donnait l’impression d’être impuissants.

Je suis certain que plusieurs d’entre vous auront décelé des choses que nous aurions pu améliorer. À ce moment-là, j’en étais inca-pable. En fait, j’ai eu une révélation en regardant le film : La vie de Brian (Monthy Python’s Life of Brian). Pour ceux qui ne l’auraient pas vu, on y suit le personnage de Brian qui est né en même temps que Jésus et que l’on prend pour le Messie.

Une scène en particulier m’a frappé. À un moment durant le film, une grande foule se rassemble sous la fenêtre de Brian et attend qu’il lui dise quoi faire. Et tout d’un coup, en écoutant son discours devant cette masse de gens, ça m’a frappé. Nous avions commencé notre cheminement Agile avec Scrum et nous nous attendions à ce que le guide nous dise quoi faire dans toutes les situations. Et même, à certains égards qu’il règle tous nos problèmes !

Être Agile au-delà de Scrum

36

Magazine Savoir Agile • Automne 2016

savoiragile.com

Ces idées se bousculaient dans ma tête pendant que le discours continuait :

Brian : « Vous n’avez pas besoin de me suivre, vous n’avez pas besoin de suivre qui que ce soit ! Vous devez penser par vous-même, vous êtes tous des individus uniques ! »

Foule : « Oui, nous sommes tous uniques ! »

Brian : « Vous êtes tous différents ! »

Foule : « Oui, nous sommes tous différents ! »

Brian : « Vous devez tous penser par vous-même ! Ne laissez personne vous dire quoi faire ! »

Soudainement, je ne savais plus si je devais rire ou pleurer. En nous concentrant sur la recherche de réponses dans les écrits, nous avions oublié les principes fondamentaux de l’Agilité. Vous voyez, une des premières valeurs du Manifeste pour le dévelop-pement Agile de logiciels, c’est de mettre de l’avant les individus et leurs interactions plutôt que les processus et les outils. Nous nous étions concentrés sur le processus Scrum, sans penser à l’essence de l’Agilité.

Inspecter et s’adapter, au-delà de Scrum...Alors, j’ai changé. Plutôt que de chercher des réponses, j’ai com-mencé à chercher de l’inspiration. J’ai commencé à participer à des rencontres et à des conférences, à rencontrer des gens et à discuter de nos difficultés. Et soudainement, plutôt que de voir plein de choses que nous ne faisions pas bien, j’ai vu une multi-tude de chances de grandir et de nous améliorer. J’ai commencé à lire à propos de la pensée systémique, sur comment les réponses devraient être propres au contexte (et c’est comme cela que j’ai compris le modèle Cynefin de Dave Snowden).

En fonction de ça, nous avons changé notre façon de tenir nos rétrospectives. Grâce à d’excellentes références qu’on m’avait sug-gérées (Agile Retrospectives par Esther Derby et Diana Larsen ain-si que l’outil Retromat), j’ai été en mesure d’essayer de nouveaux formats de rétro et, au bout d’un moment, certains membres de l’équipe se sont même proposés pour en être les facilitateurs.

À propos de la responsabilisation d’équipe, j’avais lu Responsibility Process de Christopher Avery. Après avoir participé à un atelier de deux jours avec lui et avoir appris comment appliquer ses principes à moi-même, je suis revenu vers l’équipe et nous avons commencé par déterminer notre niveau de responsabilité. Nous avons remarqué que nous étions habituellement dans un mélange d’obligation, de justification et de blâme. À partir du moment où nous avons découvert cela, nous avons commencé à nous demander si cela nous convenait ou si nous souhaitions changer. Il s’avère que cela nous a donné un nouveau point de vue sur des difficultés que nous pensions être en dehors de notre champ de compétence.

L’équipe s’est alors mise à tellement s’approprier ses sprints qu’il est devenu plus difficile pour la Product Owner de changer la portée de ceux-ci en cours d’itération. Lors d’une discussion avec la PO, elle a accepté de faire passer les sprints de deux semaines à une semaine. Cela a apporté une nouvelle vague de défis : com-ment pourrions-nous nous attendre à livrer chaque semaine s’il faut trois heures pour la mise en production ?

En fait, alors que l’équipe aurait dit que c’était impossible quelques mois auparavant, elle travaillait maintenant collectivement pour faire de cette nouvelle vision une réalité. Elle a commencé à auto-matiser plusieurs des actions nécessaires au déploiement et elle a développé un script qui sélectionnait tous les paquets approuvés durant la revue de sprint. Nous utilisions des centres de données externes alors, plutôt que ce soit nous qui livrions un incrément accompagné d’un document d’installation, nos partenaires rece-vaient soudainement un incrément auto-exécuté et ils étaient en mesure de déployer les paquets sans problèmes.

A posteriori, je pense que nous avons beaucoup appris durant cette première expérience avec Scrum. Étant habitués à travailler avec des méthodologies prescriptives, c’était difficile pour nous de laisser tomber nos habitudes. Démarrer sur la route d’une plus grande Agilité peut être effrayant au début parce que personne n’est là pour « nous dire quoi faire ». Le cheminement vers l’Agilité en est un d’éducation. C’est l’occasion d’arrêter de penser qu’il y a une réponse à toutes les questions et de commencer un chemine-ment d’expérimentation et d’apprentissage.

Appropriez-vous ces expériences, laissez l’équipe se les approprier également et assurez-vous de réfléchir au résultat de vos expéri-mentations. Je comprends que cela peut sembler intimidant au début, alors si vous désirez tout de même commencer, il pourrait être utile de vous référer aux cercles d’influence et de préoccupa-tion de Stephen Covey (The 7 habits of highly effective people).

Planifiez ce que vous souhaitez essayer et commencez par ce qui se trouve dans votre cercle d’influence (je suggérerais même d’ajouter le cercle de contrôle). Avoir du succès avec ceux-ci vous donnera, ainsi qu’à votre équipe, plus de confiance pour tenter de nouvelles expériences afin de réussir !

J’ai amorcé ce cheminement il y a déjà quelques années et je ne l’ai jamais regretté.

Plutôt que de voir des choses que nous ne faisions pas bien,

j’ai vu une multitude de chances de grandir et de nous améliorer

Adoptez les meilleurespratiques et maximisezl’efficacité de vos équipes

NOUS VOUS AIDONS À RELEVERLES DÉFIS LIÉS À VOTRE

TRANSITION VERS L’AGILITÉ

pyxis-tech.com/coaching

Mise en place de l’Agilité organisationnelleDéveloppement de leaders de premier niveau

Formation d’équipes collaboratives performantesDéveloppement personnel

C

M

Y

CM

MY

CY

CMY

K

PubCoaching_FR_Option3c_R1_FINAL.pdf 1 2016-10-15 15:47:07

37

Magazine Savoir Agile • Automne 2016

savoiragile.com

Adoptez les meilleurespratiques et maximisezl’efficacité de vos équipes

NOUS VOUS AIDONS À RELEVERLES DÉFIS LIÉS À VOTRE

TRANSITION VERS L’AGILITÉ

pyxis-tech.com/coaching

Mise en place de l’Agilité organisationnelleDéveloppement de leaders de premier niveau

Formation d’équipes collaboratives performantesDéveloppement personnel

C

M

Y

CM

MY

CY

CMY

K

PubCoaching_FR_Option3c_R1_FINAL.pdf 1 2016-10-15 15:47:07

38

Magazine Savoir Agile • Automne 2016

savoiragile.com

Y a-t-il un PO dans la salle?

Article Savoir Agile

Le fait que les approches Agiles sont axées sur la planifica-tion en fonction de la valeur d’affaires met en relief le carac-tère essentiel du rôle du Product Owner (PO) dans le cadre du développement d’un produit. Dans ce contexte, nous vous présentons ici des considérations qui peuvent être utiles lorsque vient le temps de choisir la personne qui sera amenée à jouer ce rôle primordial.

Avons-nous le bon PO?Voici d’abord des pistes de ce qu’il faut évaluer afin de savoir si nous avons choisi la bonne personne. Nous devons entre autres nous questionner sur les éléments suivants :

•Est-cequelePOproposedesindicesdeperformancefondéssur la valeur afin de s’assurer que le travail accompli obtient le retour escompté? Est-il transparent et dirige-t-il la discussion vers cette valeur?

•Est-cequelebesoindesutilisateursestaucentredesdiscus-sions avec le PO? Recherche-t-il la rétroaction de ces utilisa-teurs?

•Est-cequelePOpossèdelacapacitéderéunirplusieursparties prenantes autour de la table? Est-ce que ces parties prenantes partagent la même vision du produit?

•Est-cequelePOaconfianceenl’équipededéveloppement?Lui permet-elle d’échouer et de s’instruire?

•Est-cequeleproduitgéréparlePOaugmentelavaleurde l’organisation? Le PO est-il ouvert à avoir cette discussion? Est-ce que nous lui faisons confiance?

Si vous avez répondu par la négative à une ou plusieurs de ces questions, vous devriez vous demander ce qu’il faudrait pour changer la réponse en « oui ».

Qui serait un bon candidat?Parmi les différents rôles déjà en place dans une organisation, certains sont occupés par des gens plus aptes à jouer le rôle de PO.

Directeur de l’unité d’affaires

les + Il organise, dirige, contrôle et évalue toutes les activités de son unité d’exploitation. Il est conscient des normes de qua-lité, des échéanciers et de la rentabilité de chacun des projets, ce qui peut grandement lui faciliter la tâche.

les - Son rôle de directeur l’occupe beaucoup et il peut être moins disponible au quotidien. Il est difficile pour lui de réaliser les tâches quotidiennes du PO telles que répondre aux

39

Magazine Savoir Agile • Automne 2016

savoiragile.com

questions de l’équipe et s’occuper de l’entretien du carnet de produit.

Directeur de produit

les + Puisque le gestionnaire de produit (ou product ma-nager) est responsable de la gestion d’un produit dans son ensemble, de sa conception à sa mise en vente, il est souvent un bon candidat pour tenir le rôle de PO.

les - La personne qui joue ce rôle ne se concentre pas exclusivement sur le développement du logiciel. Comme elle est responsable de plusieurs tâches connexes telles que le marketing et la gestion du changement, elle peut avoir de la difficulté à se concentrer sur le carnet de produit.

Architecte ou analyste d’affaires

les + L’architecte et l’analyste d’affaires peuvent être de bon choix, car ils savent analyser les processus d’affaires de l’entre-prise et suggérer de nouvelles façons de faire pour accroître son rendement et son efficacité. Leurs bonnes connaissances tech-niques et leurs connaissances approfondies du domaine d’affaires peuvent être des atouts pour occuper le rôle de PO.

les - Ils ont une vue systémique de ce que pourrait devenir le produit. Le fait qu’ils occupent une position moins stratégique peut faire en sorte qu’ils ont une moins bonne vision de ce que devrait être le produit.

Chargé de projet

les + Le chargé de projet étant responsable de mener un projet à bien en gérant son bon déroulement, il peut assumer le rôle de PO. Il sait animer une équipe et organiser son travail pendant toute la durée d’un projet, ce qui peut lui être très utile pour jouer son rôle au sein d’une équipe Scrum.

les - Le chargé projet focalise son attention sur la portée du projet et travaille avec des leviers tels que les budgets et les échéanciers. Cela peut nuire, car dans le cas d’un PO, on cherche quelqu’un qui maximisera les avantages plutôt que de travailler sur la portée.

Qui est susceptible de soutenir le PO?Chacune de ces personnes a les aptitudes pour jouer le rôle de PO. Par contre, elles ont toutes un angle mort. L’équipe pourrait compenser ces aspects moins forts.

•Lagouvernancesemetauservicedeséquipes;ellelesorientegrâce à des objectifs clairs et leur fournit tout ce dont elles ont besoin afin d’être efficaces.

•Lebureaudeprojets(project management office ou PMO) gère en fonction des avantages ciblés plutôt que par le suivi des livraisons. Il incitera les équipes à entreprendre de petites initiatives apportant une forte valeur ajoutée.

•Lesarchitectesetlesanalystesélaborentdesprocessusetdesoutils malléables et flexibles, permettant des ajustements continuels à la structure organisationnelle.

•Lesresponsablesdel’infrastructureetdelagestionduchan-gement adapteront leurs pratiques de manière à pouvoir fré-quemment mettre en production les incréments livrés par les équipes de projets, et ce, avec le minimum d’impact possible.

Pour en apprendre davantage sur l’organisation Agile, téléchargez notre livre blanc sur le sujet1. :

Facteurs et considérations pour le choix du PO

La taille de l’organisation

Plus l’organisation est petite, plus le PO va jouer un rôle straté-gique, car le succès du produit est étroitement lié au succès de l’entreprise.

Dans le cas d’une plus grande organisation, le PO aura tout de même une position stratégique afin d’avoir accès aux parties prenantes et d’être en mesure de recueillir leurs impressions et, au besoin, de les convaincre. Un des défis pour les grandes or-ganisations, c’est de trouver quelqu’un qui est également proche des opérations. Il est important que le PO choisi comprenne la réalité des opérations et qu’il soit en mesure de s’aligner sur la stratégie de l’entreprise.

40

Magazine Savoir Agile • Automne 2016

savoiragile.com

On ne cherche pas nécessairement un bon gestionnaire de projet. Dans une grande organisation, le PO est plus souvent res-ponsable du carnet de produit (product backlog). Il va prioriser ce qui est absolument nécessaire plutôt que ce qui est optionnel. Il a pour objectif de livrer les meilleurs résultats possible en fonction des contraintes de temps et d’argent; lorsque le levier de la gestion de carnet ne suffit plus et que l’on doit changer les paramètres d’échéancier et de budget. Dans les grandes organisa-tions, les PO ont souvent besoin de l’intervention du bureau de projet ou d’un chef de projet.

La taille du produitLa taille du produit peut être un facteur influençant le choix du PO. Plus le projet est gros, plus on a besoin qu’un PO s’y consacre à temps plein. Il faudra donc choisir quelqu’un qui peut se consacrer entièrement au produit.

Dans le cas d’un produit d’envergure, l’organisation pourrait mettre en place plusieurs PO avec un PO principal chargé de la vision du produit et du carnet principal. Pour ce rôle, il faut choisir une personne ayant de bonnes connaissances du marché et des besoins des utilisateurs. Comme différentes équipes sont mises en place et impliquées dans le développement de produit, il faut s’assurer que chaque produit a un PO.

Dans les projets de développement d’envergure, on retrouve parfois la notion de « proxy PO ». Ce PO sera très impliqué dans la gestion du carnet de sprint de l’équipe (sprint backlog). Il faut une personne qui sera en mesure de répondre aux questions relatives aux éléments du carnet de sprint. Bien que parfois utili-sée, cette option est à éviter si possible.

Cycle du produit Le cycle de vie du produit est également une considération im-portante quand vient le temps de choisir le PO.

Pour un produit en début de cycle de vie, il faudra choisir une personne qui possède d’excellentes connaissances du marché. Pour un nouveau produit, les hypothèses de départ tendent souvent à changer. Le PO devra donc ajuster en cours de route la direction que prendra le produit en fonction des besoins et du feedback des clients. La personne qui jouera ce rôle devra être

Le PO a pour objectif de livrer les meilleurs résultats possible

en fonction des contraintes de temps et d’argent, on ne

cherche pas nécessairement un gestionnaire de projet

• est disponible;

• rend les résultats visibles;

• mesure le travail et favorise l’introspection;

• priorise bien le carnet de produit;

• a de la crédibilité aux yeux des parties prenantes quant à la prise de décision.

Un bon Product Owner :

41

Magazine Savoir Agile • Automne 2016

savoiragile.com

flexible et avoir de bonnes capacités d’adaptation. Elle devra être très disponible pour l’équipe.

Dans le cas d’un produit en fin de cycle de vie, le PO aura moins besoin d’avoir les notions de valeur du marché. Il devra par ail-leurs avoir un niveau élevé de compétences en gestion ainsi que de bonnes connaissances techniques. Souvent, à cette étape du cycle, les demandes de changement sont liées à la maintenance du produit. Comme les investissements sont minimisés, le PO ne travaille plus à temps plein sur le produit.

Maturité de l’équipeLa maturité de l’équipe est aussi un facteur qui influence le choix du PO.

Dans le cas d’une nouvelle équipe qui ne maîtrise pas le domaine d’affaires et qui n’a pas la connaissance du marché, il faudra un PO expérimenté. Il devra être en mesure de communiquer efficacement avec son équipe afin qu’elle comprenne bien les besoins des clients. Quelqu’un qui a un leadership fort est à privilégier dans ces circonstances. Il aidera l’équipe à gagner en confiance et à se souder. Ce profil lui permettra de devenir plus autonome afin qu’elle soit ultimement en mesure de bien saisir les besoins.

Dans le cas où l’équipe est mature et connaît bien le domaine d’affaires, il faudra un PO qui n’est pas trop directif, car il pour-rait miner sa créativité. On recherche quelqu’un qui est capable de partager la responsabilité du produit avec l’équipe et qui lui assurera son soutien. En quelque sorte, le candidat est appelé à jouer un rôle de consultant.

Nature du projetOn dit parfois que plus un projet est de nature technologique, plus le PO doit avoir des connaissances techniques. Avoir une personne qui a des connaissances techniques à titre de PO peut s’avérer un atout. En effet, cette personne aura plus de facilité à comprendre le langage de l’équipe. On regarde alors davantage le profil de la personne, ses qualités intrinsèques.

Alors, y a-t-il un Product Owner dans la salle?

Peu importe le candidat que l’on choisit pour occuper le rôle de PO, celui-ci jouera un rôle clé. Il faut donc bien choisir cette personne, mais surtout, bien la soutenir.

Le PO devra ajuster en cours de route la direction que prendra le produit en fonction des besoins

et du feedback des clients

• est disponible tout au long du projet;

• comprend le domaine d’affaires;

• comprend la vision et les enjeux du projet;

• est un bon communicateur;

• travaille bien en équipe.

Le profil du candidat :

1 Livre blanc : http://www.pyxis-tech.com/fr/ressources-agiles/lorganisation-agile/2 Journal de Maria : http://www.savoiragile.com/category/journal-de-maria/

Pour obtenir plus d’information sur le rôle de PO et ses défis, nous vous invitons à lire le journal de Maria2. Il s’agit d’un retour d’expérience d’une personne nouvelle-ment nommée PO. Visitez savoiragile.com. :