Agiles Projektmanagement: Scrum, Kanban und Scrumbuts im Einsatz

Agiles Projektmanagement: Scrum, Kanban und Scrumbuts im Einsatz

Aus dem
t3n Magazin Nr. 31

03/2013 - 05/2013

Autor:

Joern Bock

Online gestellt:

22.08.2013

Agile Projektmanagement-Methoden wie Scrum und Kanban versprechen effiziente Abläufe, motivierte Mitarbeiter und zufriedene Kunden. Doch kann ihr fehlerhafter Einsatz auch das genaue Gegenteil bewirken. Ein Praxisbericht, der Einblicke in Erfolgsmethoden sowie Risiken bei der Umsetzung gewährt.

Scrum und Kanban sind mittlerweile populäre agile Methoden, die auch in der Agenturwelt immer mehr Verbreitung finden. Der Grund: Sie helfen IT-Aufträge schneller, sicherer und damit auch erfolgreicher abzuwickeln, als dies mit herkömmlichem Projektmanagement möglich ist. Hinter dem Wort „agil“ verbindet sich dabei die Idee, ein Projekt oder Produkt Schritt für Schritt mit einem sich selbst organisierenden, interdisziplinären Team in Zyklen (Sprints) zu entwickeln. Der Sinn ist, einen Auftrag durch Priorisierung schlank zu halten, Kundenwünsche rasch umzusetzen und auch in späten Projektphasen noch flexibel auf Veränderungen eingehen zu können.

Vision Driven Development

Im klassischen Projektmanagement-Ansatz legt eine Planungs- und Spezifikationsphase – das sogenannte „Big Design Up-Front“  – vorab den Umfang der gesamten zu entwickelnden Lösung fest. Oft stellt der Projektleiter im Laufe der Umsetzung dann fest, dass Zeit und Budget nicht ausreichen, um alles zu bewerkstelligen. Oder er erkennt, dass das Projektteam an den Bedürfnissen des Kunden oder Marktes vorbei gearbeitet hat. Die Folgen dieses „Plan Driven Development": Stress, Unzufriedenheit und mangelnde Wirtschaftlichkeit.

Agile Methoden stellen das traditionelle Projektmanagement auf den Kopf.

Der agile Ansatz definiert hingegen zu Beginn Zeit und Budget als Konstanten – und schaut dann gemeinsam mit dem Kunden, welche Anforderungen sich innerhalb dieses Rahmens umsetzen lassen. Man spricht hier auch von „Vision Driven Development“. Die Vorteile dieser Vorgehensweise liegen auf der Hand: Der Kunde kann von Projektbeginn an mitbestimmen und die einzelnen Aufgaben von Iteration zu Iteration priorisieren (Scope-Management). Detailspezifikationen folgen nur dann, wenn sie tatsächlich auch nötig sind. Außerdem kann das Team Lerneffekte aus vorangegangenen Iterationen direkt für die nächsten Schritte nutzen. Regelmäßige Auslieferungen neuer Versionen, hohe Transparenz und ein klarer Projektfortschritt, bei dem der Umfang und die Qualität der Lösung mit jeder Iteration wachsen, helfen sowohl dem Entwickler-Team als auch dem Kunden – nicht zuletzt, weil regelmäßige Retrospektiven zu einer besseren Stimmung im Team führen.

Wie funktioniert Scrum?

Jedes Scrum-Projekt beginnt damit, dass der so genannte Product Owner das Product Backlog herstellt, also eine priorisierte Aufgabenliste für das Team. Kommt der Product Owner nicht direkt vom Kunden, kann dieser auch einen Proxy Product Owner mit dieser Aufgabe betrauen, den der Auftragnehmer stellt. Alle Aufgaben bestehen aus Sprints (Iterationen), fest definierten Zeiträumen von zwei Wochen. Während der Planungsphase – dem Sprint „Planning“ – greift sich das Team die Aufgaben aus dem Product Backlog heraus, die es in der vorgegebenen Zeit realistischerweise umsetzen kann. Gemeinsam entscheidet es, wie es dabei vorgeht (Team Commitment).

Während der Product Owner für den Erfolg des Projekts und den Return on Investment verantwortlich ist, sorgt der Scrum Master dafür, dass alle den Prozess verstehen und einhalten. Außerdem stellt er sicher, dass das Team ungestört arbeiten kann. Das Ergebnis jedes Sprints ist ein Projekt-Inkrement (etwa ein funktionierendes Kunden-Login), dessen Qualität den Review-Prozess bestanden hat und das sich somit an den Kunden ausliefern lässt. Die anschließende Retrospektive überprüft den abgeschlossenen Sprint in Bezug auf die Qualität des Scrum-Prozesses: Wie geht es dem Team? Und funktionieren die Werkzeuge? Zu Beginn des nächsten Sprints wählt das Team die nächsten Aufgaben aus dem Product Backlog, die der Project Owner als besonders relevant definiert hat – und der nächste Sprint beginnt.

