Ein durchaus aktueller IT-Witz lautet: Wer Scrum rückwärts liest, erkennt, welche Ergebnisse man damit erhält. Doch ist das wirklich so? Wie sehen das Profis agiler Software-Entwicklung?

Dr. Wolfgang Brandhuber ist seit mehr als zehn Jahren in agilen Projekten tätig. Neben der Leitung mehrerer agiler Projekte war er Entwickler, Product Owner, Scrum-Master und Chief Scrum-Master in verschiedenen Scrum-Projekten. Als selbständiger Berater hat er darüber hinaus geholfen, agile Entwicklung in Start-ups und Großprojekten einzuführen. Wir haben mit ihm über das Gelingen agiler Projekte gesprochen.

Informatik Aktuell: Wie gelingt agile Softwareentwicklung? Was ist dazu nötig?

Wolfgang Brandhuber: Wenn das Management Agilität für sich entdeckt hat, um selbst jeden Tag ein bisschen besser zu werden. Die Agilität, die das Management jeden Tag vorlebt, ist die harte Grenze für die Agilität des gesamten Projekts. Von den Projektmitarbeitern mehr zu erwarten als vom Management wäre so, wie zu hoffen, dass ein Orchester besser spielt als es das musikalische Verständnis des Dirigenten hergibt.

Mittlerweile ist das veröffentlichte Wissen über agile Entwicklung so umfangreich, dass selbst ein kompletter Studiengang kaum ausreichen würde um alle Aspekte zu beherrschen. Trotzdem ist es nach wie vor üblich, Projekte von Managern leiten zu lassen, die gerade mal eine Scrum-Master-Zertifizierung vorweisen können und teilweise noch nicht mal das. Bei Führungskräften eine solide Ausbildung mit Berufserfahrung vorauszusetzen und sie zu verpflichten, ihre Mitarbeiter selbst in agilen Methoden zu schulen und zu coachen, ist nach meiner Erfahrung der beste Nährboden für erfolgreiche Agilität.

Informatik Aktuell: Welche Ausbildung sollten Kollegen im Management denn idealerweise haben, um agile Projekte zu leiten? Und welche persönlichen und menschlichen Eigenschaften sind erforderlich?

Wolfgang Brandhuber: Meiner Meinung nach sollte ein agiler Projektleiter drei Voraussetzungen erfüllen:

Erstens sollte er durch Zertifizierungen nachweisen, dass er sich mit agilen Methoden auseinander gesetzt hat. Die üblichen Scrum-Master-Zertifizierungen wären ein Beispiel, wobei sie aus meiner Sicht aber nur vergleichbar sind mit den Regelkundeprüfungen beim Fußball. Sie zeigen also nicht, ob man Fußballspielen kann, aber zumindest kennt derjenige dann die Spielregeln, was in einigen agilen Projekten schon erheblich weiterhelfen würde. Wer ernsthaft an agilen Methoden interessiert ist, sollte auch weiterführende Zertifikate vorweisen können, wie zum Beispiel den Certified Scrum Professional, Zertifizierungen aus dem Lean-Bereich und anderen agile Methoden. Im skalierten Umfeld, also in Projekten mit zwei oder mehr Teams, sollten Projektmanager auch nachweisen, dass sie sich mit den gängigen Frameworks beschäftigt haben, um Agilität zu skalieren. Eine Zertifizierung im Scaled Agile Framework, Large Scale Scrum und Management 3.0 würden unterstreichen, dass man weiß, wovon man spricht.

Zweitens ist im agilen Bereich persönliche Erfahrung sehr wichtig – meiner Meinung nach wesentlich wichtiger als im klassischen Projektmanagemet. Jemand der ein agiles Projekt leitet, sollte also schon einige Erfahrung als Mitglied eines selbstorganisierten Teams mitbringen. Ein Scrum-Projekt zu leiten und selbst nie als Scrum-Master, Product Owner oder Entwickler in einem Scrum-Team gearbeitet zu haben, reduziert nicht nur die persönliche Glaubwürdigkeit, sondern erschwert das Einfühlungsvermögen in die Herausforderungen und Probleme des agilen Arbeitsalltags enorm.

