Ausgabe 06/2016 - Schwerpunkt Einfach machen

Agiles Management

Schneller!

• Am Anfang war – wie so oft – das Wort: „Individuals and interactions over processes and tools.“ So steht es im sogenannten Agilen Manifest. Heißt: Menschen und ihr Austausch haben Vorrang vor Prozessen und Werkzeugen. Im selben Stil geht es weiter: Zusammenarbeit mit dem Kunden ist wichtiger als Vertragsverhandlungen. Reagieren auf Veränderungen wichtiger als das Befolgen eines Plans.

Eine Gruppe von Programmierern um Kent Beck verabschiedete dieses Manifest 2001. Es war der Ausdruck ihrer Frustration darüber, wie auf der ganzen Welt Projekte abgewickelt wurden – ob es dabei nun um Software ging oder nicht. Das typische Szenario damals: Auf Hunderten oder Tausenden von Seiten beschreibt ein Auftraggeber, was er braucht. Verträge werden gemacht, Pflichtenhefte erstellt, ein Zeitrahmen abgesteckt. Dann erst beginnt die eigentliche Arbeit: Externe Programmierer entwickeln eine Software oder Ingenieure im eigenen Haus einen neuen Staubsauger. Arbeiten pflichtbewusst alle festgelegten Features und Wünsche ab und präsentieren nach Monaten oder schlimmstenfalls Jahren das Ergebnis. Manchmal gibt es dann Champagner, oft aber auch lange Gesichter. Nämlich dann, wenn der Auftraggeber auf einmal sagt, er habe sich das alles „anders vorgestellt“, weil: Ein Teil der Funktionen sei gar nicht nötig, das habe die Marktforschung gezeigt; außerdem habe die Konkurrenz ein Problem besser gelöst, so wolle man das jetzt auch; und überhaupt habe sich der Markt inzwischen verändert …

Solche Probleme versuchen Agile Softwareentwicklung und Agiles Projektmanagement zu vermeiden. „Bei Projekten mit herkömmlichen Methoden sind nach sechs Monaten Arbeitszeit meistens nur noch zwischen 50 und 80 Prozent des Ergebnisses brauchbar“, sagt Stephan Schulze, der Technikvorstand bei Project A Ventures, einem Frühphaseninvestor aus Berlin. „Agile Entwicklung setzt deswegen auf viel kürzere Zyklen und Iterationen. Man definiert, was man im nächsten ein- bis zweiwöchigen Sprint schaffen will, und erstellt dann eine funktionierende Teilversion.“ Zu dieser gibt es dann Feedback von allen Beteiligten, das in die nächste Iteration miteinfließt.

„Die Start-ups, mit denen wir es zu tun haben, arbeiten fast alle agil“, sagt Schulze. „Die wissen oft noch so wenig über ihre Kunden, und ihr Markt verändert sich meist so schnell, dass Agilität eine Notwendigkeit ist.“ Florian Heinemann, Mitgründer und Geschäftsführer von Project A, ergänzt: „Wenn nicht zumindest die geistige Bereitschaft für agiles Arbeiten gegeben ist, also für autonomes Arbeiten, offene Kommunikation und schnelles Reagieren auf Veränderung – dann sind wir an einer Zusammenarbeit auch nicht wirklich interessiert.“

Basar statt Kathedrale

„Man kann traditionelles und Agiles Projektmanagement gut mit einem Vergleich beschreiben, der auf den Software-Entwickler Eric Raymond zurückgeht“, sagt Ayelt Komus, Professor für Organisation und Wirtschaftsinformatik an der Hochschule Koblenz. „Dieser Vergleich unterscheidet zwischen einer Kathedrale und einem Basar. Beim Bau einer Kathedrale folgt alles dem Plan eines großen Baumeisters. Die Arbeiter befolgen nur dessen Anweisungen. Ein Basar ist organischer, er entwickelt sich entsprechend der aktuellen Bedürfnisse und folgt keinem Plan, der eventuell längst überholt ist.“

