La mêlée n’est pas pour vous

J’ai toujours appuyé sur le bouton Scrum pour rendre notre projet en direct – pensant que c’est la réponse ultime à une livraison meilleure et plus rapide. Travailler avec des équipes, interagir avec de nombreux professionnels de l’informatique et être le chef de projet moi-même – c’est le même modèle que j’ai vu surtout tout autour; Nous passons en mode pilote automatique pour choisir Scrum comme cadre de livraison. Pour penser pourquoi – il est évident – parmi tous les cadres agiles, Scrum est l’un des plus détaillés (avec son propre guide Scrum pour aider à comprendre comment l’appliquer), ce qui le rend plus facile à utiliser.

Cependant, au cours des trois dernières années, j’ai brisé mon sort de mêlée après avoir vu les modèles dans les équipes et les projets que je couvrirais dans ce blog pour souligner pourquoi Scrum n’est pas pour vous aussi.

1. S’en tenir à la mentalité de cascade – Ce sont de vraies vieilles habitudes ne meurent pas rapidement – la plupart des gens informatiques ont commencé leur carrière au moment où Waterfall portait à lui seul le poids de livraison du logiciel entre les entreprises. Lorsque l’ère de la numérisation est arrivée, Agile est venu. Alors que nous essayions de nouvelles façons de travailler avec Agile, nous ne sommes jamais devenus vraiment agiles. Il y a une tendance commune que j’ai vue à travers – Les équipes de Scrum transforment leurs sprints en mini-chutescomme l’un de mes chefs de produit l’a souligné à juste titre.
   
   Pour donner un exemple – Lorsqu’un sprint commence, les développeurs commencent à travailler sur leurs tâches / histoires – que ce soit la conception ou le développement – et l’équipe de test travaille sur leurs cas de test. Les histoires entrent en test vers le tout dernier d’un sprint. En principe, ce que fait l’équipe – ils prennent toutes leurs exigences dans la phase de conception et de développement et ils passent à la prochaine étape du test et du déploiement. Idéalement, dans Scrum – la livraison devrait commencer le jour 1 du sprint. Les graphiques de Burndown ci-dessous apporteront plus de clarté.
   

   Livraison cohérente de l’équipe contre l’équipe livrant à Sprint End

2. Sprint de boxe temporelle, mais pas de prise de décision – Les chefs de produit et les propriétaires d’entreprise devraient prendre la chaleur pour celui-ci. Votre lunette de sprint doit être finalisée dans la planification de sprint elle-même – bien sûr, il peut y avoir une pièce pour retirer quelques petits ajustements aux exigences, mais ce qui finit par se produire –
   • Chefs de produit / propriétaires d’entreprise priorités histoires pour le sprint qui ne sont pas entièrement raffinées ou recherchées, ce qui étire plusieurs fois ce travail pour plusieurs autres sprints
   • Changements de portée au milieu du sprint en raison d’une nouvelle demande critique des investisseurs / propriétaires d’entreprise. Lorsque ceux-ci arrivent sporadiquement, les équipes ont du mal à planifier efficacement
     

     Les exigences peu peu entraînées entraînent une chronologie peu claire

     En raison de ces facteurs qui, si cela se produit plus souvent qu’il ne le devrait, une équipe Scrum ne serait jamais en mesure de parvenir à des délais et aura du mal à terminer un sprint en temps opportun et à maintenir sa vitesse.

3. Avoir de lourds processus d’approbation – Dans un environnement où les équipes sont constamment aux prises avec des fonctions de bureau / de support / propriétaires d’entreprise pour tout accès, licences., Utilisation des outils ou pour tout processus comme les tests d’acceptation d’entreprise – de tels environnements rendent difficile pour les équipes d’avoir une planification appropriée du backlog et des sprints stables. Les équipes risquent un risque élevé d’imprévisibilité et de retard dans la livraison en raison de ces facteurs.
4. S’engager uniquement dans les tâches, et non sur les produits et la vision – La mise en œuvre de Scrum semble facile – grâce au guide détaillé de Scrum – mais il nécessite des individus et des équipes forts pour obtenir le maximum des avantages de Scrum. Afin d’atteindre un sprint et un objectif de produit dans un sprint et des rejets en cas de temporisation, les individus ne peuvent pas travailler isolément. J’ai vu des individus faire les choses suivantes –
   • Ils attendront que leur Scrum Master ou chef de projet leur attribue le travail au lieu d’avoir des articles dans l’arriéré
   • Concentrez-vous sur leur propre livraison au lieu de la livraison d’objectifs de sprint – n’ayant pas une idée de ce que les autres travaillent dans l’équipe
   • S’en tenir aux exigences telles qu’elles sont au lieu de comprendre le bénéfice qu’il apporte au client et de concevoir une meilleure solution
5. Avoir des projets à grande échelle et complexes – Coordonner avec plusieurs équipes, gérer les dépendances des équipes et maintenir une feuille de route du produit pour toutes les équipes – il y a des complexités auxquelles l’on fait face à des projets à grande échelle qui ne peuvent pas être résolus par Scrum. D’après mon expérience de travail avec des projets à grande échelle, j’ai vu à la fois le succès et l’échec des projets et la plupart du temps, l’échec est dû à la communication et à la collaboration entre les équipes. Pour avoir un canal de communication efficace dans les grandes équipes, il faut penser à un cadre à grande échelle au-delà de Scrum.

La loi de Metcalfe stipule que la valeur d’un réseau est proportionnelle au carré du nombre de ses utilisateurs connectés.

Ayant parlé de tous ces modèles que j’ai vus dans mon expérience ne sont pas indicatifs que Scrum est un cadre raté, il souligne simplement pourquoi Scrum pourrait être le mauvais outil pour la livraison de votre projet. C’est comme utiliser la fourche pour appliquer du beurre sur votre pain.

Comprendre ces limitations vous aidera à prendre une décision, que vous ayez besoin d’explorer d’autres cadres comme Kanban, Safe ou le modèle de cascade traditionnel ou vous aidera à fixer la limitation qui entrave l’équipe pour profiter des avantages de Scrum. L’objectif n’est pas d’utiliser Scrum en raison de sa popularité, mais en raison de sa nécessité dans votre projet.