Nachdem der Hype um agile Methoden abgeflaut ist, können wir unaufgeregt den Blick darauf lenken, was die Prinzipien von Agilität sind, wie sie wirken und wie man sie auch jenseits der Software-Entwicklung nutzen kann.
Dort, in der Programmierung, lagen die Anfänge von agilen Konzepten, die sich seit den 90er-Jahren des letzten Jahrhunderts entwickelten (z. B. Kent Beck, 1999: Extreme Programming). Anlass waren Probleme mit der üblichen Projektplanung, Wasserfall-Modell genannt, wo am Anfang eines Projekts eine Gesamtplanung vorgenommen wurde, von oben nach unten in die Details, die dann nach Abnahme durch den Kunden genauso abgearbeitet wurde.
Wasserfall-Modell: erst alles planen, dann alles abarbeiten
Je komplexer die Aufgaben, desto länger dauerte die Planung, und – vielleicht kennen Sie das auch? – desto wahrscheinlicher waren Planungsteile schon veraltet, bevor sie zur Umsetzung anstanden. Neue Anforderungen kamen hinzu, die Planung wurde immer komplizierter, und keiner konnte sie schließlich überschauen und damit auch verantworten.
Wenn die beteiligten Entwickler in ihrem Arbeitsbereich dringende Veränderungen anmahnten, warteten sie lange auf Entscheidungen. Die Entscheidungsträger mussten schließlich alles verstehen und die Gesamtplanung anpassen.
Bürokratie bremst schnelle Entscheidungen aus
In dieser Situation stellten die agilen Ansätze die Planungsorganisation auf den Kopf, oder sollte man sagen: vom Kopf auf die Füße? Im Zentrum der Programmierung stand nun nicht mehr die Planung, sondern das Entwicklerteam. Mit dem agilen Manifest 2001 wurden wesentliche Prinzipien, Werte und Methoden dieses Arbeitsstils veröffentlicht, die seitdem Anregungen für ein neues Managementverständnis gebracht haben – auch über die Software-Erstellung hinaus.
Diese zentralen Aspekte stelle ich vor:
- Iteratives Vorgehen
- Zusammenarbeit mit dem Kunden
- Sprints und „usable Software“
- Empowerment des (Entwickler-)Teams
- „Out of the box“-Denken
- Daily Scrum und Kanban
- Reviews und Fehlerkultur
- Product Owner und Scrum Master
1. Iteratives Vorgehen
Iterativ (oder auch inkrementell) vorgehen heißt:
anfangen → machen → testen → auswerten → den nächsten Schritt anfangen usw.
Anstatt am Anfang einen großen Entwurf zu planen, tastet man sich in kleinen, überschaubaren und wiederholten Schritten nach und nach an ein Ziel heran. Man experimentiert und wertet immer wieder aus. Lange Planungsphasen fallen weg, stattdessen kann angefangen werden und es liegen schnell erste Ergebnisse vor. Diese werden verglichen: Geht es in die richtige Richtung? Änderungen können sofort aufgenommen werden, ohne große Projektstrukturen anpassen zu müssen.
„Ja aber“, denken Sie vielleicht, „fehlt einem da nicht der Überblick?“ Ja, man belässt es bei einer allgemeineren Zielbestimmung, denn so ein Überblick durch eine Gesamtplanung ist doch oft nur eine Illusion. Eine, die ein sicheres Gefühl macht, ja – die aber auch viel kostet: Zeit, Ressourcen, Effektivität.
Ein iteratives Vorgehen ist schnell und wendig. Man fährt auf Sicht, aber man fährt sofort los, während andere noch lange die Karte studieren.
Wie anwenden?
Wie kann das Prinzip des iterativen Vorgehens im Arbeitsalltag eingesetzt werden?
Verzichten Sie auf umfassende Planungen und starten Sie stattdessen mit einem Pilotprojekt. Lassen Sie einen Prototyp erstellen und sparen Sie sich die Zeit für unergiebige Diskussionen davor. Wenn Sie etwas in Ihrem Unternehmen durchsetzen wollen, dann schaffen Sie im ersten Schritt eine beispielhafte Anwendung, und hangeln sich von dieser ersten Insel zur nächsten, bis ein Kontinent zusammenwachsen kann.
Grenzen & Risiken?
Bei dieser Vorstellung werden dann auch die Grenzen des iterativen Vorgehens spürbar: Manches braucht schon eine „große“, vielleicht strategische Zielrichtung. Eine schrittweise Annäherung reicht nicht immer aus.
2. Zusammenarbeit mit dem Kunden
Bei agiler Software-Entwicklung gibt es folglich kein Pflichtenheft, das alle Features des Programms detailliert aufführt, sondern „User Storys“. Das würde ich als IT-Laie übersetzen mit: vage Erzählungen dessen, was der Kunde haben möchte.
Auch hier wird mit einem Märchen aufgeräumt, nämlich, dass der Kunde schon genau weiß, was er brauchen wird. Stattdessen begibt man sich gemeinsam auf einen Weg. Der Kunde muss viel mehr und viel öfter mitarbeiten – dafür wird das Produkt allerdings wesentlich genauer seine Bedürfnisse abdecken, die er öfters auch erst auf diesem Weg entdeckt hat.
Wie anwenden?
Wenn Sie dieses Prinzip leben wollen, dann wird das Einbeziehen Ihrer externen wie internen Kunden zu einer A-Priorität. Das Darstellen der eigenen Fachkompetenz rückt in den Hintergrund gegenüber einer gemeinsamen Problemlösung.
Ich erinnere mich gerne an solche Aufträge, wo die ursprüngliche Anfrage des Kunden mit dem gemeinsam realisierten Projekt nur noch wenig Überschneidungen hatte, und wo beide Seiten gerade in der Zusammenarbeit viel gelernt haben und hoch zufrieden waren.
Grenzen & Risiken?
Leider gibt es auf Seiten der Kunden nicht immer die Möglichkeit zu intensiver, prozessbegleitender Zusammenarbeit. Sei es, dass dafür kein Zeitbudget da ist, oder dass strikte Ausschreibungsregeln eine Vorab-Spezifikation erzwingen.
3. Sprints und „usable Software“
Der Weg der schrittweisen Annäherung an ein Ergebnis wird auch organisatorisch sichtbar durch kurz getaktete Arbeitsphasen von zwei bis vier Wochen. Ein solcher Sprint beginnt mit der Auswahl von Aufgaben und deren Feinplanung im Team. Danach erfolgt die produktive Arbeit, die immer wieder reflektiert wird. Zwei Aspekte finde ich bemerkenswert: Das Ziel „usable Software“ und der Schutz der Sprintphase vor Auftragsänderungen.
Am Ende eines Sprints soll etwas tatsächlich Brauchbares entstanden sein, eine „usable Software“. Damit muss sich die Planung vom üblichen Weiterführen von To-Do-Listen unterscheiden. Man muss zum einen vom Ende her denken: Was soll herauskommen? Und zum anderen ist die Kundenperspektive entscheidend: Mit welchen Sprint-Ergebnis kann der Kunde tatsächlich etwas anfangen?
Der Kunde erlebt bei agiler Dienstleistung also einen steten Strom von Features, mit denen er sofort arbeiten kann. Es gibt kein langes Warten auf ein nächstes Release. Sowohl Schwierigkeiten mit Zwischenergebnissen als auch Veränderungen der Rahmenbedingungen beim Kunden können zeitnah kommuniziert und beim nächsten Sprint berücksichtigt werden.
Bei einem Sprint ist nach der reinen Lehre das Team vor Eingriffen von außen geschützt. Weder sollen kurzfristig noch neue Aufgaben hineingekippt, noch Prioritäten verändert werden. Das Team kann also in Ruhe arbeiten. Wenn die Feinplanungen für den Sprint realistisch waren, werden die Ergebnisse erreicht, wenn nicht, kann es nicht auf Außeneinflüsse geschoben werden.
Wie anwenden?
Der Kerngedanke von Sprints kann immer da verwirklicht werden, wo man sich auf schnelle Ergebnisse fokussiert. Projektteams sollten dann nicht ein halbes Jahr reden, bevor sie ins Tun kommen. Schnell meint aber nicht oberflächlich, vielmehr soll ein übersichtliches Arbeitspaket in begrenzter Zeit fertiggestellt werden. Dafür wird dann auch ein verlässlicher Zeitkorridor ohne weitere Eingriffe von oben bereitgestellt.
Grenzen & Risiken?
Außer bei reiner Projektarbeit ist ein störungsfreier Sprint kaum vorstellbar. Damit wird leider ein wichtiger Motivationshebel ignoriert: Dass es sich nur dann lohnt, klug zu strukturieren, zu planen und engagiert abzuarbeiten, wenn man Einfluss hat. Muss jeder Eingriff tatsächlich sofort erfolgen? Nach meiner Erfahrung könnten mehr geschützte Sprints das effektive Arbeiten verbessern.
4. Empowerment des (Entwickler-)Teams
Wenn ein agiles Team seinen Sprint plant und umsetzt, dann bekommt es dafür Autonomie. Das Entwicklerteam ist nicht mehr nur für das Abarbeiten des Auftrags, sondern für das gesamte Management drum herum zuständig. Dafür werden seine Entscheidungskompetenzen deutlich erhöht, das meint Empowerment.
Dem klassischen Kontrollfreak läuft es kalt den Rücken herunter, aber ich als Psychologin kann beruhigen: Nur so bekommen Sie eine Verantwortungsübernahme! Ver-Antwort-ung heißt ja wörtlich: eine Antwort geben müssen und können. Mit Empowerment liegen die Entscheidungen beim Team, und es muss Antworten liefern. Können Sie den Ernst spüren, der dadurch entsteht?
Das Team darf und muss auswählen: welche Arbeitspakete, welchen Workload packen wir auf unsere Schultern? Was können wir, was trauen und muten wir uns zu? Nur die Aufgaben, zu denen sich ein Team committed, werden in den Sprint hineingenommen. Die selbst gesteckten Ziele werden dann mit größerer Ausdauer verfolgt, als wenn sie von außen beauftragt würden. Entschuldigungen gibt es kaum, man hatte ja alles selbst in der Hand.
Wie anwenden?
Empowerment können Sie insbesondere dadurch leben, indem sich die Führung zurückhält und Entscheidungsmacht tatsächlich abgibt. Es braucht weder ein Projekt noch ein Team, das geht auch bei Einzelaufgaben an Einzelmitarbeiter. Das Commitment sollte jedoch sorgfältig besprochen werden. Die Mitarbeitenden müssen Bescheid wissen über Hintergründe, Ziele und Prioritäten, damit sie ihre (neue) Entscheidungskompetenz sinnvoll einsetzen können. Und ich wünsche Ihnen viel Freude an selbstständigem Arbeiten und effektiveren Mitarbeitern!
Grenzen & Risiken?
Voraussetzung für erfolgreiches Empowerment ist, dass ein Mitarbeiter oder Team über die richtige Qualifikation verfügt, also das relevante Wissen und Können. Für etwas geradestehen zu müssen, was man nicht versteht, das ist heftiger Stress. Agiles Führen wird gefordert, ohne dass die Rahmenbedingungen stimmen? Dazu lesen Sie hier mehr.
In der Praxis kann es zu einer Überverantwortlichkeit kommen: Man überschätzt sich, macht unbezahlte/heimliche Überstunden und legt ungesundes Arbeitsverhalten an den Tag.
5. „Out of the box“-Denken
In der Software-Entwicklung war der Know-how-Transfer zwischen Spezialisten ein erklärtes Ziel von agilen Ansätzen. Die Wissens-Silos von langjährigen Experten sollten geknackt, Wissen geteilt werden. Idealerweise wird im Team Erfahrungswissen den Kollegen bereitwillig zur Verfügung gestellt, eigene Vorgehensweisen gezeigt und Ratschläge aus dem eigenen Erfahrungsschatz gegeben. Das Know-how der Kollegen ist eine wichtige Ressource für das gesamte Team. Einzel-Expertise wird in der Arbeit weitergegeben.
Frühere Ansätze von Wissensmanagement, in denen auf abgespeichertes Wissen in Datenbanken gesetzt wurde, waren nicht sehr erfolgreich. Wissensweitergabe durch gemeinsame Arbeit scheint viel effektiver zu sein. Darunter liegt die Erwartung von ständigem Lernen: jede Aufgabe als Anlass nehmen, seine Fähigkeiten zu erweitern. Ein eingeschliffenes Expertenwissen ist schnell veraltet, während die Fähigkeit zum Austausch und zur Übernahme verschiedener Perspektiven eine wertvolle Meta-Kompetenz darstellt.
Wie anwenden?
Out oft he box-Denken wird gestärkt, wenn Arbeitsgruppen heterogen zusammengesetzt werden. Mentoren-Modelle oder Patenschaften, bei denen ein gegenseitiges Lernen voneinander stattfindet, wirken auch in diese Richtung. Daneben kann in Projekten oder anderen Besprechungen aufgefordert werden, mal eine andere Perspektive einzunehmen: Wie würde ein Kunde, ein neuer Mitarbeiter oder wer auch immer mit einem neuen Blick die Situation sehen?
Grenzen & Risiken?
Ehrlich gesagt, wird mit dem „Knacken von Wissens-Silos“ Expertenwissen entwertet. Das merken die Experten auch, und sie können sich wehren und mauern. Know-how-Transfer lohnt sich für Anfänger mehr. Es braucht eine gehörige Portion von Identifikation mit dem Unternehmen, wenn Spezialisten dennoch mitmachen.
6. Daily Scrum und Kanban
Dies sind praktische Instrumente des agilen Arbeitens.
Daily Scrum (scrum ist das englische Wort für Gedränge) ist ein täglicher Stehtreff während der Sprints. Im Team werden die Arbeitsstände ausgetauscht, Probleme benannt und Unterstützung vereinbart. Weil das Arbeitsergebnis (usable Software) als Teamergebnis vereinbart wurde, sind Schwierigkeiten bei einem Entwickler eine Aufgabe für alle. Im Idealfall setzt man sich zu zweit hin, oder man nimmt Aufgaben ab, um zu entlasten. Das Daily Scrum ist die zentrale Plattform, bei der das tägliche Austarieren von Fortschritten im Team stattfindet.
Kanban, japanisch „Kärtchen“, ist ein Begriff aus der Produktionsprozesssteuerung. Ein solches Kärtchen zeigt an, dass ein bestimmtes Material zu Ende geht und nachbestellt werden muss. Übertragen auf Projektarbeit entsteht ein Kanban-Board, auf dem der Arbeitsfortschritt dargestellt wird, indem Kärtchen mit Teilaufgaben weitergehängt werden. Es gibt 4 Rubriken:
- Arbeitsspeicher = Backlog
- ausgewählte Aufgaben = to do (von einer konkreten Person für den Sprint ausgewählt)
- angefangene Aufgaben = doing
- fertig gestellte Aufgaben = done
Alle gewünschten Anforderungen (Requirements) aus den User Storys befinden sich im Arbeitsspeicher, der Backlog genannt wird. Oftmals wird dies an einer Pinwand mit Moderationskärtchen oder Post-ist realisiert. Bei der Sprint-Planung übernimmt ein Entwickler die Verantwortung für bestimmte Aufgaben und hängt diese Kärtchen in die nächste Spalte „to do“. In den Daily Scums wird über die Umsetzung berichtet. Sobald ein Task begonnen wird, wandert das Kärtchen in die nächste Rubrik „doing“, und wenn er fertig ist, in die Spalte „done“. So ist auf einen Blick ersichtlich, welche Aufgaben im jeweiligen Sprint dran sind, welche in Arbeit und welche erledigt sind.
Wie anwenden?
Beide Tools lassen sich leicht auch jenseits der Software-Entwicklung einsetzen.
Ein Kanban-Board eignet sich hervorragend zur Steuerung von Teamaufgaben jenseits des Tagesgeschäfts. Alles, was „man immer schon mal anpacken wollte“, wird dann als Kärtchen ins Backlog gehängt. Im Team-Meeting werden Freiwillige gesucht, die diese Aufgabe in ihre Verantwortung nehmen und folglich auf „to do“ umhängen, usw. Selbst für die persönliche Arbeitsplanung ist eine Kanban-Tafel ein gutes Hilfsmittel.
Daily Scrums müssen einen Mehrwert für die Beteiligten haben, damit sie nicht zu einer Kaffeerunde verkümmern. Aber wenn echte Teamarbeit und der schnelle Informationsaustausch wichtig ist, dann sind sie nützlich.
Grenzen & Risiken?
Um Daily Scrums wirklich zu leben, braucht es eine Vertrauenskultur. Sonst kann leicht ein Rechtfertigungsdruck entstehen und man verschweigt die wirklichen Probleme.
7. Reviews und Fehlerkultur
Alle agilen Techniken können und sollen eine gemeinschaftliche Lernkurve befördern. Ein gutes Team wird von Sprint zu Sprint besser: im Einschätzen des Aufwandes, im Abfangen von Widrigkeiten und der gegenseitigen Unterstützung. Das kann nur gelingen, wenn das Team mit Zeit und Ehrlichkeit an eine Manöverkritik geht. Diese Abschluss-Meetings eines Sprints dienen der Reflexion auf Auswertung. Es gilt einerseits, Schwachstellen deutlich zu benennen, aber auch andererseits, lösungsorientiert zu denken und Schlüsse für den nächsten Sprint zu ziehen.
Nicht das Identifizieren von vermeintlich Schuldigen macht uns besser, sondern der Blick auf Zusammenhänge von Fehlern. Dem steht die menschliche Psyche im Wege, die gerne fehlerlos sein möchte. Eine Fehlerkultur, wie sie so leicht angemahnt wird, ist immer wieder eine Herausforderung.
Wie anwenden?
Machen Sie bei jeder Nicht-Standard-Aufgabe eine Reflexion, egal ob bei Einzel- oder Teamaufgaben. Vielleicht dokumentieren Sie die Lernergebnisse, die Sie sammeln, um ein Gegengewicht gegen das blöde Gefühl beim Besprechen von Fehlern zu haben?
Grenzen & Risiken?
Selbst in etablierten Scrum-Teams wird unter Zeitdruck leider gerade die Reflexion weggelassen. Wenn das Vertrauen zu gering ist, kann das Review auch zu einer oberflächlichen, formalen Routine werden, bei der Lernchancen versäumt werden.
8. Product Owner und Scrum Master
In agilen Teams gibt es neue Führungsrollen. Der Product Owner trägt die unternehmerische Verantwortung für das Produkt, er vertritt gewissermaßen die Firma und deren Anforderungen. Damit definiert und priorisiert er die gewünschten Produkteigenschaften in enger Absprache mit den Kunden, und trägt diese in das Product Backlog ein, aus dem das Entwicklerteam dann die Sprint-Tasks nimmt.
Der Product Owner stellt die unternehmerische Seite dar, in meinem Sit plus+ – Führungsmodell die Ziel- und Leistungsorientierung. In Abgrenzung dazu übernimmt der Scrum Master Unterstützungsaufgaben für das Team. Diese Person moderiert die Meetings, sorgt für die Einhaltung der Scrum-Regeln, kümmert sich um Schwierigkeiten und motiviert. Im Sit plus+ – Führungsmodell entspricht das in etwa der Mitarbeiterorientierung. Die Zielkonflikte zwischen Fordern und Unterstützen, die Führungskräfte nur zu gut kennen, werden hier interessanterweise auf zwei Personen aufgeteilt.
Die wichtigste Führungsrolle hat meiner Meinung nach jedoch das Entwicklerteam selbst: agiles Arbeiten beruht im Grunde auf einer hochentwickelten Selbstführung. Die Teammitglieder können idealerweise die Verantwortung für Kunden, Firma, Aufgaben und sich selbst austarieren.
Wie anwenden?
Führungskräfte können diese beiden Rollen auch mal explizit getrennt darstellen: „Als Vertreterin unserer Firma muss ich von Ihnen verlangen, dass…, weil…“ und „Als Teamleiterin bin ich besorgt und möchte Sie gerne unterstützen, damit Sie… schaffen“. Manch innerer Spagat, der stressend wirkt, kann so nach außen sichtbar gemacht und entschärft werden.
Auch in Projekten kann es eine Idee sein, diese beiden Führungsrollen getrennt zu vergeben.
Grenzen & Risiken?
Der Product Owner kann mit zu viel Macht agieren und die Selbstverantwortlichkeit des Teams stören. Oder er wird von Firmenseite mit zu wenig Entscheidungsmacht ausgestattet, so dass er keine verbindlichen Zusagen machen kann.
Ein Scrum Master braucht ein gutes Fingerspitzengefühl, um die richtigen Unterstützungspunkte zu finden. Er sollte wie ein Gruppencoach agieren und nicht wie ein Hausmeister.
Nach der reinen Lehre sollten die Elemente nur ganzheitlich verwirklicht werden. Und in der Tat: die Aspekte ergänzen sich. Die enge Kundenbeziehung ergibt zusammen mit dem iterativen Vorgehen Sinn. Dieses lässt sich verwirklichen durch Sprints, die wiederum ein empowertes Team und neue Führungsrollen und Arbeitstools wie Scrum und Kanban brauchen. Ich meine dennoch, dass auch einzelne Ansätze Nutzen bringen können, und das „Anfangen – Machen – Testen – Auswerten“ dazu steht ja in bester agiler Tradition!