Ist das noch Scrum oder kann das weg?

Theorie und Praxis sind oft schwer miteinander in Einklang zu bringen! In diesem Beitrag teilen wir mit euch unsere Erfahrungen mit dem Methodenkoffer von Scrum und hinterfragen ihn kritisch. Wir zeigen euch, welche Themen wir wie umgesetzt haben und was wir dann doch ganz anders gemacht haben.

Ausgangssituation

55 Prozent aller Startups setzen auf agile Methoden, wenn es um Projektmanagement geht. Davon entscheidet sich wiederum ein Drittel für Scrum als ihre „weapon of choice“. Zu diesem Ergebnis kommt eine Umfrage von eylean unter deutschen Startups.

Präsentiert von www.eylean.com

Die von Jeff Sutherland und Ken Schwaber entwickelte Methode für die agile Software-
Entwicklung scheint also ein probates Mittel für unterschiedliche Anwendungsfälle zu sein.

Auch wir bei TablonautiX haben uns daher nach der Gründung für Scrum als Rahmen des Software-Entwicklungs-Prozesses entschieden. Wir starteten mit dem Ziel, eine schlanke und einfach zu bedienende Web-Applikation zur Datenanalyse zu schaffen. Wir erhofften uns von Scrum:

  • Gesteigerte Effizienz und Effektivität zur Minimierung der Kosten
  • Hohe Flexibilität bezüglich interner und externer Stakeholder Anforderungen
  • Schnelles Liefern von Ergebnissen bei der Entwicklung einer komplett neuen Software

Doch Scrum fing bei uns an zu leben, sich zu verändern, sich zu entwickeln und sich unserem Projektgeschäft anzupassen. Daher fragen wir uns inzwischen: Ist das überhaupt noch Scrum was wir hier machen oder kann das weg?

4 Gründe, warum Scrum ‚by the book’ bei uns nicht gepasst hat

Planen kostet nur unnötig Geld

Im klassischen Scrum läuft der Start eines Sprints folgendermaßen ab: Zuerst wird ein Meeting einberufen, in dem sich das Team auf User-Stories committed, welche es im nächsten Sprint erledigen will. Das sogenannte Planungsmeeting teilt sich in zwei Teile auf. Im Planning I präsentiert der Product Owner, welche Stories er gerne im nächsten Sprint umgesetzt haben möchte, um ein Produktinkrement ausliefern zu können. Daraufhin schätzt das Team die Stories, wenn dies nicht schon zuvor in einem separaten Meeting erledigt wurde, und teilt dem Product Owner mit, wie viele Stories geschafft werden. Im Planning II werden die Stories im Team (meist ohne Product Owner) detailliert besprochen und in kleiner Aufgabenpakete unterteilt. Das Planungsmeeting kann so insgesamt bis ca. 8 Stunden dauern.

Das Problem hierbei ist, dass die Planung zu viel Zeit beansprucht und dadurch sehr teuer ist. Deshalb haben wir uns entschieden, nicht mehr zwischen Planning I und II zu unterscheiden. Der Product Owner schlägt User Stories vor und erklärt diese kurz. Bei Fragen oder Uneinigkeit werden die Stories diskutiert und gegebenenfalls aus dem Sprint genommen. Das Sprint Planning II findet nicht mehr statt. Jeder Entwickler bricht sich seine User-Stories selbst in kleine Aufgabenpakete herunter.

Keine Schätzungen mehr? Doch, aber wir nutzen T-Shirt Größen als Schätzmethode. Also S für kleine, M für mittlere, L für große und XL für sehr große Stories. Jedes Teammitglied entscheidet sich dabei unabhängig für eine der Größen. Ist man sich einig oder liegt nur eine Größe auseinander, so wird die Schätzung akzeptiert bzw. die Größere verwendet. Bei
Uneinigkeit muss erneut diskutiert und geschätzt werden.

Der Vorteil: Wir sparen Zeit bei der Planung und Abstimmung. Damit haben wir mehr Zeit und Budget für Produkt und Kunde.

Der Nachteil: Wie die einzelnen Stories bearbeitet werden, entscheidet jeder Entwickler selbst. Natürlich kann er andere Kollegen um ihre Meinung bitten. Passiert dies nicht, werden eventuell mögliche Stolpersteine allerdings zu spät entdeckt.

