Get best of the week

Was ist die verborgene Bedeutung der Autoren im SCRUM-Handbuch? Teil 1. Über den Prozess

Sprechen Sie ĂŒber Magie und Einhörner SCRUM-a?

Bild

Es ist kein Geheimnis, dass viele versucht haben, SCRUM in ihren HĂ€usern zu implementieren, aber nicht jeder hat Erfolg, und viele verstehen nicht, woher die Magie kommen kann.

Stimmen Sie sofort zu, das einzige Handbuch fĂŒr SCRUM ist Scrum Guides . Es wird geĂ€ndert und aktualisiert. Ich empfehle Ihnen daher, es regelmĂ€ĂŸig erneut zu lesen.

Diese Artikelserie ersetzt nicht das Lesen des Handbuchs, sondern ergÀnzt den Leitfaden um einige persönliche ErgÀnzungen des Autors.

Und wir werden wahrscheinlich mit dem beginnen, was auf der letzten Seite des Handbuchs geschrieben steht:

Die Rollen, Ereignisse, Artefakte und Regeln von Scrum sind unverÀnderlich, und obwohl die Implementierung nur von Teilen von Scrum möglich ist, ist das Ergebnis nicht Scrum.

(Scrum-Rollen, Ereignisse, Artefakte und Regeln bleiben unverĂ€ndert . Obwohl die EinfĂŒhrung nur von Teilen von Scrum möglich ist, ist das Ergebnis nicht Scrum.)

Was sagt mir das, das nach 4 Transformationen in der Firma bereits einen Kallus auf der Stirn von dem Rechen hat, den wir angegriffen haben.

DarĂŒber - wenn wir A95-Benzin erhalten möchten, mĂŒssen wir uns wahrscheinlich strikt an die Produktionsstandards halten, das Öl in der RatifizierungssĂ€ule auf eine genau definierte Temperatur erwĂ€rmen, die DĂ€mpfe in einer bestimmten Höhe entnehmen, Komponenten nicht „mit dem Auge“ hinzufĂŒgen, sondern den letzten Punkt beachten seine Mutter! technologischer Prozess. Damit das Endergebnis A95 ist und nicht irgendein Körpergewicht, das Ihr Auto ruiniert.

Aber warum? Ein typischer (klassischer) Manager, der sich plötzlich entschied, SCRUM zu Hause zu implementieren, glaubt, dass der „technologische Prozess“ nicht in seinem Unternehmen liegt. Seine Leute sind anders, ihre HĂ€nde sind anders oder ihre Beine, der Code ist an der falschen Stelle geschrieben? Und im Allgemeinen scheint es mir nicht alle 30 Jahre der Entwicklung von ManagementansĂ€tzen zu interessieren. Es gibt eine Million GrĂŒnde, Ihr Fahrrad zum ersten Mal seit einer Million zu erfinden und dann stolz auf einer Nabe darĂŒber zu schreiben oder sogar ein Buch ĂŒber Ihr „schwarzes GedrĂ€nge“ zu schreiben . Durch die Popularisierung dieser „Bodyagie“ wurde durch den Schmerz und die TrĂ€nen der Entwickler der etablierte klassische Prozess zerstört, mit dem das Unternehmen mehrere Jahrzehnte zuvor gelebt hatte, und infolgedessen funktionierte es nicht.

// SCRUM ist - einfach zu verstehen


Das meine ich also. Was könnte einfacher sein als SCRUM: Planen Sie, verbringen Sie fĂŒnf Minuten am Morgen und sammeln Sie nach zwei Wochen alle und lassen Sie sie das Ergebnis zeigen (normalerweise nicht mehr benötigt), und warten Sie auf das Produkt, das allen Geld, Freude und Stolz bringt! Einfach? Lassen Sie uns implementieren, sagen Manager!

Dieser „Haken“ wirkt normalerweise jung und nicht erfahren, weil erfahrene (Leser) bereits wissen, dass es nicht so einfach ist.

// SCRUM ist - schwer zu meistern


Wissen Sie, was Jeff und Ken auf diesen 19 Seiten des Handbuchs versteckt haben? Eine einfache Wahrheit ist, dass je mehr sich ein Manager / Manager / Vorgesetzter um sein Team „kĂŒmmert“, desto schlechter das Team mit Selbstorganisation, desto schlechter das Ergebnis seiner Arbeit.

Jeder weiß, dass der schlechte Manager (mit dem sich das Team verschlechtert) ist:

  • kann nicht delegieren
  • er verteilt die Arbeit selbst, er akzeptiert das Ergebnis
  • tĂ€gliche Monitore
  • Es erfordert stĂ€ndige Berichterstattung, Dokumentation und das AusfĂŒllen von Zeitschildern (AnwesenheitsplĂ€ne).
  • traut dem Team nicht
  • erlegt seine Entscheidungen auf

(Ich hoffe, hier hat sich niemand wiedererkannt.)

Dies ist das gleiche „Hyperanliegen“ oder das GefĂŒhl von „Ältesten“, „Eltern“, „Verantwortlichen“, „Ich brauche es nur“.

Mit einem Befehl macht dies notwendigerweise schlechte Magie:

  • Das Team verliert die FĂ€higkeit zu denken. (Ihr Manager hört hier auf zu philosophieren, aber sagen Sie mir einfach, was ich tun soll.)
  • Das Team arbeitet an Aufgaben, nicht am Ergebnis, und gibt manchmal vor, aktiv zu sein. (Wir erledigen Aufgabe 1, Aufgabe 2, Aufgabe 3, und das Produkt ist gefallen. Lassen Sie die Administratoren / Entwickler verstehen.)
  • Das Team ist mit der Berichterstellung, Dokumentation, aber nicht mit der Arbeit beschĂ€ftigt. (Ich schreibe montags und freitags einen halben Tag Berichte, ich mache keine Aufgaben.)
  • Das Team widersetzt sich jeder Innovation. (Was sind die automatischen Tests? Lassen Sie uns die Aufgabe erledigen.)

