Scrum: gérer le manque de motivation

Selon cela , "Scrum s'appuie fortement sur des équipes hautement motivées, collaborant étroitement, interfonctionnelles et auto-organisées." Alors, comment gérez-vous des collègues qui ne sont peut-être pas aussi motivés à s'approprier le code? Comment incitez-vous quelqu'un à devenir propriétaire?

Je ne sais pas si c'est le problème de votre équipe, mais c'était définitivement pour nous lorsque nous avons introduit Scrum pour la première fois. Un jour, notre direction est venue nous voir et nous a dit que vous ne travailleriez plus dans des silos individuels. Au lieu de cela, vous travaillerez comme une mêlée. Voici un tas de nouveaux processus que vous devez tous suivre et suivez-les.

La clé est qu'ils ne sont jamais venus chez nous, les développeurs, et ont demandé, comment voulez-vous travailler? qu'est-ce qui vous rendra plus heureux? plus efficace?. Donc, ce que j'ai entendu était, "vous ne possédez plus de code. Tout ce que vous écrivez sera piétiné (vous savez, la propriété de l'équipe). Vous ne bougerez pas ou ne lèverez pas le doigt parce que nous allons maintenant gérer votre temps à l'heure". Oh et maintenant vous avez un stand de 15 minutes ennuyeux tous les jours où les gens discuteront de choses qui ne vous intéressent pas et cela prendra généralement 30 minutes, puis toutes les deux semaines aura une réunion de planification de 4 heures ultra ennuyeuse qui ne manquera pas de sucer toute vie hors de toi.

En réalité, ce n'est pas Agile ou Scrum, cela passe simplement d'un style de gestion à un style différent, où tout est toujours contrôlé de manière centralisée, et non seulement cela m'a sucé toute la vie, mais cela m'a aussi donné beaucoup de liberté le temps de mettre à jour mon CV.

Au cours des douze derniers mois, après avoir fait de nombreuses pressions pour que notre chef d'équipe essaie quelque chose de différent, il m'a en fait accepté mes suggestions, et je pense que nous avons eu une année très réussie.

Je crois que le changement clé pour nous a été de donner aux développeurs beaucoup plus de voix et de liberté dans le choix de la façon dont nous voulons travailler. Peu de choses que nous avons faites:

1. Divisez la grande équipe de développement "agile" en 3 petites afin que chacune n'ait que 3-4 développeurs. Cela rend tout le monde engagé et les individus ne sont pas noyés.
2. Assurez-vous que tout le monde dans la même équipe travaille autour du même domaine fonctionnel afin que les gens se soucient de ce dont les autres parlent dans les stand-ups et les plans d'itération.
3. Au lieu que la direction choisisse simplement qui travaille sur quoi et attribue des histoires / tâches, nous avons créé un carnet de commandes et l'équipe elle-même a eu beaucoup à dire sur la façon dont le travail est divisé.
4. Parce que nous avions de nombreux nouveaux membres, nous avons commencé avec un système de silo où chaque personne possède un domaine de responsabilité principal. Cela a permis à de nouvelles personnes de se concentrer sur une zone plus petite d'un produit inconnu et de sentir plus rapidement qu'elles ne jouent pas dans le bac à sable de quelqu'un d'autre. Mais 6-8 mois après le début du programme, ces zones ont commencé à se métamorphoser à mesure que les frontières devenaient plus grises. Maintenant, les gars, dans les équipes sur lesquelles je fais partie, sont assez à l'aise pour entrer dans le code des autres ou faire travailler d'autres développeurs dans le leur.
5. Les révisions de code de toutes les soumissions étaient essentielles (et c'était la première chose à laquelle on a lésiné lorsque nous avons fait Scrum pour la première fois):
   • Transfert de connaissances en termes de techniques / méthodes de programmation
   • C'était génial pour les autres d'apprendre du code qu'ils n'auraient pas vu autrement
   • Votre équipe a la chance de communiquer et de socialiser, ce qui améliore la dynamique de l'équipe
   • Et je suppose que les revues de code attraperont un bogue ou deux, mais je vois leur valeur principalement dans les aspects ci-dessus.
6. La direction doit écouter l'équipe. Si l'équipe dit que quelque chose ne fonctionne pas ou doit être changé, et qu'ils l'ignorent simplement, alors les membres de l'équipe vérifieront simplement et laisseront la direction gérer le projet. Si vous voulez que les gens soient motivés, ils doivent être investis et ils ne seront investis que s'ils font ce qu'ils croient être juste, pas ce qu'on leur dit de faire d'en haut.

Il y a beaucoup de raisons pour un manque de motivation, mais la plus courante est probablement de ne pas avoir l'impression d'avoir son mot à dire. Lorsque notre équipe a commencé à faire de la mêlée, j'ai remarqué que les personnes les moins motivées à propos de la mêlée se sont retournées après avoir vu leurs suggestions des rétrospectives mises en œuvre.

Un tas de problèmes mineurs peuvent devenir démotivants. Par exemple, la semaine dernière, un membre de l'équipe n'a pas aimé les réunions de 16 h. C'est facile à réparer.

En d'autres termes, la meilleure façon de découvrir ce qui démotive votre équipe est de leur demander.

En leur conférant la propriété individuelle du code.

De nombreux magasins travaillent sur un modèle de «propriété d'équipe». C'est formidable pour la collaboration croisée et la réduction des risques, mais pas tellement pour motiver les individus à être personnellement responsables. La propriété d'une équipe peut entraîner un code moyen, car il n'y a pas d'incitation à la propriété individuelle.

Solution: affectez des individus à chaque section du code pour être les administrateurs de cette partie du code, mais autorisez l'accès complet de l'équipe à l'intégralité de la base de code.

Voir également: /software//a/33464/1204