1/5: L’équipe est « multi-tâches » (Cinq facteurs de succès pour vos projets Agile/Scrum)

1/5 l'équipe est multi-tâches
1/5 l'équipe est multi-tâches

Régulièrement lorsque je démarre un projet, il arrive qu’un membre de l’équipe vienne me demander: « Dis, quel sera exactement mon rôle sur le projet ? ». Et moi invariablement je réponds: « Je ne sais pas ».

Pour que votre projet soit un succès un premier point à prendre en compte est que l’équipe (et donc vous y compris) soit « multi-tâches ». En effet, sur un projet Agile ou Scrum, ne vous attendez pas à avoir une « job description » avec les différents acteurs (développeur, analyste,…) ainsi que les différentes tâches liées à ces rôles (le développeur est responsable du code,…). Non sur un projet Scrum/Agile on pourrait résumer le pragmatisme par: « C’est le projet qui prime ». Et donc si pour le succès du projet aujourd’hui vous devez aller dans une papeterie pour acheter des post-its de couleurs et bien c’est qu’on fera.

« Ce n’est pas comme ça qu’on fait d’habitude ?! » doit être dans le top 5 des phrases que j’entends le plus sur un projet ;-) D’après la dernière analyse de Gartner que j’ai lu, plus de 70% des projets informatiques sont un échec, il est peut-être temps de changer nos habitudes ?

L’équipe doit être multi-tâches

OK mais qu’est-ce qu’on entend par là ? C’est à vous, coach, Scrum Master, Team Member expérimenté à transmettre à votre équipe ce qu’il y a derrière cette expression. On pourrait résumer cette approche par 1. examiner et 2. s’adapter, merci Derek :-).

Exemple, si en tant qu’architecte vous devez étudier l’architecture IT, il est possible que vous ayez d’abord à faire le Sherlock Holmes pour trouver de la documentation existante. Autre exemple si aucun outil de test n’est utilisé, à vous d’en proposer. Ou encore: le client est à 50km de chez-nous, comment faire pour pouvoir installer Skype sur le réseau. Il y aura beaucoup de tâches « différentes » ou « annexes » à réaliser. On ne peut pas garantir, par exemple, à un développeur qu’il ne fera que du développement et pas du test. Ou encore, à un analyste fonctionnel qu’il ne touchera pas un peu à la technique. C’est en partie pour cela que tous ces titres sont abandonnés dans Scrum et que l’on parle de « Team Member ».

Plutôt que d’expliquer « pourquoi ça ne va pas » et « de qui est-ce la faute », notre approche va-être: « Que faut-il faire pour que ça fonctionne ?« . Et pour que cela soit possible, chaque membre de l’équipe devra faire toute sortes de tâches différentes. Il n’y a pas ici un « bon » team member qui est multi-tâche. Et un mauvais « team member » qui veut toujours faire la même chose. Non on parle ici d’honnêteté et d’humilité. A vous team leader à expliquer dès le début ce que vous attendez de vos team member. Si, lors de votre recrutement, quelqu’un vous dit « non merci moi je ne fais que du code un point c’est tout » et bien pas de soucis, il ira sur un autre projet. L’organisation a aussi besoin de personnes qui fonctionnent comme ça. Et les équipes plus opérationelles ou les autres projets de type waterfall sont aussi très utiles.

Les outils

Dans le cas d’un projet IT être « multi-tâches » c’est bien évidemment amener des techniques Agile ou des mode de collaborations différents. En vrac je vous citerai faire de l’XP, du pair programming, du test driven development, utiliser les user stories… A chacun d’apporter ses idées

Dans la dynamique d’équipe on va accorder également une grande part au partage de connaissance entre team-members et prendre des décisions en commun. Raisonner en équipe est alors à ce moment primordial car mettre tous les cerveaux autour de la table va nous permettre d’avoir « de la perspective ». Par exemple on ne mettra pas en place une technique sexy (web-service, flex,…) si on n’estime qu’elle n’a pas de valeur ajoutée pour le client. Dans ce genre de processus il peut être aussi très intéressant de mélanger des personnes ayant une très bonne connaissance du projet, avec des personnes ne le connaissant peu va pas du tout.

Le multi-tâches en pratique, le Sprint 0

La meilleure manière pour moi est de démarrer par un sprint 0. En résumé: vous voulez faire du Scrum ? Ok commencez dès maintenant…je veux dire MAINTENANT. Imaginez-vous. Vous êtes Scrum Master ou chef de projet, et vous devez initier le projet. Si vous savez déjà qui sera dans votre équipe, même si vous n’avez encore de 2 personnes sur 9 de disponibles et bien faites du Scrum tout de suite !

  • Vous êtes trois ? Faites au moins une daily meeting chaque jour.
  • Vous devez organiser le déménagement afin d’avoir des locaux pour l’équipe ? Répartissez-vous les tâches
  • Vous devez créer le Scrum Board ? Créer le en équipe
  • Vous devez sélectioner des technologies, mettez déjà l’équipe dans la boucle

Au plus vite vous serez dans le concret, au plus vite votre équipe va monter en compétence et se familiariser avec le système.

Un sprint zéro est la manière idéale de réaliser toutes les tâches d’initiation d’un projet. Exemples créer l’équipe, trouver des locaux pour être ensemble, choisir ses outils et l’architecture, créer le product backlog etc…

Voilà, c’est tout pour le moment.

Fin de notre premier épisode de notre série « Cinq facteurs de succès pour vos projets Scrum/Agile ».

Tout feedback est le bienvenu !

Portez-vous bien.

Bruno.



This content is published under the Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported license.

J-B

Salut, j’ai un gros projet à gérer pour le moment, j’essaye dans la mesure du possible de m’inspirer de tout ça… même si pour le moment je suis seul là-dessus et que ça n’a rien à voir avec de l’informatique… on pourra en discuter un de ces 4!

brunosbille

Hello

Bien entendu ! Je t’envoie un mail pour qu’on en discute.
C’est un des grand avantages de Scrum c’est qu’il peut s’appliquer à tout type de projets.

Merci pour ton commentaire,,

Bruno.

PM Hut

Hi Bruno,

Good article. I would like to republish it on PM Hut under the Scrum section. I’m sure PM Hut readers will appreciate it. Please either email me or contact me through the « Contact Us » form on the PM Hut site in case you’re OK with this.

Thanks,

HTN

Salut Bruno,

Je partage votre point de vue.

En effet rien ne va quand une équipe s’embrouille pour avoir une claire définition de rôle de chacun pour que les analystes puissent s’éloigner de l’aspect technique et les développeurs coder sans comprendre l’objectif du projet.

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