Es ist nicht seltsam, aber SCRUM "begrenzt" das Team nur von einer solchen "Hyperkontrolle" durch den "Ă€lteren Elternteil".

Benötigen Sie Beweise? Bewahren Sie alles gemĂ€ĂŸ dem Scrum Guide auf:

Standup, nur fĂŒr das Entwicklungsteam!


Jeder Scrum-Master weiß, dass sich der Stand-up sofort in einen „Statusbericht“ verwandelt, sobald der „Manager“ eintrifft, selbst der „unser Freund“ -Produktbesitzer. Das Team wird nicht mehr darĂŒber diskutieren, was damit zu tun ist, um die Ziele des Sprints zu erreichen, aber plötzlich beginnen sie, „vor dem Ältesten zu tanzen“, um zu erzĂ€hlen, was ich getan habe und wie gut ich in allen Details bin. Und glauben Sie mir, das dauert sofort viel mehr als 15 Minuten, und das Traurigste ist, dass es fĂŒr alle Teammitglieder eine absolut nutzlose Zeitverschwendung ist.

In diesem Handbuch steht nicht umsonst geschrieben -
The Daily Scrum ist ein internes Meeting fĂŒr das Entwicklungsteam. Wenn andere anwesend sind, stellt der Scrum Master sicher, dass sie das Meeting nicht stören

(Daily Scrum ist ein internes Meeting des Entwicklungsteams
Es gibt noch jemanden, der Scrum-Master stellt sicher, dass er das Meeting nicht stört.)

Aber die ehemaligen Manager, die im neuen Prozess normalerweise Product Owner werden, hassen es, wenn sie nicht zu Stand-Ups eingeladen werden. Und das erste, was im SCRUM-Technologieprozess zusammenbricht, ist, dass alle Stand-Ups ihn besuchen, weil „Kontrolle ĂŒber allem steht“.

Bei Besprechungen mit dem Product Owner hat das Team nicht mehr als 10% der Zeit und nicht mehr als eine Minute Zeit


(Ich meine diejenigen, bei denen PO vorhanden ist, das Team kann sich jederzeit an PO wenden, wenn sie diese benötigen.)

FĂŒr einen zweiwöchigen Sprint sind dies streng regulierte 3 Meetings:

  • Maximal 4 Stunden beim Sprint-Planen
  • maximal 2 bei Sprint-ÜberprĂŒfung
  • und 1,5 Stunden Sprint Retro

Und das ist alles, in 2 Wochen hat der Product Owner laut Vorschriften nur 7,5 Stunden, zu denen es absolut keine Zeit fĂŒr „Kontrolle“ gibt. Die verbleibenden 90% der Zeit arbeitet das Team am Ziel des Sprints. (Aber haben Sie darĂŒber nachgedacht, wie viel Ihr Team wirklich codieren kann?)

In Wirklichkeit wird unser ehemaliger „Manager“ dies natĂŒrlich nicht tolerieren und dieses „Durcheinander“ mit ein paar Zwischenberichten und Rallyes brechen .

Das Team sollte die BedĂŒrfnisse des Kunden umsetzen, nicht die persönlichen Ziele des Product Owners.


Denn nirgends steht geschrieben, dass der Product Owner die Anforderungen fĂŒr das Produkt selbst schreiben muss, aber es ist geschrieben, was zu priorisieren und fĂŒr alle verstĂ€ndlich zu machen ist.

Ein guter Scrum-Meister weiß, dass es zur GewĂ€hrleistung von "Transparenz" unbedingt erforderlich ist, User Story-Kunden einzuladen, deren PrioritĂ€t es ist, sich mit dem Team zu treffen. Stellen Sie eine direkte Kommunikation mit dem Kunden her. Denn angesichts des Versprechens an den Kunden, oh, wie sehr motiviert das Team.

3 Prinzipien von SCRUM: Transparenz, Forschung, Anpassung

Aber was wird ein vernĂŒnftiger "Manager" erlauben? Es stellt sich heraus, dass die „Managerwahrheit“ des Ego in Frage gestellt wird. Dies ist die Chance des Teams, alle PlĂ€ne fĂŒr Karrierewachstum und die Eroberung des Universums zu „verhandeln“ und zu brechen.

Nein, SCRUM ist ein Albtraum fĂŒr den klassischen Manager, und die Menschen sind es gewohnt, in „Prozessen“ zu leben.

Daher versuchen sie normalerweise, diesen gesamten SCRUM-Prozess zu unterbrechen, mehr Kontrolle, weniger Transparenz und keine Anpassungsentwicklung hinzuzufĂŒgen.

Zusammenfassend: Der beste Weg, SCRUM zu begraben, besteht darin, Product Owner, frĂŒhere Projekte oder Ihre eigenen Manager zu ernennen.

  • PO, kein AnfĂŒhrer.
  • PO muss eine Person mit einzigartigen FĂ€higkeiten sein - um den Stapler dort zu sehen, wo andere ihn nicht sehen.
  • PO muss verstehen, wo mehr und wo weniger Geld / Werte und PrioritĂ€ten setzen.
  • PO sollte in der Lage sein, den Stapler zum Team zu bringen, wo das Team selbst sein Produkt bereits verkauft.

und weiter
— ? , Scrum , , .

Lass gute Leute gute Artikel lesen :)

More articles:


All Articles