Die agile Entwicklung ist De-facto-Standard wegen der Flexibilität und der schnellen Verfügbarkeit. Aber die agile Entwicklung ist nur die Werte oder Denkart. Deshalb muss man konkreten Vorgang überlegen, um die agile Entwicklung einzusetzen.

Es gibt mehrere Frameworks agiler Entwicklung. Aber Scrum ist wahrscheinlich am beliebtesten. Das liegt vielleicht daran, dass Scrum sehr einfach zu verstehen ist. Die Scrum-Ereignisse sehen normalen Projekt-Management aus. Deshalb neigen viele Team- oder Projektleiter, Scrum einzusetzen.

Ich bin überzeugt davon, dass das Projekt schief geht, wenn der Leiter Scrum einsetzt, ohne den Hintergrund von Scrum zu verstehen.

In diesem Eintrag erzähle ich, warum Scrum in Ihrem Team nicht funktioniert.

Warnung

Ich bin kein zertifizierter Scrum Master. Meine Kenntnisse auf Scrum basieren auf den folgenden Materialien.

• [SS] Scrum Guide
• [A] Scrum Advanced: Software Development & Program Management (Bescheinigung)
• [RW] Scrum in der Praxis
• Verschiedene Webseite, was ich gehört habe und meine Erfahrung.

Oberflächlicher Unterschied

Bevor wir über den Grund für ein schief gehendes Projekt diskutieren, sehen wir den Unterschied zwischen einem normalen Projektteam und einem idealen Scrum Team.

Die Bedingungen werden nicht im Scrum Guide [SS] erwähnt, sondern sie werden oft zum idealen Scrum Team gesagt. Den Grund für die Bedingungen kann man in [RW] finden (außer Crossfunktionalität).

Wichtig ist, dass jede Entwickler sich nur einem Projekt widmen kann.

Der schlimmste Fall liegt vor, wenn Teammitglieder verschiedenen Projekten zugeordnet sind. Damit wird die Entscheidung, welche Arbeit wichtiger ist und in welcher Reihenfolge abgearbeitet wird, auf die betroffene Person abgewälzt. ([RW] §3.1.2)

Damit alle Entwickler sich nur auf das Projekt konzentrieren können, vertreibt der Scrum Muster denjenigen, der ein Teammitglied um etwas bittet.

Erfüllt Ihr Team die Bedingungen für ein ideales Scrum Team?

Aber eigentlich habe ich den wichtigsten Unterschied noch nicht geschrieben. In nächstem Abschnitt diskutieren wir darüber, nachdem ich über Crossfunktionalität schreibe.

In Bezug auf die Crossfunktionalität in Scrum

Vielleicht sind viele Scrum Masters gegen meine Behauptung für Crossfunktionalität. Crossfunktionalität kann nämlich in Scrum funktionieren. Ich muss leider widersprechen.

Achten Sie darauf, dass es keine Schuldzuweisungen innerhalb des Teams gibt. ([RW] §3.1.1)

Wenn ein Sprint nicht erfolgreich ist, ist das ganze Team schuldig. Man darf nicht sagen, dass ein bestimmter Entwickler schuldig ist.

Aber was wäre, wenn wie ein komplexes System einbauen würden. Zum Import der Daten muss man verschiedene API und nötigen Bibliotheken verwenden. Für Hadoop Cluster braucht man natürlich besondere Kenntnisse. Eine Dashboard-Applikation verlangt auch viel Übung, um die Funktionen und Verhalten der Applikation zu verstehen.

Es ist typisch, dass ein Backend-Entwickler nicht durch einen Frontend-Entwickler ersetzt werden kann, und vice versa. Was wäre, wenn der Backend-Entwickler eine Aufgabe in diesem Sprint nicht fertig machen könnte.

Könnte der Frontend-Entwickler sich schuldig fühlen? Er hat keine Kenntnisse auf dem Backend, deswegen konnte er nicht viel machen, damit der Backend-Entwickler rechtzeitig die Aufgabe erledigen konnte.

Alle Teammitglieder sind gemeinschaftlich für die Ergebnisse verantwortlich. ([RW] §3)

Das ist nicht vereinbar mit der Crossfunktionalität. Natürlich ist es normal, die Fähigkeiten der Teammitglieder unterschiedlich sind. Aber im Prinzip muss jeder Entwickler in der Lage sein, jede Aufgabe zu erledigen. Egal, wer am schnellsten eine Aufgabe erledigen kann.

Der größte Unterschied: die Autorität

Ein Scrum-Team besteht aus drei Rollen: einem Projekt Owner, Entwicklern und einem Scrum Master. Hier gibt es keinen Platz für einen Projektleiter. Der Scrum Master ist kein Projektleiter, weil er keine Autorität hat.

Niemand gibt Entwicklern eines Scrum-Teams Anweisungen, wie etwas umzusetzen ist. Alle Entscheidungen werden vom Entwicklungsteam eigenständig und gemeinschaftlich getroffen. ([RW] §3.1)

Ein Scrum-Team muss selbstorganisiert sein. Man kann vielleicht Scrum als demokratisch darstellen. Alle Teammitglieder sind verantwortlich für das Projekt.

Alle Scrum-Ereignisse sind die Ideen dafür, ein selbstorganisiertes Team schaffen zu können. Statt der Autorität sind die Regeln und eine Person nötig, die sich darum kümmert, dass alle Teammitglieder die Regel befolgen. Die Person ist ein Scrum Master.

