Back to the future – eine Zeitreise in die Zukunft der agilen Softwareentwicklung
Alle sind heute agil. Sagen sie zumindest. Und viele glauben das wirklich. Bei näherer Betrachtung sieht es aber oft ganz anders aus: Standups oder Dailys dauern ewig oder finden nur selten statt, gearbeitet wird zwar in Sprints oder Iterationen, der Kunde interessiert sich aber sowieso nur für das Ergebnis nach einem halben Jahr oder später. Die Entwickler nervt der "Overhead" des Sprintwechsels, zu den Reviews erscheinen keine Stakeholder, die Retrospektiven produzieren keine Veränderung. Selbst bessere agile Implementationen haben oft nach wie vor das Problem von hoher Last und großem Druck, weil die Backlogs so voll, die Zeit so knapp, die Kunden so fordernd sind und das Management so viel verspricht.
Durchwursteln 2.0?
Diese Vorgehensweise nenne ich "Durchwursteln 2.0". Sie erinnert zuweilen an die Erinnerungen von Programmierern alter Schule, die auf Zuruf der Fachabteilungen entwickelt haben. Manche davon fragen sich noch heute, was daran schlecht gewesen sein soll. Manche bestimmt sogar zu recht, denn möglicherweise war ihr Verhalten des Entwickelns auf Zuruf genau das angemessene Verhalten für die damalige Situation.
Welches Problem wollen wir eigentlich lösen?
Die erste Frage an jeden, der sich mit agiler Softwareentwicklung beschäftigt, sollte lauten: Welches Problem willst du lösen? Das Agile Manifest ist uns an dieser Stelle nur eine unzureichende Hilfe. Der Anfang des Manifests sagt mit "We are uncovering better ways of developing software by doing it and helping others do it" nicht, welches Problem wir lösen wollen, sondern nur, dass es darum geht bessere Wege der Softwareentwicklung zu finden.
In meinen Gesprächen mit Kunden kristallisieren sich die folgenden Erwartungen an die Einführung Agiler Methoden heraus:
- schneller werden,
- flexibler werden,
- zuverlässiger in Lieferung und Planung werden,
- die richtigen Produkte herstellen.
Besser wäre in diesem Sinne also schneller, flexibler, zuverlässiger oder passendere Software zu entwickeln.
Wie lösen Agile Methoden diese Probleme?
Angesichts dieser Herausforderungen stellt sich die berechtigte Frage, ob und wie Agile Methoden einen Beitrag leisten.
Schneller werden agile Teams je nach Ausgangsgeschwindigkeit nicht so einfach, wie sich das viele Manager wünschen würden. Der Wirkmechanismus zur Beschleunigung basiert auf mindestens folgenden vier Effekten:
- Schnelleres Feedback zur Qualität durch Entwickeln ganzer Features, sodass später weniger Nacharbeiten und Bugs zu erledigen sind.
- Die Retrospektiven sind Teil eines kontinuierlichen Verbesserungsprozesses, der auch (aber eben nicht nur) die Beschleunigung der Entwicklung zum Inhalt hat. Dabei verbessert das Team selbst aus seinen Erfahrungen den Prozess.
- Agile Teams arbeiten meist störungsfreier und fokussierter. In Scrum hilft die Rolle des Scrum Masters diesen Fokus herzustellen und gegenüber der Organisation zu verteidigen. Dieser Vorteil ist in gewisser Weise unfair, weil klassische Teams ihn auch haben könnten. Es fällt in der Praxis trotzdem auf, dass agile Teams ihn konsequenter und häufiger nutzen. (Und ja, es gibt natürlich agile Teams, die noch nicht genug Fokus haben.)
- Haupthebel der Beschleunigung ist die richtige Auswahl der zu entwickelnden Features. Die Beschleunigung erfolgt quasi durch das Weglassen der falschen, nicht benötigten Features und gar nicht durch schnellere Entwicklung der gewollten, richtigen Features.
Flexibler im Umgang mit Veränderungen, insbesondere auch bzgl. der inhaltlichen Ausgestaltung der zu erstellenden Software, sind agile Teams vor allem durch die folgenden Effekte:
- Die Software wird inkrementell erstellt, also Feature für Feature. Das hat den großen Vorteil, dass nach jedem fertiggestellten Feature neu entschieden werden kann, welches Feature als nächstes entwickelt werden soll. Dies erfolgt bei agiler Vorgehensweise in zeitlich kurzen Zyklen wie mehreren Tagen oder wenigen Wochen. Es setzt voraus, dass die Features entsprechend klein genug definiert werden.
- Bei Agilen Methoden wird detailliert nur für sehr kurze Zeiträume bis max. vier Wochen geplant. Das erhöht die Flexibilität, weil so kein Aufwand für das Detaillieren von Features investiert wurde, die vielleicht gar nicht mehr oder anders benötigt werden.
- Letztlich trägt zur Flexibilisierung die Einstellung bei, dass sich gar nicht alles weit im Voraus festlegen lässt, sondern sich stattdessen viele Erkenntnisse erst unterwegs während der Entwicklung ergeben werden. Genau dies kennzeichnet ja komplexe Umfelder.
Zuverlässiger liefern agile Teams vor allem aus den folgenden Gründen:
- Ausliefern von Features ist oberstes Ziel und steht spätestens am Ende jeder Iteration bzw. jedes Sprints an. Dadurch wird das Ausliefern und die damit verbundenen Tätigkeiten so oft durchgeführt, dass sie zum einen gut eingeübt (und damit beherrscht) und zum anderen (teilweise) automatisiert werden.
- Die Entwicklung selbst wird in Features, also kleineren Einheiten gedacht und geplant. Dadurch ist die Differenz oder das Delta zwischen zwei Lieferungen geringer, was die Lieferung einfacher macht und bei eventuellen Problemen die Menge an Änderungen, die überprüft werden müssen, als Ursache der Probleme kleiner und überschaubarer macht.
- Die konkrete Planung erfolgt auf der Ebene einzelner Iterationen oder Sprints, was Teams kleine und überschaubare Zeiträume von bis zu maximal vier Wochen gibt, für die detailliert geplant wird. So ein Zeitraum ist leichter zu überschauen und damit die Leistungsfähigkeit des Teams für diesen Zeitraum realistischer zu schätzen als für längere Zeiträume. Das verbessert die Planung und so die Chance, dass die Planung tatsächlich zutrifft. Von dieser besseren Einschätzung im Kleinen, kann die Planung im Großen profitieren, die so auch realistischer wird.
- Das Denken und Arbeiten in einzelnen Features führt dazu, dass die Lieferung nicht als gescheitert angesehen wird, nur weil eines der Features nicht fertiggestellt wird. Somit behindern also die Arbeiten sich nicht wechselseitig, sondern die Lieferfähigkeit bleibt immer erhalten, auch wenn der Umfang ggf. noch nicht ganz dem erwarteten entspricht.
Passendere Software darf von agilem Vorgehen vor allem dank folgender Effekte erwartet werden:
- Es gibt viele kleine Feedback-Schleifen, die dafür sorgen, dass Anwender, Kunden, Stakeholder eingebunden werden und den bisherigen Stand der Entwicklung sehen und kommentieren. So wird früh erkannt, ob unbrauchbare, falsche oder unnütze Features gebaut wurden oder noch weitere Features benötigt werden.
- Das Feedback befördert nicht nur das Erkennen von Fehlentwicklungen, sondern erlaubt zusätzlich das Lernen und Anpassen an geänderte Umfelder noch während der Entwicklung. So erhalten Kunden nicht die Software mit dem Stand von vor zwei Jahren, sondern Software, die aktuelle Veränderungen direkt und schnell berücksichtigt.
Zu welchem Preis lösen Agile Methoden diese Probleme?
Entgegen zuweilen anderer Erwartungen, kommen diese Vorteile für die meisten Organisationen zu einem Preis, dessen Höhe im Vorhinein nur schwer abgeschätzt werden kann. Dieser Preis besteht aus einer Reihe Veränderungen, die in der Organisation neben der reinen Einführung der agilen Mechanik notwenig wird. Ansonsten ergeben sich die Vorteile nämlich nicht. Zu diesen Veränderungen gehört im Wesentlichen ein geändertes Mindset, dass nicht nur Mitarbeiter betrifft, sondern auch Management und Fachseite umfasst. Konkret erleben wir mindestens die folgenden vier Veränderungen als Herausforderungen für Organisationen:
- Offenheit und Transparenz herstellen – die agilen Teams (und ihre Product Owner!) brauchen zum einen Zugang zu Informationen, um gute Entscheidungen selbst treffen zu können; zum anderen muss die Organisation lernen, mit nicht so guten offenen Informationen aus den agilen Teams umgehen zu können, ohne schnell in einen Panik-, Retter- und Mikromanagement-Modus zu verfallen.
- Lernen muss erlaubt und erwünscht sein – so lernen agile Teams schnell über ihre eigene Leistungsfähigkeit und die Bedürfnisse der Kunden, dies führt aber zu Veränderungen ursprünglicher Annahmen, auf deren Basis Pläne erstellt wurden. Diese Pläne müssen dann sinnvollerweise entsprechend des neuen Wissensstands angepasst werden. Das Lernen gelingt nur, wenn Fehler im System nicht zu Bestrafung führen, solange aus den Fehlern gelernt wird (und nicht immer wieder die selben Fehler gemacht werden).
- Manager sind für die Umgebung und die strategische Ebene außerhalb des Tagesgeschäfts zuständig. Mikromanagement ist schädlich in agilen Kontexten. Zuweilen existiert im Management Angst davor, überflüssig zu werden. Diese Angst ist zumeist unbegründet. Vielmehr können sich Manager im agilen Kontext mehr auf ihre Kernaufgaben konzentrieren: Richtung vorgeben, Personal entwickeln, Umgebung optimieren.
- Fokus herstellen – die meisten Organisationen leiden heute unter extremen Verzetteln. Zu viele Projekte werden gleichzeitig durchgeführt, neue Projekte gestartet bevor laufende fertig sind. Selbst die Anzahl strategischer Ziele und Maßnahmen liegt gern im zweistelligen Bereich. Für erfolgreiches agiles Arbeiten ist eine große Disziplin und Fokussierung notwendig, auch wenn das für viele kontra-intuitiv klingen mag: Wenn Agilität nicht Durchwursteln 2.0 sein soll, braucht sie Fokussierung. Ein guter Teil der positiven Wirkung basiert auf Fokus, der zugegebenermaßen auch nicht-agilen Umfeldern gut tun würde.
Zu diesen Herausforderungen im Rahmen von agilem Vorgehen kommt die allgemeine Herausforderung hinzu, die sich aus Veränderungen im Vorgehen für die meisten Organisationen ergeben.
Eine kurze Rückbesinnung
Als ich Ende der 90er Jahre über eXtreme Programming zu agiler Softwareentwicklung kam, gab es den Begriff "agil" noch gar nicht. Stattdessen sprach man von "leichtgewichtigen Methoden". Sie standen im Gegensatz zu den schwergewichtigen und dokumenten-getriebenen Prozessen der damaligen Zeit, die alle mehr oder weniger wasserfallartig gestaltet waren. Die agile Bewegung hat sich ihren Namen und ihr Ziel mit dem Agilen Manifest im Jahr 2001 gegeben.
Rund um das Agile Manifest existieren immer noch sehr viele Missverständnisse, insbesondere was die Werte auf der rechten Seite der Wertepaare angeht. Auch in agilen Projekten kommen Prozesse und Werkzeuge zum Einsatz. Man kann selbst auf Scrum als einen Prozess schauen (auch wenn es eher ein Prozessframework ist). Trotzdem leben agile Teams einen Prozess. Das Wertepaar soll nur verdeutlichen, dass wir bereit sind, an unserem Prozess etwas zu verändern und ihm nicht stur folgen. Wenn er also für die Individuen nicht funktioniert oder wichtige Interaktionen hilfreicher wären für den Fortschritt, weichen wir vom Prozess ab.
Ähnlich verhält es sich mit der Dokumentation: Wir wollen nicht grundsätzlich auf Dokumentation verzichten. Wir glauben nur, dass ausgelieferte (dokumentierte) Software mehr Wert hat, als ein Stück Dokumentation.
Vertragsverhandlungen schaffen einen Rahmen, auch für agile Vorhaben. Wir wollen aber keine Verträge, die im Voraus alle Eventualitäten klären (und damit das Lernen während der Vertragslaufzeit zur Störung machen), sondern solche, die uns eine gute partnerschaftliche Zusammenarbeit mit den Kunden erlauben.
Und schließlich folgen auch agile Teams Plänen. In Scrum wird zu Beginn jedes Sprints geplant (aber eben auf dieser Konkretisierungsebene nur für den anstehenden Sprint), auch agile Projekte haben Releasepläne. Wir wollen nur nicht Pläne als ein so enges Korsett verstehen, dass Lernen und Veränderungen nicht mehr erlaubt sind. Im Lernen unterwegs liegen die großen Chancen, bessere und passendere Software für die Kunden zu bauen (als die ursprünglich geplante).
Was also konkret tun für die agile Zukunft?
Um eine gute agile Zukunft zu gestalten, müssen wir heute gemeinsam handeln. Dazu gehört eine Rückbesinnung darauf, wofür Agile Methoden einmal angetreten sind: Wege zu finden, wie es besser geht. Diese Reise wird nie zu Ende sein.
Viele Manager, Führungskräfte und Mitarbeiter haben bereits angefangen. Wer noch nicht recht weiß, was er (allein) konkret tun kann, dem sind die folgenden Abschnitte gewidmet. Die wichtigsten Aspekte agilen Handelns sind meines Erachtens:
- Liefern,
- Inspizieren und Anpassen auf Produkt- und Prozessebene,
- Fokus (wo liegt der Wert?),
- Pragmatisch sein, weder dogmatisch noch beliebig,
- Veränderungen durchführen, mit Experimenten Neues ausprobieren.
Mit verlässlichen Lieferungen wertvoller Produktinkremente kann Vertrauen erreicht werden, das ein Umfeld begünstigt, in dem pragmatische Veränderungen möglich sind, die auf in Experimenten gewonnenen Fakten basieren.
Auf Konferenzen und in Schulungen erlebe ich oft, dass Mitarbeiter sagen, sie würden gern agiler arbeiten, aber das Management würde sie nicht lassen. Ich höre gleichzeitig von Managern, sie würden gern agiler arbeiten, aber ihre Mitarbeiter würden nicht wollen. Dabei kommen Mitarbeiter und Manager aus der selben Firma! Ich habe schon darüber nachgedacht, ob ich eine Datingplattform für agil-willige Mitarbeiter und Manager bauen sollte! Hinter der Komik dieser Situation steckt eine wichtige Erkenntnis: Jeder nimmt an, der Andere müsste den ersten Schritt gehen. Jeder kann den ersten Schritt machen und niemand sollte sich von anderen aufhalten lassen.
Was Manager jetzt tun sollten
Liefern: Als Manager ist es essentiell, dass ich so klar wie möglich vermittle, was eigentlich geliefert werden soll. Welches Ergebnis erwarte ich? Ich sollte dabei deutlich machen, welchen Wert das Liefern für uns als Unternehmen hat. Erfolgt die Lieferung, ist es wichtig, dass damit für die Mitarbeiter eine entsprechende Anerkennung einhergeht. Dabei meine ich weniger Boni oder Gehaltserhöhungen, sondern vor allem eine persönliche Anerkennung der Leistung.
Inspizieren und Anpassen auf Produkt- und Prozessebene: Kent Beck, der Vater der Agilen Methode eXtreme Programming (XP), hat für sein Buch zu XP den schönen Untertitel "Embrace Change" gewählt, also "Änderungen willkommen heißen". Genau dafür steht Inspizieren und Anpassen im Kern agiler Vorgehensweisen. Für Manager bedeutet dies vor allem eine geeignete Umgebung dafür zu schaffen. Sich also von der Vorstellung verabschieden, dass alles gleich beim ersten Mal perfekt sein wird. Es bedeutet, Irrtümer zuzulassen. Das glauben die meisten Mitarbeiter vermutlich erst, wenn sie einmal erlebt haben, dass es keine Strafen oder Nachteile gibt, wenn ein Fehler gemacht und zugegeben wurde. Für den Manager heißt dies vor allem, mit gutem Beispiel voranzugehen: Eigene Mängel und Defizite offen legen und systematisch aus ihnen lernen. Es ist sinnvoll, wenn man als Manager nicht die Fehler, sondern das Lernen aus Fehlern lobt.
Fokus (wo liegt der Wert?): Fokussierung ist in vielen Organisationen nicht nur insgesamt, sondern für jeden einzelnen Mitarbeiter sehr schwierig. Jede neue Aufgabe oder Initiative kommt zur bisherigen Arbeit hinzu, nur selten wird im Tausch etwas anderes dafür weggelassen. Manager können hier für sich und ihre Mitarbeiter Großes leisten, wenn sie sehr klar in den Prioritäten sind: Was genau wollen wir in diesem Monat/Quartal/Jahr erreichen? Wie wichtig ist die neue Herausforderung im Verhältnis zu den bisherigen Aufgaben? Was darf jetzt entfallen oder reduziert werden?
Pragmatisch sein, weder dogmatisch noch beliebig: Die Balance zwischen Dogma und Beliebigkeit zu finden, ist eine sehr individuelle Herausforderung, sowohl für das Unternehmen als auch für einzelne Mitarbeiter oder Manager. Gleichzeitig bietet dieses Spannungsfeld eine gute Gelegenheit, miteinander ins Gespräch zu kommen. Pragmatische Manager können mit ihren Mitarbeitern diskutieren wie es einfacher ginge, wenn man sich von der bisherigen Prozessbefolgung entfernt. Der Beliebigkeit wirken dabei die Konzentration auf das Liefern und die Fokus-Themen entgegen.
Veränderungen durchführen, mit Experimenten Neues ausprobieren: Veränderung auf Basis von Experimenten ist empirisches Management. Das überzeugt jeden, der Fakten für eine wichtigere Grundlage für Entscheidungen hält als Meinungen. Als Manager kann man z. B. die Meinungen oder Befürchtungen der Kollegen ernst nehmen und statt einer von oben beschlossenen Veränderung ein Experiment durchführen. Im besten Fall zeigt es die gewünschte Wirkung und überzeugt. Oder es bewahrheiten sich die Befürchtungen. In beiden Fällen werden wir etwas lernen, sodass wir entweder ein weiteres Experiment entwerfen oder endgültig wissen, dass eine bestimmte Idee für uns nicht funktioniert.
Was Mitarbeiter jetzt tun sollten
Liefern: Als Mitarbeiter scheint ziemlich offensichtlich, was zu tun ist: Liefern bedeutet, konkrete Ergebnisse zu erzielen. Das mag im Einzelnen in Anbetracht der Aufgabenteilung im Unternehmen schwierig sein, weil man vielleicht nur ein sehr kleines Rädchen im Gesamtprozess ist und nur in einem geringen Maße zum Gesamtergebnis beiträgt. Gerade dann ist es umso wichtiger, dass man sich klarmacht, welchen Anteil man am Gesamtergebnis hat, wie man diesen optimieren kann und mit anderen, z.B. den Kollegen der vor- oder nachgelagerten Prozessanteile, ins Gespräch kommt.
Inspizieren und Anpassen auf Produkt- und Prozessebene: "Änderungen willkommen heißen" schreibt der Kent Beck also. Auch für Mitarbeiter ist ein Vorgehen von Inspizieren und Anpassen in kleinerem Maße ohne Managementunterstützung und -erlaubnis möglich. Schließlich ist das gleichzeitig eine wundervolle Risikominimierungsstrategie. Wenn man als Mitarbeiter ausreichend viel darüber spricht, was man in kleinen Veränderungen gelernt hat und dadurch an der eigenen Vorgehensweise verbessern konnte, bekommt man über kurz oder lang sowohl mehr Kollegen als auch Manager ins Boot.
Fokus (wo liegt der Wert?): Mitarbeiter können ihre Manager beim Fokussieren unterstützen und sich selbst helfen, indem sie einen klaren Fokus einfordern. Selbst für die eigene Arbeitsorganisation kann sich dies auszahlen. Im Optimalfall kann jeder Manager und jeder Mitarbeiter für jede seiner Tätigkeiten angeben, warum sie gerade im Fokus liegt. In der Regel mögen Mitarbeiter einem sinnvollen Fokus auf die Erhöhung des Kundennutzens oder auf Optimierungen fürs Unternehmen eher folgen, als abstrakten Konzepten wie höherer Regelkonformität oder Zielen, die dem Chef den Bonus sichern.
Pragmatisch sein, weder dogmatisch noch beliebig: Für die Balance zwischen Dogma und Beliebigkeit können Mitarbeiter hervorragend pragmatische Lösungen wählen, die vom Standardprozess im Unternehmen abweichen und dies entweder nachträglich oder im Vorwege mit ihrem Manager diskutieren. Der Beliebigkeit wirken dabei die Konzentration auf das Liefern und die Fokus-Themen entgegen.
Veränderungen durchführen, mit Experimenten Neues ausprobieren: Mitarbeiter können Experimente im Kleinen verwenden und werden von ihren Managern dafür vermutlich leichter grünes Licht bekommen als für größere gewünschte Veränderungen. Letztlich haben viele agile Transitionen so ihren Anfang genommen: Ein Team von Mitarbeitern hat darum gebeten, es einmal ausprobieren zu dürfen. Wichtig ist, dass man ehrlich die Ergebnisse ans Management kommuniziert und diese nicht den Eindruck haben, sie sollen manipuliert werden.
Abschluss
Wir wollen schneller, flexibler und zuverlässiger dabei werden, passendere Software zu entwickeln. Wir haben gesehen, mit welchen Mitteln agile Ansätze dazu beitragen können. Agilität hat seinen Preis und sollte nicht als ein Allheilmittel der Entwicklung verstanden werden. In der Rückbesinnung stellen wir fest, worum es seit der Erstellung des Agilen Manifests ging: Bessere Wege finden, um zum Vorteil der Kunden Software zu erstellen.
Auf dieser Reise befinden sich heute viele, manche erleben dabei Erfolgserlebnisse, andere großen Frust, auch weil das Gelände nicht so ist, wie sie es sich wünschen würden. Handlungsfähig ist jeder von uns, vor allem, wenn wir hungrig bleiben und die Reise immer weiter fortsetzen wollen. Ich wünsche uns dabei gutes Gelingen!