Ein weiterer Nachteil: Unsere Schätzung ist ungenau. Es kann sein, dass zu viele oder zu große Stories im Sprint sind. So wird das Sprintziel nicht erreicht und die Velocity kann nicht exakt gemessen werden. Die Velocity ist wichtig, um Aussagen über die Geschwindigkeit des Teams machen zu können. Meist wollen Kunden wissen, wann Features fertig sind. Mit Hilfe einer Velocity Messung kann diese Aussage relativ einfach getroffen werden. Bei uns geht das nur ungefähr.

Sprints sind nicht heilig

Im klassischen Scurm ist der Sprint „heilig“. D.h. während der Sprint läuft, darf das Team nicht mit neuen oder zusätzlichen Aufgaben belastet werden.

Das Problem dabei ist, dass anfallende wichtige Aufgaben während des Sprints nicht mehr integriert werden können. Trotzdem, auch bei uns ist der Sprint nach wie vor „heilig“ – wohl aber nicht mehr im Sinne des Erfinders. Denn gerade wenn es darum geht, die Produkt-Architektur zu erweitern oder komplett neue Funktionalität in das bestehende Tool zu integrieren, ist selbst ein Zwei-Wochen-Rhythmus zu behäbig. Deshalb können bei uns sogenannte Ad-hoc-Aufgaben auch im laufenden Sprint mit hoher Priorität eingebracht werden. Dies geschieht dann, wenn das Team oder unsere externen Stakeholder ohne das Eingreifen in den Sprint ansonsten blockiert wären.

Der Vorteil: Wir können durch diese gelockerte Sprint-Handhabung deutlich agiler auf die Anforderungen unserer Stakeholder reagieren und beheben „Show-Stopper“ deutlich schneller als zuvor. Das erhöht unsere Entwicklungsgeschwindigkeit in Summe deutlich – auch wenn mal ein Sprint länger dauert als zunächst angenommen oder nicht alle Aufgaben umgesetzt werden konnten.

Der Nachteil: Das Einkippen von Ad-hoc-Aufgaben kann dazu führen, dass nicht alle User Stories / Bugs innerhalb eines Sprints abgearbeitet werden können und somit das eigentliche Sprintziel verfehlt wird. Aber ebenso wie beim Auftreten von äußeren Umständen (Krankheit etc.) lassen wir uns davon nicht mehr verrückt machen und verlängern den Sprint entsprechend. Der von vielen Entwicklern bemängelte hohe Druck beim Scrum-Prozess kann so entschärft werden. Ein Vorteil im Nachteil sozusagen.

Demo ist unnötig

Im klassischen Scrum findet nach Sprintende ein sogenanntes Review-Meeting statt. Dazu sind alle Projektbeteiligten eingeladen. Das Entwicklungsteam präsentiert seine Arbeit und erhält dafür Feedback. Anschließend entlastet der Product Owner das Team von seinem Versprechen des Sprint-Planning I, wenn das Ziel erreicht wurde.

Hier haben wir das Problem, dass dieses Meeting immer zu einem festen Zeitpunkt stattfindet, obwohl vielleicht schon früher weitere Produktinkremente getestet werden könnten. Deshalb haben wir uns gegen einen fixen Demo-Termin mit unseren Kunden nach Beendigung eines Sprints entschieden. Dies hat vor allem zwei Gründe:

  1. Im Sinne von Continuous Integration liefern wir kontinuierlich nach jedem Check-In des Entwicklungs-Teams ein fertiges Produktinkrement aus. Dadurch steht dem Kunden ständig eine neue Version zur Verfügung, die er sofort testen kann.
  2. Bedingt durch Continuous Delivery stehen wir automatisch viel häufiger in Kundenkontakt. Feste Termine brauchen wir daher nicht mehr.

Die Absprache zwischen Product Owner und Kunde hinsichtlich der Funktionalität neuer Features finden in den wöchentlichen Absprachen natürlich aber weiterhin statt.

Der Vorteil: Die Absprachen finden meist mit nur mit einem Teammitglied aus der Entwicklung statt. So kann Zeit gespart werden und die anderen Entwickler können coden, coden, coden 😉

