Seit über einem Jahr beschäftige ich mich ausführlich mit Scrum. In dieser Zeit habe ich Scrum bei meinem Arbeitgeber eingeführt, als auch zwei weiteren – externen – Teams beim Umstieg unter die Arme gegriffen. Die vergangenen Monate waren von sehr vielen neuen Erfahrungen, Problemstellungen aber auch vielen Lösungswegen geprägt. Die auffallendsten Knackpunkte habe ich versucht hier zu diskutieren.
1) Backlog-Pflege ist nicht einfach
Das “richtige Backlog” kann wohl Bücher füllen. Meine Erfahrung ist, dass im Backlog nur konkrete Einträge vorkommen sollten. Ideen, vage Anforderungen und Vorschläge sind separat zu verwalten. Die Einträge müssen beschrieben und priorisiert sein. Besteht noch keine Bewertung (für diejenigen, die Schätzungen durchführen), ist diese schnellstmöglich nachzuholen. Die Quintessenz hierbei ist die Wahrscheinlichkeit der Umsetzung. Ein Backlog ist der Strick an dem sich das Team festhält, es ist der Fahrplan für die kommenden Wochen. Besteht dieser aus vagen Angaben, glaubt niemand daran. Das Backlog wird schlicht nicht ernst genommen. Das sollte es aber.
Idealerweise sind zwei bis drei Sprints gut beschrieben und priorisiert. Es sollte jedoch nicht sein, dass über den aktuellen Sprint hinaus weder Schätzungen, noch eine sinnvolle Reihenfolge besteht. Ein Backlog zu verwalten ist eine ernsthafte Aufgabe, der auch Zeit gewidmet werden muss.
2) Schätzungen sind immer problematisch
Schätzungen sind generell ein schwieriges Thema. Bei Verwendung von Storypoints wird es anfangs schwierig damit zu rechnen. Nach einigen Sprints ergeben sich jedoch historische Echtdaten mit denen gerechnet werden kann. Wer es über Jahrzehnte hinweg gewohnt ist in Stunden bzw. Tagen zu rechnen tut sich schwer, eine andere Bewertung vorzunehmen bzw. zu verwenden. Während sich ein Entwicklungsteam aufgrund der Schätzungsarbeit einigermaßen flott daran gewöhnen kann (muss aber nicht so sein), benötigt das Projektmanagement in der Regel wesentlich länger. Die fehlende Akzeptanz ist hier der Knackpunkt. Warum fehlt sie? Mit Stunden bzw. Tagen kann man rechnen, das ist man gewohnt. Damit kann man die Dauer/den Durchlaufzeitraum leichter abschätzen. Was man kennt, schafft Vertrauen. Schätzungen bleiben aber Schätzungen.
Bei der Verwendung von Storypoints (beispielsweise auf Basis der Komplexität im Vergleich zu einer Referenz) kann Sprint für Sprint ein Umrechnungsfaktor in die Welt der Stunden und Tage errechnet werden. Dadurch bekommen Schätzungen eine weit realistischere Ausprägung und Vorhersagen sind nicht mehr ausschließlich Kaffeesatzlesen.
3) Retrospektive FTW
Die Retrospektive ist wohl einer der größten Vorteile von Scrum (wer kein Scrum macht, sollte sich zumindest dieses Instrument zulegen). Dabei wird der vergangene Sprint rückwirkend betrachtet:
- Was ist im letzten Sprint gut gelaufen?
- Was ist im letzten Sprint schlecht gelaufen?
- Gibt es generell Probleme?
- Wo muss unbedingt etwas verbessert werden?
- Was wäre schön zu haben?
Anfangs ist es gar nicht so einfach die notwendige Offenheit an den Tag zu legen, da hier schon auch mal zwischenmenschliche Probleme auf den Tisch gelangen. Bei ernsthafter Durchführung ist aber bereits nach einigen Sprints eine große Veränderung zu sehen/spüren. Diese Veränderungen werden zwar mit der Zeit kleiner (wie auch die behandelten Probleme), aber es gibt eine spürbare Veränderung hin zum Positiven. Die Retrospektive schwört alle Beteiligten ein, hilft, ein gemeinschaftliches Bild zu entwickeln, sie schweißt zusammen.
4) Daily mit Mehrwert
Das Daily-Meeting ist der richtige Platz um eine tägliche Einsatzplanung zu veranstalten. Fragen wie
- Wie lautet das Tagesziel des Teams?
- Was unternimmt jeder um es zu erreichen?
- Welche Probleme müssen hierfür aus dem Weg geräumt werden?
müssen beantwortet werden. Gerne erfolgt eine Konzentration auf Erledigtes. Gibt es eine gute Kommunikation, eventuell auch einen Review-Prozess ist jeder darüber informiert (abgesehen von der vorherigen Einsatzplanung) und es muss nicht mehr darüber gesprochen werden. Eine Ausnahme sind neue Aufgaben, die sich ergeben haben.
Im Vordergrund muss stehen, was das gesamte Team an diesem Tag erreichen möchte, nicht eine einzelne Person. So wird ein gemeinsames Bild geschaffen und daran kann gearbeitet werden.
Eine Einsatzplanung findet in der Regel recht zeitig statt.
5) Scrum braucht Unterstützung
Scrum benötigt einen gesunden Nährboden. Dies bedeutet, dass alle involvierten Personen den Prozess akzeptieren und leben müssen. Nur so kann ein geregelter Prozessablauf stattfinden und Verbesserungen erreicht werden. Gibt es Strömungen dagegen, entstehen Teilprozesse, die gerne auch einmal gegeneinander ausgerichtet sein können (und wohl auch werden). Sie entstehen aus (meist kurzsichtigen) unterschiedlichen Interessen. Das Ergebnis ist in der Regel eine verschlechterte Performance (verglichen mit dem Ausgangsprozess).
Tritt dieses Phänomen gibt es zwei Möglichkeiten:
- Alle Personen mit unterschiedlichen Interessen müssen zu einer Aussprache an einen Tisch gebracht werden. Eventuell können damit die bestehenden Probleme gelöst werden. Wenn nicht, bleibt vermutlich nur noch Möglichkeit 2.
- Scrum ist eventuell nicht die richtige Methode. Eventuell ist eine Entwicklung hin zu einer anderen Lösung von mehr Unterstützung und Verbesserungen geprägt.
6) Scrum mit Auflagen
“Wir haben erst einmal nur Teilbereiche aus Scrum umgesetzt. Das, was wir eben brauchen.” oder “Wir machen das etwas anders, da es besser zu uns passt.” habe ich schon sehr oft gehört. Wann immer ich dies gehört habe, hat Scrum letztendlich nicht funktioniert. Ich habe gelernt, Scrum in seiner Urform zu starten, streng nach Lehrbuch. Mit der Zeit lernt man die tatsächlichen Probleme und Anforderungen kennen. Vor allem jedoch auch, wie die einzelnen Personen ticken. Erst auf Basis dieser Erfahrungen können Anpassungen vorgenommen werden. Niemals sollte Scrum auf Basis von Annahmen “reguliert” sein. Das ist nur interessant, um am Stammtisch erzählen zu können, man setze ja das hippe Scrum ein.
7) Erzwungenes Scrum
In der Produktentwicklung empfinde ich Scrum als sehr förderlich. Ist ein Team erst einmal eingespielt, werden große Fortschritte gemacht, nicht nur was die Umsetzungsgeschwindigkeit betrifft, sondern auch hinsichtlich Innovationen. Es gibt jedoch auch genügend Situationen, in denen Scrum einfach nicht passt. Besonders gerne ist das reine Projektgeschäft davon betroffen. Der Kunde will nicht, das gewählte Projekt lässt es nicht zu, oder aber es ist das Team schlicht zu klein. Das muss man sich eingestehen und davon ablassen. Es findet sich ein anderer Prozess, der besser geeignet ist und in der Realität Vorteile bringt.
8) Das Team testet
Ich kann mich noch gut an dezidierte Test-Phasen, QA-Wochen oder ähnlichen “Veranstaltungen” erinnern. Es wird Sourcecode geschrieben als gäbe es kein Morgen und dann werden wochenlang Fehler gesucht und gefixt. Ein sehr kontraproduktiver Vorgang, aus mehreren Gründen:
- Über die gesamte Entwicklungs- und Testzeit steht eigentlich keine wirklich vernünftige Version zur Verfügung die ausgeliefert werden könnte.
- Wochenlanges, ausschließliches, Testen verbraucht unheimlich Manpower und somit Kosten.
- Fehler werden teilweise Wochen nach ihrer Entstehung gefixt. Die Erinnerung ist nicht mehr frisch, eine Lösung oft nicht mehr einfach möglich.
In Scrum muss nach einem Sprint ein Potentially Shipable Product (PSP) zur Verfügung stehen. Dies bedeutet, das Team hat die Implementierung zu testen, es ist dafür verantwortlich. Mit dem einher geht die automatisierte Unterstützung (Unit Tests, Integrationstests etc.). Dadurch lässt sich die Stabilität der Software stark erhöhen und die Problemstellen minimieren. Continuous Integration ist hierbei natürlich ein gutes Stichwort. Persönlich setze ich zusätzlich gerne auf Tools á la SonarQube zur Bewertung von technischen Schulden.
Fazit
Scrum ist ein wunderbares Werkzeug um positive Veränderungen zu schaffen. Voraussetzung ist eine großflächige Unterstützung für diese Methode – und sie muss natürlich für die Abteilung/das Unternehmen passen. Wenn nicht, lieber etwas anderes einsetzen. Aus meiner Erfahrung begeht man am wenigsten Fehler, wenn Scrum von Beginn an nach Lehrbuch eingesetzt wird, man sich langsam daran gewöhnt und erst dann Schritt für Schritt Erweiterungen/Änderungen einführt.
Toller Artikel, dessen Inhalt man immer noch so unterschreiben kann! Was mich an einer Scrum-Implementierung gestört hat, die ich in der Vergangenheit erlebt habe, waren die Quartal-Plannings. Als damaliger Produktmanager musste man ein Dreivierteljahr vor Fertigstellung wissen, was eigentlich fertig werden soll. Das ganze Konstrukt war schließlich durch immer mehr Hürden (Freigabe Business Case, Freigabe Software-Architektur, etc.) so komplex, dass es alles andere als agil war. Ansonsten gefällt mir Scrum als Methode sehr gut!
Hallo Norbert,
danke für den Beitrag :-)
Da sind einige motivierende Ideen dabei um Scrum nochmal eine Chance zu geben.
lg Jürgen
Hallo Jürgen,
das freut mich. Verrätst du mir um welche Ideen es sich konkret handelt?
Norbert
Hallo Norbert,
die Punkte 1), 2), 5), 6) und 8) sind lassen mich speziell über Prozesse beim Kunden reflektieren. (Ich werde mal nicht konkreter.)
Ist auf jeden Fall so geschrieben, dass man anfängt über die Prozesse zu reflektieren in die man involviert ist. ;)
lg Jürgen
Wenn ich dich dabei unterstützen kann, schreibe mir einfach ein E-Mail.
lG;
Norbert
Hallo Norbert!
Schöner Artikel!
Ich würde das so unterschreiben.
Beim einführen nach Lehrbuch und erst späterem Ändern habe ich ebenfalls gute Erfahrung gemacht.
Zwar gibt Scrum.org an, dass das dann kein SCRUM mehr ist, aber das ist mir egal solange der Prozess funktioniert und das Ergebnis stimmt.
Grüße,
Florian
Hallo Florian!
Danke für das Lob und die Bestätigung. Auch ich muss dir zustimmen. Wichtig ist, dass es funktioniert und weniger wie es genannt wird.
Norbert