Praktische Erfahrung im Umgang mit agilen Frameworks

Scrum 2.0 bei GFE Media

Mitte 2018 begann GFE Media, seine Vorgehensweise in der Software-Entwicklung auf das Projektmanagement-Framework „Scrum“ umzustellen: Zeit also, jetzt einmal die Erfahrungen und den aktuellen Stand der Transition zu betrachten. Hier folgt ein erster Zwischenbericht.

»… und aus dem Chaos sprach eine Stimme: ›Lächle und sei froh, es könnte schlimmer kommen!‹ und ich lächelte und war froh – und es kam schlimmer.«

Der nachfolgende Beitrag dient einer retrospektivischen Betrachtung von anderthalb Jahren praktischer Arbeit mit den Frameworks Scrum und Kanban¹ bei GFE Media GmbH in Göppingen, in Hamburg und in vielen Hangouts „draußen“ im Internet.

I. Nur zur Erinnerung: Scrum-Grundlagen und Werte

Beginnen wir nochmals mit einer kurzen Darstellung der Versuchsanordnung, unter der wir bei GFE Media angetreten sind, und damit der Frage nach den wichtigsten Werten agiler Arbeitsweise, besonders mit Scrum. Zu diesen Scrum-Values zählen natürlich an erster Stelle die bekannten Big Five: „Courage“, „Respect“, „Focus“, „Commitment“ und „Openness“.²

Unter „Courage“ verstehen auch wir vor allem den Mut, die richtigen Entscheidungen zu treffen und zu verantworten, um gemeinsam auch schwierigste Aufgaben zu meistern. Den Mut aufzubringen, Informationen und Wissen konsequent zu teilen und vor allem auch eine eingeschlagene Richtung wieder zu ändern, wenn sich dies als notwendig erweisen sollte. Wichtiger Aspekt von Courage ist natürlich auch die Möglichkeit, Meinungen und Ansichten frei zu vertreten, und die Chance, auch Fehler machen zu können.

Unter „Focus“ verstehen wir, wie alle anderen „Scrummer“ auch, die absolute Konzentration auf die vom Team festgelegten Ziele, die Möglichkeit also, möglichst ungestört und nicht von außen beeinflusst Projekte umzusetzen. Dies genau im Rahmen der selbstgesetzten Arbeitseinheiten in entsprechenden Inkrementen und Sprints.

„Commitment“ steht im agilen Umfeld für die Selbstverpflichtung jedes Mitwirkenden, die selbst gesteckten Ziele auch im gesetzten Rahmen zu erledigen und zu Ende zu bringen, eisern! Es geht also darum, ein Problem zu seiner eigenen Sache zu machen, nicht zuletzt auch für die fristgerechte „Completion“ einzelner Arbeitseinheiten.

„Openness“ steht für das Prinzip der radikalen Offenheit, zu der sich Teams und Stakeholder verpflichten. Dies gilt im Umgang mit der Transparenz aller Projekt-relevanten Informationen, potentiellen Schwächen bei Mitarbeitern und Planungen, aktuellen Fehlern und sonstigen Herausforderungen, die normalerweise lieber unter dem Tisch gehalten werden.

Und last but not least Nummer 5 und damit „Respect“ – dies steht für die grundlegende Achtung vor dem Anderen im Team, der Grundannahme also, dass sich alle Team-Mitglieder maximal einbringen, dass sich keiner verweigert und jeder sein Bestes gibt und geben wird. Es geht bei Respect um die Akzeptanz von Verschiedenartigkeit, bei der Stärken genutzt und Schwächen respektiert, beziehungsweise unterstützt werden. Und zwar von allen Mitwirkenden in allen Scrum-Prozessen. „Errichte Projekte rund um motivierte Individuen. Gib ihnen das Umfeld und die Unterstützung, die sie benötigen und vertraue darauf, dass sie die Aufgabe erledigen.“³

Zusammenfassend gilt damit das Prinzip der Selbstorganisation als grundlegendes Management-Prinzip, bei dem Scrum-Teams ihre Arbeit selbst und autonom organisieren können. Alle Teams entscheiden weitgehend selbst, wie sie ihre Arbeit ausführen wollen. Es gilt: möglichst keine Fremdbestimmung von außen und zwar von niemandem. Abgelehnt wird autoritäre Führung ebenso wie hierarchische Strukturen, klassisches „Top-down“-Management sowie alle herkömmlichen Wasserfallmethoden.