Drittens sollte ein agiler Projektleiter für alle im Projekt ein Vorbild durch Leistung sein und nicht – wie im klassischen Projektmanagement oft üblich – auf seiner Position durch Protektionismus und Besitzstandwahrung beharren. Wie der Kapitän einer Fußballmannschaft ist es für einen agilen Projektmanager wichtig, jeden Tag seine Position durch persönliche Leistung untermauern zu wollen. Er sollte von sich aus seine eigene Leistung messbar machen, um sie mit der Leistung seiner Kollegen vergleichen zu können. Und er sollte emotional erwachsen sein, also eine Persönlichkeit besitzen, die groß genug ist, um seine eigenen Gefühle nicht auf andere projizieren zu müssen oder andere für die eigenen Gefühle verantwortlich zu machen.

Idealerweise sollte das Management eines agilen Projekts von allen Projektmitgliedern gewählt werden, so wie es auch Craig Larman in Large-Scale Scrum vorschlägt. Dadurch wäre das Management – so wie in den agilen Methoden gefordert – automatisch der Dienstleister, um die Arbeit der Teams zu koordinieren und zu optimieren.

Informatik Aktuell: Immer wieder gibt es auch agile Projekte, die scheitern. Ein IT-Witz baut sogar darauf auf, dass man Scrum nur mal rückwärts lesen müsse, um zu wissen, was davon zu halten sei. Woran liegt es denn, dass auch immer wieder Projekte schief laufen?

Wolfgang Brandhuber: Gründe für das Scheitern von Scrum-Projekten gibt es jede Menge. Nach meiner Erfahrung lassen sie sich aber meistens in zwei Kategorien einteilen: Zum einen werden die Feedback-Zyklen oft nicht verstanden oder nicht genutzt und zum Anderen passen viele lieber das Projekt ihren Fähigkeiten an als ihre Fähigkeiten dem Projekt.

Um uns selbst in Teams zu organisieren, müssen wir erst mal Muskulatur dafür aufbauen

Scrum ist zunächst mal kein Werkzeug, um besser oder schneller zu arbeiten. Scrum holt die Probleme und den Arbeitssumpf an die Oberfläche, um allen Beteiligten die Möglichkeit zu geben, gemeinsam Lösungen dafür zu finden. Und das bedeutet in den meisten Fällen, alte Gewohnheiten hinter sich zu lassen und ungewohntes Terrain zu betreten. Ken Schwaber, einer der beiden Scrum-Väter, nennt das "Against the Muscle Memory". Jeder in unserer Gesellschaft kennt die Regeln, nach denen Hierarchie gespielt wird. Um in der Schule oder im Studium klar zu kommen, müssen wir sie aus dem Effeff beherrschen. Und viele haben auch in Projekten Jahre ihres Lebens in Hierarchien verbracht. Um uns selbst in Teams zu organisieren, müssen wir erst mal Muskulatur dafür aufbauen. Vor allem für die Kollegen in vorgesetzten Positionen ist das besonders schwer, weil sie in selbstorganisierten Teams erst mal viel von ihrer Daseinsberechtigung verlieren.

Aber agile Entwicklung setzt auch viele handwerkliche Fähigkeiten voraus, die jeder Schritt für Schritt verstehen und trainieren muss. Was genau machen gute User Stories und Story Maps aus? Wie funktioniert agiles Requirement Engineering und agiles Schätzen? Was genau ist Acceptance Test-Driven Development [1], Testautomatisierung, Continuous Integration, Continuous Deployment und was hat das mit eXtreme Programming und DevOps zu tun? Was ist das Geheimnis von Lean und Kanban? Und worauf muss ich achten, wenn ich agile Projekte skaliere, wenn also mehrere Teams in einem Projekt zusammenarbeiten müssen? Wenn ein selbstorganisiertes Team Entscheidungen über seinen Arbeitsalltag trifft, muss jeder im Team diese Zusammenhänge kennen und verstehen. Für das Management gilt das in einem noch viel höheren Maße. Um für die Entwicklungsteams die Rolle des "Servant Leaders" ausfüllen zu können, muss jeder diese Konzepte verstanden und verinnerlicht haben, um tragfähige Entscheidungen treffen zu können, die für alle Teams verbindlich sind.