Im Laufe der Nullerjahre bildeten sich Standards an agilen Methoden und Techniken heraus, von denen „Scrum“ eine der bekanntesten ist. War der Einsatzbereich anfangs nur auf Software-Entwicklung beschränkt, breitete sich die agile Arbeitsweise nach und nach auch auf andere Bereiche aus.

Das hat laut Komus drei Hauptgründe: „Nach der alten Methode muss der Auftraggeber vorab alles festlegen. Doch in der Regel überfordert es ihn, detailliert und wirklich durchdacht zu formulieren, was er genau will. Unter anderem, weil vieles am Anfang einfach noch zu abstrakt ist.“

Der zweite Grund: Gerade bei neuen Projekten sei die Lernkurve meist extrem steil, es sei also wichtig, aufgrund von neuen Erkenntnissen noch nachjustieren zu können. „Das gilt für Software, die sich fast immer mit neuen Problemen beschäftigt, sicher stärker als für den Bau eines Supermarkts, wo man beim vierzigsten hoffentlich weiß, wie es funktioniert“, so Komus.

Der dritte Grund: Die Welt verändert sich. Die agile Methode kann auf Marktbedingungen, Mitbewerber oder Regulierung flexibel reagieren. Wer einen vorher streng fixierten Plan abarbeitet, kann das hingegen nicht.

Es ist also kein Wunder, dass Agile oder Scrum in den vergangenen Jahren zu Mantren wurden, die auf zahllosen Konferenzen gesungen wurden. „Im klassischen Hype Cycle ist das Thema im Moment sicherlich in der Phase der Übersteuerung“, sagt Komus. „Es wird als Wunderwaffe abgefeiert und von manchen als eine Art Religion betrieben. In ein paar Jahren wird sich das abgekühlt haben, und wir werden auf Konferenzen wieder weniger Vorträge darüber hören. Aber das heißt ja meist nur, dass etwas in der Breite und der Praxis angekommen ist.“

Dass diese Art des Projektmanagements keine Eintagsfliege ist, sondern noch viel populärer werden wird, daran herrscht für Komus kein Zweifel. Seine Zuversicht stützt sich auf die Ergebnisse der Studie „Status Quo Agile“, die sein Team gemeinsam mit der Deutschen Gesellschaft für Projektmanagement durchgeführt hat. Dabei zeigte sich unter anderem, dass die meisten Studienteilnehmer zwischen 2010 und 2013 anfingen, die Methode zu nutzen, und mehr als ein Viertel der Anwender inzwischen jenseits des IT-Bereichs angesiedelt ist.

„Die Überlegenheit trat deutlich zutage“, sagt Komus. „Egal ob es um Ergebnisqualität, Termintreue oder Mitarbeitermotivation ging – klassische Projektmanagement-Methoden schnitten durchgehend schlechter ab.“ Gleichzeitig habe sich gezeigt, dass an vielen Orten auch Hybridformen aus agilen und traditionellen Methoden eingesetzt werden. „Die Projekte, die komplett nach agilen Regeln durchgeführt wurden, waren aber wiederum noch häufiger erfolgreich als die, die auf Mischformen setzen.“

Fraglich, das gibt auch Komus zu, ist allerdings, ob es sich nicht um eine Scheinkorrelation handelt. Möglicherweise sind erfolgreiche Unternehmen auch darin erfolgreich, neue Methoden zu erkennen – und können es sich leisten, sie zu testen und einzusetzen.

„Agile ist ein Krebsgeschwür“

Nicht alle sind begeistert. Einer der wütendsten Kritiker dürfte der niederländische Programmierer Erik Meijer sein. Der frühere Microsoft-Mitarbeiter bezeichnete die Methode auf der finnischen Konferenz „Reaktor Dev Day“ im September 2014 als ein „Krebsgeschwür“, das „ein für allemal eliminiert“ werden müsse. „Statt die ganze Zeit nur über das Programmieren zu reden und unsere Zeit in Daily Stand-ups (siehe Glossar) zu vergeuden“, redete sich Meijer in einem Batik-T-Shirt auf der finnischen Bühne in Rage, „sollten wir lieber wieder ein bisschen mehr Code schreiben. Denn das ist es, was Entwickler tun.“