Abgelehnt wird die Arbeit mit Riesenprojekten über Monate und Jahre, die in langen Pflichtenheften, Excel-Sheets, MS-Project-Files und Gantt-Visualisierungen geplant und selten erfolgreich zu Ende gebracht werden! Dies vor allem deshalb – wie nicht zuletzt im vorigen Beitrag zum Thema nachzulesen –, weil es in der Realität stets anders kommt, weil sich die Anforderungen ständig ändern und vor allem weil die Funktionsweise komplexer Softwaremodule für Anwender oft schlecht antizipiert und meist erst nach Fertigstellung beurteilt werden kann.

Agil, auch bei unseren Bienen

Und genau deshalb wird unter Scrum eben anders gearbeitet: nämlich inkrementell, in überschaubaren kurzen Einheiten, mit eindeutigem Anfang und Ende, statt mit endlosen Pflichtenheften und noch längeren „Verpflichtungsbüchern“, die niemals fertig werden. Gearbeitet wird mit Zwischenständen, die tatsächlich funktionieren, im Sinne von ablauffähiger Software am Ende eines jeden Arbeitsschrittes oder Sprints. Und vor allem wird gearbeitet mit neuen Rollen und Spielregeln, wie der Rolle des Scrum Masters, des Product Owners und mit neuen Tools wie Jira und Tempo. Gearbeitet wird vor allem auf Grundlage sauber aufbereiteter sogenannter Backlogs, die mit dem jeweiligen Kunden abgestimmt, für jedermann verständlich formuliert werden und Grundlage für die selbstständige Entwicklung durch die Scrum-Teams darstellen.

II. Scrum im Alltagseinsatz

Mit all diesen – zugegebenermaßen nicht ganz unambitionierten – Vorstellungen sind wir also im Frühsommer 2018 bei GFE losmarschiert und sind bei der Umsetzung neben viel Freude an der neuen Arbeitsweise, auch auf nicht ganz unerhebliche Herausforderungen gestoßen. Vorauszuschicken ist, dass die Einführung der neuen Scrum-Arbeitsmethoden bei GFE nicht ganz Lehrbuch-konform erfolgte.

Hier wird nicht von allen an einem oder zwei Projekten gearbeitet, die in eindeutigen und klar abgegrenzten Sprints abgeleistet werden können. Hier wird gleichzeitig an zig Projekten gearbeitet und zwar mit immer wieder den gleichen Leuten in unterschiedlichen Teams und Sprints. Bei GFE wird teils agil, teils aber eben immer noch wie früher gearbeitet! Wir fahren auch heute immer noch zweigleisig, dies, weil Kunden manchmal nicht wollen oder weil bestimmte Tagesarbeiten, Support-Leistungen, Bugfixes etc. etc. (scheinbar) nicht nach den neuen Verfahrensabläufen abgebildet werden können.

Aber auch da, wo relativ streng nach Scrum gearbeitet wurde, gibt es noch jede Menge Hürden und Herausforderungen, die wir bei GFE in Zukunft noch werden nehmen müssen: An allerwichtigster Stelle steht hier das konsequente Einhalten der selbstgesetzten Regeln. Regeln wie die Arbeit in klar abgegrenzten Sprints, deren präzise Vorbereitung in entsprechenden Plannings, die konsequente Projekt-Kommunikation in regelmäßigen Daily Scrum Meetings, Retrospectives und was es sonst noch alles gibt!

Wichtig ist, die agilen Values ganz praktisch zu operationalisieren und dafür zu sorgen, dass z. B. Commitments über einen Sprintverlauf immer wieder neu eingegangen werden! Immer wieder gilt es, z. B. zu checken, ob sich ein Vorhaben noch im Plan befindet oder ob Stress durch Verzug droht. Wie kann ein eingegangenes Commitment im Falle einer Verzögerung doch noch sichergestellt werden? „Dailys“ – oder im Falle von GFE eben „Boost“-Meetings – haben hier vor allem auch den Zweck, das am Beginn eines jeden Sprints eingegangene Commitment täglich zu erneuern und sich gegenseitig in der gemeinsamen Absicht immer wieder zu bestätigen.⁴