Der andere Problembereich sind die Feedback-Zyklen. Scrum hat jede Menge davon und nimmt – verglichen mit Wasserfall-Projekten – dafür auch viel Overhead in Kauf. Bei den Retrospektiv-Zyklen ist das für die Scrum-Teams oft am schnellsten und schmerzhaftesten zu spüren. Scrum schreibt vor, dass sich jedes Team am Ende einer Iteration zusammensetzen muss, um sich darüber zu unterhalten, was im vergangenen Sprint nicht so gut lief und was im nächsten Sprint verbessert werden könnte. Oft schon nach kurzer Zeit verlieren viele die Lust auf diese Meetings, weil nur wenige Ideen umgesetzt und nachhaltig verfolgt werden. Die identifizierten Probleme aber nicht anzugehen, demotiviert die Mitarbeiter oft noch mehr, als ihnen erst gar keine Möglichkeit zu geben, darüber zu sprechen. Was für die Retrospektive gilt, gilt im Grunde für jedes Event in Scrum, egal ob Sprint Planning, Daily Scrum, Sprint Review oder andere Good Practices wie Backlog-Refinement oder Scrum of Scrums.

Der meiste Schaden wird aber in aller Regel damit angerichtet, dass die Verantwortlichen die zwölf Prinzipien des agilen Manifests nicht beachten und das erste und das siebte Prinzip ignorieren: "Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen." und "Funktionierende Software ist das wichtigste Fortschrittsmaß. [2]"

Mit Scrum wird nicht notwendigerweise mehr Software produziert als mit herkömmlichen Methoden. Ich kann durch die Feedback-Zyklen aber sehr viel genauer das programmieren, was der Kunde am Ende wirklich braucht. Dazu muss ich die Software dem Kunden aber auch regelmäßig zur Verfügung stellen, um Feedback zu bekommen. Am besten am Ende jedes Sprints, um ihm die Möglichkeit zu geben, sie auszuprobieren und selbst Erfahrungen damit zu sammeln. Diese Erfahrungen und Ideen müssen so schnell und so direkt wie möglich wieder zurückfließen in die Planung der nächsten Inkremente. Software einfach nur inkrementell zu programmieren bringt keinen Gewinn, wenn diese Art zu arbeiten nicht die Grundlage für Feedback-Zyklen ist, die das gesamte Projekt steuern.

Informatik Aktuell: Wenn ich meine Softwareentwicklung von Wasserfall auf agile Entwicklung umstellen möchte, was sind die wichtigsten Punkte, die ich dabei beachten muss?

Wolfgang Brandhuber: Die Unterschiede zwischen Wasserfall und agiler Entwicklung lassen sich grob in drei Bereiche einteilen: Iterativ, inkrementell und selbstorganisierend. Inkrementell ist von diesen drei Punkten in aller Regel am einfachsten umzusetzen und bedeutet im Grunde nichts anderes, als dass zu einem bereits bestehenden Produkt noch etwas hinzugefügt wird. Softwareprojekte arbeiten also von vorne herein inkrementell, weil sie mit jedem Release zu einer bestehenden Software neue Features hinzufügen. Im Unterschied zur agilen Welt sind diese Zeitspannen aber oft sehr lang und die Inkremente sehr groß. Während in der traditionellen Entwicklung Release-Zyklen in aller Regel Monate oder Jahre dauern, liefert die agile Entwicklung innerhalb weniger Wochen fertige Inkremente. Um kontinuierlich in diesen stark verkürzten Zeitspannen liefern zu können, müssen neue Werkzeuge eingeführt und neue Fähigkeiten erlernt werden. Vielleicht muss sogar der gesamte Entwicklungsprozess umgekrempelt werden. Aber diese Umstellungen sind gut planbar und stellen zumeist keinen all zu großen Bruch zur bisherigen Vorgehensweise dar.

Iterative Arbeitsweisen einzuführen ist schon deutlich herausfordernder und genau an diesem Punkt scheitern auch schon viele hochtrabende Pläne, mit agiler Entwicklung schneller, besser und mehr zu liefern. Iterativ bedeutet in der agilen Entwicklung, dass das genaue Ziel nicht von vorne herein bekannt ist, sondern dass sich das Projekt Schritt für Schritt einer Lösung annähert, indem die Erkenntnisse aus jeder Iteration in die Planung der nächsten Iteration mit einfließen. In Iterationen zu arbeiten bedeutet Feedback-Zyklen zu etablieren und die Ergebnisse dieser Zyklen kontrolliert in die Projektsteuerung einfließen zu lassen. Reviews und Retros, wie Scrum sie vorschreibt, sind nur verschwendete Zeit, wenn die Ergebnisse aus diesen Meetings nicht direkten Einfluss auf die unmittelbar nächsten Arbeitszyklen haben. Für einige Manager ist die Umstellung von ihrem persönlichen Bauchgefühl zu wissenschaftlichen Methoden der Projektsteuerung aber schon zu viel Kontrollverlust.