Wie lässt sich Kanban anwenden?

Viele Agenturen nutzen Scrum und Kanban für jeweils unterschiedliche Projekte und Teams. Im Gegensatz zu Scrum handelt es sich bei Kanban um eine Methode,, die einen kontinuierlichen Arbeitsfluss (Flow) sicherstellen soll. Dazu visualisiert man alle Aufgaben und Abläufe (also auch die Probleme, die diese behindern) und macht sie somit erkennbar. Dies geschieht mithilfe eines Boards, das in Zeilen und Spalten (Lanes) aufgeteilt ist. An diesem Board wandern alle Aufgaben in Form von Tickets über die einzelnen Spalten. Jede Spalte repräsentiert einen Arbeitsschritt. Somit können Projektbeteiligte jederzeit sehen, welche Aufgabe sich in welchem Status befindet.

Daneben gibt es ein Limit für die Menge parallel laufender Aufgaben. Das heißt, dass in der Spalte „Entwicklung“ zum Beispiel nur vier Tickets auf einmal hängen dürfen. Ziel ist, dass jeder Mitarbeiter möglichst nur an einer Aufgabe arbeitet und nicht an mehreren parallel. Dahinter steht der Flow-Gedanke: Die Tickets sollen möglichst gleichmäßig und ohne lange Wartezeiten oder Blockaden über das Board fließen. Was den Flow behindert, wird betrachtet und gegebenenfalls behoben. Auf diese Art lassen sich Probleme im Prozess sichtbar machen und nach und nach lösen. Im Gegensatz zu Scrum visualisiert Kanban also lediglich den aktuellen Prozess, ändert diesen aber nicht signifikant.

Der Scrum-Prozess: Rund zwei Wochen dauert ein typischer Sprint.

Typische ScrumButs

Die Agentur AOE media begann bereits 2007, die ersten Projekte mit Hilfe agiler Methoden umzusetzen und machte dabei erste praktische Erfahrungen mit Plannings, Reviews und Retrospektiven – und erzielte direkt Erfolge. Die Retrospektiven zeigten schnell, dass sich Scrum stetig verbessern lässt. An dieser Stelle ist jedoch Vorsicht geboten: Wer Scrum einführt, für den ist die Versuchung oftmals groß, direkt eigene Modifikationen an Scrum vorzunehmen (ScrumButs  ) und wichtige Elemente wegzurationalisieren. Doch oft zeigt sich, dass man die für den Erfolg existenzielle Bedeutung dieser Elemente nur noch nicht verstanden hat. Typische Beispiele für so einen ScrumBut sind:

Wir nutzen Scrum, aber wir...

• verzichten auf den Scrum Master, da das Team zu klein ist.
• brauchen das aufwändige Schätzen des Aufwands einzelner Aufgaben nicht.
• verlängern die Sprints, bis wir das Ziel erreichen.
• kommen ohne die Retrospektiven aus.

Ein absolutes Muss in Scrum sind regelmäßige, feste Zeitabschnitte (Timeboxes). Schafft man die Arbeit innerhalb der festgelegten Iteration nicht, sollte das Team keinesfalls den Zeitraum verlängern. Vielmehr sollte man sich überlegen, wie man das Projekt in kleinere Inkremente aufteilen kann. Das Motto lautet hierbei: „How to slice the Elephant?“ Ein weiteres Risiko ist, dass sich ein Scrum Master wie ein Projektmanager verhält und sich als Teamleitung versteht. Bei Scrum hat jedoch das Team die Autorität. Darüber hinaus muss der Kunde für die agile Entwicklung bereit sein – also nicht mehr im Plan Driven Developement leben und denken, sondern die Rolle des Product Owners wirklich erfüllen können. Ist das nicht der Fall, lässt sich sein Projekt nur sehr schwer mit Hilfe von Scrum verwirklichen. All dies führt dazu, dass Organisationen (auf Kunden- wie auf Dienstleister-Seite) bei schlechten Scrum-Interpretationen schnell dazu neigen, die Methode als ungeeignet über Bord zu werfen und für den Misserfolg eines Projekts verantwortlich zu machen. Man sollte Scrum daher unbedingt sauber implementieren. Später lassen sich durchaus sinnvolle, zum Unternehmen passende Modifizierungen machen. Diese sollten nicht so radikal wie bei einem ScrumBut sein, doch lässt sich etwa die Rolle des Scrum Master anpassen. AOE media hat zum Beispiel seinen eigenen Weg gefunden und sieht Scrum heute als Framework, das sich an verschiedene Projekte und Situationen anpassen lässt.