Zu diesem konsequenten Einhalten selbstgewählter Spielregeln gehört in besonderer Weise auch die Notwendigkeit, Schätzungen über geplante Aufwände in nachfolgenden Sprints möglichst immer in Teams zu ermitteln, und nicht einen Einzelnen für das Team kalkulieren zu lassen, und schon gleich gar nicht den Einen schätzen und den Anderen entwickeln zu lassen. Dies vorzugsweise in der Form, dass Projekt-Aufwand-Schätzungen erst vom Team gemeinsam ermittelt (Planning-Poker etc.) und erst dann die Aufgaben an einzelne Team-Mitglieder verteilt werden.

Ganz wichtig natürlich, Time-Estimations immer inklusive aller notwendigen Arbeiten wie Planungen, Besprechungen, Deployments, Qualitätssicherung, Bugfixing, Dokumentation etc. etc. zu erstellen! OK, war früher zu Wasserfallzeiten genauso wichtig, spielt aber auch bei Scrum eine große Rolle! Was an Aufwänden zu Beginn vergessen wurde, führt am Ende stets zu Stress, denn wer bezahlt die nicht angemeldeten und nicht freigegebenen Aufwände?

Gelungener Sprint bei GFE

Nur unter der Voraussetzung einer maximalen Klarheit über alle Abläufe und Prozesse und nur auf Grundlage eines konsequenten Arbeitens nach den Scrum-Regeln kann ein Projekt erfolgreich abgeschlossen werden. Dies setzt natürlich die persönliche Kenntnis und Internalisierung sämtlicher Scrum-Regeln bei jedem Einzelnen voraus, was sich in entsprechenden Zertifizierungen, zumindest aber in umfangreicher Kenntnis der einzelnen Spielregeln zum Ausdruck bringt. Dies setzt natürlich auch die organisierte und permanente Selbstreflexion der Teams voraus: „In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann und passt sein Verhalten entsprechend an.“⁵

III. Scrum Communication

Aber nicht nur um persönliche Kompetenz geht es hier: Zu den täglichen Herausforderungen im praktischen Umsetzen des Scrum-Frameworks gehören natürlich auch die maximale und konsequente Abstimmung aller Mitarbeiter untereinander und die konsequente und absolute Kommunikation zwischen allen Beteiligten. Es gilt, hohe Transparenz hinsichtlich aller Prozesse für alle Betroffenen zu gewährleisten. Dies – nicht nur aber vor allem auch – hinsichtlich der aktuellen und für verschiedene Kunden parallel verlaufenden Sprints. „Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteams zu übermitteln, ist im Gespräch von Angesicht zu Angesicht.“⁶

Wichtig im Kanon des zur erfolgreichen Abwicklung von Scrum-Projekten unbedingt Notwendigen ist die vollständige und Tages-aktuelle Erfassung geleisteter Arbeiten durch alle Mitarbeiter im dafür vorgesehenen Tempo-Tool und zwar genau hier. Wie sich bald herausstellen sollte, ist die erfolgreiche Umsetzung von Scrum-Projekten nur unter der Voraussetzung eines präzisen Trackings der geleisteten Arbeiten denkbar. Nur unter dieser Voraussetzung können Projekte wirtschaftlich erfolgreich abgerechnet und schnell auf Risiken und Probleme innerhalb von Projekten reagiert werden. War natürlich auch früher schon ganz gut, ab und zu mal abzurechnen, die agile Arbeitsweise enthebt uns aber leider in keinerlei Hinsicht dieser Verpflichtung!

IV. Ressourcen-Management unter Scrum

Wichtig im praktischen Scrum-Alltag ist auch, möglichst keine funktionalen Doppelbesetzungen zuzulassen, egal wie eng der Schuh auch drücken mag! So bei GFE durchaus passiert, wenn z. B. aus Ressourcen-Mangel der Scrum-Master durchaus auch in die Rolle eines PO schlüpfen musste, wenn immer wieder Account-Management und Product-Ownership vermengt wurde.

Die derzeitige Praxis bei GFE für die Auswahl der für ein Projekt zuständigen PO liegt bei der wöchentlichen PO-Runde, also einer Art „Weekly“ aller bei GFE tätigen Product Owner. Das Account-Management kann diesbezügliche Wünsche und Vorschläge unterbreiten. Kommen die PO zu keiner einvernehmlichen Entscheidung, trifft diese der Scrum Master. Jeder Mitarbeiter sollte in maximal zwei parallelen Scrum-Projekten eingeplant werden, wobei immer mindestens zwei Developer für jedes Scrum-Projekt vorgesehen werden sollten.