Wenn alle drei Stufen – inkrementell, iterativ und selbstorganisierend – gemeistert werden, ist ein Projekt auf jeden Fall agil

Die Umstellung von hierarchischen Strukturen zu selbstorganisierten Teams ist im Verhältnis dazu aber nochmal sehr viel schwieriger. Solange die Vorgesetzten nicht bereit sind, Kontrolle abzugeben, werden sich Teams nicht selbst organisieren. Erst wenn die Personen an der Spitze bereit sind, sich selbst Regeln aufzuerlegen, die ihre Macht einschränken, werden die Untergebenen damit beginnen, diese neuen Freiräume zu nutzen und erst dann kann Agilität ihren großen Mehrwert entfalten. Ohne Projektverfassung, die die Machtbefugnisse der einzelnen Beteiligten klar regelt, und ohne die persönliche Verpflichtung jedes einzelnen Managers, bestimmte Grenzen nicht zu überschreiten, werden die Teams nur das tun, was ihnen aufgetragen wird. Kreativität und Engagement fallen dann zentralen Entscheidungsstrukturen zum Opfer. Erst die dezentralen Entscheidungsstrukturen bringen den großen Vorteil gegenüber der Wasserfallentwicklung. Aber durch meine Gespräche mit anderen agilen Coaches stelle ich immer wieder fest, dass im Moment nur wenige Projekte bis zu diesem Punkt kommen.

Informatik Aktuell: Viele Projekte und Organisationen stellen von herkömmlichen Softwareentwicklungsmethoden auf agile Entwicklung um und befinden sich während der Übergangsphase in einer Grauzone. Ab wann kann ein Projekt von sich behaupten, agil unterwegs zu sein?

Wolfgang Brandhuber: Wenn alle drei Stufen – inkrementell, iterativ und selbstorganisierend – gemeistert werden, ist ein Projekt auf jeden Fall agil.

Am einfachsten lässt sich das mit einem projektweiten anonymen Fragebogen messen, auf dem jeder Mitarbeiter jedes Prinzip des agilen Manifests auf einer Skala von -5 bis +5 bewerten kann. Einmal online aufgesetzt kann diese Umfrage am Ende jedes Sprints schnell und einfach wiederholt werden.

Wenn zum Beispiel das dritte Prinzip "Liefere funktionierende Software regelmäßig innerhalb weniger Wochen oder Monate und bevorzuge dabei die kürzere Zeitspanne" im Durchschnitt schlecht abschneidet, ist das ein klarer Hinweis darauf, dass es noch Schwierigkeiten mit der Stufe "Inkrementell" gibt und dass die gemeinsamen Anstrengungen im Projekt darauf gerichtet werden sollten, diese erste Stufe in den Griff zu bekommen.

Das siebte Prinzip "Funktionierende Software ist das wichtigste Fortschrittsmaß" wäre ein Beispiel für die iterative Stufe. Läuft das Projektmanagement immer noch Fassadenmetriken hinterher, wie Eric Ries es nennt? Wird der Projektfortschritt immer noch in Story Points oder Mann-Tagen gemessen, oder wird die programmierte Software am Ende jedes Sprints wirklich auf einem Produktionssystem oder einem möglichst produktionsnahen System deployt und anhand einer soliden Wertschöpfungsmetrik gemessen?

In vielen Fällen wird vom Management lediglich ein agiles Etikett auf das Projekt geklebt, um Erwartungshaltungen der Vorgesetzten oder der Stakeholder zu befriedigen, ohne wirklich zu verstehen, was agile Entwicklung eigentlich bedeutet und ohne sich ernsthaft damit auseinandersetzen zu wollen. Mittlerweile ist das gesamte Gebiet der agilen Entwicklung allerdings so groß, dass es auch durch ein komplettes Hochschulstudium nicht mehr vollständig abdeckbar wäre. Ab und zu mal eine agile Schulung zu besuchen oder einen Artikel im Internet zu lesen, wäre vergleichbar mit einem Arzt, der versucht, Patienten mit Hilfe von Zeitschriftenartikeln zu behandeln.