Meijer sagt nicht, die Methoden von Agile seien samt und sonders falsch. Er bemängelt, dass aus einer ursprünglich guten Idee der Vereinfachung und Flexibilisierung ein lukratives Geschäft geworden sei.

Auch Dave Thomas, einer derjenigen, die das Agile Manifest in die Welt brachten, rechnete vor einiger Zeit in seinem Blog unter dem Titel „Agile ist tot (lang lebe die Agilität)“ mit der aktuellen Entwicklung ab: „Das Wort ‚agile‘ ist inzwischen bis zur Bedeutungslosigkeit verdorben, und was als Agile-Community gilt, scheint mir inzwischen vor allem eine Arena für Berater und Verkäufer, die ihre Dienstleistungen und Produkte verhökern.“

„Alle wissen, dass es am Ende anders kommt“

Doch selbst, wenn man agile Methoden vernünftig anwendet, können damit nicht unbedingt sämtliche Probleme gelöst werden. Das sieht auch Ayelt Komus so. Zum einen sei nicht jedes Produkt für permanente Änderungen geeignet: „Mit Software lässt sich das einfacher machen. Da können Sie jederzeit eine neue Version erstellen“, sagt er. „Wenn bei einer Autobahnbrücke mal die ersten Pfeiler stehen, wird es schwieriger.“

Die Lösung für solche vergleichsweise starren und langlebigen Produkte könne jedoch sein, so lange wie möglich im Virtuellen – also beispielsweise mit Computer-Aided Design (CAD) – zu planen und zu entwickeln, um sich möglichst lange maximale Flexibilität zu bewahren. Ein weiteres Problem sei außerdem, dass permanentes Lernen und ständiger Austausch und Hinterfragen des eingeschlagenen Kurses auch viel Energie kosten. „Im Umkehrschluss kann das bedeuten, dass es sich bei Prozessen, die ich sehr gut im Griff habe, die also eine sehr hohe Prozessreife besitzen, nicht unbedingt immer lohnt, mit agilen Methoden vorzugehen.“

Zu guter Letzt sei auch ein Problem, dass agile Methoden in direktem Konflikt mit der Kultur vieler Konzerne stünden, so Komus. „Das Management weiß oft genau, dass sich ein Plan nicht realisieren lässt. Aber es muss ein Plan da sein. Der wird oft mit einem Augenzwinkern erstellt, weil allen klar ist, dass man drei Jahre im Voraus nicht auf die Nachkommastelle genau sein kann. Aber ohne einen solchen Plan geht es in vielen Unternehmen nicht. Das Controlling beharrt darauf, der Einkauf beharrt darauf – obwohl alle wissen, dass es am Ende anders kommt. Und schließlich erfüllen derartige Planungsriten zumindest die Funktion, dass die Unternehmen organisatorisch und finanziell ein Gefühl für die Größenordnung der anstehenden Veränderungen bekommen.“

Das neue Richtig heißt: weniger falsch

Florian Heinemann weiß sehr gut, wie schwer sich gerade große Unternehmen mit dem Thema Agilität tun. Trotzdem ist er davon überzeugt, dass es anders nicht mehr geht: „Die digitale Welt funktioniert generell bottom-up und nicht mehr durch Marschbefehle, die aus der Führungsebene nach unten gereicht werden“, sagt Heinemann. „Zusätzlich gilt: Das neue Richtig ist das Weniger-Falsch.“ Fehler zuzugeben und bei Bedarf nachzujustieren sei in großen Firmen jedoch oft undenkbar: „Fehler sind da karrierehemmend, deshalb werden sie unter den Teppich gekehrt – und somit auch nichts daraus gelernt.“ Agile Methoden hätten darüber hinaus den Vorteil, wenig anfällig für internes strategisches Geplänkel zu sein: „Wenn in einem Unternehmen die Performance in Meetings wichtiger wird als die inhaltliche Performance, dann wird es in der Regel gefährlich. Ich versuche meistens, zu diesem Zeitpunkt nicht mehr da zu sein.“