Und dies führt zum Thema Ressourcen-Management, welches einen ganz wichtigen Stellenwert innerhalb erfolgreicher Transition einnimmt. Es reicht im agilen Unternehmens-Alltag ganz offensichtlich nicht aus, in die vorgesehenen Planungswerkzeuge wie Jira und Kanban entsprechende Personalanforderungen einfach einzutragen. Nein, es gilt, auch bei Scrum für eine strategische Ressourcenplanung zu sorgen, die Projekt-übergreifend und für das ganze Unternehmen funktioniert.

Ein solches Ressourcenmanagement befasst sich beispielsweise mit Fragen, wer am besten wo eingesetzt werden kann, wer, wie parallel in welchen Projekten arbeiten kann und wer voraussichtlich mit welchen Aufgaben wie lange ausgelastet sein wird. Ein solches professionelles Ressourcenmanagement ist die klare Voraussetzung, um ein rechtzeitiges Gegensteuern auch bei Auslastungsproblemen zu gewährleisten, ebenso wie potentielle Unterbesetzungen bei Projekten zu verhindern.

V. Scrum und Finanzplanung

Mindestens ebenso wichtig wie die allgemeine Ressourcenplanung ist die Gewährleistung finanzieller Planbarkeit des Unternehmens und zwar über 14-tägige Sprints hinaus und hinunter bis zur täglichen Liquiditätsplanung. Hier muss Planungssicherheit Eingang in den agilen Alltag finden und hier darf die agile Arbeitsweise nicht als Ausrede für fehlende Vorausplanung, ständiges Abrechnungschaos und Projekt-Verzögerungen dienen.

Transition von Wasserfall zu Scrum darf nicht als Grund für alle möglichen Unzulänglichkeiten herangezogen werden, die ganz andere Ursachen haben. Und genau hier ergaben sich große Belastungsproben für die kaufmännisch Verantwortlichen im Unternehmen, denen vor lauter Agilität oft der notwendige Überblick zur Steuerung der finanziellen Prozesse verloren zu gehen drohte.

Und wenn man diese Anforderung ernst nimmt, muss dringend und gerade auch im agilen Umfeld auf eine zügige Abrechnung aller geleisteten Arbeiten im Projekt-Alltag geachtet werden. Dies ist ebenso wichtig wie die wirtschaftliche Transparenz aller Projekte und ein sauberes Controlling auf der Grundlage klarer und nachvollziehbarer Kalkulationen für alle Projekte, Sprints und Inkremente.

Kurz, es geht um nichts weniger als die konsequente Sicherstellung nachhaltiger Wirtschaftlichkeit im Betrieb auch und gerade unter einer agilen Ausprägung der Projektabläufe. Damit geht es besonders auch um die Konkretisierung der agilen Arbeitsformen zur Herstellung sprintübergreifender Prognosen, vor allem auch darüber, ob die Einnahmen immer auch die Ausgaben werden decken können. Deshalb gilt es eben auch, die wirtschaftliche Planbarkeit des Unternehmens systemisch zu ermöglichen.

Was wir nicht wollen, ist die Wiedereinführung traditioneller Excel-Sheets oder erneute Anläufe mit Wasserfall-Gantts z.B. aus der Microsoft Project Hexen-Küche. Was wir aber wahrscheinlich doch brauchen, sind geeignete Vorausplanungsmethoden, die mit der agilen Arbeitsweise von Scrum harmonieren und eine gewisse unternehmerische Planungskonsistenz mit der agilen Arbeitsweise verbinden, dies vorzugsweise mit funktionierenden Schnittstellen zu Jira und Tempo!

VI. Transition to Scrum: Shift Happened

All dies zeigt, was eigentlich sowieso offensichtlich ist: Die konsequente Einführung agiler Verfahrensformen und Abläufe kann nur dann funktionieren, wenn diese in den praktischen Arbeitsalltag eines Unternehmens durch eine Vielzahl von unternehmens-spezifischen Spielregeln und Verfahrensweisen, Ablauf-Organisationen, kurz gesagt einem eigenen Rahmen Unternehmens-spezifischer „Rules“ eingebunden sind. Hierzu gehören z. B. auch folgende derzeit noch in der Abstimmung befindliche Regeln:

„Das Entwickler-Team und der PO entscheiden über die anzuwendende Technologie bei der Umsetzung von Projekten, wobei das jeweilige Sprint-Team vom zuständigen PO vorgeschlagen wird. Der Scrum-Master muss bestätigen, im Konfliktfall auch in Abstimmung mit der Geschäftsleitung. Das Entwickler-Team kann während der Projektdauer nur in Abstimmung mit dem Scrum-Master verändert werden. Ein PO kann während der Projektdauer nur in Abstimmung mit dem Scrum-Master und dem entsprechendem Account-Manager ersetzt werden etc. etc.“⁷

Was nun die Entwicklung und Umsetzung solcher und vieler anderer Agil-Regeln betrifft, können diese nur durch alle Mitarbeiter des Unternehmens gemeinsam erfolgen: Durch jeden für sich und durch alle miteinander! Denn – und damit sind wir wieder bei unserem eigenen Leitbild und der eigenen GFE-Unternehmenskultur angekommen – alle sind Teil des Problems, aber eben auch Teil der Lösung, die nur gemeinsam gemeistert werden kann.

Deshalb müssen alle Betroffenen und damit das gesamte Team mit den neuen Regeln und Abläufen einverstanden sein. Alle müssen nicht nur einverstanden sein, sondern auch gerne mitmachen! Wie immer sollte auch in diesem Fall möglichst gar nichts „vorgesetzt“ und verordnet werden. Erfahrungsgemäß klappt es nur dann, wenn alle gerne mitziehen und die neuen Verfahrensweisen und Regeln auch tatsächlich als persönliche Bereicherung von jedem Einzelnen erlebt werden können.

Scrum-Workshop bei GFE

Dass dies so wird und auch so bleibt, erfordert Engagement und zwar von innen wie von außen. Wobei es – und dies wird allen Beteiligten immer deutlicher – vor allem um die individuelle Änderung des eigenen „Mindsettings“ geht, fast mehr noch als die praktische Umsetzung praktischer Scrum-Alltagsregeln.

Es geht um die richtige agile Haltung im Umgang mit den täglichen Herausforderungen, um die richtigen Haltungen und Wertehorizonte, die von allen Mitwirkenden in Scrum-Projekten kultiviert und gepflegt werden: „It’s more about mindset and less about practical doing!“ (Senad Redzic, Scrum Certified Developer bei GFE) Bei dieser Versuchsanordnung, gepaart mit einem gehörigen Schuss „Common Sense“, zur Not auch ganz normalem gesundem Menschenverstand, kann alles eigentlich „immer nur besser kommen“!

Göppingen im Februar 2020
Michael W. Bader, GFE Media GmbH

Anmerkungen

1. Kanban wurde 1947 von Taiichi Ohno bei Toyota als Methode der Produktionsprozesssteuerung in der Automobilindustrie entwickelt. Siehe REFA Bundesverband e. V., „Kanban.“. http://projektmanagement-definitionen.de/glossar/kanban (letzter Zugriff: 28. Januar 2020).
   David Anderson hat das Konzept bei Microsoft auf das IT-Projektmanagement übertragen und 2007 vorgestellt. Siehe Wikipedia, „Kanban (Softwareentwicklung).“. https://de.wikipedia.org/wiki/Kanban_(Softwareentwicklung) (letzter Zugriff: 28. Januar 2020).
2. Ken Schwaber, Jeff Sutherland und u. a., „Manifest für Agile Softwareentwicklung.“. https://agilemanifesto.org/iso/de/manifesto.html (letzter Zugriff: 20. Februar 2019).
3. Ken Schwaber, Jeff Sutherland und u. a., „Manifest für Agile Softwareentwicklung – Prinzipien hinter dem Agilen Manifest.“https://agilemanifesto.org/iso/de/principles.html (letzter Zugriff: 29. Januar 2020).
4. Stephanie Ockerman, „Maximize Scrum with the Scrum Values: Commitment (Part 4 of 5).“. https://www.scrum.org/resources/blog/maximize-scrum-scrum-values-commitment-part-4-5 (letzter Zugriff: 29. Januar 2020).
5. „Prinzipien hinter dem Agilen Manifest.“https://agilemanifesto.org/iso/de/principles.html (letzter Zugriff: 29. Januar 2020).
6. Ebd.
7. GFE Rules in the making