Um die dritte Stufe "selbstorganisierend" zu meistern muss das Projektmanagement ein völlig neues Verständnis seiner eigenen Aufgaben und Befugnisse entwickeln und den Entwicklungsteams, die ja die eigentliche Wertschöpfung generieren, ihre Leistungen als  "Management as a Service" anbieten. Dazu ist viel Wissen, viel Erfahrung und vor allem eine große projektweite gemeinsame Anstrengung nötig. Durch die Überlegungen und Aktionen einer Handvoll Manager wird diese Stufe nicht zu meistern sein. Für den Reifegrad dieser dritten Stufe ist zum Beispiel das fünfte agile Prinzip ein guter Indikator: "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."

Wenn in dieser regelmäßigen Umfrage zum agilen Manifest die Durchschnittsbewertung aller zwölf Prinzipien im positiven Bereich liegt, kann ein Projekt aus meiner Sicht mit Fug und Recht von sich behaupten, agil zu sein, auch wenn es vermutlich selbst dann noch viel Luft nach oben gibt.

Informatik Aktuell: Welche Entwicklung erwarten Sie für das nächste Jahr? Was sind die neuen Themen agiler Softwareentwicklung?

Wolfgang Brandhuber: Neue Entwicklungen und vielversprechende Ansätze gibt es aus meiner Sicht im Moment einige. Holacracy zum Beispiel bietet Projekten und Organisationen einen Weg zu einer eigenen Verfassung, weg von klassisch hierarchischen Strukturen. Dieses Thema wird in Zukunft wohl noch deutlich mehr Aufmerksamkeit auf sich ziehen, denke ich. Auch die Management 3.0-Bewegung nimmt immer mehr Fahrt auf. Dabei geht es um das Mind Set, das jeder Manager braucht, damit sich Selbstorganisation entwickeln kann. Aber das sind alles Ideen, die helfen, die dritte Stufe zu meisten.

Viele Projekte und Organisationen hängen aber nach wie vor an der ersten Stufe: Inkrementelle Entwicklung. Die DevOps-Bewegung zum Beispiel bietet mittlerweile viele Hilfsmittel auf diesem Gebiet, die auch immer weitere Verbreitung finden. Auch "Acceptance Test-Driven Development" oder "Specification by Example" findet immer mehr Anklang, was stabileren Code und damit schnellere Code-Zyklen zur Folge hat. Story Maps, Impact Maps und Gamestorming helfen, Anforderungen transparenter zu machen und damit die Anforderungszyklen zu verkürzen. Das alles ist nur ein kleiner Ausschnitt aus der aktuellen agilen Landschaft und im Grunde nichts Neues, aber alles extrem wichtig, um den agilen Trampelpfad in eine Autobahn umzubauen und neue Standards zu definieren, an die sich Entscheider halten können, wenn sie auf dem agilen Weg voran kommen wollen. Ich denke, dass ein Großteil der agilen Welt sich im nächsten Jahr in diesem Bereich abspielen wird.

Der Leuchtturm der zweiten Stufe – Iterative Entwicklung – ist für mich nach wie vor "The Lean StartUp" von Eric Ries [3]. Die von ihm postulierten Prinzipien um Feedback-Schleifen aufzubauen und Projekte und Organisationen über diese Schleifen wissenschaftlich fundiert zu steuern, wären zwar für viele ein riesiger Schritt nach vorne, sind aber im Moment für die große Mehrheit, die auf dem agilen Weg pilgert, nichts weiter als ferne Zukunftsmusik. Klar juckt es mich in den Fingern in großen Unternehmen auch die dritte Stufe – Selbstorganisation – nach den neuesten Erkenntnissen der agilen Community sauber zu implementieren und selbst miterleben zu dürfen, aber dazu braucht es entweder jemanden mit viel Mut oder einem großen Leidensdruck. Bis sich die große Mehrheit diesem Punkt nähert, wird es vermutlich noch viele Jahre dauern.

Auch wenn mein aktueller persönlicher Plan für das kommende Jahr vor allem daraus besteht, agile Projekte auf den ersten Schritten zu begleiten, gebe ich die Hoffnung nicht auf, dass es immer mehr mutige Entscheider geben wird, die schon 2016 den großen Schritt wagen und mit ihrem agilen Projekt die zweite Stufe angehen und sich iterativ weiterentwickeln wollen. Die deutlich größere Wertschöpfung, die funktionierende Feedback-Zyklen und die Lean StartUp-Prinzipien [4] mit sich bringen, zu einem integralen Teil ihres Projektmanagements zu machen, wäre die Anstrengung in jedem Fall wert.

Informatik Aktuell: Vielen Dank für das Interview!

Die Fragen stellte Andrea Held.