#JAVAPRO #Agile
Die Einführung agiler Methoden wie Scrum geht immer mit Veränderungen einher. Diese betreffen heute nicht mehr nur die Teamebene oder die Produktentwicklung, sondern sie beeinflussen die Mitarbeiter, das Management, Beurteilungssysteme und Stellenbeschreibungen, sprich die gesamte Firmenstruktur und -kultur.
Dynamische Marktveränderungen, wirtschaftliche Unsicherheiten und technologische Umbrüche stellen Unternehmen vor die Herausforderung schnell zu handeln. So wie sich Produktlebenszyklen insbesondere in der Technologiebranche verkürzen, verringern sich auch die Phasen, in denen mit neuen Produkten hohe Gewinne erzielt werden können. Die Verluste durch zu späten Markteintritt wiegen schwerer als höhere Kosten während der Entwicklung. Immer mehr Unternehmen wird bewusst, dass sie mit den bestehenden Prozessen zu langsam sind und agiler werden müssen. Agile Projektmanagement-Methoden wie Scrum setzen vor allem auf Flexibilität und Selbstbestimmung.
Scrum erobert neues Terrain
Als wohl bekannteste agile Methode kann Scrum inzwischen auf eine 20-jährige Erfolgsgeschichte zurückblicken. Ursprünglich angewendet in der Softwareentwicklung, wächst das Verfahren mehr und mehr über die IT hinaus und erobert auch andere Unternehmensbereiche, denn: Von der „strukturierten Selbstbestimmung“ profitiert nicht nur die Software-, sondern auch die Organisationsentwicklung. Scrum ist ein iterativer, inkrementeller Prozess für die Produktentwicklung und die Organisation von Teams, der Mitte der 90er Jahre von Ken Schwaber und Jeff Sutherland entworfen wurde. Im Kern steht das Setzen auf eine hohe Eigenmotivation: Mit Scrum legt ein Team selbst fest, welche Aufgaben es wie erledigen kann. Kundenanforderungen werden iterativ priorisiert und sukzessive realisiert. Ziel ist, Transparenz zu erreichen durch die frühzeitige und umfassende Einbeziehung des Kunden und die regelmäßige Kommunikation aller Beteiligten.
Die drei Scrum-Rollen
Im Gegensatz zu klassischen Projektmanagement-Methoden kennt Scrum weder Projektmanager noch Projekt- oder Teamleiter. Jedenfalls nicht dem Namen nach. Stattdessen arbeitet es mit drei wichtigen Rollen: Product-Owner, Scrum-Master und Team. Alle drei sind gleichgestellte Management-Rollen und haben bestimmte Verantwortlichkeiten:
- Der Product-Owner ist verantwortlich für die Produktvision, die umfassende Vorstellung vom Endergebnis, die Erhebung und Priorisierung der Anforderungen, die Budget-Kontrolle und den Return-on-Investment.
- Der Scrum-Master räumt Probleme aus dem Weg, sorgt für die Einhaltung der Scrum-Regeln und schafft die nötigen Rahmenbedingungen für das Team.
Das Team ist in Scrum eine selbstorganisierte Einheit, die für die Erstellung und die Qualität des Produkts verantwortlich ist. Scrum-Projekte werden in Iterationen, sogenannte Sprints, aufgeteilt und haben in der Regel eine Länge von zwei oder vier Wochen. Zunächst nimmt der Product-Owner die Anforderungen des Kunden und der Stakeholder auf. Diese werden in einem Plan, dem Backlog, erfasst und anschließend priorisiert. Im Sprint-Planning stellt der Product-Owner dem Team die Liste aller Anforderungen samt dazugehörigen Akzeptanzkriterien vor. Das Team findet durch gezielte Fragen heraus, was sich genau hinter den fachlichen Anforderungen verbirgt und schätzt grob den Aufwand. Anders als in klassischen Projektmanagementverfahren schreibt man dem Scrum-Team nicht vor, wie viele Features es in einer bestimmten Zeit realisieren soll. Stattdessen wählt das Team selbst aus, welche Funktionen es in einem Sprint für umsetzbar hält. Alle Anforderungen werden schließlich in einzelne Aufgaben heruntergebrochen und schriftlich festgehalten. Diese Aufzeichnungen werden täglich mit der Angabe über den jeweiligen Restaufwand versehen, so dass immer eine aktuelle grafische Übersicht vorhanden ist.
Am Ende eines Sprints präsentiert das Team dem Product-Owner und gegebenenfalls den Stakeholdern die implementierten Funktionen. Dieser entscheidet dann, ob alle Akzeptanzkriterien erfüllt sind und er die Lieferung abnimmt. Der Scrum-Master sorgt während des gesamten Prozesses für die Einhaltung der Regeln und wehrt Störungen von außen ab.
Von der Team- zur Organisationsebene
Methoden wie Scrum sind erprobt und zeichnen sich durch Transparenz und einfache Regeln aus. Allerdings wurden sie ursprünglich für kleinere Teams entwickelt, sie lassen sich nicht ohne weiteres skalieren. Dabei sind agile Pilotprojekte durchaus auch in großen Unternehmen erfolgreich. Häufig abgekoppelt
von den übergreifenden Unternehmensstrukturen wird für diese Piloten der nötige Freiraum geschaffen, um sich auf die eigentliche Produktwertschöpfung zu konzentrieren und so erreichen viele Piloten die gewünschten Ergebnisse. Der Einbruch kommt beim Versuch, die Ergebnisse aus den Piloten auf das Gesamtunternehmen zu übertragen. Agiles Verständnis kollidiert dann mit bestehenden Strukturen und mit klassischem Unternehmensdenken. Ängste beim Management führen oft zu Widerständen, denn der Schritt vom Manager hin zum Agile Leader ist nicht trivial und erfordert ein ganzheitliches Umdenken im
Unternehmen.
Grundsätze des Agilen Handelns verstehen
Deshalb ist der erste und entscheidende Schritt zur Agilität – noch vor dem Erlernen bestimmter Methoden – das Verständnis für die Prinzipien und Überzeugungen, die diesen Methoden zugrunde liegen. Dazu lässt sich ein Meta-Framework wie z. B. das Enterprise-Transition-Framework (ETF) von agile42 nutzen. Hier werden neue Methoden unter Berücksichtigung der Unternehmenskultur und der agilen Prinzipien eingeführt. Agiles Arbeiten fußt auf Einstellungen und Handlungsweisen, die eine ständige Verbesserung ermöglichen. Es ist ein Wachstums- und Lernprozess, den jedes Team und jede Organisation durchlaufen muss, um ihren agilen Weg zu finden. Das Bild der Agile-Reading-Glasses beschreibt, wie sich im Vergleich zu herkömmlichen Ansätzen die Schwerpunkte verschieben: von der definierten zur empirischen Prozesskontrolle, von Push zu Pull. Lean-Thinking, iterative und inkrementelle Verbesserungen
sind weitere Grundsätze.
Empirische versus definierte Prozesskontrolle
Bei der herkömmlichen, definierten Prozesskontrolle wird ein Gesamtprozess in Teilaufgaben untergliedert und anschließend die für jede Teilaufgabe benötigte Zeit geplant. Kontrolliert wird die tatsächlich benötigte Arbeitszeit im Vergleich zur geplanten Arbeitszeit. Diese kostengünstigste Form der Kontrolle ist erfolgversprechend bei einfachen wie komplizierten Prozessen. Sie setzt allerdings voraus, dass die notwendigen Arbeitsschritte in ihrer Abfolge schon genau bekannt und festgelegt sind, die Zeit kann dann daraus abgeleitet werden. Bei neuen Entwicklungen muss aber zunächst herausgefunden werden, was genau zu tun ist. Es wird getestet, Erfolgsfaktoren und Wechselwirkungen sind noch gar nicht verstanden, Überflüssiges muss erst erkannt und eliminiert werden. Hier greift man auf die empirische Prozesskontrolle zurück. Das ist die aufwendigste, aber auch einzig erfolgversprechende Form der Kontrolle unter komplexen Bedingungen. Aufwendig deshalb, weil es nicht um einen einfachen Zahlenvergleich geht, sondern jedes Mal das Zwischenprodukt geprüft und beurteilt werden muss. In agilen Projekten werden dazu Zeiträume von zwei bis vier Wochen festgelegt. Danach erfolgt dann regelmäßig ein Abgleich des Ergebnisses mit den Kundenanforderungen. Ein agiler Coach wird diesem entscheidenden Punkt besondere Aufmerksamkeit widmen: Das Team lernt, die effektiven Prozesse zu identifizieren und in der weiteren Arbeit anzuwenden. Sind diese Arbeitsschritte herausgefiltert, werden auch statistisch gestützte Aussagen zur Prozessgeschwindigkeit möglich. Nur in dem Maße, wie die nötigen Prozesse verstanden und etabliert sind, kann auch der Übergang zur definierten Prozesskontrolle erfolgen.
Pull versus Push
Das Team, als sich selbst organisierende Einheit, entwickelt die nötige Kompetenz, die Kundenanforderungen in Aufgaben zu übersetzen und richtig zu verteilen. Die Erfahrungen sind kumuliert zu kollektiver „Weisheit“, die ein einzelner übergeordneter Manager so nicht haben kann. Das Team agiert also innerhalb der gesetzten Rahmen und Ziele eigenverantwortlich. Lean-Thinking stellt sicher, dass stets der Kundennutzen im Fokus des agilen Handelns bleibt: Agile Methoden zielen darauf ab, dem Kunden genau das zu liefern, was er braucht – schnell und in bester Qualität. Was nicht wertschaffend ist, entfällt. Überflüssige Variationen ebenso wie unnötige Tätigkeiten. Der Idealzustand im gewohnten Prozessansatz sieht so aus: Der Kunde liefert zu Beginn des Projekts eine klare und umfassende Beschreibung des benötigten Produktes mit allen Eigenschaften. Daran ändert sich während des gesamten Projektzeitraums nichts. Wie jeder Projektarbeiter weiß, sieht die Realität anders aus: Der Kunde sagt was er wünscht (was er eigentlich braucht, kann etwas ganz anderes sein), doch dann ändern sich plötzlich die Rahmenbedingungen. In solch einem Fall starr am ursprünglich Vereinbarten festzuhalten, wäre mit dem Kundennutzen nicht vereinbar. Der agile Ansatz akzeptiert diese Änderungen und arbeitet iterativ und mit inkrementellen Verbesserungen. Ergebnis jedes Durchlaufs (Sprint) ist ein marktfähiges Produkt. Durch den Abgleich der Ergebnisse mit den Kundenanforderungen können Fehler und Abweichungen schnell erkannt und behoben werden. Parallel wird auch auf unnötige Synchronisation von Abläufen verzichtet. Das verkürzt die Time-to-Market. Das Produkt sollte so früh wie möglich bereits auf dem Markt verfügbar sein und wird dann fortlaufend verbessert.
Das passende Tempo finden
Die genannten Prinzipien sollten vor dem Übergang zum agilen Arbeiten durchdacht werden. Das fällt Unternehmen leichter oder schwerer, je nachdem, wie stark eine Kultur der Eigenverantwortung und des ständigen Lernens bereits ausgeprägt ist. Auf diesem Weg verändert sich das Unternehmen schrittweise in einem selbstbestimmten Tempo und so wie es dem Bedarf entspricht. Änderungen werden nicht vorgeschrieben oder auf einem Blatt Papier entwickelt, sondern erwachsen aus den echten Arbeitsbedingungen heraus. Schritt für Schritt werden so immer mehr Teams und Abteilungen in die agile Arbeit einbezogen. Die parallel zum Projekt laufende Ausbildung von internen Coaches hilft, das agile Denken nachhaltig im Unternehmen zu verankern.
Agile Transition erfordert Geduld, denn kaum ein Tool oder eine Erfahrung kann eins zu eins auf ein anderes Projekt übertragen werden. Jedes Unternehmen muss seinen eigenen agilen Weg finden.
Marion Eickmannist Mitgründerin und Mitglied der Geschäftsführung von agile42. Seit über 15 Jahren ist sie im Bereich Softwareentwicklung und Projektmanagement tätig. Aufgrund dieser Erfahrung ist es Marion Eickmann und ihrem internationalen Team möglich, seit 2007 erfolgreich agile Projekte lokal und global umzusetzen.
marion.eickmann@agile42.com
https://de.linkedin.com/in/marioneickmann/de
https://www.xing.com/profile/Marion_Eickmann