Agiles Arbeiten – Geplant reaktionsfähig sein und bleiben
Die agile Arbeitsweise hat sich im Bereich der Softwareentwicklung als erprobte Vorgehensweise etabliert. Von Beginn an werden Dynamik und Änderungsbedarf als normal aufgefasst. Mit anderen Worten: Die Änderung ist das neue Normal und löst keine "Herzattacken" mehr aus. Als IT-Dienstleister ist man oft in der Position, dass man sich zum einem auf die Arbeitsweise des Kunden einlassen sollte und zum anderen die eigenen Prozesse und Vorgehensweisen zielorientiert umsetzen muss. Den Kunden muss man dabei oft behutsam in die richtige Richtung "pressen". Das ist kein leichtes Unterfangen, wenn dieser bisher mit IT-Entwicklung und agilem Arbeiten wenig zu tun hatte.
In diesem Artikel wollen wir zunächst die Ursprungsidee der agilen Arbeitsweise beleuchten. Es macht Sinn, sich die Grundgedanken immer wieder ins Bewusstsein zu rufen, wenn man mit akuten Herausforderungen in einem Projekt beschäftigt ist. Der Blick auf das große Ganze hilft dabei, die Zusammenhänge nicht aus den Augen zu verlieren. Im Anschluss berichten wir zum aktuellen Stand der agilen Arbeitsweise. Wie groß ist der Anteil agiler Vorgehensmodelle? Welche Hürden gibt es primär zu meistern und in welchen Bereichen der Unternehmen wird der agile Gedanke bereits aktiv gelebt? Wenn Agilität ein Werkzeug ist, die Herausforderungen der digitalen Transformation zu bewältigen, dann ist die Nutzung und Akzeptanz auch ein Gradmesser, wie gut es uns bereits gelingt, diese Veränderungen zu bewältigen. Im dritten Abschnitt berichten wir aus der Praxis. Aus der Erfahrung, wie Kunden auf ihren persönlichen Weg der digitalen Transformation begleitet werden. Um die Zusammenarbeit nachhaltig zu optimieren, müssen sich alle Beteiligten auf eine agile Projektdurchführung einlassen. Das braucht Vertrauen und vor allem auch Mut und gegenseitigen Respekt.
Flexibilität durch Agile Methoden
Die agile Arbeitsweise hat ihren Ursprung in der Unmöglichkeit einer umfassenden Planung und Durchführung komplexer und lang anhaltender Softwareentwicklungsprojekte. Bekanntermaßen ist die strikte Abarbeitung eines Entwicklungsvorhabens – streng gestaffelt nach Phasen – eher schwierig. Das Hauptproblem besteht darin, dass eine vollständige und korrekte Erhebung der Anforderungen zu Projektbeginn nahezu unmöglich ist. Auch kann die Stabilität solcher Anforderungen i. d. R. nicht garantiert werden. Dies hat mehrere Ursachen:
Unvollständige und unpräzise Anforderungen zu Beginn des Projektes,
dynamische Änderungen während der Projektlaufzeit in den Geschäftsmodellen und
lange Projektlaufzeiten, teilweise von mehreren Jahren.
Eine Tatsache ist, dass auch die Kunden oft nur eine ungefähre Vorstellung davon haben, in welcher Form eine Software das bestehende Problem lösen soll. Darüber hinaus ist es schwierig, den Entwicklern der Software diese ungefähren Anforderungen zu vermitteln, sie beispielsweise für diesen Zweck auch vollständig und nachvollziehbar zu dokumentieren. Die Ursache für dieses Dilemma liegt in den Haupteigenschaften des Produktes Software begründet. Als abstraktes und immaterielles Gut ist es schwierig, dieses vollständig mit seinen Anforderungen und Eigenschaften zu erfassen. Der Anwender kommt lediglich mit dem User Interface in Berührung. Das Gesamtgebilde Software bleibt verborgen und gewissermaßen ein mystisches Gebilde. Im Gegensatz zu herkömmlichen Produkten, wie beispielsweise einem PKW oder einer Maschine, bleiben nicht nur die Funktionsweise, sondern oftmals auch die Einsatzgebiete und die Vor- und Nachteile zu Beginn im Nebel. Erst mit weiterem Projektfortschritt lichtet sich dieser Nebel und die eigentlichen Erfordernisse an das Produkt Software kristallisieren sich im Kontext der sich schärfenden Problemstellung heraus.
Ein weiteres Problem ergibt sich aus der Dynamik der Geschäftsmodelle. Anforderungen und Rahmenbedingungen, welche zum Zeitpunkt der erstmaligen Analyse galten, sind nicht über die gesamte Projektlaufzeit konstant. Dabei ist zu beobachten, dass das Ausmaß an Dynamik im Laufe der Zeit zunimmt. Da die zu erstellenden Anwendungssysteme immer komplexer und umfangreicher werden, nehmen auch die Laufzeiten der Projekte zu. Dieses wirkt sich ebenso negativ auf die Möglichkeiten einer umfassenden Planung aus. Je länger die Zeitspanne zwischen dem Projektstart und der endgültigen Bereitstellung der Software ist, desto schwieriger wird es, die dann geltenden Kundenanforderungen zu erfüllen. Die agilen Methoden sind nicht "vom Himmel gefallen", sie sind vielmehr die Folge einer längeren zeitlichen Entwicklung.
In den 1980er und frühen 1990er Jahren wurde großer Wert auf sorgfältige Projektplanung und formalisierte Qualitätssicherung gelegt. Die Entwicklung erfolgte oft in großen Teams. Im Ergebnis wurde oft mehr Zeit für die Planung der Entwicklung aufgewendet als für die tatsächliche Programmentwicklung und die nachfolgenden Tests. Trotz dieses sehr planvollen und stark phasengetriebenen Vorgehens waren die Ergebnisse nicht immer zufriedenstellend. Zu viele Projekte scheiterten oder konnten die Anforderungen und Wünsche der Kunden nicht erfüllen. Im Ergebnis wurde erstmals Mitte der 1990er Jahre von "agilen Methoden" gesprochen. Das Ziel war schnell formuliert: Die Entwickler sollten sich verstärkt um ihren eigentlichen Job der Programmentwicklung kümmern und nicht mehr so viel Zeit für den Entwurf und Dokumentation aufwenden.
Fassen wir an dieser Stelle zusammen:
"Agilität" steht also für die Fähigkeit, mit Änderungen umzugehen, d. h. schnell und flexibel auf Kundenanforderungen zu reagieren. Änderungen werden nicht mehr als störend aufgefasst, sondern tragen dazu bei, dass das Anwendungssystem frühzeitig in die richtige Richtung gesteuert wird.
Ein wesentliches Ziel dieses Vorgehens ist es, möglichst in kurzer Zeit eine erste Version des späteren Endproduktes an den Kunden auszuliefern und bereits in sehr frühen Phasen des Entwicklungsprozesses mit Prototypen zu arbeiten. Frühe produktionsfähige Produktversionen sind zwar im Funktionsumfang eingeschränkt, sie geben jedoch den Anwendern die Möglichkeit, rechtzeitig Feedback zu geben. Das Feedback ist wiederum die Ausgangsbasis, um mögliche Modifikationen zeitnah in den weiteren Projektverlauf einzuarbeiten.
Es gibt unterschiedliche Ansätze agiler Entwicklungsmethoden. Dazu zählen Extreme Programming (XP), Scrum, Feature Driven Development, Design Thinking, Lean Startup und Kanban. Einige Ansätze sind bereits älter und wurden für die Softwareentwicklung adaptiert. Beispielsweise kommt Kanban aus der Autoindustrie und dient dazu, Projektfortschritte zu visualisieren (Kanban Board). Bei der Teamarbeit sorgt es dafür, dass alle Beteiligten zu jeder Zeit sehen können, in welchem Stadium sich die einzelnen Aufgaben befinden. Durch diese Transparenz wird Doppelarbeit vermieden. Ebenso ist eine leichtere Priorisierung möglich. Auch eine Kombination oder eine individuelle Anpassung des Vorgehens an die Erfordernisse der eigenen Projekte und Teamarbeit ist möglich und wird praktiziert. Design Thinking zielt zum Beispiel darauf ab, den Ideen- und Innovationsprozess zu gestalten und kann in viele Ansätze integriert werden. Extreme Programming und Scrum fokussieren dagegen auf hohe Flexibilität und Dynamik der Projektsteuerung, primär im Bereich der Softwareentwicklung. Die Idee und den Ansatz von Scrum haben wir im kommenden Abschnitt kompakt zusammengefasst.
Scrum
Die häufigste angewendete agile Methode ist Scrum, welches als Rahmenwerk für agile Prozesse bekannt ist. Der Begriff "Scrum" stammt aus der Sportart Rugby. Dabei stehen sich zwei gegnerische Mannschaften gedrängt (Scrum = Gedränge) gegenüber und versuchen den Ball zu erkämpfen. Ein selbstorganisiertes Entwicklerteam steht im Mittelpunkt von Scrum. Der Scrum Master bildet eine Schnittstelle zwischen dem Team und den Produktverantwortlichen. Er sorgt dafür, dass der Entwicklungsprozess reibungslos abläuft. Die Idee ist, dass bei umfangreichen Projekten der Erfolg nur durch ein regelmäßiges Feedback zu erreichen ist. Dadurch werden die Abweichungen vom Soll schnell erkannt und notwendige Anpassungen ermöglicht. Die gesamte Entwicklung wird in Iterationen mit einer Dauer zwischen einer und vier Wochen strukturiert und durchgeführt (Sprints). Die Sprints haben eine feste Dauer und enden unabhängig davon, ob die Aufgabe abgeschlossen werden konnte oder nicht. Die Produktanforderungen werden in einem Product Backlog gesammelt. Dieses wird fortlaufend vervollständigt. Das Team entscheidet über die Priorisierung der Anforderungen bzw. Aufgaben. Jeder Sprint endet mit der Überprüfung der Ergebnisse (Sprint Review) und Reflektion der Prozesse (Sprint Retrospektive). Am Ende jedes Sprints steht eine lauffähige, getestete und inkrementell verbesserte Software zur Verfügung.
Scrum unterscheidet zwischen drei Rollen: Der Product Owner repräsentiert in Scrum die Kundenbedürfnisse. Im besten Fall ist er der Kunde selbst oder ein vom Kunden bevollmächtigter Vertreter. Er trifft eigenständig und zügig qualifizierte Entscheidungen über das Produkt. Er koordiniert die Kundenanforderungen und priorisiert sie im Product Backlog. Ebenso definiert er die Akzeptanzkriterien und nimmt die Arbeitsergebnisse des Teams ab. Der Scrum Master ist der Coach für das Team. Er hilft den Teammitgliedern, Scrum richtig einzusetzen. Seine Rolle ist umso wichtiger, je weniger Erfahrung das Team mit Scrum hat. Das Scrum-Team hat die zentrale Rolle. Es ist von Vorteil, wenn die Mitglieder über ein breites Spektrum an Wissen verfügen. Dieses Wissen darf sich nicht in den Köpfen von Spezialisten konzentrieren, sondern es muss gemeinsames Wissen des gesamten Teams sein oder werden.
Das Ziel besteht darin, die Problemlage, welche auf der ungenauen Formulierung der Anforderungen beruht, zu beseitigen.
Das Team organisiert sich selbst, d. h. es entscheidet über eine Vielzahl von Dingen selbstverantwortlich. Hierdurch entsteht eine höhere Identifikation mit dem Projekt und das Verantwortungsgefühl steigt. Insbesondere schätzt das Team selbst die Aufwände für die einzelnen User Stories, und es übernimmt die Verantwortung, dass diese richtig konzipiert sind. Ein wichtiger Punkt ist das "Commitment" im jeweiligen Sprint auf bestimmte User Stories. Dabei entscheidet das Team, welche und wie viele User Stories es im nächsten Sprint umsetzen kann. Zentrale Merkmale sind regelmäßige, kompakte und ergebnisorientierte Meetings. Sprint Planning Meetings sind so genannte Start Meetings für den jeweiligen Sprint und diese werden in zwei Schritten ausgeführt. Dies sind die Festlegung des Inhalts des nächsten Sprints und die Erstellung des Sprint Backlogs. Das Sprint Review wird am Ende jedes Sprints durchgeführt und dient zur Überprüfung und Abnahme des Produkt-Inkrements durch den Product Owner. Dabei werden die Ergebnisse präsentiert. Durch die regelmäßige Durchführung bekommt man sofort ein Feedback und eine Entwicklung in die falsche Richtung kann ausgeschlossen werden. Die Sprint Retrospektive zielt im Gegensatz zum Sprint Review auf eine Analyse der Zusammenarbeit während des vorangegangenen Sprints ab. Es ist für die Qualität nicht nur wichtig, dass die Features auch funktionieren, sondern für alle Beteiligten ist es auch äußert interessant, wie die Ergebnisse erreicht wurden. Aus der gemeinsamen Betrachtung zieht man Schlüsse für den nächsten Sprint. Das Daily Scrum umfasst tägliche 15-minütige Meetings des Teams unter Beteiligung des Scrum Masters und eventuell des Product Owners. Diese dienen hauptsächlich dem Informationsaustausch des Teams untereinander. Grundsätzlich verfolgt jedes Scrum Meeting das Ziel, die Ergebnisse zu analysieren und die daraus resultierenden Anpassungen unmittelbar umzusetzen.
Das Ziel einer agilen Vorgehensweise besteht also darin, die oben beschriebene Problemlage zwischen Business und IT, welche auf der ungenauen Formulierung der Anforderungen beruht, zu beseitigen.
Das Requirements Engineering stößt an seine Grenzen, wenn es versucht, die Anforderungen an das zu entwickelnde System im Vorhinein "generalstabsmäßig" zu planen und auch umzusetzen. Wie man es besser machen kann, zeigen die agilen Methoden, wie zum Beispiel Scrum.
Agile Durchdringung – State of the Art
![Abb. 1: Organisationsformen der Unternehmen. Quelle: SqissQ [1]](/fileadmin/_processed_/0/3/csm_Abb1_Agile_Bochkor_Krypczyk_34621d4fe3.png "Abb. 1: Organisationsformen der Unternehmen. Quelle: SqissQ [1]")
So klar die Notwendigkeit und die Vorteile einer agilen Arbeitsweise auch sind, so schwer tut man sich in der Praxis damit, den agilen Weg zu beschreiten. Gerade eine wirkliche Änderung (Change-Management) der Unternehmensprozesse über Abteilungsgrenzen und Zuständigkeiten fällt schwer. Eine Umfrage von SqissQ aus dem Jahr 2019 bei mehr als 400 Personen aus unterschiedlichen Unternehmen, Branchen und Regionen aus der Schweiz liefert interessante Ergebnisse [1]. Die Frage nach der Organisationsform zeigt noch einen erheblichen Nachholbedarf an agiler Projektarbeit (s. Abb. 1).
Ein tiefergehender Blick bestätigt ebenso, dass die agile Arbeitsweise im Development bereits zu einem sehr großen Teil verankert ist. In den anderen Unternehmensbereichen, insbesondere auch im Business, ist man davon noch ein sehr großes Stück entfernt [1]. Letztendlich werden sich Erfolge auf breiter Ebene aber nur dann einstellen, wenn die gesamte Unternehmensstrategie mehr Flexibilität zulässt und die Grundideen der agilen Projektsteuerung aufgreift, zulässt und letztendlich auch anwendet. Die größten Hemmnisse für Agilität werden in den folgenden Punkten gesehen:
Bestehende Unternehmenskultur und Hierarchien: Die Einführung einer agilen Arbeitsweise setzt umfassende Veränderungen im Unternehmen voraus. Dazu müssen lang etablierte Prozesse aufgebrochen und geändert werden. Die Mitarbeiter im Unternehmen müssen individuelle Lernprozesse durchlaufen und bereit sein, Änderungen zu akzeptieren und lieb gewonnene Gewohnheiten anzupassen.
Nicht angepasste Prozesse: Eine agile Arbeitsweise macht es erforderlich, dass Geschäftsprozesse über Abteilungen hinweg aufgebrochen und modifiziert werden. Die Änderungen werden sich langfristig nicht nur auf eine Abteilung, zum Beispiel die Entwicklung, beschränken, sondern weite Teile des Unternehmens umfassen.
Fehlender Gesamtüberblick/Vision: Die agile Transformation ist ein umfassendes Umkrempeln an vielen Bereichen des Unternehmens. Damit man sich nicht im "Klein-Klein" der Details verliert, ist die Vision ("Was wollen wir erreichen?") und damit der Gesamtüberblick stets im Blick zu behalten.
Kunde nicht involviert: Agile Methoden setzen eine intensive Zusammenarbeit mit den Kunden voraus. Ohne diesen geht es nicht. Der Kunde muss am gesamten Projekt mitwirken. Dazu muss dieser auch bereit sein und beispielsweise vom Entwicklungsteam zur Abgabe von Feedback aufgefordert werden. Feedback ist eine wichtige Voraussetzung für den Projekterfolg.
Priorisierung der Aufgaben: Komplexe IT-Projekte brauchen eine Priorisierung der Aufgaben. "Was ist jetzt und heute wichtig?"; "Welche Anforderung ist als nächstes umzusetzen?"
Hohe Spezialisierung der Mitarbeiter: Das Team ist für das gesamte Projekt zuständig. Probleme sind eigenständig im Team zu lösen. Auch die Arbeitsorganisation liegt in den Händen des Teams. Die Lösungskompetenz darf nicht bei einigen wenigen Mitarbeitern liegen. Wichtig sind cross-funktionale Teams (Abb. 2), welche gemeinsam die Aufgaben bewältigen. Idealerweise hat jedes Teammitglied eine Spezialisierung, die Mitglieder arbeiten gemeinsam an einem Ziel, das Team vereint die Kompetenzen und alle Teammitglieder lernen voneinander [2].
Agilität umfassend in einem Unternehmen zu verankern ist daher kein einmaliger Akt, sondern ein stetiger Prozess des Lernens und Anpassens. Er wird nur dann gelingen, wenn Unternehmen sich entsprechend öffnen und für die Veränderung bereit sind. Einen Blick in die agile Praxis eröffnet der folgende Abschnitt.
Kundenprojekte agil steuern: Erfahrungen aus dem Kundenprojekt
Projekttyp & -ziel: Sehr häufig werden so genannte Digitalisierungsprojekte durchgeführt, welche Nicht-IT-Unternehmen auf den Weg der digitalen Transformation begleiten. Geschäftsprozesse sollen jeweils umfassend digitalisiert werden.
Methoden des agilen Arbeitens: Meist werden Scrum und Kanban – je nach Projektsituation – eingesetzt. Scrum ist der Favorit, wenn es um größere Projekte geht. Auf Kanban wird bei vielen kleineren Projekten, Wartung und Support gesetzt. Die Erfahrung hat gezeigt, dass es kein einzelnes Patentrezept gibt. Jeder Kunde, jedes neue Projekt, jedes neue Feature ist anders und fordert regelmäßig neue Lösungen zu suchen und zu finden.
Primäre Vorteile des agilen Arbeitens: Diese liegen ganz klar im Erfolg für den Kunden. Scrum und Kanban folgen einem inkrementellen Ansatz. Dadurch können erfolgsentscheidende Themen für das Projekt bzw. das Produkt sehr zeitig und dementsprechend auch kostengünstig angegangen werden. Allerdings bedarf es doch einiges an Erfahrung, um genau diese Fragestellungen mit dem Kunden herauszuarbeiten, zum Beispiel:
- Ist es eine spannende neue Idee und ist es entscheidend als erster auf dem Markt zu sein?
- Wird eine neue Technologie benötigt und sind wir noch unsicher, ob sie schon Produktreife hat?
- Soll ein Bestandssystem ersetzt werden und es gibt riskante Integrationsthemen?
- Welches ist die Kernfunktionalität, die der Nutzer lieben muss, damit unser Produkt zum Erfolg wird?
Manchmal kann es sein, dass es mehrere MVPs (Minimum Viable Product) und Feedbackrunden braucht, bis man den richtigen Ansatz gefunden hat. Eine Wahrheit, die jeder schon am eigenen Leib kennen gelernt hat, der länger in der IT arbeitet, ist, dass sich Anforderungen ändern. Das gilt selbst bei den erfahrensten und besten Teams. Es liegt einfach daran, dass es in jedem Projekt Fragen gibt, die sich im voraus einfach nicht klären oder manchmal nicht einmal erwarten lassen. Das agile Manifest lehrt uns solche "Plan-Änderungen" mit offenen Armen zu empfangen, um sie anzugehen; konventionelle Methoden bieten hierfür einfach keine adäquaten Vorgehensalternativen. Der Vorteil kommt aus der engen Kollaboration mit dem Kunden, die insbesondere im Scrum Framework in Form der "Scrum-Events" eingebaut ist. Die definierte Regelmäßigkeit reduziert Komplexität für eine sonst deutlich schwerer zu steuernde Herausforderung.
Neue Mitglieder ins Team bringen: Praxisnah, in Form von Schulungen, Workshops und die direkte Mitarbeit in Projekten mit Unterstützung von erfahrenen Kollegen.
Hürden bei der Zusammenarbeit, wenn der Kunde die agile Arbeitsweise noch nicht kennt: Ist der Kunde das Wasserfallmodell gewöhnt, dann muss man ihn überzeugen und Vertrauen schaffen. Man muss zunächst einfach erst einmal anfangen und spätestens nach den ersten Sprints kann man die ersten Ergebnisse kommunizieren. Der Kunde merkt, dass er ein Mitbestimmungsrecht hat und aktiv in das Geschehen eingreifen kann. Spätestens dann erkennt er, dass er Teil des Projektes ist und aktiv mitwirken darf und soll. Am Ende kommt ein Ergebnis heraus, wovon der Kunde begeistert ist, weil er die ganze Zeit involviert war.
Interne Projektsteuerung: Die agile Arbeitsweise sollte nicht nur nach außen gelebt werden, sondern Teil der Unternehmenskultur sein. Auch interne Projekte sollte man so steuern.
Hilfe in Form von Tools: Whiteboard, ein paar Stifte und Sticky Notes, um kreative Lösungen zu finden. Online-Tools, um die Zusammenarbeit über Zeit- und Ortsgrenzen zu koordinieren, zum Beispiel Jira (Ticketsystem), Confluence (Wiki/ Intranet), Teams, Slack (Kommunikation) und eine ganze Reihe von CI-Tools.
Arbeitsumgebung: Diese hat ganz entscheidenden Einfluss darauf, wie viel Nutzen wir aus dem agilen Arbeiten ziehen können. Diese kann Teamwork und Kundenkommunikation fördern oder aber auch verhindern. Förderlich sind zum Beispiel Kreativräume, Teams/ Slack, freie Wahl der Tools/ Arbeitsmittel, Kicker, gemeinsamer Essensraum, Meetingräume, Whiteboards, Planning-Poker-Karten.
Ganz wichtig: flache Hierarchien fördern die Motivation und Kollaboration!
(*Die Projekterfahrungen stammen von einem Projekt von ApiOmat)
Fazit und Zusammenfassung
Die vorherigen Betrachtungen haben eines ganz deutlich gezeigt: Eine agile Arbeitsweise kann die Antwort auf die Dynamik der heutigen Anforderungen an eine moderne IT sein. Sicher ist dabei jedoch lediglich: "Nur die Veränderung wird bleiben."
Prozesse und Vorgehensweisen müssen ständig angepasst werden, um die Dynamik einer sich stetig verändernden Umwelt abbilden zu können.
- SwissQ: Trends & Benchmarks in Software Development Schweiz 2019
- Techdivision: Was ist ein cross-funktionales Team?
