Von grau zu bunt, von statisch zu agil

Am großen grauen Stahlgebäude prangt ein riesiges magentafarbenes T. Ein Bauwerk eines großen, behäbig wirkenden Konzerns, von dem man eigentlich nicht viel mehr weiß, als dass er ein gut ausgebautes Telekommunikationsnetz besitzt, die Frauenquote propagiert und René Obermann als Chef fungiert. Vor der Eingangstür dieses Komplexes steht man Auge in Auge mit der Anonymität. Vor einem großen Unternehmen mit unzähligen Mitarbeitern, die doch nicht alle nur für Handynetze zuständig sein können. Kühl und beliebig wirkt dieser Ort. Und es ist kaum vorstellbar, dass man hier Menschen treffen soll, die mit Hilfe von agile development neue Produkte und Prozesse gestalten.

Um zu diesen Menschen zu gelangen, muss man durch die Eingangshalle von Products & Innovation, vorbei an einem Café und einem Demo-Bereich für Produkte. Mit dem Aufzug drei Stockwerke nach oben und einen langen Gang entlang, in einen Raum voller Post-its. Viele kleine bunte Klebezettel hängen dort und repräsentieren viele kleine Ideen. Teilweise geordnet, teilweise scheinbar zusammenhangslos.

Jeder Mitarbeiter in diesem Raum hat seinen eigenen Schreibtisch. Nirgends gibt es Wände, die sie voneinander trennen. Ein Raumkonzept der Offffenheit und Dynamik. Hier ist das Agile Transition Team im Bereich Products & Innovation der Deutschen Telekom zuhause. Ihr Auftrag: „Weg von der klassischen Produktentwicklung“. Draußen bleiben müssen verstaubtes, antiquiertes Handeln und das Denken in Hierarchiestufen, das häufig noch geprägt ist durch die Strukturen des ehemals öffentlich-rechtlichen Unternehmens. Agile Produktentwicklung, das ist die Methode der Wahl.

Mit agile development werden aus Post-its, und einer lockeren Atmosphäre Produkte. Die klassische Produktentwicklung folgt oftmals der Wasserfallmethode. Der Auftraggeber gibt dem Entwicklungsteam von Beginn an klare Vorgaben, wie das Endprodukt aussehen und funktionieren soll. Dann wird erst einmal geplant, wie man das Produkt entwickelt und wann welcher Arbeitschritt vollzogen wird. Erst nach dieser langen Planungsphase geht es an die eigentliche Entwicklung. In bestimmten Paketen wird das Ergebnis entworfen und schlussendlich fertiggestellt. Immer ein Schritt nach dem anderen. Veränderte Voraussetzungen während dieser Entwicklungsphase, können häufig nicht mehr aufgegriffen werden.

Mit agile development zu mehr Dynamik

Genau hier setzt agile Produktentwicklung an. Die Arbeitsschritte werden nicht in langer Vorbereitung zu Beginn festgelegt, sondern in kurzen Entwicklungszyklen von ein bis vier Wochen für priorisierte Themen abgearbeitet. Seine Ursprünge hat agile development in der Softftware- Industrie, aber auch außerhalb der Softwareentwicklung hat es sich über die vergangenen Jahre in verschiedene Bereiche entwickelt. 2001 wurden die Grundprinzipien agiler Entwicklung das erste Mal im agilen Manifest förmlich festgehalten. Erste Ansätze der Methode gab es zwar schon seit 25 Jahren, aber selbst in der Software-Industrie stand die Entwicklung noch am Anfang. Dieses agile Manifest zeigt, welche Werte für die Arbeitsweise mehr zählen als andere:

