Y avait-il un Scrum *?

* Scrum (nom) est un cadre qui aide à résoudre les tâches qui changent au cours du processus de travail afin de livrer efficacement et de manière créative des produits aux clients avec la plus grande valeur possible.

Pourquoi j'ai décidé d'écrire cet article

Très souvent dans un environnement de travail, sur Internet et lors des entretiens, vous pouvez entendre, par exemple, ceci:

«Il y a tellement de rencontres avec cette Scrum! Quand travailler alors?! ”;
"Eh bien, que ce soit au moins Scrum, au moins la honte, juste le retirer et laissez-moi écrire le code!";
«Nous avons également imposé ce Scrum, en général on ne sait pas pourquoi»;
«Chaque jour, debout pendant une quarantaine de minutes, pourquoi dois-je y assister? Je veux savoir ce que j'ai fait et sur quoi je travaille actuellement - voir Jira, Confluence, Git, etc. "
«Le Scrum master est généralement un bouffon, il devrait faire le tour de la danse au lieu de gérer le projet!»;
"Oui, nous avons utilisé Scrum: l'essentiel est que nous ayons réalisé des rétrospectives."

Le but de cet article est de montrer que la négativité, qui continue de couler dans un grand courant vers Scrum, ne s'applique pas à elle, et le problème doit être cherché ailleurs.

Ensuite, je voudrais parler de cas typiques d'où proviennent ces problèmes.

Je suis moi-même un employé Scrum certifié (scrum.org) d'une grande organisation du secteur financier (pas «vert» si cela). À l'heure actuelle, nous n'avons pas Scrum, mais nous allons dans cette direction, et personnellement j'ai une vision de pourquoi et comment nous continuerons à le faire.

En fait, la fascination pour les méthodologies flexibles et Scrum en particulier m'est venue il n'y a pas si longtemps, mais à mon avis, il est important non pas «il y a combien de temps», mais «comment qualitativement et consciemment».

Et plus vous plongez dans ce sujet, plus vous vous rendez compte que ce cadre est un puissant «outil», et plus chaque fois que vous rencontrez des phrases et des critiques au début de l'article, ce qui est, en règle générale, la preuve de tentatives maladroites de passer à Scrum.

Pourquoi des tentatives, et même maladroites: parce qu'ils ne savaient pas pourquoi tout ce Scrum, et Agile, en principe, s'arrêtaient un peu plus tôt qu'au tout début de la transition.

Les entreprises qui comprennent pourquoi Scrum est nécessaire et comment l'utiliser, à mon avis, ne sont pas si fréquentes dans notre pays.

La puissance de Scrum, invisible pour beaucoup, peut être comparée dans une certaine mesure à la puissance d'Excel: tout semble assez simple, mais si vous creusez ...

Néanmoins, je ne considère pas Scrum comme une solution miracle, tout comme ses créateurs (je ne fournirai pas de lien vers un article récemment publié dans une publication faisant autorité), et c'est déjà un sujet pour un article séparé.

1. «Imposée»

À mon avis, l'une des principales raisons pour lesquelles Scrum provoque une telle aversion est qu'il a simplement été «abaissé d'en haut» lors de la transformation de l'organisation. Et le problème ici est exactement comment s'est déroulée la transformation:

• La direction a-t-elle compris pourquoi elle allait adopter des méthodologies flexibles et Scrum en particulier?
• Comment ont-ils informé les employés de la nécessité de la transformation et pourquoi les méthodologies flexibles et Scrum en particulier y aideront-ils?
• Comment avez-vous accompagné les collaborateurs dans les conditions de la transformation, avez-vous assuré une formation de qualité, une certification et une assistance au lancement des équipes?

Une histoire très courante, c'est lorsque les entreprises se transforment, simplement parce que c'est «à la mode».
En fin de compte, il est peu probable que quelque chose de bien se produise et le murmure qui en résulte se transforme par la suite en une vague de négativité.

À cet égard, j'ai aimé une phrase du sujet: "Dans les entreprises traditionnelles, les managers traditionnels organisent les transformations traditionnelles".