Der für Heinemann interessanteste Punkt ist die inhaltliche Beteiligung der IT. „Wenn man die Programmierer auch in den Gestaltungsprozess einbezieht, wenn man sie ermutigt, Businessprobleme zu lösen, dann kann das ein wahnsinnig mächtiges Werkzeug werden“, sagt er. Googles Anzeigenplattform AdWords sei dafür das beste Beispiel: „Die Art und Weise, wie Werbung vorher verkauft wurde, war extrem ineffizient. Kunden, die Werbung schalten wollten, gingen zu einer Media-Agentur, die verhandelte mit den Fernsehsendern oder Zeitungen. Das dauerte lange, und alle Zwischenhändler schlugen etwas auf den Preis drauf. Am Ende wusste der Kunde nicht, ob seine Werbung funktioniert und ob er einen guten Preis bekommen hat.“

Bei Google AdWords hingegen – und der meisten Onlinewerbung generell – kann jeder Interessierte selbst Werbeplätze buchen. In Sekundenbruchteilen wird – je nachdem, ob ein männlicher Teenager in Wuppertal oder eine Rentnerin mit Autokaufabsicht vor dem Rechner sitzt – eine andere Werbung eingeblendet. „Das macht es viel effizienter und schneller. Und es waren nicht Werbefachleute, die diese Idee hatten. Sondern Programmierer“, sagt Heinemann. „Solche Fälle werden wir immer öfter sehen, denn überall werden die Wertschöpfungsketten digitaler.“

Heinemann erkennt darin großes Potenzial. Dieses Know-how, das da gerade entstehe, dürfe nicht bei ein paar kleineren Firmen hängenbleiben, sagt er. „Sondern es muss uns gelingen, es auf größere Schwungräder der deutschen Wirtschaft zu applizieren. Dann würde sich wirklich etwas bewegen.“ Allzu optimistisch ist er jedoch nicht: „Als ich neulich auf einer Tagung von deutschen Familienunternehmen war, schien mir das Interesse am Thema Erbschaftsteuer bei vielen größer als das an der digitalen Transformation.“

Agiler als agil

Neben den Fans und Kritikern gibt es noch eine dritte Gruppe: diejenigen, denen agil allein schon nicht mehr agil genug ist. Eric Bowman, Oberentwickler bei Zalando, ist einer von ihnen. Der gebürtige Amerikaner, zuvor für Gilt Groupe und Tomtom tätig, leitet im ehemaligen Gebäude der DDR-Nachrichtenagentur ADN in der Berliner Mollstraße mehr als 800 Programmierer an. An anderen Standorten Zalandos sitzen noch einmal 400 Software-Entwickler, im Lauf dieses Jahres sollen 600 weitere dazukommen. Um sich trotz dieses massiven Wachstums leichtfüßig durch die digitale Welt zu bewegen, hat Bowman ein Konzept namens „Radical Agility“ erfunden, das eine ganze Firma in Schwung bringen soll: „Wie können Dutzende oder Hunderte von Teams agil arbeiten? Gleichzeitig ist es wichtig, dass unsere Mitarbeiter motiviert sind und Freude an der Arbeit haben. Denn die Leute, die wir brauchen, sind so gut, dass sie überall arbeiten könnten, wo sie wollen.“

Zalando ist gerade dabei, sich vom Onlineshop zu einer Modeplattform, einer Art Betriebssystem zum Thema Mode zu wandeln (siehe „Rennmäuse“, brand eins 12/2015). Das erfordert sowohl neue Software als auch Überarbeitungen der bestehenden Infrastruktur. „Trotzdem ist bei einem Umsatz von drei Milliarden Euro im Jahr klar: Man kann den Shop nicht zumachen, um ein neues Kassensystem einzubauen“, sagt Bowman.

