La photo est tirée de cette ressource .Votre concurrent ou partenaire a déjà implémenté Scrum et affiche de bons résultats, et bien sûr, vous souhaitez obtenir le même résultat. J'ai de mauvaises nouvelles pour vous: s'il est mal utilisé, Scrum peut être dangereux.
Voici, par exemple, une liste de situations identifiées empiriquement dans lesquelles Scrum peut interférer avec votre travail.
1. Prévoyez-vous de combiner les rôles de la gestion de projet classique et Scrum
Scrum-team doit inclure 3 rôles: Product Owner, Development Team et Scrum-Master. Dans le cadre de la composition proposée, l'équipe reste «plate», c'est-à-dire que nous n'avons pas de subordination directe entre les participants. Une telle équipe est habilitée à prendre indépendamment toutes les décisions concernant le produit en cours de développement. Les rôles dans Scrum décrivent clairement qui est responsable de quels problèmes.
Imaginez maintenant que vous envisagez d'implémenter Scrum dans une équipe avec une gestion de projet classique. Ensuite, l'équipe Scrum commence à travailler avec la participation du chef de projet. Que se passe-t-il dans ce cas? En fait, PM n'a tout simplement rien à faire dans un tel projet. Tous les domaines de responsabilité que nous lui transférons créent un déséquilibre dans l'équipe Scrum. Donnez un budget à PM? Excellent, c'est-à-dire que PM ne réglemente pas la valeur et le contenu du produit, mais en cas de problème, ce sera lui qui le recevra sur la tête. Lui donnerons-nous également du travail avec la valeur du produit? Il sera alors possible de supprimer le Product Owner. Mais ce ne sera pas Scrum.
Comment les rôles et les tâches dans une équipe changent avec l'arrivée de Scrum2. Vous travaillez avec des exigences extrêmement claires
Scrum a été créé pour développer des produits à haut niveau d'incertitude. Cela fonctionne bien dans les cas où nous avons besoin de versions fréquentes pour obtenir des commentaires du marché. Dans une situation où nous avons des exigences détaillées qui ne laissent pas de place à la créativité, ou lorsque nous n'avons pas besoin de commentaires des clients / utilisateurs, Scrum ne passe du temps d'équipe que pour des réunions qui ne sont pas d'une grande valeur pour le développement de produits.
Quand tout est déjà clair, pourquoi le compliquer?
3. Vous travaillez avec des projets de courte durée
La base de Scrum est une approche empirique. Son sens est que nous nous tournons vers l'expérience existante de l'équipe afin de pouvoir prédire ses futurs succès. Si nous travaillons sur un projet d'une durée de 2 mois, nous n'aurons tout simplement pas le temps d'accumuler suffisamment d'expérience pour l'appliquer afin d'améliorer les processus de travail.
4. L'équipe n'a aucune envie de changer l'approche du travail
C'est l'une des principales limitations de la mise en œuvre de Scrum. Implémenter Scrum comme guide est presque toujours une mauvaise idée, d’abord il est important de transmettre des valeurs à l’équipe, de «vendre l’idée». Mais même après cela, vous n'aurez pas la garantie que les idées de Scrum seront proches de tous ses participants. Ceux qui n'ont pas accepté en interne l'idée de Scrum et des valeurs agiles peuvent commencer à détruire le système de l'intérieur, à «secouer le bateau».
Il existe plusieurs scénarios possibles. Premièrement: Scrum ne prend pas racine du tout. Cela peut arriver si la majeure partie de l'équipe est contre le changement. Soit l'équipe organisera une émeute dès le début, soit elle fera tout pour que la nouvelle approche se révèle inefficace.
Deuxième option: un ou plusieurs participants ne voudront pas travailler dans le nouveau système. En règle générale, de telles situations font en sorte qu'un participant «problématique» quitte l'équipe par lui-même.
Changer Nous attendons le changement.
La photo est tirée de cette ressource .5. Vous n'êtes pas prêt à utiliser toutes les pratiques requises de Scrum
Pour cette approche, ils ont même inventé le terme spécial ScrumBut. C'est à ce moment que nous travaillons sur Scrum, mais ... Nous n'avons pas de rétrospectives. Mais nous avons une réunion quotidienne 2 fois par semaine. Mais nous avons abandonné le rôle du Scrum master. Et bien d'autres «mais» similaires.
Le cadre Scrum fournit une réponse simple et claire à toutes ces situations. Oui, vous pouvez ajouter des pratiques supplémentaires au processus Scrum de votre équipe (par exemple, des pratiques de XP). Mais non, vous ne pouvez refuser aucun élément de Scrum, car ce ne sera pas Scrum.
Tous les rôles, événements et artefacts de Scrum sont étroitement liés et visent à atteindre un objectif commun - fournir efficacement aux clients un produit de valeur maximale. Le rejet de toute partie de Scrum nous éloigne de cet objectif.
6. Vous n'êtes pas prêt à recruter des employés pour travailler à temps plein sur un produit
Avez-vous vu un graphique de la dépendance du temps de travail productif sur le nombre de projets sur lesquels vous travaillez simultanément? Sinon, alors regardez.
Ce diagramme lui-même est le meilleur argument en faveur de l'implication des employés dans le travail sur un projet à la fois. Mais si elle ne vous convainc pas, soustrayez du temps restant sur un projet lorsque vous travaillez avec plusieurs autres, le temps qui sera consacré aux réunions obligatoires (réunions quotidiennes, rétro, planification, revue de sprint). Un membre de l'équipe aura trop peu de temps pour travailler sur des tâches. En avez-vous besoin?
Il existe des exceptions à cette règle. Par exemple, Scrum-Master peut travailler avec plusieurs équipes à la fois. Mais pour les autres participants, il est nécessaire d'assurer une implication maximale uniquement dans ce projet.
7. Vous n'avez pas de support de gestion
Tout comme nous voulons que les employés adoptent une nouvelle approche du travail, nous avons également besoin du soutien de la direction. Il est important de comprendre que l'introduction de Scrum, en particulier sur
les premiers stades peuvent nécessiter un certain investissement. Par exemple, embaucher un coach Agile ou un Scrum Master professionnel, former le Product Owner, organiser une formation Scrum pour les employés, et bien plus encore. Le leader doit être prêt à soutenir financièrement la nouvelle entreprise.
Mais ce n'est pas la chose la plus importante. Il est beaucoup plus important que la direction de l'entreprise partage les valeurs de Scrum et soit prête à changer la culture de l'entreprise. Par exemple, un leader doit être préparé au fait qu'il devra donner de nouveaux pouvoirs dans le cadre de nouveaux rôles dans l'équipe. Tout le monde n'est pas prêt pour cela, donc «vendre une idée» à ce niveau peut également être nécessaire.
Cette liste de critères ne prétend pas être exhaustive, vous pouvez la compléter par vous-même ou partager vos cas dans les commentaires.