Agile Minds

Ein Gedränge kann gut sein

Wir planen schon irgendwie. Also meistens fangen wir mit ein paar Brainstorming-Ideen einfach mal zu implementieren an. Die lästigen Spezifikationen will sowieso keiner schreiben. Und das lässt auch viel mehr Freiraum für spätere Schuldzuweisungen, wenn ein Feature dann nicht so geworden ist, wie gedacht. Also wie die Geschäftsleitung es sich gedacht hat. Und uns mitgeteilt! Nein! Doch! Wann denn? Damals! Per Mail? Ja, auch. Wie noch? Im Meeting! Aha. Dann hätten wir das ja geklärt. Nicht so schlimm. Jetzt gibt es also eine Spezifikation nach der wir vorgehen können. Also ein paar Zeilen halt im „Ticket“. Die paar Zeilen müssen reichen, sonst planen wir uns ja zu Tode. Genau. Und bei der Entwicklung? Wie wär’s mit einem Konzept- und/oder einem Designdokument? Nein? Achso, da es keine Spezifikation gibt, wäre auch ein Konzept natürlich potenziell falsch. Das klingt logisch. Perfekt. Also dann fangen wir halt mal gleich mit dem Implementieren an. Wer macht was? Ach egal. Happy coding. Hauptsache schon mal den neuesten C++ Standard benutzen. Unsere verwendete Compiler-Version kann das zwar noch nicht, aber so zum Spielen kann man ja mal die neueste Version herunterladen und installieren. Das Feature? Erstmal egal. Die Spezifikation wird sich ja sowieso nochmal ändern!

Klingt das bekannt? Wenn ja, willkommen im Club! Letztlich ist es keine böse Absicht und schlicht die Erkenntnis, dass man nicht alles im Voraus planen kann, die solche Stilblüten beim Arbeitsablauf hervorbringen kann, wie eben geschildert. Der Wasserfall als Vorgehensmodell bringt nicht schnell gute Lösungen hervor und während der Entwicklung können sich immer noch viele Änderungswünsche ergeben. Das ist Realität. Abhilfe schaffen können „Agile“ Methoden! Zu diesen gehört „Scrum“. Das ist eine neue Herangehensweise, die typischerweise vor allem bei der Softwareentwicklung benutzt wird. Der Begriff kommt aus dem Rugby Sport und bezeichnet die Anordnung bei der alle Mitglieder einer Mannschaft sich mit den Armen zusammenschließen und so gemeinsam als Einheit versuchen die gegnerische Mannschaft nach Hinten wegzudrücken, das sogenannte „Gedränge“. Der Name drückt bereits aus, dass das Team und der Teamgeist in den Vordergrund gerückt werden. Das Team entscheidet, wie ein Feature realisiert wird. Es erhält die Anforderungen des Produktmanagements durch die Person im Team, die die Rolle „Product Owner“ inne hat. Der Product Owner kennt alle Wünsche und Anforderungen, die das Team umsetzen soll und gibt diese Information an die übrigen Teammitglieder weiter, damit diese entscheiden können, wie sie umgesetzt werden. Dabei kommt es zu keiner „Übergabe“ fertig ausgearbeiteter „Requirements-Dokumente“ im klassischen Stil, sondern das Team berät über die Umsetzung, deckt aufwendige und weniger aufwendige Teile der Anforderungen auf und berät so den Product Owner, welche Feature zunächst angegangen werden sollten, um mit möglichst wenig Aufwand die wichtigsten Wünsche zu erfüllen. Dabei können gemeinsam auch die Anforderungen entsprechend der gemeinsamen Entscheidung geändert werden!

Der „Scrum Master“ im Team sorgt für die Durchführung der Scrum Events wie z.B. dem „daily scrum“, an dem alle Teammitglieder teilnehmen und darstellen, woran sie an diesem Tag arbeiten werden und ob es etwas gibt, das sie blockiert und dadurch aufhalten könnte. So wird sichergestellt, dass Hindernisse erkannt, benannt und aus dem Weg geräumt werden können. Er motiviert das Team und arbeitet immer wieder die Gründe für die Scrum Events etc. heraus. Er wiederholt dabei nicht dogmatisch plump das Scrum Vokabular, sondern arbeitet an konkret erlebten Beispielen im Team auf, warum welche Vorgehensweise besser gewesen wäre..

Weiterhin ist das besondere an Scrum im Vergleich zu anderen Modellen, die iterative, inkrementelle Herangehensweise. Es wird eben nicht zu Beginn eines neuen Produktes jedes Detail bis zuletzt durchdacht, sondern man plant erste einfache Teile, „backlog items“ genannt, und setzt diese dann um. Die Umsetzung erfolgt in kurzen, immer gleichlangen Zeiteinheiten, die je nach Firma typischerweise 2 oder 4 Wochen lang sind, und die „sprint“ genannt werden. Das Team entscheidet, welche der vom Product Owner gestellten Aufgaben, im sprint angegangen werden. Diese sog. „commits“ werden ausschließlich durch das Team bestimmt! Bevor dies am Anfang des sprints im „sprint planing meeting“ überhaupt gemacht werden kann, müssen alle Aspekte der entsprechenden backlog items bekannt sein und das Team muss vollständig verstanden haben, was zu tun ist. Das Team bestimmt also auch, ob ein solches item tatsächlich „ready“ ist. Während eines sprints darf das Team nicht mit neuen Aufgaben behelligt werden! Es arbeitet ungestört und dadurch hoffentlich optimal an den commits. Am Ende eines sprints werden die Ergebnisse z. B. durch Produktdemonstrationen vorgestellt und besprochen und ggf. Änderungen am grob vorgeplanten Projekt eingearbeitet. Ziel ist es, in einem sprint einzelne backlog items komplett inclusive testing umzusetzen und dadurch bereits nach jedem sprint ein fertiges Feature zu haben, das ggf. bereits für einen Endkunden interessant und benutzbar ist („minimal viable product“).

Klingt cool, oder? Kann auch klappen, muss es aber nicht. Z. B. dann nicht, wenn man die Grundidee nicht verstanden hat oder sich nicht an die Rituale hält. Zurück in die alten Gleise fallen, ist für uns Menschen als Gewohnheitstier auch allzu leicht. Jeder der ohne Schuld ist, werfe den ersten Stein! Aber darüber reden, reflektieren und schließlich einsehen, ist unerlässlich. Probleme löst man dadurch, dass man sie als Problem erkennt und benennt. Dann geht es weiter. Außen den Scrum-Aufkleber daraufkleben reicht nicht. Ist die Umstellung eines Vorgehensmodells einfach? Sicher nicht. Ist die Umstellung speziell auf Scrum einfach? Natürlich auch nicht! Zu ungewohnt sind die Abkehr von Law and Order und Hierarchie und die Zuwendung zu völlig eigenverantwortlichem Arbeiten. Scrum bedeutet als Team in vertrauensvollem und respektvollem Umgang gemeinsam Probleme zu lösen. Mit klaren Aufgaben und Zielen, klaren Rollen und Verantwortlichkeiten. Wie heißt es im Fußball so schön: „11 Freunde müsst ihr sein!“; sonst klappt es nicht.

Kategorien:Agile Minds