Vorheriger Artikel Nächster Artikel

Agiles Projektmanagement: Scrum, Kanban und Scrumbuts im Einsatz

Aus dem
t3n Magazin Nr. 31

03/2013 - 05/2013

Agiles Projektmanagement: Scrum, Kanban und Scrumbuts im Einsatz

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

Links und Literatur

Softlink 3276
  1. 1 http://en.wikipedia.org/wiki/Big_Design_Up_Front
    Big Design Up Front
  2. 2 http://www.scrum.org/ScrumBut
    ScrumBut
  3. 3 http://de.wikipedia.org/wiki/Open_Space
    Open Space
Newsletter

Bleibe immer up-to-date. Sichere dir deinen Wissensvorsprung!

Vorheriger Artikel Zurück zur Startseite Nächster Artikel
6 Antworten
  1. von Frank am 22.08.2013 (22:34 Uhr)

    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 Teilen
  2. von Matthias am 23.08.2013 (09:26 Uhr)

    "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 Teilen
  3. von Laph am 23.08.2013 (16:59 Uhr)

    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 Teilen
  4. von marcus.heinold am 14.09.2013 (02:46 Uhr)

    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 Teilen
  5. von AndreasAt99 am 24.10.2014 (10:59 Uhr)

    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 Teilen
  6. von boris_es am 08.12.2015 (12:52 Uhr)

    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 Teilen
Deine Meinung

Bitte melde dich an!

Du musst angemeldet sein, um einen Kommentar schreiben zu können.

Jetzt anmelden

Alle Hefte Jetzt abonnieren – für nur 35 €

Kennst Du schon unser t3n Magazin?