Wann Scrum, wann Kanban?

Auch Kanban hat AOE media eingeführt: Hier gibt es mehrere Boards mit sehr unterschiedlichen Designs und mehreren Lanes. Zu Beginn hatten die Teams noch wenig Erfahrung, wann welche Methode einzusetzen ist: Scrum und Kanban wurden deshalb parallel verwendet. So konnte man sehr gut vergleichen, welche Methode für welches Projekt und welches Team besser geeignet ist. Kanban führt vor allem zu deutlichen Verbesserungen bei projektübergreifenden Teams, bei kontinuierlichen, schlecht planbaren Aufgaben und bei kleineren Projekten, die sich nicht in Iterationen aufteilen lassen. Für große, komplexe Aufträge und vor allem langfristige Projekte eignet sich Scrum besser.

Bunte Post-Its helfen, die aktuellen Projektsituation zu visualisieren.

Eigenmotivation und Transparenz

Bei AOE media entdeckten die Unternehmensleitung und die Entwickler gleichermaßen die agile Entwicklung für sich. Pioniere aus verschiedenen Unternehmensbereichen erarbeiteten sich damals gemeinsam die Einführung der agilen Ansätze, die stark auf Eigenmotivation und Selbstbestimmung setzen und damit sehr gut zur flachen Hierarchie und den gelebten Werten der Agentur passen. Im Zuge der agilen Entwicklung machte sich das Management auch mehr und mehr Gedanken um intrinsische Faktoren wie die Mitbestimmung, Verantwortung oder die Motivation, die aus der Person oder einer Aufgabe entspringt.

Dass Mitarbeiter ihre Aufgaben – wie in Scrum oder Kanban – innerhalb eines Rahmens selbst wählen können, trägt ganz erheblich zu einer hohen Arbeitszufriedenheit und hervorragenden Ergebnissen bei. Besonders Scrum ermöglicht zudem ein hohes Maß an Transparenz. Einerseits im Team, andererseits aber auch dem Kunden gegenüber: Release-Pläne sind durch die regelmäßigen Aktualisierungen am Ende jeder Iteration nicht länger ein frommer Wunsch, sondern Realität. Dies zieht sich hin bis zur Vertragsgestaltung: AOE media bietet Kunden zum Beispiel einen eigens entwickelten agilen Festpreisvertrag.

Meetings und Open Fridays

Meetings sind in Scrum keine Berichte „von unten“ an einen Projektleiter „da oben“. Sie dienen vielmehr der Information des gesamten Teams. Jeder kann im täglichen Meeting (Daily) sagen, was er gemacht hat, was er als nächstes angeht und auch, was ihn eventuell aufgehalten hat. Hier kommt unter anderem der Scrum Master zum Einsatz. Er sorgt dafür, dass der Fokus während des Meetings nicht verloren geht – etwa weil auf einmal über die defekte Kaffeemaschine gesprochen wird. AOE media hat zudem spezielle Formen der Retrospektive eingeführt. Dazu gehört zum Beispiel der Open Friday, der quartalsweise nach verschiedenen Methoden abläuft, etwa als Open Space . So besprachen die Mitarbeiter beim letzten Open Friday beispielsweise, welche Möglichkeiten AOE media hinsichtlich Feedback, Offenheit und Transparenz bietet oder wie sich die Arbeit im Support-Team attraktiver gestalten lässt. Daraus bildeten sich regelmäßig stattfindende Arbeitsgruppen.

Fazit

Wer Scrum einführen will, für den reicht es nicht, Bücher zu lesen: Zwar sind die Grundlagen von Scrum oder Kanban einfach zu verstehen. Die disziplinierte Umsetzung ist jedoch nicht ganz so leicht einzuhalten. Doch nur sie führt letztlich in die „Freiheit“ und aus der klassischen Projektmanagement-Tretmühle. Es lohnt sich, die (klassischen) Projektmanager, das Team und die Kunden zu schulen. Auch ein Scrum-Coach kann sich als wertvoll erweisen. Scrum ist dabei wesentlich mehr als ein neues Instrument der Software- oder Produktentwicklung: Scrum führt einen Paradigmenwechsel ein, der vom gesamten Team und auch den Kunden ein Umdenken verlangt. Die Voraussetzung, um agile Entwicklung zur Maxime der Unternehmenskultur zu machen, sind der Mut zu kontinuierlicher Veränderung, das Lernen aus Fehlern und der Wille zur Verbesserung der Prozesse. Das Wesentliche: Alle Mitarbeiter, nicht bloß das Management, müssen beteiligt sein. Nur dann wird agile Entwicklung im Unternehmen auch wirklich gelebt.

http://t3n.de/magazin/praxisbericht-scrum-kanban-scrumbuts-agiles-232822/