Scrum est cool.

Scrum nous donne suffisamment de règles permettant la mise en place de quelque chose qui est assez facile à comprendre pour modifier le processus de développement de produits complexes,  optimiser la prévisibilité et réduire les risques. Mais nous savons tout cela et nous l’aimons bien, pas vrai?

Ce que nous savons aussi, c’est que, tout en étant très facile à comprendre et à apprendre, il est extrêmement difficile de maîtriser Scrum et de l’appliquer correctement. Notamment, parce que nous sommes confrontés a des systèmes et comportements complexes, et il n’est pas évident de modifier ces systèmes à cause de leur complexité intrinsèque.

Si je veux pratiquer le surf, il est facile de savoir ce qu’il faut faire avec mon outil super léger (la planche de surf). Toutefois, à moins que l’océan soit plat et ennuyeux, il est très difficile de respecter les règles du surf et de réussir à surfer : rester droit, regarder bien en face de soi et ne pas tomber. Facile! Vous avez juste besoin d’être strict avec ces règles. Si vous tombez trop de fois, vous pourriez penser que c’est une bonne idée de changer votre planche ou de tout simplement pratiquer un autre sport. Je conseille plutôt d’aller de l’avant, de pratiquer encore et encore, pour finir par apprendre les règles de base et enfin tenir sur votre surf. Ensuite, il peut y avoir des falaises, des vents violents et parfois des requins. Vous devez juste faire attention et continuer à pratiquer.

Surf :

  • Léger;
  • Très simple à comprendre;
  • Extrêmement difficile à maîtriser.

Ça vous dit quelque chose?

Nous pourrions considérer l’océan comme un énorme système dynamique complexe, peut-être un peu comme votre organisation. Ou peut-être faites-vous partie des personnes qui vivent dans un étang? Dans ce cas, pas de vagues, pas de fun! Et pas besoin de surf, je dirais.

Allons plus loin. Imaginons que vous soyez sur l’océan et que vous ayez apporté votre planche de surf avec vous; votre seul choix serait de vous entraîner. Pour Scrum, c’est la même chose, mais comme il est statistiquement prouvé qu’il est beaucoup plus fréquent d’essayer de changer Scrum que de changer une planche de surf, il est préférable de toujours connaître quel est le delta entre ce que vous faites et ce que vous devriez faire. Si vous voulez jouer le jeu de Scrum (et avoir du plaisir), vous devez respecter toutes les règles. Nous savons cela, parce que c’est écrit dans le Guide Scrum…

Maintenant, nos questions sont les suivantes :

  • Est-ce que vous respectez les règles?
  • Savez-vous quelles sont les règles importantes que vous ne respectez pas?
  • Pensez-vous qu’il est important de le savoir ou ça vous importe peu?

Si vous naviguez sur de grosses vagues imprévisibles, vous seriez mieux de ne pas être chancelant sur votre planche de surf afin de ne pas goûter à l’eau de mer. Nous pensons que c’est la même chose lorsque vous essayez d’utiliser Scrum dans votre organisation.

Faire la même chose avec Scrum peut être difficile. Le « manuel » de Scrum comporte 16 pages uniquement, mais il indique beaucoup de choses à faire. Si vous prenez le guide officiel de Scrum (Scrum.org), vous pouvez probablement trouver une règle par phrase, ou plus. Notre question est donc la suivante :

Comment pouvons-nous être certains que nous n’oublions pas quelque chose d’important?

Nous avons réfléchi à cette question et voici notre réponse : dresser une liste à utiliser dans le cadre des rétrospectives pour pousser plus loin l’amélioration continue. Quelque chose comme : « Avez-vous fait ceci? Non. Avez-vous fait cela? Oui. » Bonne idée, n’est-ce pas?

Nous avons donc découpé le Guide Scrum. Nous y avons ajouté un peu de notre expérience sur le terrain et nous avons commencé à l’utiliser au travail. Nous avons également pensé aller un peu plus loin en le transformant en un index, pour vérifier nos progrès. Nous avons fini par obtenir une liste de contrôle qui nous donne des résultats chiffrés de votre application de Scrum. Par exemple : 33 %, 50 % et même… 100 % (wouah, mais là vous avez triché, il me semble ? ).

