SCRUM is agile
Das bekannteste Vorgehensmodell in der aktuellen Softwareentwicklung. Bei der Einführung von SCRUM wird dabei häufig erwähnt, dass man SCRUM nur dann richtig macht, wenn man auch SCRUM nach Lehrbuch durchführt. Und in diesem Detail liegt der Fehler: Das Manifest für agile Softwareentwicklung besagt “Individuen und Interaktionen mehr als Prozesse und Werkzeuge”. Wenn es also die höchste Divise ist, SCRUM umzusetzen, dann widerspricht dies dem Manifest.
Eine weitere Gefahr, wenn SCRUM 1:1 umgesetzt wird, ist es auch in einen sogenannten Cargo-Kult zu verfallen. Dies ist dann auch nicht agil und wird sehr wahrscheinlich keine Auswirkung auf eine verbesserte Arbeit haben.
Trotzdem ist SCRUM super viel Wert. Jede Zeremonie hat ihre Daseinsberechtigung und sollte in jedem gut laufenden Team evaluiert werden.
Productowner und SCRUM Master sind kein Teil des Teams
Laut SCRUM-Guide gibt es das Entwicklungsteam und diese beiden extra Rollen. Häufig wird nun begründet, dass diese beiden Rollen extern sein müssen, damit sie eine Neutralität wahren können. Dabei kann es nie eine komplette Neutralität geben. Ab dem Zeitpunkt, an dem zwei oder mehr Personen eine Kommunikation haben, wird eine Beziehung aufgebaut. Diese wird niemals neutral sein.
Der SCRUM-Guide sieht keine expliziten Tester, Architekten etc. vor, mit der Begründung das jedes Teammitglied das wichtigste erledigen soll, ungeachtet vom Skilllevel. Natürlich hat jedes Teammitglied Spezialitäten und besondere Fähigkeiten. Aber die Fähigkeit, überall helfen zu können, würde ich als den wichtigsten Grund sehen, warum T-Shaped-Mitarbeiter aktuell so gefragt und gehyped sind.
Warum sollte diese Arbeitsweise bei dem Productowner und dem SCRUM Master halt machen?
Das Daily muss maximal 15 Minuten dauern
Eine häufige Diskussion in ineffizienten agilen Teams ist die Länge des Dailies. Als Folge dessen werden viele unterschiedliche Ideen versucht, um dies “effizienter” zu gestalten. Dabei liegt das Problem ganz woanders. Es liegt an der fehlenden Teamarbeit. Wenn mich die Probleme und Aufgaben meines Kollegen interessieren und ich der Thematik vertraut bin, kann ich viel besser unterstützen und mich interessieren auch Details seines täglichen Doings. So kann ich sagen, dass ich schon regelmäßige Dailies von 45 Minuten genossen habe, aber in anderen Kontexten ein Daily nach 5 Minuten zur Hölle wurde. Im zweiteren Fall ist das Ziel nicht, dies weiter zu verkürzen und damit noch inhaltsloser zu machen, stattdessen muss das „Team“ mehr als ein Team agieren. Die Gründe hierfür können vielfältig sein.
Agile Softwareentwicklung hat zu viele Meetings
Dieser Punkt lehnt sich ganz nah ans Daily an. Auch hier kann ein fehlendes Teamgefüge ein Problem sein. Gleichzeitig sollte in einer agilen Welt alles erlaubt sein, damit das Team erfolgreich arbeiten kann.
Eine Retrospektive sollte das einzige verpflichtende Meeting sein. Diese schafft es, einmal auf Pause zu drücken, um über Verbesserungen nachzudenken. Stichwort ständiges Lernen.
Häufig werden aber auch schnelle Absprachen oder eine Zusammenarbeit mit Kollegen als Meetings gesehen. Softwareentwicklung ist Teamsport! Es wird wenig erreicht wenn viele Individuen einzeln in eine Richtung gehen, daher sollten viele kleine Abstimmungen nicht als verlorene Meetingzeit angesehen werden, sondern als deine Arbeit! So wird es zwar viele Meetings geben, aber diese sind hoffentlich effizient und agil. Sofern diese als verlorene Zeit angesehen werden, schafft dieses eine Meeting ab oder guckt, wieso das Ziel dieses Meetings nicht erreicht wird.
Agil beinhaltet keine Zeitplanung
Die einzige Zeitplanung in der agilen Softwareentwicklung ist das Commitment für den nächsten Sprint. Dies zu glauben ist natürlich schön, aber in der Praxis selten umsetzbar. Gleichzeitig ist es mit wechselnden Prioritäten und mit schwer abschätzbaren Aufgaben sehr schwer eine finale Deadline festzusetzen. Eine fixe Deadline und erst recht ein fixes Preisschild ist selten machbar. Trotzdem sollten wir uns hier noch einmal die agilen Prinzipien 2 bis 4 ansehen
Funktionierende Software mehr als umfassende Dokumentation
Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung
Reagieren auf Veränderung mehr als das Befolgen eines Plans
Wenn wir funktionierende Software erreichen wollen, bedeutet das aus meiner Sicht jeder Zeit Businessvalue zu schaffen. Ein Ziel sollte es sein, am Ende eines, z.B. Sprints, Probleme eines Kunden gelöst zu haben. Sofern dieser Wert den Kunden auch bereitgestellt wird, hat dieser ein gutes Gefühl, wie lange gleich große Aufgaben vermutlich dauern können. Mit dieser Semantik kann man auch genauso gut oder schlecht einen Projektplan erstellen. Durch die gute Zusammenarbeit mit dem Kunden, kann dieser jederzeit sagen, dass seine Software fertig (oder good enough) ist. Sofern ein Budget ausgelaufen ist, hat dieser Kunde nicht nichts, sondern eine Software, die bis dahin alle seine Probleme löst. Mit diesen von uns bevorzugten Vorgehen ist die Reaktion auf Veränderung vorprogrammiert und löst sich von ganz alleine.
