Das könnte dich auch interessieren

Du hast deinen AdBlocker an?

Es wäre ein Traum, wenn du ihn für t3n.de deaktivierst. Wir zeigen dir gerne, wie das geht. Und natürlich erklären wir dir auch, warum uns das so wichtig ist. Digitales High-five, deine t3n-Redaktion

t3n 31

Agiles Projektmanagement: Scrum, Kanban und Scrumbuts im Einsatz

    Agiles Projektmanagement: Scrum, Kanban und Scrumbuts im Einsatz

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.
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.
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.

Links und Literatur

  1. Big Design Up Front
  2. ScrumBut
  3. Open Space

Finde einen Job, den du liebst zum Thema Online Marketing, Webdesign

6 Reaktionen
boris_es
boris_es

Blöde Frage. Scrum wird ja insbesondere in der Entwicklung eingesetzt. Hier ist das Prinzip einfach: jedes Teammitglied kann fast jede Aufgabe aus dem Backlog umsetzen. Wie funktioniert es aber mit interdisziplinären Teams (z.B. Entwickler, Designer, Konzeptioner, Texter) bei komplexen Projekten?

Insbesondere wenn Aufgabenteile einander bedingen: erst Text - dann Design - dann Entwicklung ...

Antworten

AndreasAt99
AndreasAt99

Mehr über Kanban und speziell "Personal Kanban", also Kanban zur Task-Planung für Privatpersonen, findet man da:

http://99-developer-tools.com/personal-kanban-kanbanpad/

Lesen! wenn Du an Kanban interessiert bist.

Antworten

probeabo
probeabo

Bei einer Webagentur sehe ich im Moment die Probleme eher in der starken Integration des Kunden, wie es z.B. Scrum verlangt. Viele Kunden sind gar nicht bereit oder in der Lage, Anforderungen zu spezifizieren oder mehr zu tun als unbedingt nötig, sie wollen einfach ein fertiges Konzept / Produkt und fertig.

Antworten

Laph
Laph

Ugh! Das Thema KanBan ist doch reichlich verkürzt dargestellt, was den Eindruck erweckt, KanBan wäre quasi statisch, weil es "lediglich den aktuellen Prozess darstellt".

Aber KanBan ist das genaue Gegenteil davon. Lt. der Theorie soll man mit dem Prozess zwar dort starten, wo man ist - diesen dann aber stetig anpassen, wenn es Bedarf dafür gibt.

Und der Kerngedanke von KanBan, die Reduktion paralleler (und daher die Wertschöpfung behindernder) Arbeit durch die Einführung von WiP (Work-in-Progress) Limits kommt auch nur am Rande vor.
Nicht umsonst heißt die primäre Website für KanBan http://www.limitedwipsociety.org

KanBan ist flexibler als Scrum - weniger Regeln, keine Timeboxes - und daher IMHO besonders gut für Agenturen geeignet.

Antworten

Matthias
Matthias

"Oft stellt der Projektleiter im Laufe der Umsetzung dann fest, dass Zeit und Budget nicht ausreichen, um alles zu bewerkstelligen."

Das ist schlicht und pauschal falsch. Ebendas ist eher der Fall in agilen Projekten. Warum? Der Kunde möchte unbedingt ein zumindest abgegrenztes Festpreisangebot haben. Das verträgt sich grundsätzlich natürlich eher weniger mit einem agilen Ansatz. Soweit sich beide Seiten auf einen Rahmen des Umfangs einigen und trotzdem agil vorgehen, kann entsprechend dieses Aufwands auch die gewünschte Funktionalität geändert werden. Hat man sich dann aber im Gesamtprojekt nicht gut überlegt, was man wirklich benötigt und was vielleicht doch später genügt, dann wird ein agiles Projekt in aller Regel viel eher zur Kostenfalle für den Kunden als ein Projekt mit einer Spezifikation oder einer iterativen Spezifikation.

"Die Folgen dieses „Plan Driven Development": Stress, Unzufriedenheit und mangelnde Wirtschaftlichkeit."

Auch hier wieder sehr subjektive Betrachtung des Sachverhalts, der aus meiner Sicht schlicht falsch ist. Stress folgt eher in agilen Projekten für die Entwicklung, weil diese harte und zeitnahe Ziele hat und immer wieder Änderungen unterworfen ist. Diese sind spannend, natürlich, aber diese können auch komplette Architekturen niederreißen.

Für schnelle Ergebnisse oder Produktentwicklungen sind agile Methoden geeignet, auch wenn man den Rahmen absteckt und sich vorher im Klaren ist, was die Kernfunktion bzw. -ziel des Projekts ist. Pauschal aber so zu werten, ist mehr als fraglich und finde ich aus meiner Sicht schlecht. Daher muss ich auch sagen, dass ich von dem Artikel sehr enttäuscht bin, da man die "ich liebe agile Methoden" Brille hier sehr deutlich herausliest und diese Welt ist nunmal nicht rosarot. Der Mittelweg ist meist der Goldene, nicht die Wiese rechts und links davon ...

PS: wie mein Vorredner sagte, Qualität was die Architektur angeht, ist in diesen sehr agilen Vorgehen auch meiner Meinung nach nicht gegeben bzw. einfach sehr wage, da einfach viel zu schnell durch Funktionsänderungen zu zerstören.

PPS: zu den SCRUMBUTS ... wenn man agil entwickelt, dann richtig, wenn man dies so abändert wie hier dargestellt, ist das kein SCRUM und auch keine SCRUM Abwandlung, dann ist das nur ein Buzzword für Marketing Zwecke. Vor allem der Punkt keine Retrospektivmeetings zu machen, nicht ordentlich zu schätzen, Zeitlinien zu verlängern, klar, wenn es nicht anders geht, sollte man einen Ausweg finden, aber hier wird das ja zur Regel verklärt. Sry entweder das geht in einem Projekt oder nicht. Es gibt genügend Alternativen, die nicht starr darauf aus sind, alles komplett vorher tot zu definieren und trotzdem genug Agilität im Projekt zu haben, dass der Kunde noch einen Entscheidungsspielraum hat. Wobei auch die Darstellung oben, der Scope ist fix, das ist richtig, aber eigentlich meint Scope im Englischen nicht den detaillierten Umfang einer Aufgabe, sondern die Rahmenbedingungen und hier wird einfach falsch dargestellt, dass man es unbedingt mit einer totdefinierten Aufgabenstellung herumplagen muss. Es wird auch nicht darauf eingegangen, was die Nachteile sind "Detailspezifikationen folgen nur dann, wenn sie tatsächlich auch nötig sind", das kann extrem nach hinten losgehen, weil sich oft die Erwartungshaltungen von den Parteien unterscheiden, hier liegt der Teufel eben schon im Detail.

Antworten

Frank
Frank

Danke für den übersichtlichen Vergleich der Methoden. Ein Kritikpunkt an Scrum aus dem Bereich ERP-Software ist, dass durch die Fokussierung auf einzelne kleinere Programmierungen, der Blick für die Qualität der Gesamtfunktionalität leidet. Bin gespannt, wie das andere Leser einschätzen.

Antworten

Melde dich mit deinem t3n-Account an oder fülle die unteren Felder aus.

Abbrechen