Vor ziemlich genau einem Jahr ist er mit seinem Konzept angetreten und hat damit selbst in dem eigentlich jungen Zalando-Organigramm kaum einen Stein auf dem anderen gelassen. „Über Nacht hatte so gut wie jeder einen neuen Chef. Aber nicht, weil wir neue Posten im Management vergeben hätten, wir haben die Hierarchien eher reduziert.“ Außerdem wurden Teams interdisziplinär zusammengestellt. Diese hätten nun zwei Chefs, so Bowman: „Einen Delivery Lead, der für die konkreten Aufgaben zuständig ist, und einen People Lead, der sich um die Belange der Mitarbeiter kümmert.“

Trotz der zwei Chefs gebe es mehr Autonomie für die Mitarbeiter als je zuvor: Sie entscheiden selbst, an welchem Projekt sie mitarbeiten, und sie entscheiden im Team, mit welchen Werkzeugen, etwa Programmiersprachen, sie arbeiten wollen. „Mehr als 60 Prozent unseres Traffics kommt inzwischen über mobile Geräte, unsere mobile App ist deshalb extrem wichtig für uns“, sagt Bowman. „Als wir unsere App vor Kurzem neu gebaut haben, brauchten wir dafür rund zwei Monate. Früher hätte das sicher ein Jahr gedauert.“ Zahlreiche Teams arbeiteten parallel.

Komplett dirigiert von der unsichtbaren Hand der Radical Agility? „Ein paar Freiheiten mussten wir für eine gewisse Zeit einschränken, um das Ziel zu erreichen“, gibt Eric Bowman zu. „Aber manchmal haben wir auch Teams, bei denen wir überhaupt nicht wissen, was genau sie tun – und das ist ebenso etwas, das wir wollen.“

Streng genommen steht das im Widerspruch zur reinen Agile-Lehre. Dort ist maximale Transparenz wichtig, und jeder weiß jederzeit, woran der andere gerade arbeitet. Bowman will es nicht immer und bei allen so genau wissen. So hat ein kleines Zalando-Team auf eigene Faust eine App entwickelt: eine Art „Tinder für Mode“. Wie bei der Flirtplattform wischt man nach rechts oder links, um Zustimmung oder Ablehnung zu signalisieren. Nur dass man damit keinen Partner für die nächste Nacht aussucht, sondern angibt, welches Kleidungsstück einem gefällt und welches nicht. „Wir haben die App jetzt in Schweden gestartet und werden sehen, wie sie sich entwickelt“, sagt Bowman.

Ein anderer Erfolg, den Eric Bowman auf Radical Agility zurückführt, ist ein Wechsel in der Programmiersprache: „Wir hatten sehr lange in Python gearbeitet“, sagt er. „Eine Programmiersprache, die leider nicht sehr gut skaliert – das heißt, wenn viele Leute auf unserer Seite waren, wurde sie immer langsamer.“ Es gab keine Direktive von oben, Python durch eine andere Programmiersprache zu ersetzen. Aber nach und nach merkten Teams, die eine Sprache namens Scala ausprobierten, dass sie damit deutlich höhere Geschwindigkeiten erzielten. Das sprach sich herum, und Scala wurde öfter und öfter eingesetzt. „Es hat viel reibungsloser geklappt, als irgendwann offiziell einen großen Schalter umzulegen und zu sagen: Ab heute darf nur noch Scala benutzt werden“, sagt Bowman. „Das Ergebnis ist großartig: Wir haben jetzt durch eine skalierbare Infrastruktur immer dieselbe schnelle Performance, egal wie viele Leute unser Angebot nutzen.“