Der Nachteil: Nicht jeder aus dem Enwicklungsteam bekommt das ungefilterte Feedback vom Stakeholder.

Ein dezidierter Scrum Master ist nicht nötig

Im klassischen Scrum wird zwischen den Rollen des Scrum Masters, des Product Owners und des Entwicklungs-Teams unterschieden.

  • Der Scrum Master
    • Prüft die Einhaltung des Prozesses
    • Motiviert das Team
    • Löst Konflikte im und außerhalb des Teams
    • Hält Störungen, die das Sprintziel gefährden, vom Team fern
  • Der Product Owner
    • Pflegt das Backlog
    • Ist verantwortlich für das Produkt
    • Kommuniziert mit den Stakeholdern
  • Das Entwicklungs-Team
    • Implementiert die Produkteigenschaften
    • Ist für die Einhaltung des Sprintziels verantwortlich

Dabei ist problematisch, dass sich alle Störungen beim Scrum Master sammeln und diese von ihm nur sequentiell abgearbeitet werden können, was die Bearbeitungszeit wichtiger Dinge extrem verlangsamt. Deshalb haben wir uns gegen einen dezidierten Scrum Master entschieden. Dieser ist vollständig in unserem Entwicklungsteam aufgegangen. Das Team motiviert sich gegenseitig dazu, die Prozesse einzuhalten. Genauso werden Konflikte innerhalb des Teams gelöst. Sollte eine außenstehende Person zur Konfliktlösung sinnvoll sein, so greift unser Product Owner ein. Dies funktioniert natürlich nur bei einem eingespielten Team, welches genügend Scrum-Erfahrung vorzuweisen hat.

Der Vorteil: Dem Team kann noch mehr Verantwortung übertragen werden. Somit fühlt es sich selbst für den Prozess verantwortlich. Der Scrum Master ist nicht mehr der Flaschenhals, bei dem sich alle Störungen stapeln.

Der Nachteil: Die genannten Störungen, welche nicht mehr durch den Scrum Master abgefangen werden, müssen durch das Team gelöst werden. Es muss sich abstimmen, wann und durch wen Störungen beseitigt werden können. Dies kostet Zeit und gefährdet das Sprintziel.

Fazit – Kann das jetzt also weg?

Scrum wird definitiv in die Geschichte als Methode eingehen, die die Software-Entwicklung für immer verändert hat. Davon sind wir überzeugt. Aber dennoch funktioniert Scrum nach Lehrbuch in bestimmten Konstellationen (so wie bei uns) nicht optimal.

Unser Weg hat für uns gegenüber dem „klassischen“ Scrum einige Vorteile:

  • Wir können durch die verkürzte Planungsphase mehr Budget in die Weiterentwicklung der Software stecken.
  • Wir können durch unseren Sprint mit der Möglichkeit für Adhoc-Tickets Probleme des Kunden schneller lösen.
  • Dank CI/CD können wir dem Kunden mehrmals pro Sprint Neuerungen präsentieren und haben eine kurze Feedback-Schleife.
  • Da das gesamte Team mit einem sehr agilen Mindset ausgestattet ist, lösen wir Probleme gemeinsam und brauchen den Scrum Master nicht als Moderator.

Doch selbst unter widrigen Bedingungen kann Scrum als Ausgangspunkt gewählt werden. Die Kunst ist es, die Prozesse auch wirklich leben zu lassen. Dann wird man sehr schnell feststellen, an welchen Ecken und Enden nachgebessert oder abgeändert werden muss. Letztendlich entscheidend ist, dass jedes Team seinen eigenen Prozess findet, in dem alle
motiviert, schnell, mit viel Spaß und zielgerichtet arbeiten können. Auch deshalb würde ich, sagen unser Prozess kann nicht weg, sondern hat auf jeden Fall für UNS eine wichtige Daseinsberechtigung. Doch wie lange …dass weiß keiner!

Über Florian Hofmann