„Individuen und Interaktionen mehr als Prozesse und Werkzeuge. Funktionierende Software mehr als umfassende Dokumentation. Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung. Reagieren auf Veränderung mehr als das Befolgen eines Plans.“
(Quelle: http://agilemanifesto.org/iso/de)

Die Festlegung einer solchen Wertestruktur hat weitreichende Folgen für alle Methoden, die dieser zugrunde liegen. So wurden verschiedene Methoden im Laufe der Zeit entwickelt, die auch auf Entwicklungsprojekte oder Projektmanagement außerhalb von Software angewendet werden können. Insbesondere die Scrum Methodik erfreut sich großer Beliebtheit und ist die derzeit am weitesten verbreitete agile Methode.

Abgeleitet von den Werten des agilen Manifests versucht Scrum, die hohe Komplexität von Entwicklungsprojekten durch die Prinzipien Transparenz, Überprüfung und Anpassung zu reduzieren. Bei Scrum bilden dabei drei Rollen ein Scrum-Team: der Product Owner, der Scrum Master und das eigentliche Entwicklungsteam.

Die agile Terminologie

Der Product Owner ist dabei für den ökonomischen Erfolg und die Produktvision verantwortlich. Er steht in engem Kontakt mit dem Auftraggeber und den Stakeholdern, um deren Vorstellungen in den Entwicklungsprozess einfließen zu lassen. In klassischen Entwicklungsmethoden ist er wohl am ehesten mit einem Produkt Manager zu vergleichen. Bei großen Entwicklungsprojekten ist es häufig so, dass mehrere Scrum-Teams parallel an unterschiedlichen Teilen eines Projekts arbeiten und somit ein Produkt Manager oder auch Chief Product Owner mit mehreren Product Ownern der einzelnen Entwicklungsteams arbeitet.

Die Aufgabe des Scrum Masters ist es, das Entwicklungsteam dabei zu unterstützen, die Methodik einzuhalten und dafür zu sorgen, alle Schwierigkeiten und Herausforderungen zu lösen, die während des Entwicklungsprozesses dem Team im Weg stehen. Er nimmt dabei explizit nicht die Rolle eines Teamleiters ein, sondern handelt nach dem Prinzip servant leadership. Er dient also dem Team und ermöglicht den Teammitgliedern effizient und konzentriert zu arbeiten.

Das Entwicklungsteam ist während des Prozesses für die Entwicklung der Produktfunktionalität in der gewünschten Qualität verantwortlich und arbeitet dabei absichtlich sehr autonom. So entscheidet es selbst, wie viele Teile der geforderten Produktfunktionalität es innerhalb des nächsten Entwicklungszyklus liefern kann und möchte. Zudem organisieren die Teammitglieder eigenverantwortlich, welche der geplanten Aufgaben sie bearbeiten. Idealerweise bestehen solche Entwicklungsteams aus fünf bis neun Personen. Die Teammitglieder sind außerdem dazu angehalten, unterschiedliche Aufgaben anzunehmen und sich gegenseitig auszuhelfen, um so den Unwägbarkeiten eines Projekts besser gewachsen zu sein. Neben den drei Kernrollen gibt es bei Scrum drei Meetings, welche die Methode entscheidend prägen: das Sprint Planning, das Daily Scrum und das Sprint Review Meeting.

Meetings und Sprint Planning

Beim Sprint Planning handelt es sich um das Planungstreffen für den nächsten Sprint. Ein Sprint ist ein Entwicklungszyklus von ein bis vier Wochen, der für ein Entwicklungsprojekt immer die gleiche Länge hat. Dies dient einer besseren Planbarkeit und verbessert somit die Einschätzung zukünftiger Sprints. Während des Sprint Plannings erarbeitet das Entwicklungsteam gemeinsam mit dem Scrum Master und dem Product Owner, welche Produktfunktion innerhalb des kommenden Sprints fertig gestellt werden kann. Dabei verpflichtet sich das Entwicklungsteam aus freien Stücken bis zum Ende eines Sprints, ein bestimmtes Ergebnis zu liefern.

Während eines Entwicklungszyklus trifft sich das Scrum Team täglich zum sogenannten Daily Scrum. Während diesem höchstens 15-minütigen Treffen beantwortet jedes Teammitglied folgende drei Fragen: „Was habe ich seit dem letzten Daily Scrum erreicht?“, „Was möchte ich bis zum nächsten Treffffen erreichen?“ und „Wo habe ich Schwierigkeiten und Herausforderungen?“. Dieses Treffffen dient dazu, mögliche Schwierigkeiten zu identififizieren und einen Überblick über die erledigten Aufgaben zu erhalten. Sollte es inhaltliche Diskussionen geben, die innerhalb der vorgesehenen 15 Minuten nicht erledigt werden können, müssen diese in ein separates Treffen verlegt werden.

Sprint Review Meeting

Zum Abschluss eines Entwicklungszyklus findet das Sprint Review Meeting statt. Bei diesem Treffen präsentiert das Entwicklungsteam dem Product Owner die Ergebnisse des vergangenen Sprints. Dabei ist es wichtig, dass jedes der Ergebnisse für sich voll funktionsfähig ist. Der Product Owner überprüft dabei, ob die zu Beginn gesteckten Ziele in der gewünschten Qualität erreicht wurden. Häufig sind in eine Sprint Review auch der Auftraggeber, andere Stakeholder oder spätere Nutzer involviert, um zusätzliche Rückmeldung zu den erbrachten Ergebnissen zu erhalten. Ein Sprint Review sollte nicht länger als 90 Minuten dauern. Durch dieses sogenannte „timeboxing“ wird versucht, die Meetings möglichst effizient zu halten.

Während all dieser Treffen steht das Entwicklungsteam immer wieder vor seinem Taskboard, auf dem von links nach rechts, auf vielen bunten Post-its, zunächst die geplanten Funktionen, dann die dafür nötigen Aufgaben, die in Bearbeitung befindlichen und zuletzt die erledigten Aufgaben stehen. Die Priorität der Funktionen und Aufgaben ist auf einen Blick sichtbar, da sie absteigend von oben nach unten sortiert sind.

Die Orientierung am Menschen zeigt sich vor allem am weitestgehend selbstständigen Arbeiten des Entwicklungsteams während eines Entwicklungszyklus. Während einem Sprint hält sich der Product Owner aus der täglichen Arbeit zurück, so dass die Teammitglieder ungestört die Aufgaben des Sprints erledigen können. Das Team soll aufkommende Probleme selbst lösen und nur wenn dies unmöglich ist, ist der Scrum Master oder Product Owner gefordert. Gegebenenfalls werden dann auch andere Führungskräfte hinzugezogen.

Was das für die Deutsche Telekom bedeutet war 2010 noch unklar. Die Struktur war beeinflusst von der alten Welt der Wasserfallmethode. Aber der Konzern versucht, sich stetig zu verändern, zu verschlanken und schneller zu werden. Im rasant voranschreitenden Internetgeschäft sucht man ständig nach neuen Wachstumsfeldern. Die vorhandenen Prozesse, die besonders durch große Infrastrukturprojekte der Deutschen Telekom geformt sind, können der Fülle an Anforderungen und ständigen Veränderungen des Internetgeschäfts nicht mehr gerecht werden. Lasten- und Pflichtenhefte können nicht mehr zu Beginn eines Projekts erstellt und durch verschiedene Aufsichtsgremien mit magentafarbenen Slideshows gereicht werden, bis der nächste Entwicklungsschritt gegangen werden darf.

Einfacher, schneller und effiffizienter sollen komplexe Projekte gemeistert werden. Moderne agile Methoden nehmen diese Herausforderung an und sorgen in einem nie still stehenden Umfeld für Ordnung und transparente Abläufe.

Die Product Owner des Agile Transition Teams, Bernd Klumpp und Andrea Maier, sind für die Vision des Projekts verantwortlich. Sie erklären, dass das Vertrauen der Mitarbeiter in Products & Innovation und vor allem in agile Entwicklungsmethoden die Basis für ihre große Begeisterung bilden. Zu Beginn waren sich beide bewusst, dass die Umstellung auf eine neuartige Arbeitsweise einiger Zeit bedarf, um vollständig akzeptiert und anerkannt zu werden.

Aus Produktmanagern werden Product Owner, aus Entwicklungspaketen entstehen User Stories.

Thomas Kiessling, damals gerade neu als Chief Product & Innovation Officer, greift im November 2010 den Drang zur Veränderung auf. Durch seine persönlichen Erfahrungen mit agilen Methoden fällt es ihm leicht, Veränderungen des Produkt- und Projektmanagements in Bewegung zu setzen. Auch wenn sich die agile Vorgehensweise zunächst nicht mit den klassischen Prozessen im Bewusstsein der Mitarbeiter vereinen lässt.

In der Praxis startet die wirkliche Veränderung Anfang 2011 mit ersten Lighthouse-Projekten. Agile Teams werden zusammengestellt und arbeiten von Anfang an nach der Scrum-Methode. Eines davon arbeitet an der elektronischen Buch- & Magazin-Plattform PagePlace. Im letzten Sprint vor der Leipziger Buchmesse im März 2012 hatte das Team an der Benutzerführung und einer Lesezeichen- Funktion gearbeitet. Die für den bevorstehenden Entwick- lungszyklus ausgewählten Funktionen, wurden während des Sprint-Plannings so gestaltet, dass sie zum Ende des Sprints und damit pünktlich zur Messe veröffentlicht werden konnten.

Projektmanagement bei komplexen Projekten

Bei größeren Entwicklungsprojekten, wie beispielsweise dem Internet-TV Produkt Entertain, arbeiten erste Scrum-Teams derzeit noch parallel mit klassischen Entwicklungsteams. Langfristig sollen möglichst alle Entwicklungsprojekte bei Products & Innovation komplett agil sein. Um ein solches Arbeiten von mehreren Teams an einem Großprojekt zu ermöglichen, arbeiten sie an spezifischen Teilen des Produkts innerhalb von vorher gestalteten Rahmenbedingungen – beispielsweise einer einheitlichen Design-Sprache. Damit am Ende einer Entwicklungsphase ein einheitliches und konsistentes Gesamtprodukt entsteht, ist ein hoher Abstimmungsaufwand nötig. Die kurzen Entwicklungszyklen mit klaren Reflektionsphasen vereinfachen dies. Damit wird sichergestellt, dass nicht Teile eines Produkts über Monate hinweg in die falsche Richtung entwickelt werden.

In einer so großen Organisation, wie der Deutschen Telekom, die schon seit Jahrzehnten mit etablierten Prozessen arbeitet, lassen die ersten Schwierigkeiten nach der Einführung nicht lange auf sich warten. Mal passen die Einkaufsprozesse nicht, mal müssen ganz triviale Probleme wie Raumnot gelöst werden. Hilfe zur Selbsthilfe ist eines der Prinzipien mit denen das Agile Transition Team die Veränderung vorantreibt. Sie greifen nur dort ein, wo die Teams selbst nicht mehr weiterkommen. Eine ganz grundlegende Veränderung ergibt sich, als klar wird, dass alle Mitglieder eines agilen Teams diesem voll zur Verfügung stehen müssen. Sie können nicht wie bisher in fünf bis sechs verschiedenen Projekten involviert sein. Eine Schwierigkeit, die nicht ganz einfach mit den jeweiligen Führungskräften zu lösen war.

Nicht nur für die Mitarbeiter verändert sich viel durch die Scrum Methodik. Besonders die Führungskräfte müssen lernen, umzudenken und auf die Leistungsfähigkeit der Teams vertrauen. Um die Unterstützung der Führungskräfte aller Ebenen zu gewinnen führt das Agile Transition Team Trainings durch.

Die ständige Kontrolle und hierarchische Aufgabenverteilung, die sonst zu Lasten der Selbstständigkeit und Kreativität der Mitarbeiter ging, wird ausgebremst. Führungskräfte ziehen sich aus der kleinteiligen Aufgabenverteilung zurück und geben den Teams die Möglichkeit, diese selbst zu wählen. Die Hauptaufgabe der Führungskräfte ist nun, gemeinsam mit den Scrum Mastern, ihren Teams den Rücken freizuhalten. Die Teams sind in der agilen Entwicklung nun selbst verantwortlich für ihr Produkt. Die Verantwortung wird also nicht mehr wie bisher auf ein Gremium abgewälzt. Eine Veränderung, an die sich der Bereich Products & Innovation, aber vor allem das gesamte Unternehmen, erst noch gewöhnen muss.

Doch noch ist die Veränderung nicht in allen Teilen der Deutschen Telekom angekommen. Immer wieder stößt das Agile Transition Team gerade in seiner Anfangszeit auf Zurückhaltung, Ungläubigkeit und starre Strukturen. Dafür wird das Konzept „Scrum in 90 Minuten“ entwickelt. Ein wöchentlicher Termin, zu dem jeder interessierte Mitarbeiter eingeladen ist. Dort werden die fachlichen Grundlagen der agilen Entwicklung erläutert und anschließend im „Scrum Café“ in lockerer Atmosphäre diskutiert. So entsteht schnell reger Austausch zwischen den Mitgliedern agiler Teams und anderen Mitarbeitern.

Bis agile Methoden in allen Entwicklungsbereichen des Konzerns angekommen sind, werden wohl noch einige Jahre vergehen. Das Ergebnis der Veränderungen zeigt sich aber schon Ende 2011. Mehr als 30 agile Teams haben sich bis dahin gebildet. „Seit einem viertel, fast halben Jahr haben wir eine Kurve erwischt. Es wird einfach verstanden, dass es ernst gemeint ist mit der Transition.“, erläutert Andrea Maier.

Agile Entwicklung wird in vielen Unternehmen für Veränderung sorgen

Die Mitglieder der agilen Teams äußern sich bisher durchweg positiv über die neue Arbeitsmethode. Themen können im Sinne des Konzerns schneller bearbeitet und die Qualität konnte kontinuierlich gesteigert werden. Was wird wohl passieren, wenn irgendwann das gesamte Unternehmen beginnt agiler zu arbeiten? Agile Entwicklung wird nicht nur in der Deutschen Telekom einen anderen Blickwinkel auf modernes Projektmanagement werfen. Es bietet Unternehmen die Chance, den Schritt in eine offene Zukunft zu wagen. Das heißt, individueller und flexibler auf Kundenwünsche einzugehen. Die Umstellung auf ein Konzept, das vor allem von seinen Mitarbeitern mehr Selbstständigkeit erwartet.

Die Innovationswelt in bunt. Auf Post-its.

Für das Agile Transition Team ist die Welt Magenta, und wenn man die bunten Büros dieses grauen Konzerns verlässt, ist dieser plötzlich nicht mehr ganz so farblos. Man möchte direkt beginnen, das eigene Büro mit vielen bunten Post-its auszuschmücken. Die Methode macht Sinn! Nicht nur im großen Konzern, sondern auch bei kleinen Ideen, die zu großen Projekten werden können.

Autor: Tim Schikora ist Mitglied bei der studentischen Unternehmens- beratung Junior Consulting Team e.V. in Nürnberg. (tim.schikora@jct.de)