Größtmögliche Freiheit und Vertrauen scheinen Zalando im erbitterten Kampf um digitale Talente (siehe „Die Zukunft gehört den Geeks“, brand eins 06/2015) tatsächlich zu helfen: Die Bewerberzahlen für IT-Jobs haben sich seit der Einführung von Radical Agility laut Bowman verdreifacht, die Zahl der Mitarbeiter, die die Firma verlassen haben, ist hingegen um ein Drittel gesunken. „Und viele derjenigen, die vor ein oder zwei Jahren woanders hingegangen sind, sind wiedergekommen.“

Es ist beinahe eine Ironie des Schicksals, dass das große Vorbild von Zalando, der Schuh-Onlinehändler Zappos aus den USA, mit der Weiterentwicklung der agilen Prinzipien weitaus weniger Erfolg hatte: Vor etwa zwei Jahren begann Zappos Chef Tony Hsieh schrittweise, eine Managementphilosophie namens „Holacracy“ einzuführen. Diese verzichtet auf Hierarchien und setzt stattdessen auf Selbstorganisation. Doch laut US-Medienberichten gibt es immer weniger zu organisieren: Bis zu einem knappen Drittel der Mitarbeiter soll die Firma im vergangenen Jahr aufgrund der neuen Methoden verlassen haben. ---

Glossar

Scrum
Grundstruktur für agile Prozesse, die keine konkreten Techniken, dafür aber zwei wichtige Rollen vorgibt: den Scrum Master und den Product Owner. Der Scrum Master ist für die Einhaltung des Prozesses zuständig, der Product Owner dafür, dass das Produkt nach Anforderungen des Kunden entsteht. Da es zu Rollenkonflikten kommen kann, sollten Scrum Master und Product Owner nicht ein und dieselbe Person sein.

Daily Stand-up
Tägliches Kurzmeeting im Stehen, bei dem reihum jedes Teammitglied drei Fragen beantwortet: Wie bin ich gestern mit der Arbeit vorangekommen? Woran werde ich heute arbeiten? Welche Hindernisse stehen mir dabei eventuell im Weg? Jeder hat dafür zwei Minuten Zeit, sodass bei einer idealen Teamgröße von sechs bis acht Personen eine Viertelstunde reicht.

Sprint
Begriff aus dem > Scrum, mit dem der Zeitraum bezeichnet wird, in der das Team eine neue Version des Produkts erstellt. In dieser Zeit kommen keine neuen Anforderungen oder Änderungswünsche hinzu. Ein Sprint soll nicht länger als einen Monat dauern, idealerweise sind alle Sprints in einem Projekt gleich lang und schließen aneinander an.

Planning Poker
Um den Aufwand einzelner Aufgaben jedes > Sprints einschätzen zu können, verwendet man beim Planning Poker Spielkarten mit Zahlen. Auf ein Kommando hin hält jeder Teilnehmer die Zahl hoch, die er als Zeitaufwand schätzt. Das soll verhindern, dass Wortführer und Hierarchien die Schätzung lenken. Weichen die Schätzungen stark ab, äußern die Teilnehmer mit der höchsten und niedrigsten Schätzung ihre Argumente, danach wird erneut geschätzt.

Taskboard
Visuelles Hilfsmittel, um den Projektfortschritt anzuzeigen. Einzelne Aufgaben wandern dabei durch verschiedene Spalten von links nach rechts. Das Taskboard kann digital verwaltet werden, oft wird aber empfohlen, es analog zu pflegen und dort aufzuhängen, wo das > Daily Stand-up stattfindet.

Mehr aus diesem Heft

Einfach machen 

Ehrensache

Bauen mit Wüstensand galt als unmöglich. Gerhard Dust und Gunther Plötner haben das Gegenteil bewiesen. Und endlich das Projekt ihres Lebens gefunden.

Lesen

Einfach machen 

Was lange währt, wird manchmal nichts

Ein persönlicher Rückblick auf die erfolgloseste Entwicklungsredaktion Deutschlands.

Lesen