Agilität ist für Florian stets ein zentrales Thema. Schon während seines Informatikstudiums und seiner Tätigkeit bei Cubeware arbeitete er als Entwickler in einem agilen Team. 2014 mitbegründete er TablonautiX, hier übernimmt er nun die Rolle des Product Owners. Auch privat ist Florian sehr agil und sucht die Herausforderung im Klettern, Segeln und Reisen.

16 Kommentare

  1. Stefan Wolpers

    Stimme Dir insofern zu, dass (Scrum)-Malen nach Zahlen nicht funktioniert. Es gibt keine Checkliste, die zum Erfolg führt. Die erfolgreiche Version von “Agile” muss jede Organisation für sich selbst herausbekommen, was u.a. von deren Größe, Alter und Kultur abhängt.

    Nichtsdestotrotz sind Planung (wenn auch anders als bei Dir beschrieben), Sprint Demo und die relative Unantastbarkeit der Sprints in den Organisation, mit denen ich mich auskenne, wichtige Bestandteile der agilen Produkt-/Engineering-Kultur.

  2. Florian Hofmann Artikelautor

    Vielen Dank für Deinen Kommentar.
    Ich stimme Dir absolut zu, dass die genannten Meetings wichtige agile Bestandteile sind.
    Mir sind auch viele Unternehmen bekannt bei denen das so gehandhabt wird und optimal funktioniert.

  3. FCS

    Schau an, dieses Thema hatten wir in meinem aktuellen Job auch diskutiert, worüber ich mit fast dem gleichen Titel auch etwas geschrieben hatte: http://quereinstieg.blogspot.com/2016/01/ist-das-noch-scrum-oder-kann-das-weg.html

    Mein Punkt wäre zunächst der: Einiges von dem was Ihr weggelassen habt ist gar kein originärer Bestandteil von Scrum. Die Art wie Ihr Planning macht oder den Sprint „entheiligt“ ist ohne weiteres mit dem Scrum Guide vereinbar (http://www.scrumguides.org/scrum-guide.html).

    Anders sieht es mit dem Weglassen von Reviews und Scrum Master aus. Das kann gut gehen wenn ein Team sehr erfahren ist, wie bei Euch anscheinend der Fall. Die Frage die ich mir stellen würde: was passiert wenn es mal nicht so gut läuft und dieses Event/diese Rolle plötzlich doch gebraucht werden? Habt Ihr dann nicht eine Sollbruchstelle eingebaut?

  4. Jan

    Hello!

    Ich denke jedes Team sollte sich ab und zu mal fragen:
    – Wozu machen wir ein Review?
    – Wie wichtig ist uns ein Sprint-Ziel?
    – Was bringt uns das Schätzen?
    usw…

    Jedes agile Team adaptiert nach meiner Erfahrung Scrum und entwickelt eigene Prozess- und auch Wertvorstellungen.

    Ich habe z.B. als PO eine Zeit lang gar keine Stories mehr „abgenommen“, weil das Vertrauen im Team und die Software-Qualität sehr hoch waren. Und das bei CI und einer recht großen Zahl an Usern 😉

    Für mich ist allerdings der Scrum-Master / agile Coach eine extrem wichtige Rolle.
    Sie/Er ist für mich die einzige Person in einem x-funktionalen Team, die dediziert Richtung Kunde und Wertschöpfung agieren kann. Schließlich wirken sich Retros, ständige Verbesserung, Vertrauen, Geschwindigkeit, schlanke Prozesse etc. auf die time-to-market – und somit mittelbar auf Kundennutzen – aus.

    Diese Rolle – nicht unbedingt die Person – abzuschaffen finde ich schwierig.

    LG, Jan

  5. Florian Hofmann Artikelautor

    Vielen Dank auch für Eure Kommentare.
    Ich freu mich, dass es so viele Diskussionspunkte zu diesem Thema gibt!

    @FCS das ist ja lustig, sogar der selbe Titel 🙂
    Unsere Sollbruchstelle besteht darin, dass wir bei Diskussionen, welche nicht ohne Scrum Master gelöst werden können, eine dritte unabhängige Person hinzuziehen.

  6. Hendrik Lennarz

    Sehr interessant. Viele deiner Beschreibungen treffen auch bei uns exakt so zu. Unsere besondere Challenge ist, wie man Scrum über mehrere Scrum Teams hinweg ohne zu viel Overhead implementieren kann.

    Btw. ich stimme den vorherigen Kommentatoren zu, die Scrum Master wegzulassen, halte ich ebenfalls für extrem gefährlich. Da musst du schon einen sehr empathischen Product Owner und ein sehr umgängliches Scrum Team haben, damit das funktionieren kann.

  7. Björn Schotte

    Hi Florian,

    das klingt ja fast so, als ob Ihr schon mehr in Richtung Kanban unterwegs seid 😉 Glückwunsch, wenn das bei Euch so gut klappt!

    Was mich wundert, sind die bis zu 8h für das Planning Ritual. Meist deutet das auf ein fehlendes „shared mental model“ (also gemeinsames Verständnis) hin und evtl ein Team, das noch nicht gut zusammenarbeitet. Möglicherweise hat sich dies über die Zeit verbessert.

    In freier Wildbahn habe ich auch schon Scrum Implementationen gesehen (auch bei uns), da wird das Review durch den PO schon innerhalb des Sprints erledigt. Confidence Smileys signalisieren dem PO darüber hinaus frühzeitig, ob ein Fertigstellen einer Story gegen Sprint Ende erreicht wird oder eher nicht.

    Am Ende ist es vermutlich fast egal, welche Art von Scrum Implementation Ihr nutzt. Die Schlüsselerkenntnis lieferst Du im Beitrag gleich mit: durch eine Continuous Deployment Infrastruktur seid Ihr in der Lage, regelmäßig zu liefern.

    Dadurch schafft Ihr frühzeitig und kontinuierlich Lerngelegenheiten für die weitere Produktentwicklung. Und das ist IMHO das eigentliche Ziel, das es braucht. Ob das mit einem Scrum-Verschnitt oder einem evolutionären IT-Kanban-Modell erreicht wird, ist dabei fast egal.

    Du hast geschrieben, dass die Rolle des Scrum Masters im Team aufgegangen ist. Chapeau! Das deutet auf ein sehr reifes Team hin? Wie geht Ihr konkret mit Konflikten um? Gibt es einen Supervisor / externen Coach, der das Team begleitet und ggf. bei Group Thinking gezielt irritiert / interveniert?

  8. Florian Hofmann Artikelautor

    Hi Björn,
    wie Du schon vermutet hast, handelt es sich bei uns um ein sehr erfahrenes Team in Sachen Agilität.
    Bei Konflikten, welche nicht Team-Intern gelöst werden können, holen wir uns einen dritten unabhängigen Kollegen dazu. Dieser arbeitet sich in die Thematik ein und versucht den Konflikt zu lösen.
    Meisten handelt es sich bei uns jedoch um externe Einflüsse, also „impediments“ von außen. Diese werden im Team gelöst und erfordern keine dritte Person.

  9. Daniel

    „Der Nachteil: Wie die einzelnen Stories bearbeitet werden, entscheidet jeder Entwickler selbst.“

    … ist das eigentlich einer Nachteil? …

  10. Florian Hofmann Artikelautor

    Hallo Daniel,
    vielen Dank für Deine sehr gute Frage.
    Es kann durchaus ein Nachteil werden. Normalerweise werden im Planning Meeting II die User Stories in einzelne Tasks aufgeteilt. Dabei diskutiert das gesamte Team über die Story und entscheidet was zu tun ist. Durch das miteinander reden werden Stolpersteine frühzeitig erkannt und können sofort im Team gelöst werden.
    Passiert dies nicht, so ist der Entwickler auf sich selbst gestellt und hat lediglich sein eigenes Know How zur Verfügung.

  11. Matthias Frey

    „You can do what you want, but don’t name it Scrum“ sagte mal einer 😉

    Zu „Dabei ist problematisch, dass sich alle Störungen beim Scrum Master sammeln und diese von ihm nur sequentiell abgearbeitet werden können, …“
    Ei warum denn? Wie kommst du auf so etwas? Erstens können Störungen von jedermann behoben werden, dazu benötit man keinen SM. Und zweites muss er die Störungen nicht der Reihe nach lösen. Scrummacht darüber keine Aussage.

  12. Simon

    Meiner Meinung nach hat ein z.B. 14-tägiger Sprint-Rhythmus mehrere Vorteile:

    – Das Team kann konzentriert an einem Sprint-Ziel arbeiten (Produktivität des Teams steigt, sonst besteht die Gefahr, dass man so vor sich hin arbeitet).

    – Steakholder kennen dne Rhythmus nach einer gewissen Zeit und können damit planen (Features mit < 14 Tage Vorlaufzeit ist wurden meiner Meinung nach nicht vernünftig getestet; Bugs sind ausgenommen).

    – Schätzungen in einem wiederkehrenden Rhythmus werden genauer, wenn sich eine Velocity nach einer gewissen Zeit einpendelt.

    Daher würde ich nicht auf Sprints verzichten.

    Ich stimme zu, dass ein Team auch ohne Scrum Master gut funktionieren kann (wenn der PO einige planerische Aufgaben übernimmt).

  13. Florian Hofmann Artikelautor

    Hi Matthias, hallo Simon,
    vielen Dank für Eure Kommentare.
    Matthias, ich stimme Dir absolut zu. Die Aussage dabei sollte lediglich sein, dass mehrere Personen parallel Störungen bearbeiten können und einer alleine nur sequentiell. Bei uns haben sich die Aufgaben immer beim Scrum Master gestapelt, so dass dieser der Flaschenhals war. Aber natürlich macht Scrum an sich darüber keine Aussage.

  14. Timo Eger

    Hi Florian,
    bei uns ist das ähnlich. Wir nehmen uns das von Scrum raus, was auf unseren Workflow passt und bei uns gut funktioniert. Grundsätzlich halten wir uns an Scrum und den 14-tägigen Sprint, auch wegen der Vorteile, die Simon aufgezählt hat. Aber auch unser Ziel ist es zum Beispiel ohne Scrum-Master aus zu kommen (was hoffentlich bald funktioniert) und wir nutzen extra Schätz-Meetings für die Kalkulation und dann nur eine kurze Sprint-Planung zur Vorstellung der Tickets. Das dauert aber in Summe nie 8h! So wie ich das verstehe ist Scrum ja auch ein Baukasten von Regeln, die als Vorschlag dienen. Es ist alles kein „Muss“.
    Mich würde interessieren, wenn Ihr mit T-Shirt Größen plant, wie leitet Ihr dann die Kosten für den Kunden daraus ab? Ist das nicht sehr vage?

  15. Matthias Frey

    Nein, Scrum ist kein Baukasten von Regeln. Was Scrum ist steht im Scrum-Guide. Wenn man ein Element daraus weglässt ist es kein Scrum mehr.
    Natürlich „muss“ man nicht Scrum benutzen und man kann mit dem Elementen von Scrum sich was eigenes basteln. Das machen wir auch. Das dann Scrum zu nennen finde ich Heuchelei.

    Das Ziel ohne Scrum-Master aus zu kommen finde ich wichtig in dem Sinne, als dass das Team selbständig und selbstverantwortlich arbeiten soll. Auf einen Scrummaster würde ich jedoch nie verzichten – im Gegenteil. Gerade wenn ein Tem meint, keinen zu benötigen ist er nötiger denn je. 😉

    Zur Ausgangsfrage „Ist das noch Scrum oder kann das weg?“: Es ist kein Scrum mehr. Weg muss es deswegen noch lange nicht. 😉

  16. Florian Hofmann Artikelautor

    Hi Timo,
    vielen Dank auch für Deinen Kommentar! Ich freu mich von Euren Erfahrungen zu hören.
    Aktuell ist es so, dass wir ein fest definiertes Budget haben. Der Kunde weiß nur vage was er dafür bekommen wird.
    Jedoch werden sich einzelne Teile des Produktes im Laufe des Projektes sowieso verändern. Somit ist es auch nicht schlimm, dass der Kunde nur vage weiß was er bekommt.
    Ich denke was für den Kunden letztendlich zählt ist, dass er mit seinem geplanten Budget sein Problem lösen kann.
    Zu diesem Thema kann ich auch folgenden Artikel empfehlen: https://hbr.org/2014/12/your-agile-project-needs-a-budget-not-an-estimate

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.