Aujourd'hui, je partagerai les observations du Scrum Master sur la première année de vie de l'équipe dans le nouveau cadre.
Pourquoi avons-nous décidé d'aller à Scrum? Les raisons sont courantes pour de nombreuses entreprises:
- la relation pas si simple entre «entreprise» et «développement»;
- la nécessité d'accélérer les livraisons;
- comprendre qu'il est nécessaire de reconstruire les processus.
Le passage à Kick-Off nous a pris environ six mois (à partir de début 2019): étudier, former, préparer le matériel et collecter les informations nécessaires. Et enfin,
le 3 juin 2019, nous avons commencé le premier sprint.
La première année dans le nouveau cadre est un défi pour l'équipe et le Scrum Master. Il est nécessaire de changer radicalement la mentalité et de commencer à faire les choses différemment.
De quoi un Scrum Master doit-il se souvenir pendant cette période?
La Scrum Master n'est pas une chaussure, elle n'a pas besoin d'être confortable. Il est nécessaire de développer une compétence durable pour refléter l'équipe et ses membres individuels de comportements malsains. Il est très important d'apprendre à donner un feedback correctement et en temps opportun, même si cela fera sortir le Scrum Master et l'adversaire de la zone de confort.
Pensez en termes d'équipe, pas d'individus. Vous devez considérer l'équipe comme un organisme vivant et vous rappeler que si «des organes individuels tombent malades», alors tout l'organisme peut commencer à se morfondre. Pour continuer l'analogie, le Scrum Master est un thérapeute. Pas un chirurgien, mais un thérapeute, par conséquent, les cas cliniques difficiles sont pour d'autres spécialistes.
Scrum, comme LeSS, ne tolère pas l'immaturité personnelle des membres de l'équipe. Si l'équipe ne sait pas ce qu'est Scrum, n'a jamais travaillé dans ce cadre et, de plus, si elle a déjà fonctionné dans la composition actuelle, alors je recommanderais de ne pas retourner dans LeSS tout de suite.
Identifier des volontaires pour le coup d'envoi (qui prend généralement trois jours) au sein d'une équipe qui n'a pas travaillé auparavant sur Scrum est plus susceptible d'être faux. Si les gens n'ont jamais travaillé dans ce cadre auparavant, ils comprennent à peine ce que c'est et peuvent vraiment parler de leur volonté de travailler de cette façon.
Hardy n'est pas tout. S'il y a un problème avec le logiciel, alors même un développeur qui est très cool en termes de dureté peut devenir un gros problème.
Dans les équipes auto-organisées, les personnes ayant une réflexion développée, une intelligence émotionnelle et un désir de développement personnel continu, d'expansion de la conscience et une volonté de changer de paradigme peuvent vivre et exister harmonieusement.
Il serait naïf de croire que vous êtes le plus intelligent. Il est très important de transmettre ce message à chaque membre de l'équipe. La pénétration dans cet état d'esprit le plus simple donne lieu à de nombreux avantages plutôt qu'à des inconvénients: du respect mutuel au «sentiment d'être ensemble».
Le plus dur est de travailler de manière responsable. Il est important que les gens comprennent que le «volontariat» ne concerne pas seulement la volonté et la volonté de travailler dans Scrum. Il s'agit de la volonté de se développer, de se développer au-dessus de soi, d'apprendre à donner et à recevoir du feedback, à réfléchir et à apporter des changements. Il s'agit du processus continu d'amélioration non seulement des processus, mais également de nous-mêmes.
Les gens ne comprennent souvent pas pourquoi un Scrum Master est nécessaire. Et ici, après avoir mené de nombreux dialogues et ateliers, discussions et conversations, je suis arrivé à la conclusion que ce malentendu est souvent dû à la réticence à le comprendre. Le Scrum Master doit garder cela à l'esprit et continuer à y travailler.
Qu'est-ce que Scrum nous a apporté en un an?
«Les affaires» et le «développement» sont devenus inséparables - la compréhension de «nous» et «ils» a cessé d'exister. Les experts métiers travaillent avec les développeurs dans les mêmes équipes. Désormais, la compréhension de ce dont une entreprise a besoin réside au sein des équipes de développement. En conséquence, nous avons considérablement amélioré la vitesse de livraison: désormais, les versions se produisent une fois par sprint. Nous vivons actuellement dans des sprints de trois semaines. Auparavant, le taux de diffusion réel n'était pas plus d'une fois tous les 1,5 mois.
Nous avons légalisé la dette technique et avons commencé à prendre du temps pour cela dans les sprints. Nous nous sommes mis d'accord sur la proportion de 70% contre 30%, où 30% étaient alloués à la dette technique.
En un an, nous avons pu impliquer toutes les compétences critiques au sein de l'équipe, abandonner les fournisseurs et internaliser le développement. L'influence de chacun sur les résultats de développement et sur les solutions mises en œuvre s'est considérablement accrue. L'immersion des développeurs dans le produit et le contexte client a considérablement augmenté. En conséquence, la charge sémantique «Pourquoi?» A changé qualitativement.
Nous avons lancé le processus Discovery - augmenté de manière significative l'immersion dans la «peau du client». Maintenant toutes nos idées, quant à ce qu'il nous semble que le client serait utile, nous vérifions directement avec les clients. Créé un environnement prêt à expérimenter et une culture de la volonté d'expérimenter.
Mise en œuvre de CI / CD.
Nous avons couvert pratiquement toutes les fonctionnalités de l'application WEB avec des tests automatiques, ce qui a considérablement réduit le temps et les coûts de main-d'œuvre pour la régression manuelle.
Nous avons entamé la transition vers une architecture de microservices, ce qui devrait ajouter plus d'indépendance aux équipes de développement.
Nous avons introduit un système de surveillance des applications et du matériel: maintenant en mode en ligne, il est possible de surveiller l'état de l'un et de l'autre, et parfois de recevoir des signaux avant que les appels des clients ne partent. Nous avons construit un certain nombre de tableaux de bord pour le suivi des indicateurs métier, y compris les KPI en mode automatique.
Au cours de l'année, nous avons réussi à faire beaucoup, mais notre chemin continue.
PS: Je n'ai délibérément pas écrit sur les étapes de la mise en œuvre de Scrum. Vous pouvez en lire beaucoup à ce sujet maintenant. Si cela vous intéresse, je peux écrire un article séparé.