Scrum: gérer le manque de motivation


11

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?


Peut-être qu'ils préfèrent être propriétaires d'un autre code? Bien sûr, si le code en question est si odorant que personne ne veut le posséder, c'est un problème plus important ... et CERTAINS devront simplement le sucer et posséder ce code.
FrustratedWithFormsDesigner

2
Il serait bon de chercher d'abord la raison du manque de motivation. Il y a une tendance à négliger les facteurs humains, allant des conflits de personnalité au sein de l'équipe aux politiques RH des entreprises qui sont plus à blâmer que de donner du crédit (ex: "classer et tirer").
jfrankcarr

1
Rien dans l'article ne parle de motiver les gens à posséder le code. En fait, Scrum décourage la propriété du code. Pourquoi essayez-vous de les motiver à posséder le code plutôt que la charge de travail?
pdr

Réponses:


14

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.

4

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.


Avez-vous limogé le membre de l'équipe qui n'aimait pas les réunions à 16 heures ?? ;)
Dave Hillier

3

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


Je dirais que ce sont des zones fonctionnelles verticales et non des zones infrastructurelles horizontales. C'est-à-dire que la pire chose que vous puissiez faire est d'avoir le Guy UI, le Backend Guy et le Database Guy parce que pour chaque élément de fonctionnalité, vous aurez besoin de ces trois pour collaborer.
Michael Brown

1
Un rare downvote de ma part. Tout cela conduit à l'opposé exact des développeurs Scrum-n travaillant sur n différents flux de travail. Les développeurs perdent leurs connaissances sur tous les projets et lorsque le flux de travail A devient une priorité très élevée, il devient très difficile d'attirer des gens d'ailleurs. Une pression supplémentaire est exercée sur l'individu qui possède cette zone du code, il quitte et vous vous retrouvez avec un projet échoué.
pdr

@pdr: Vous soulevez un point intéressant. Je pense que je pourrais en apprendre beaucoup si vous et Robert Harvey discutiez davantage de ce point.
Jim

@JimG. Voir la réponse de DXM pour une vue plus nuancée et complète (avec laquelle je suis d'accord).
Robert Harvey

1
@JimG. C'est dommage, parfois, que nous n'ayons pas de forum (le chat est trop immédiat, je n'ai pas ce genre de temps à consacrer à une discussion) où une poignée de développeurs expérimentés et intéressés, qui ont rencontré différents problèmes, peut partir, débattre de quelque chose et revenir avec une réponse combinée. Cependant, je suis particulièrement intéressé par celui-ci, car je suis rarement en désaccord avec les réponses de Robert ici et (peut-être plus intéressant) nous sommes tous les deux d'accord avec la réponse de DXM.
pdr
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.