Cependant, je vais être honnête avec vous: lorsque nous avons obtenu Agile / Scrum / Kanban pour la première fois, c'était à propos de Scrum que je pensais au départ comme une sorte de poubelle avec des réunions sans fin. Des changements d'attitude à son égard sont survenus après que je me suis posé la question: «Et si ...?» Pour moi dans un projet très cool.

2. La bonne aventure par Scrum

Une autre raison de l'indignation et même de l'amertume chez Scrum est son interprétation incorrecte, associée principalement à l'endroit où nous en tirons des connaissances. En conséquence, par exemple, nous avons des «cérémonies du thé» ou des «rituels de sacrifice» au lieu d '«événements».

Je n'exclus pas la présence de schismatiques qui se disputent à propos de se tenir sur le Daily Scrum avec un cercle, un carré ou une autre figure. S'il est rond, passez le mot dans le sens horaire, contre ou d'une autre manière.

Dans le même temps, il y a un manque total de compréhension de la raison pour laquelle ces réunions (événements) obligatoires notoires existent dans Scrum, qui, en passant, peuvent être comptées sur les doigts d'une main.

En regardant l'énorme flux d'informations sur le réseau, il semble que beaucoup ne savent tout simplement pas quelle est la source principale et où obtenir les connaissances de base du cadre.

Ainsi, le document Scrum principal est le Guide Scrum, co-écrit par Ken Schwaber et Jeff Sutherland, disponible dans de nombreuses langues, y compris le russe.
À mon avis, afin d'acquérir des connaissances de base sur Scrum et, par la suite, de ne pas obstruer votre esprit avec toutes sortes d'ajouts mal compris à Scrum, vous n'avez besoin que de deux éléments principaux: le désir et la lecture réfléchie du Guide Scrum, et plus d'une fois. Ce document est assez compact - moins de vingt pages, vous pouvez maîtriser.

Quant aux formations, je dirai brièvement: attention! Je ne ferai de publicité à personne dans le cadre de cet article, mais je pense que dans notre pays, seules une ou deux entreprises peuvent se fier aux «bonnes formations» sur ce sujet.

3. "Interprétation" de certaines sections du Scrum Guide et pas seulement

Dans le contexte du nombre de discussions similaires dans le réseau autour de Scrum, je vais essayer d'attirer l'attention sur elles et de déclarer ma compréhension conformément au guide et à l'expérience de Scrum.

Scrum c'est ...

Je distinguerai deux des trois caractéristiques: simple à comprendre et difficile à maîtriser parfaitement .

Certaines personnes pensent qu'il y a une contradiction.

Sprint

Dans cette sous-section, je vais délibérément soulever quelques questions qui pourraient vous faire réfléchir et repenser votre approche du cadre.

1. Que pensez-vous qu'il est logique d'appeler des sprints fixes dans des intervalles de temps? Par exemple, peut-il être plus simple d'envoyer simplement un rapport d'étape toutes les deux semaines?
2. Si vous êtes en train de passer à Scrum, depuis combien de temps avez-vous choisi Sprint? Lorsque j'ai posé cette question, j'ai rencontré le plus souvent un regard étonné, puis la réponse: "Standard - 2 semaines".
3. Pourquoi avez-vous choisi un sprint d'une telle longueur?
4. Pourquoi n'est-il pas recommandé de définir la durée du sprint sur plus d'un mois?

Certains peuvent ne pas le croire, mais les réponses à ces questions se trouvent dans le Scrum Guide.

4. mêlée quotidienne

L'un des sujets les plus controversés est le Daily Scrum, alias Daily Standup Meeting, alias Daily Scrum, ou simplement «Stand-up».

Vous ne me croyez peut-être pas, mais cet événement a une durée fixe (time-box) - pas plus de 15 minutes, quelle que soit la durée du Sprint.

L'équipe détermine elle-même le format de la réunion. Et la chose la plus importante au cours de cette période de quinze minutes est de comprendre l'état d'avancement du Sprint Goal.

Maintenant, des questions pour le remblayage: combien d'entre vous savent ce qu'est l'objectif de sprint? Combien d'entre vous savent comment le formuler? Et qui les formule du tout?

