SCRUM Teil 2
« | 11 May 2019 | »Vor ein paar Monaten habe ich mich ja schon einmal über SCRUM (nicht gerade positiv) ausgelassen.
Das geschah natürlich auch aus der Frustration heraus, dass mir die Erinnerung an ein leider gescheitertes Projekt noch frisch in Kopf dampfte.
Inzwischen habe ich aber die Ehre einem anderem SCRUM Team anzugehören …
Kurz zusammengefasst:
Naja, wenn man es besser angeht, ist SCRUM nicht soooo schlecht, aber große Sprünge macht man damit auch nicht.
Natürlich darf man die individuellen Eigenschaften EINES Projektes nicht gleich auf ein gesamtes Arbeitsmodell verallgemeinern um es zu beurteilen.
Und so lautet meine konkrete Einstellung:
- Letztes Pseudo-SCRUM Projekt: Totalversagen auf allen Ebenen
- Aktuelles SCRUM Projekt: Hoffnungsvoll neutral
Doch wenn man wieder in die Vogelperspektive wechselt, bleibt mein Basiseindruck leider bestehen:
SCRUM wird leider grundsätzlich nur vom Management dazu eingesetzt, Zeitabschätzungen für Finanzierungspläne zu machen. Und dabei bleibt leider stets die Qualität der Softwareentwicklung weit zurück.
Und so stellt sich immer wieder das leidige Problem ein, dass nur um schnell einen Sprint abzuschließen “irgendetwas” gemacht wird. Danach wird dieses “Irgendetwas” lange in der Retrospektive diskutiert, und für “ganz toll” befunden, um dann im Folgesprint zahlreich eingehende Defekte und andere Probleme entgegenzunehmen, die natürlich erst im übernächsten Sprint erst angegangen werden können.
Jetzt kann man natürlich positiv argumentieren, dass alle diese Schritte formal dokumentiert werden und sich im Laufe der Zeit eben auch ein entsprechender Fortschritt einstellt.
Doch diese zeitlichen Verzögerungen haben auch den unangenehmen Nebeneffekt, dass Entwickler sich in inzwischen “alte” Themen wieder neu einarbeiten müssen. Und das kostet Zeit.
Die Unflexibilität von starren Sprintabläufen, die nicht vom Team, sondern vom SCRUM Owner vorgegeben werden, führt damit in Summe zu einem größeren Zeitablauf um “das Produkt” marktreif zu bekommen, als wenn die Arbeitsschritte in logisch zusammenhängenden Arbeitspaketen abgearbeitet werden.
Auch demokratische Beschlüsse sind hier nicht immer gerade ein Optimum, denn wenn mit Implementierungsdetails nicht-vertraute Kollegen per Abstimmung über die Priorität von Themen letztendlich entscheiden, geht der Schuss auch mal nach hinten los und man beobachtet dann zwei Wochen später das interessante Gespräch, das mit
Ich hab’s euch schon gleich gesagt, dass … so nicht funktionieren wird.
beginnt. (Und die Aussage kommt dann noch nicht mal von mir …)
Ebenso interessant ist dann, dass wenn ein Entwickler eine User Story oder einen Task einbringt und viel Zeit investiert wird, um:
- die Story zu beschreiben
- die Inhalte zu diskutieren
- die Aufwände abzuschätzen
Dann wird (2 Wochen später) jemand anderes mit der Implementierung beauftragt, der sich darin einarbeitet und 2 Wochen herumdoktort.
Am Sprint-Ende meldet dann der Story Urheber:
Nein, so war das nicht gemeint, du hättest nur hier X Zeilen anfügen sollen.
W.T.F. ? denke ich mir dann … denn eigentlich hätte der Urheber das auch selbst in einer Stunde erledigen können, doch so wurden 3 Wochen vergeudet.
Am meisten schockiert mich aber die Erfahrung (nun schon aus mehreren Firmen),
dass solche “Missverständnisse” niemanden stören und als “normal” angesehen
werden. Schließlich kann man stets lang und breit darüber reden, dass es ja
eine Erkenntnis und einen Fortschritt gibt … selbst wenn es sich nur um
wenige Mikrometer handelt.
Und so wiederholt sich das Spiel jedes Monat.
Da lobe ich mir die guten alten Tage, wo sich in Startup-Manier ein paar Leute zusammensetzten, jeder sich seinen Fachbereich suchte und einfach unbeirrt drauf losschrieb und wie durch ein Wunder (oder eben durch fachliche Kompetenz und gute Aufteilung) am Ende ein gutes Produkt daraus wird.
Doch wenn ich beginne die Sache von der wirtschaftlichen Seite zu sehen, dann stelle ich etwas schadenfroh fest:
Zum Glück werde ich ja nach Arbeitszeit bezahlt.
Doch ich kann auch Positives erkennen, denn mit dem Versuch Pair-Programming in den Prozess mit aufzunehmen ergibt sich nach und nach der positive Seiteneffekt, dass Wissen zwischen den Entwicklern verteilt wird. Extreme Programming lässt grüßen.
Ist dieses Konzept erst mal Teil eines SCRUM Sprints, so “muss” dieses auch umgesetzt werden und darf mit Zeitaufwand bedacht werden. Hier arbeitet dann dieses System endlich auch mal “für” die Entwicklung und seine Mechanismen stellen den Fortschritt in der Zusammenarbeit sicher.
Das ist zwar nicht ganz so “romantisch” wie in den alten Hacker-Tagen, wo sich das von selbst so organisiert hat, aber es ist immerhin ein guter Anfang.
Es hilft aber auch das eine oder andere Gespräch mit Kollegen zu suchen und die Frage zu stellen:
Sag mal, wie war das denn früher, also vor SCRUM.
Und die ebenso interessante Antwort war:
Naja, mal so und mal so, aber in Summe schlimmer.
Der vor mir stets präferierte Ansatz, dass sich Entwickler in ihrer Fachrichtung selbst organisieren und nur dann gemeinsame Meetings abhalten, wenn sie es für nötig erachten, kann natürlich auch dazu führen, dass sich eine Entwicklungsabteilung selbst ausbremst, oder gegenteilige Arbeitspakete ohne das Wissen der anderen umgesetzt werden.
Ich bleibe jedoch bei meiner Meinung, dass es in allen Konstellationen, egal ob mit SCRUM oder ohne immer um die Kommunikation in einem Team geht.
Oder anders gesagt: Wenn zwei mit einander nicht reden wollen/können, hilft auch die beste Projektverwaltung oben drüber nichts, denn ob man jetzt an einander vorbei arbeitet und “nichts” sagt, oder an einander vorbei arbeitet und es beim Standup oder Review schön redet kommt am Ende zum gleichen Ergebnis.
Deshalb lobe ich mir vor allem jene Akteure, Owner und Master, die proaktiv Problemstellungen erkennen und dort schnell einschreiten, dann aber auf der anderen Seite die reale Arbeit nicht durch Formalismen und Meeting-Bürokratie künstlich erschweren.