Stellen Sie sich vor, dass Sie ein Projektleiter ist. Da Sie oft über Scrum gehört haben und Scrum einfach zu verstehen ist, setzen Sie Scrum in das Team ein. Nach mehreren Sprints finden Sie, dass das Team irgendwie nicht effektive ist. Das Team ist gar nicht selbstorganisiert. Das Performance des Teams verbessert sich nicht. Da der Projektleiter (Sie!) sich nie schuldig fühlt, fangen Sie an, zu denken, dass es ein schlechtes Teammitglied gibt. Und ...

Scrum funktioniert in Ihrem Team nicht.

Aber das liegt nicht daran, dass Scrum ihrem Team nicht passend ist, sondern daran, dass der Projektleiter oft neigt, gegen die Regeln der Scrum-Ereignisse zu verstoßen.

Der Projektleiter ist der Grund für das nicht funktionierende Scrum.

Höchstwahrscheinlich kann kein Projektleiter meine Behauptung akzeptieren. Aber haben Sie den Scrum Guide [SS] gelesen? Was steht im Abschnitt "Definition von Scrum"?

Scrum ist:

• Leichtgewicht
• Einfach zu verstehen
• Schwierig zu meistern

Ja, Scrum ist schwierig zu meistern. Deshalb ist ein Scrum Master nötig. Scrum verlangt die wesentliche Änderung ihrer Denkart. Scrum ist komplett anderes als normales Projektmanagement.

Scheint es, dass die normalen Vorgänge für Projektmanagement durch Scrum-Ereignisse ersetzbar sind? Das ist falsch.

Fall 1) Sich auf einen Entwickler nicht verlassen

Angenommen, dass es eine Applikation gibt, die nicht richtig funktioniert. Der Entwickler ist am Grundüberlegen. Deshalb muss er sich auf das Problem konzentrieren.

Aber der Projektleiter, der das Problem erfahren hat, kommt beim Entwickler vorbei, und fängt das Verhör an. Der Projektleiter ließt kein Code, hört den Entwickler gar nicht. Am Ende des Gespräch gibt er dem Entwickler Anweisungen, die das Problem sogar kompliziert machen.

Wenn der Entwickler sich mehrere Stunden auf das Problem konzentrieren könnte, würde das Problem behoben. Aber weil der Projektleiter dem Entwickler unnötige Anweisungen gegeben hat, muss der Entwickler für die unnötigen Anweisungen Zeit verwenden, weil der Projektleiter Autorität hat.

Im Scrum passiert das nicht, weil niemand Autorität hat.

Daher ist es wichtig, dass ein Team als Gemeinschaft agiert und sich aufeinander verlassen kann. ([RW] §3.1.1)

Den folgenden Satz habe ich oben einmal zitiert.

Niemand gibt Entwicklern eines Scrum-Teams Anweisungen, wie etwas umzusetzen ist. ([RW] §3.1)

Der Projektleiter ist verantwortlich für den Plan des Projekts. Er wollte unbedingt den Zustand jeder Aufgaben wissen. Deshalb fängt er das Verhör an und gibt ad hoc Anweisungen, ohne ausführlich das Problem zu überlegen.

Fall 2) Daily Scrum

Daily Scrum ist eines der wichtigen Scrum-Ereignisse, um ein selbstorganisiertes Team zu schaffen. Damit erfährt jeder Entwickler den Fortschritt des Projekts und was andere Entwickler (gerade) machen. Ein Hindernis erwähnt jeder, um den Fortschritt sicher zu machen und die nötige Hilfe zu erhalten.

Aber trotzdem werden sehr oft Daily Scrum als Status-Meeting betrachtet. Deswegen führt der Projektleiter beim Daily eine Diskussion.

E: Gestern habe ich angefangen, diese Eigenschaft zu implementieren. Heute mache ich sie weiter.
L: Warum dauert die Implementation so lang? Was ist so schwierig?
E: Ich muss mehrere Fälle berücksichtigen. Zum Beispiel ...
L: Beim letzten Refinement hat niemand das erwähnt. Wie viele Fälle gibt es denn?
E: ... (etwas Kompliziertes) ...

Wegen der Diskussion kann man das Ziel, den Zustand des Projekt zu erhalten, nicht erreichen, weil andere Teammitglieder nicht zuhören. (Was hat die erste Person gesagt?)

Darüber hinaus verlieren alle Entwickler die Zeit für Entwicklung. Ist eine einmalige Diskussion nicht problematisch? Leider kann solche Diskussion jeden Tag passieren, vor allem, wenn es eine Verspätung oder ein Problem im Projekt gibt.

Angenommen, dass das Team zu siebt ist. Falls jeden Tag weitere 15 Minuten für Daily verwendet werden. Dann 8.75 Stunden pro Woche verliert das Team. (7 Personen x 0.25 Stunden x 5 Tage)

Warum wollten Sie Scrum einsetzen?

In den obigen Fällen verstoßt der Projektleiter gegen die Regeln von Scrum. Aber der Projektleiter findet sich gar nicht schuldig, weil er einfach seine Aufgabe erledigt hat: den Fortschritt des Projekts zu kontrollieren. Deshalb überdenkt der Projektleiter den Vorgang nicht. Infolgedessen wird ein kleines Problem einfach größer. Scrum wird ein toter Buchstabe.

Wenn Sie Scrum-Ereignisse als den Ersatz für den Managementprozess betrachten, brauchen Sie Scrum gar nicht. Ihr Management wird agil nicht, auch wenn Sie nur den Vorgang geändert haben. Am wichtigsten ist, dass Sie Ihre Denkart wesentlich ändern.