Ma fille aînée s’est mariée récemment. Environ un mois avant le mariage, j’ai réalisé que je danserais avec elle, puis avec ma femme à la réception par la suite. Mais euh-oh : je n’ai pas dansé depuis un bon bout de temps. J’avais besoin de cours.
Mais je n’ai pas paniqué. À quel level cela pourrait-il être difficile? Patrick Swayze a fait en sorte que cela ait l’air facile. Et je ne pensais pas que ma fille ou ma femme s’attendrait à ce que je les tienne au-dessus de ma tête.
Cela s’est avéré assez difficile, même si cela semblait si facile. Alors que je luttais pour apprendre, j’ai réalisé que la danse ressemblait beaucoup à Mêlée: Facile à comprendre mais difficile à maîtriser.
Examinons huit raisons pour lesquelles Scrum est difficile, probablement même plus difficile que d’apprendre à danser.
Problème 1 : Tout changement est difficile
Si la nouvelle façon de faire quelque selected était plus facile, vous le feriez probablement déjà de cette façon. Il y a généralement une raison pour laquelle nous avons choisi de faire quelque selected comme nous l’avons fait. Il y a quelques mois, j’ai remarqué que je fouettais toujours les aliments dans le sens des aiguilles d’une montre. Juste pour le plaisir, j’ai commencé à fouetter dans la course opposée. C’est dur.
Lorsqu’une équipe adopte Agile, cela affecte presque tous les points de la façon dont les membres de l’équipe effectuent leur travail quotidien. Un tel changement généralisé est difficile. Même si les membres de l’équipe sont motivés pour réussir le changement, il y aura des moments où ils se demanderont si cela en vaut la peine.
C’est vrai : quelque selected de easy à comprendre peut être difficile à maîtriser. Pour soulager une partie de la douleur de l’apprentissage, donnez aux gens un chemin clair à suivre et beaucoup de clarté sur le remark et le pourquoi. Mon pourquoi pour obtenir un recyclage de danse, c’était que je ne voulais pas embarrasser ma femme et ma fille au mariage; et mon remark était les leçons.
Problème 2 : Les revues de dash font peur au début
Montrer votre travail aux autres et entendre leurs opinions à ce sujet peut sembler une menace pour votre estime de soi. Vont-ils l’aimer? Le système plantera-t-il pendant la partie démo du revue de dash? En avons-nous fait assez pendant le dash ? Ce sont des questions intimidantes.
Pourtant, ces questions, et d’autres comme elles, nous viennent à l’esprit lorsque Équipes Scrum commencez par donner des démos lors des revues de dash.
La bonne nouvelle est qu’après un sure temps, les critiques deviennent une seconde nature. Comme les équipes de développement voient l’avantage de recevoir des commentaires rapides, elles peuvent anticiper les avis avec impatience plutôt que de les craindre.
Problème 3 : Savoir quoi faire avec les commentaires est difficile
Même une fois que les membres de l’équipe sont devenus à l’aise de montrer leur travail toutes les deux semaines, il peut être difficile de savoir quoi faire de tous ces commentaires. Avec les commentaires qui arrivent rapidement et furieusement, les équipes doivent décider quels commentaires intégrer et lesquels ignorer.
Il y a aussi le timing : avec un processus en cascade, les commentaires sont sollicités à la fin, une fois que l’équipe a l’impression que le projet est terminé. Lorsque les commentaires sont fournis de manière plus progressive, toutes les deux semaines, les équipes peuvent se sentir dépassées. Ils ont l’impression de prendre du retard chaque fois qu’ils demandent des commentaires.
Une answer consiste à… hiérarchiser les objectifs de votre produit. Cela vous aidera à passer au crible les commentaires cruciaux des détails qui n’ont pas besoin d’être traités pour le second. Après tout, tout ne peut pas être prioritaire A.
Problème 4 : Toute cette collaboration semble plus lente
Avant de devenir programmeur, j’ai travaillé dans une chambre noire pour développer des photographs. Je commençais chaque jour en emportant un tas de pellicules non développées dans ma chambre noire. Je n’ai ouvert la porte qu’à midi, quand j’ai mis les photographs du matin dans une poubelle. J’ai pris le déjeuner, une nouvelle pile de movies, et je me suis séquestré dans la chambre noire jusqu’à l’heure de la démission.
J’ai aimé l’isolement. Et cela a continué en tant que programmeur lorsque je mettais des écouteurs, montais la musique et codeais de manière isolée toute la journée.
Je peux donc m’identifier aux membres d’équipes agiles qui souhaiteraient pouvoir se voir confier une tâche importante, puis s’en aller et le faire pendant quelques semaines (ou plus) sans avoir besoin de communiquer jusqu’à ce que la tâche soit terminée.
Mais les produits que nous fabriquons aujourd’hui nécessitent beaucoup plus de collaboration qu’au début de ma carrière. Et parfois, collaborer avec ses coéquipiers donne l’impression que cela nous ralentit.
La clé est de réaliser que toutes les conversations, les e-mails, les messages et les réunions aident à prévenir les problèmes. Ce que vous entendez et dites lors d’une réunion ne sera parfois pas utile. Mais très souvent, dans une réunion bien gérée, ce que vous entendez résout un problème, et ce que vous dites s’avère utile à quelqu’un d’autre.
Problème 5 : Les story factors sont une nouvelle façon d’estimer
L’idée d’estimer dans factors d’histoire peut certainement être un défi pour de nombreux membres de l’équipe. Je peux presque les entendre penser : « J’ai du mal à estimer en jours et maintenant je dois estimer dans une unité relative abstraite dont je n’ai jamais entendu parler auparavant ? »
Les factors d’histoire sont un défi sure, mais ils en valent la peine. En tant qu’estimations kin abstraites de l’effort, les factors d’histoire permettent de meilleures conversations sur la durée du travail.
Sans factors d’histoire, un programmeur senior et un programmeur junior ont des conversations qui se transforment en « C’est le temps que cela vous prendra, mais cela me prendrait deux fois plus de temps. » Et puis les deux choisissent une estimation qui est horrible pour l’un d’eux ou, peut-être pire encore, ils se partagent la différence.
Avec les factors d’histoire, les programmeurs seniors et juniors peuvent envisager d’ajouter une nouvelle fonctionnalité et tous deux conviennent que cela prendra deux fois plus de temps que de faire une fonctionnalité plus easy. Ils donnent ensuite à l’élément le plus gros une estimation deux fois supérieure à celle de l’élément le plus easy.
L’estimation de cette manière relative permet aux développeurs de s’entendre même s’ils ne pourraient jamais s’entendre sur le nombre d’heures ou de jours que quelque selected prendrait. Bonus : les factors d’histoire découragent les managers de comparer la vélocité de l’équipe.
Problème 6 : Les gens se plaignent qu’il y a trop de réunions
Une plainte courante à propos de Scrum est qu’il y a trop de réunions. C’est une critique juste, mais je ne pense pas qu’elle soit justifiée, automotive chacun peut être assez efficace. Considérons la durée recommandée de les rencontres d’un dash de deux semainescomme résumé dans le tableau.
| Réunion | Temps par dash de deux semaines (heures) | |
|---|---|---|
| Mêlée quotidienne | 1.5 | |
| Planification des sprints | 2 | |
| Examen | 2 | |
| Rétrospective | 1 | |
| Raffinement du backlog | 1.5 | |
| Complete | 8 |
C’est environ huit heures. Huit heures de temps de réunion dans un dash de deux semaines, c’est donc trop ? Tout d’abord, gardez à l’esprit que ces chiffres sont conservateurs. Sept heures peuvent être un whole plus réaliste. Huit heures, c’est beaucoup de temps, mais je ne pense pas que ce soit excessif.
Les réunions dans Scrum sont comme les lignes sur l’autoroute. Les lignes sont là pour aider les conducteurs à avancer rapidement et en toute sécurité. Les réunions de Scrum devraient se sentir de la même manière. Ils assurent la sécurité des membres de l’équipe en s’assurant qu’ils savent chacun ce que fait l’autre.
Les réunions doivent aider l’équipe à bouger plus vite en créant des opportunités de communication. Si les réunions de votre équipe ne ressemblent pas aux lignes blanches sur l’autoroute, envisagez de raccourcir ou d’éliminer une réunion.
Problème 7 : Ce n’est pas facile d’être un Scrum Grasp
Tu as raison. Scrum n’est pas facile. Et ce n’est pas facile d’être un Maître de mêlée soit. Mais la plupart des emplois ne sont pas faciles lorsque vous êtes nouveau. Restez avec lui assez longtemps et cela devient plus facile.
Et à ce stade, il existe de nombreux livres, cours, boards en ligne et bien plus encore sur le fait d’être un Scrum Grasp. Vous n’êtes jamais très loin des conseils.
Problème 8 : Être Product Proprietor est un travail difficile
Si vous pensiez qu’être un Scrum Grasp était difficile, essayez d’être le propriétaire du produit. Les propriétaires de produits l’obtiennent des deux côtés : les équipes demandent de la clarté et plus de détails, les shoppers et les utilisateurs demandent des fonctionnalités. Être propriétaire d’un produit nécessite d’équilibrer ces demandes concurrentes pour leur temps.
Scrum est difficile mais ça vaut le coup
Adopter une approche Scrum est difficile. Il y aura probablement des moments où vous voudrez lever les bras et revenir à ce que vous faisiez auparavant.
Habituellement, ces pensées sont assez fugaces. Tenez-vous-en, cependant, je suis sûr que vous êtes déjà bien meilleur que moi en danse. Et je n’ai pas encore abandonné. Je m’en tiendrai si tu veux.
Qu’en penses-tu?
Quels points de Scrum avez-vous trouvé difficiles ? Y a-t-il eu des moments où vous avez été tenté de l’abandonner ? Avez-vous persévéré? Cela en valait-il la peine? Veuillez partager vos réflexions dans les commentaires ci-dessous.
