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

[English version below: « Team is « multi-tasks » (Five keys to succeed in your Agile/Scrum projects) »]

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.

Team is « multi-tasks » (Five keys to succeed in your Agile/Scrum projects)

When i initiate a project, i regularly have this question from a team member. « Look, what specifically will be my role on this project ? ». And i always answer… « i don’t know ».

To make your project a success first point to consider is that the team (and so do you) must be « multi-tasks ». Indeed, on a Agile or Scrum project , do not expect to have a « job description » with the different actors (developer, analyst ,…) and the various tasks associated with these roles (the developer is responsible for code ,…). No, on a Scrum / Agile project we can summarize pragmatism by: « Project comes first ». If the project success requires you go and buy colourful post-it notes in a shop, then you do.

« Usually we don’t do this way ?! » Is one of the top 5 i hear while i’m working on a project 😉 According to the latest analysis from Gartner that I read, over 70% of IT projects are unsuccessful, it may be time to change our habits?

The team must be « multi-tasks »

OK but what do we mean by that? It’s up to you, as a Coach, Scrum Master, Experienced Team Member, to explain to your team the meaning of « multi-tasking ». We could summarize this approach by: during the project you should 1. inspect and 2. adapt, thank you Derek 😉

Example, as an architect you will need, to study the IT architecture, it is possible that you have first to take the Sherlock Holmes role to find the existing documentation. Another example where no testing tool is used, it’s up to you to propose one. OR: the customer is 50km away from you, how to install Skype on the network ?. There will be many different tasks to achieve. We can not guarantee, for example, to a developer that he will only do development and not testingt. Or, to a functional analyst that he/she will not have some technical tasks. This is one of the reasons why, in Scrum, we do use the term « Team Member » and no « developer », « analyst »,….

Rather than explain « Why it doesn’t work » and « Who is to blame », our approach will be: »What do we have to do to get it done?  » And to make it happens, each team member must make all sorts of different tasks. There is here no « good » team member who is multi-task or a bad « team member » who always wants to do the same thing. We speak about honesty and humility. It’s up to you as a team leader to explain at the very beginning of the project, what you expect from your team. So, when you recruit your team members if someone tells you « no thanks, I am only writing code nothing more », that’s ok. He will go on another project. The organization also needs people who work like that. A more « operational » team is also useful for your company.

Tools

On a IT project being « multi-tasks » is obviously bring Agile techniques or different collaborations methods. Like Xtreme Programming, Lean thinking, pair programming, test driven development, using user stories… Everybody can bring ideas !

In the way the team members interact, we will also provide sharing of knowledge and take decisions as a team. Thinking together is important at this time. Bring all the brains around the table will allow us to have « perspective ». For example, we will not use a sexy technology (web service, flex ,…) if we consider that it has no added value for the customer. In this kind of process, it can also be very interesting to mix people with very good knowledge of the project, with people not knowing the project at all.

Multi-tasking in practice, the Sprint #0

In my opinion, , it is best to start with a Sprint #0. In short: you want to do Scrum? Ok start now … I mean NOW. Imagine. You are Scrum Master or project manager, and you must initiate the project. If you already know who will be in your team, even if only 2 people on 9 are available. I suggest you to start in Scrum mode immediately.

• You’re three? Make at least one daily meeting every day.
• You want to organize the move to have offices for your team ? Divide tasks between team members
• You want to create the Scrum Board? Create it with the Team
• You want to select technology, already put the team in the loop

The faster it will be concrete, the faster your team will become familiar with the method.

A sprint #0 is the ideal method to do all the « initiation » tasks on a project. Like: set-up the team, seat the team together, choose tools, architecture, create product Backlog,…

That’s all for the moment.

End of our first episode of our series « Five success factors for your projects Scrum / Agile ».

Feel free to give feedback.

Take care.

Bruno.