Dans la grande majorité des cas, Scrum s'indigne précisément à cause de leur ignorance et de leur incompréhension, car cet événement appelé Daily Scrum est nécessaire.

Ce n'est pas une réunion de reportage! Dans ces réunions que je regarde souvent, il n'y a pas assez d'informations, sauf sur le nombre de fois où une personne a bu du café, du thé, de l'eau et est également allée aux toilettes. Et «pas plus de 15 minutes» peut s'étirer pendant une heure et demie.

Encore une fois: Daily Scrum consiste à progresser vers les objectifs de sprint!

Ne réalisant que cette partie de Scrum, vous, à mon avis, pourrez faire une percée significative.
Et une autre remarque, qui pour beaucoup devient une révélation, Daily Scrum est un événement auquel il peut participer (note, «participer» et «se tenir prêt, écouter» sont deux choses différentes) que l'équipe de développement! Même Scrum Master (Scrum master) et Product Owner (Product Owner), s'ils ne sont pas membres à temps partiel de l'équipe de développement, ne sont pas directement impliqués dans cette réunion!

5. Scrum master n'est pas un chef de projet ni un serviteur

Un autre sujet très courant: Scrum Master (SM) = Project Manager (PM).

Vous pouvez trouver un tas d'articles sur SM vs PM.

Je vais souligner les principaux:

• Le Scrum Master est responsable de la promotion et du soutien de Scrum conformément au Guide Scrum.
• Les principales idées fausses sur le Scrum-master:
• Scrum master ne gère PAS le projet;
• Scrum master ne gère PAS l'équipe (qui prendre, qui retirer);
• Les Scrum-masters ne sont pas sélectionnés sur la base de l'employé le plus expérimenté ou de longue durée de l'entreprise;
• Scrum-master n'est PAS un secrétaire d'équipe, "obstruant les arrivées".
• Les tâches du Scrum Master NE comprennent PAS la livraison de pizza le vendredi (un sujet préféré lors des formations), le lavage des chaussettes et le repassage des lacets du propriétaire du produit ou des membres de l'équipe de développement.

Les domaines de responsabilité du Scrum Master sont également décrits dans le Scrum Guide.
À la fin de cette section, je peux lancer quelques sujets supplémentaires, pour étude indépendante, si quelqu'un est intéressé:

• Scrum en tant que culte du cargo vs. Scrum et shuhari.
• Le Product Owner est un chef de produit, pas un projet ou une équipe. Voici le PO vs PM.
• Product Owner et Scrum Master dans un seul paquet.
• La chose principale dans Scrum est une rétrospective, ou vous avez rencontré presque comme ceci: Scrum = rétrospective (mais une rétrospective de ce qui est une autre question)!
• ...

Elle est mûre à la lumière de ce que l'on retrouve dans l'ouvrage, dans les commentaires, y compris sur Habré.
Scrum est Ken Schwaber, Jeff Sutherland et leur Scrum Guide. Voir note de fin.
Scrum - c'est ce qui est dans le Guide Scrum, et non ce que vous avez l'habitude d'appeler dans votre entreprise.
Nous n'avons pas encore Scrum, mais nous le comprenons, le reconnaissons et savons comment nous y diriger. De plus, nous comprenons également qu'il est absolument nécessaire de s'y installer, car cela peut vraiment apporter de grands avantages à l'organisation.

Pour résumer

Si les notes ci-dessus, j'ai au moins fait réfléchir et repenser ce qu'est ce Scrum, et les méthodologies flexibles en général, alors je suppose que j'ai atteint l'objectif!
L'eau use la pierre et, peut-être, dans un avenir proche, nous n'entendrons pas aussi souvent que nous l'entendrons maintenant: "Vous êtes très emporté par ce Scrum, et sur la base des résultats de telle ou telle équipe (en utilisant ScramNO en fait) cela n'en vaut pas la peine."

Merci à tous pour votre attention et je serai heureux de vos commentaires et commentaires!

Les références

www.scrumguides.org/index.html