Get best of the week

Quelle est la signification cachée des auteurs dans le guide SCRUM. Partie 1. À propos du processus

Tu parles de magie et de licornes SCRUM-a?

image

Ce n'est un secret pour personne que beaucoup ont essayé d'implémenter SCRUM chez eux, mais tout le monde n'y parvient pas, et beaucoup ne comprennent pas d'où peut provenir la magie.

D'accord immédiatement, le seul manuel de SCRUM est Scrum Guides , il change et se met à jour, donc je vous conseille de le relire régulièrement.

Cette série d'articles ne remplacera pas la lecture du manuel, mais sera un ajout au guide avec quelques ajouts personnels de l'auteur.

Et nous commencerons probablement par ce qui est écrit sur la dernière page du manuel:

les rôles, les événements, les artefacts et les règles de Scrum sont immuables et bien que l'implémentation de seulement des parties de Scrum soit possible, le résultat n'est pas Scrum.

(Les rôles, les événements, les artefacts et les règles de Scrum sont inchangés . Et bien que l'introduction de seulement des parties de Scrum soit possible, le résultat ne sera pas Scrum.)

Qu'est-ce que cela me dit, qui a déjà un cal sur le front du râteau que nous attaquions, après 4 transformations dans l'entreprise.

À ce sujet - si nous voulons obtenir de l'essence A95, nous devons probablement respecter strictement les normes de production, chauffer l'huile dans la colonne de ratification à une température strictement définie, prendre les vapeurs à une certaine hauteur, ajouter des composants non «à l'œil», mais respecter le dernier point sa mère! processus technologique. Pour que le résultat final soit A95, et non une sorte de poids corporel qui ruinera votre voiture.

Mais pourquoi? Pourquoi, un manager (classique) typique, qui a soudainement décidé de mettre en œuvre SCRUM à la maison, estime que le «processus technologique» n'est pas dans son entreprise. Son peuple est différent, ses mains sont différentes ou ses jambes, le code est écrit au mauvais endroit? Et en général, il semble que je ne me soucie pas des 30 ans d'évolution des approches managériales. Il y a un million de raisons pour inventer un vélo pour la première fois sur un million, puis écrire fièrement à ce sujet sur un moyeu, ou même écrire un livre sur votre «mêlée noire» . En popularisant que la «bodygirl», à travers la douleur et les larmes des développeurs, a détruit le processus classique établi avec lequel la société avait vécu pendant plusieurs décennies auparavant, et en conséquence, cela n'a pas fonctionné.

// SCRUM est - simple à comprendre


Voilà donc ce que je veux dire. Quoi de plus simple que SCRUM: planifiez, passez cinq minutes le matin, et après 2 semaines, rassemblez tout le monde et laissez-le montrer le résultat (généralement plus nécessaire), et attendez le produit, ce qui apporte de l'argent, de la joie et de la fierté à tout le monde! Simplement? Implémentons, disent les managers!

Ce «crochet» se rencontre généralement jeune et non expérimenté, car les (lecteurs) expérimentés savent déjà que ce n'est pas si simple.

// SCRUM est - difficile à maîtriser


Savez-vous ce que Jeff et Ken ont caché dans ces 19 pages du guide? Une vérité simple est que plus un manager / manager / superviseur «se soucie hyper de son équipe, plus l'équipe avec l'auto-organisation est mauvaise, plus le résultat de son travail est mauvais.

Tout le monde sait que le mauvais manager (avec lequel l'équipe se dégrade) est:

  • ne peut pas déléguer
  • il distribue lui-même l'œuvre, il accepte le résultat
  • moniteurs quotidiens
  • Cela nécessite des rapports constants, de la documentation, le remplissage des écrans horaires (horaires de présence)
  • ne fait pas confiance à l'équipe
  • impose ses décisions

(J'espère que personne ne s'est reconnu ici)

C'est la même «hyper inquiétude», ou est-ce le sentiment d '«aîné», «parent», «le plus responsable», «je n'en ai besoin que».

Avec une commande, cela fait nécessairement de la mauvaise magie:

  • l'équipe perd la capacité de penser. (Vous manager arrêtez de philosopher ici, mais dites-moi quoi faire)
  • l'équipe travaille sur des tâches, pas sur le résultat, parfois en «faisant semblant» d'être active. (Nous effectuons la tâche 1, la tâche 2, la tâche 3 et le produit est tombé, laissez les administrateurs / devops comprendre.)
  • l'équipe est occupée à produire des rapports, de la documentation, mais ne travaille pas. (J'écris des rapports une demi-journée le lundi et le vendredi, je ne fais pas de tâches.)
  • l'équipe résiste à toute innovation. (Quels sont les tests automatiques? Faisons la tâche.)

Ce n'est pas étrange, mais SCRUM «limite» simplement l'équipe à un tel «hyper contrôle» par le «parent aîné».

Besoin d'une preuve? Gardez tout selon le Scrum Guide:

Debout, uniquement pour l'équipe de développement!


Chaque Scrum master sait que dès que le «manager» arrive, même le «notre ami» Product Owner, le stand-up se transforme instantanément en «status report». L'équipe ne discutera plus de ce qu'il faut faire pour atteindre les objectifs du sprint, mais soudain, elle commence à «danser devant l'aîné» pour dire ce que j'ai fait et à quel point je suis bien fait dans tous les détails. Et croyez-moi, cela prend immédiatement plus de 15 minutes, et le plus triste, c'est que c'est une perte de temps absolument inutile pour tous les membres de l'équipe.

Dans le guide, ce n'est pas pour rien qu'il est écrit -
The Daily Scrum est une réunion interne pour l'équipe de développement. Si d'autres sont présents, le Scrum Master s'assure qu'ils ne perturbent pas la réunion

(Daily Scrum est une réunion interne de l'équipe de développement. S'il y a
il y a quelqu'un d'autre, le Scrum-master s'assure qu'ils n'interfèrent pas avec la réunion)

Mais les anciens managers, qui deviennent généralement Product Owner dans le nouveau processus, détestent quand ils ne sont pas invités aux stand-up. Et la première chose qui tombe en panne dans le processus technologique SCRUM est que tous les stand-up le visitent, car «le contrôle c'est avant tout».

Lors des réunions avec le Product Owner, l'équipe n'a pas plus de 10% du temps, et pas plus d'une minute


(Je veux dire ceux sur lesquels le PO est présent, l'équipe peut toujours se tourner vers le PO si elle en a besoin)

Parce que pour un sprint de 2 semaines, ce sont 3 réunions strictement réglementées:

  • 4 heures maximum sur le rabotage Sprint
  • maximum 2 sur la relecture de Sprint
  • et 1,5 heures Sprint rétro

Et c'est tout, en 2 semaines le Product Owner, selon la réglementation, ne dispose que de 7,5 heures, au cours desquelles il n'y a absolument pas de temps pour le «contrôle». Les 90% restants du temps, l'équipe travaille sur l'objectif du sprint (mais avez-vous considéré combien votre équipe peut vraiment coder?)

En réalité, bien sûr, notre ancien «manager» ne tolérera pas cela, et brisera ce «gâchis» avec quelques rapports et rallyes intermédiaires .

L'équipe doit mettre en œuvre les besoins du client et non les objectifs personnels du propriétaire du produit.


Parce que nulle part il n'est écrit que le Product Owner doit écrire les exigences pour le produit lui-même, mais il est écrit quoi prioriser et les rendre compréhensibles pour tout le monde.

Un bon Scrum master sait que pour assurer la "transparence", il est impératif d'inviter des clients User Story dont la priorité est de rencontrer l'équipe. Établir une communication directe avec le client. Parce que vu la promesse faite au client, oh combien motive l'équipe.

3 principes de SCRUM: Transparence, Recherche, Adaptation

Mais quel «gestionnaire» sensé permettra? Il s’avère que la «vérité managériale» de l’ego est remise en question, c’est la chance de l’équipe de «négocier» et de briser tous les plans de croissance de carrière et de capture de l’univers.

Non, SCRUM est un cauchemar pour le manager classique, et les gens vivaient dans des «processus».

Par conséquent, ils essaient généralement de rompre tout ce processus SCRUM, d'ajouter plus de contrôle, moins de transparence et aucune adaptation, développement.

En résumé: La meilleure façon d'enterrer SCRUM est de nommer le Product Owner, d'anciens projets ou vos propres managers.

  • PO, pas un leader.
  • PO doit être une personne avec des capacités uniques - pour voir l'empileur là où les autres ne le voient pas.
  • L'OP doit comprendre où plus et où moins d'argent / de valeurs et prioriser.
  • L'OP devrait pouvoir apporter l'empileur à l'équipe, où l'équipe elle-même vendra déjà son produit.

et plus loin
— ? , Scrum , , .

Laissez les bonnes personnes lire de bons articles :)

More articles:


All Articles