Le nom que nous avons choisi pour cet outil est le « Scrum Adherence Index ». Et vous pouvez le trouver ici et jouer l’utiliser. Si vous souhaitez le modifier, allez-y. Cependant, nous aimerions que vous partagiez vos modifications ici. Nous avons décidé d’utiliser une licence Creative Commons. Donc, la règle de copyleft est la suivante : Attribution -Share Alike 3.0 Unported (CC BY- SA 3.0 ).

 Amusez-vous et dites-nous ce que vous pensez!

Christian et Francesco


Avertissement important : Ce petit outil est tout simplement une liste de base délivrant un index . Il est important de ne pas le prendre à la lettre non plus! Les index sont bons si on les regarde avec détachement, sinon ils peuvent vous faire croire que la réalité est plus simple que ce que nous voyons. Les indices doivent être interprétés et pris avec modération. Y devenir accro n’est pas non plus recommandé! Laissez- vous conduire par l’empirisme, et continuez l’inspection et l’adaptation.

Note 1 : Voici le lien vers  le « Scrum Adherence Index ». Vous ne pouvez pas modifier ce fichier, mais vous pouvez le télécharger et  le mettre dans votre propre Google Drive si vous le souhaitez, ou l’importer dans votre tableur favori (et probablement y apporter quelques modifications).
Note 2 : Notre travail n’est qu’une ébauche. Il y a des problèmes connus et probablement d’autres qui sont inconnus. Veuillez nous-les signaler…
Note 3 : Dans la même feuille de calcul y a aussi un onglet avec une version sans index. En fait, qui contient uniquement la liste. Il peut être utilisé pour avoir une vision rapide sur les pratiques qui sont utilisées et celles qui ne le sont pas. Il peut aussi servir de base pour suivre les changements futurs. Nous l’avons appelé « Scrum Adherence Checklist ». Original, n’est-ce pas ?

Le Scrum Adherence Index (et Checklist) préparé par Christian Lapointe et Francesco Lomonaco est distribué sous la licence suivante : Commons Attribution -Share Alike 3.0 Unported Creative (http://creativecommons.org/licenses/by-sa/3.0/deed.fr).

Basé sur le travail disponible à http://goo.gl/VVGY80

Billet précédent

Développement de soi : les conférences de Tremeur

Billet suivant

Un premier Agile Tour pour Pyxis Belgique

pyxis

Pyxis est présente en Amérique du Nord, en Europe et en Asie.

Nos conseillers Agiles vous aident à concrétiser réellement les avantages de l’Agilité : accroître la fréquence des livraisons et la vélocité des équipes; collaborer avec les clients en s’alignant sur leurs besoins; maîtriser les risques et les changements en cours de livraison et encourager la concentration, la rigueur et l’énergie au sein des équipes. Communiquez avec nos coaches, formateurs, Scrum Masters et développeurs pour en apprendre davantage sur nous.

2 Commentaires

  1. varia@ackx.net'
    Youri Ackx
    21/01/2014 at 19:41 — Répondre

    Bonne initiative!

    Ne devrait-il pas y avoir des minimas par catégorie, un peu comme aux crash-tests euro-ncap ? Par exemple, même avec un mauvais score dans la rubrique “PO”, on peut encore avoir un bon score final, ce qui n’est sans doute pas conforme à la réalité si le PO fait défaut.

  2. flomonaco@pyxis-tech.com'
    Francesco Lomonaco
    22/01/2014 at 16:26 — Répondre

    Merci!

    C’est vrai. Toutefois, ce chiffre ne reflète pas le niveau de maturité. Il ne s’agit pas d’un score. C’est plutôt un indicateur de conformité aux éléments contenus dans le Guide Scrum que nous avons découpés et ajoutés à cette feuille. Il y a sûrement objet à amélioration! Il s’agit, en fait, d’un indicateur clé de performance (« KPI ») qui va être interprété. Sans l’interprétation ni une relecture critique (par un coach, par exemple), la valeur de cet index n’est pas optimale.

    Aussi, comment allons-nous marquer les minima pour les rétrospectives, le Product Owner, le Scrum Master? C’est un « framework » utilisé pour la complexité. Il peut tomber sur le PO, sur les points d’inspection inefficaces, sur la manque d’autoorganisation, etc.

    À la fin, la codification par couleur peut aider à repérer les points en « danger ». Je peux avoir 80 %, mais avec une zone rouge (<33%) qui nous regarde mal 😉 Si on s'attarde au chiffre final sans interpréter les éléments, nous avons sûrement perdu quelque chose.

    Du moins, c'est ce que je pense. :)

Laissez un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.