Agile im Alltag – so funktioniert‘s
Kommentare

In der Theorie funktioniert Agile ja ganz gut, doch wie sieht es eigentlich im realen Arbeitsalltag aus? Schaffen es die Unternehmen auch im echten Leben, den von ihnen so hoch gelobten Prinzipien treu

In der Theorie funktioniert Agile ja ganz gut, doch wie sieht es eigentlich im realen Arbeitsalltag aus? Schaffen es die Unternehmen auch im echten Leben, den von ihnen so hoch gelobten Prinzipien treu zu bleiben oder gehen agile Idealbilder schnell verloren, wenn es hart auf hart kommt?

Dieser Frage widmete sich Alan Ettlin in seiner Session „Agile Methoden in komplexen realen Projektsituationen“ auf der BASTA! Spring 2014. Dort berichtete er von seinem Einsatz als Berater bei einem großen Schweizer Finanzsoftwaredienstleister, der damals von sich behaupten konnte, schon seit zwei Jahren aktiv Scrum zu betreiben.

Nichtsdestotrotz lief bei diesem Kunden so einiges schief. Die Projektleiter arbeiteten nicht richtig mit den Entwicklern zusammen, ein gegenseitiges Vertrauensverhältnis bestand nicht. Dabei kam es soweit, dass einige der Entwickler die Vorgehensweise Scrum sogar aktiv bekämpften oder vor lauter Frustration über das Chaos im Unternehmen und die hohe Arbeitsbelastung kündigten.

In diesem Unternehmen war es nämlich so, dass jeder Mitarbeiter verschiedenen Projekten zugeteilt war. Wer besonders gut war, hatte besonderes Pech, denn ihn wollte logischerweise jeder in seinem Projekt haben. Als ersten Schritt musste deshalb die Struktur der Arbeitsverteilung angepasst werden. Es wurde eine Reihe kleinerer Teams gebildet, in denen gemeinsam an mehreren Projekten gearbeitet wurde. Das nahm einigen Mitarbeitern eine gehörige Last von den Schultern.

Auch hatte fortan nicht mehr jedes Projekt seinen eigenen Product Owner, sondern es gab nur noch einen einzigen, allen anderen übergeordneten Product Owner. Dieser war unter anderem für die Qualitätssicherung zuständig. Außerdem war wichtig, dass der Product Owner ab diesem Zeitpunkt allein für die Releaseplanung zuständig war und nur er Prioritäten für einen Sprint vergeben und den einzelnen Teams ihre Ressourcen zuordnen durfte. Inhaltliche Aufgaben, die der Product Owner aufgrund ihrer schieren Menge nicht alleine bewältigen konnte, sollten künftig an die Story Owners delegiert werden.

Was oft verloren geht, wenn man Agile nicht mehr aus der theoretischen Perspektive betrachtet, sondern im realen Alltag einsetzt, sind die Grundprinzipien eines Product Backlogs. Dieser muss nämlich alle Eigenschaften des DEEP-Prinzips vorweisen können, die da wären: detailed appropriately, estimated, emergent und prioritised. Für die einzelnen Items des Backlogs kommt wiederum das INVEST-Prinzip zum Einsatz, denn diese müssen independent, negotiable, valuable, estimable, small/sized right und testable sein. Auch an diese beiden Akronyme musste der Schweizer Finanzsoftwaredienstleister erst einmal wieder erinnert werden. Im Alltag waren sie ganz einfach verloren gegangen.

Das Unternehmen beschäftigte übrigens auch externe Teams in Brasilien und Osteuropa, was die Frage aufwirft, wie mit diesen in einer agilen Organisation umgegangen werden sollte. Sie wurden mit einem eigenen Product Owner und einem separaten Backlog ausgestattet. An dieser Stelle hob Ettlin besonders hervor, dass man die externen Teams keineswegs in Ablaufstrukturen und Mechanismen der Heimzentrale zwingen darf, sondern ihnen stattdessen ihren eigenen Lernprozess erlauben sollte.

Externe Teams, vergessene Prinzipien… All das ist ja schön und gut, doch sind nicht das wahre Hindernis einer agilen Vorgehensweise im Echtzeiteinsatz die ungeplanten Aufgaben, die ständig aufkommen und natürlich immer so wichtig sind, dass sie so schnell wie möglich erledigt werden müssen? Für derartige Aufgaben hat Ettlin bei seinem Kunden einen Kanban-Prozess parallel zum Scrum-Prozess eingeführt. Durch einen derartigen kontrollierten Parallelprozess wird die ursprüngliche Planung nicht bei jeder unvorhergesehenen neuen Aufgabe komplett über den Haufen geworden. Beim Kanban-Ansatz wird der Workflow visualisiert und in überschaubare Arbeiten aufgeteilt, wobei die dazugehörigen Item Cards auf dem Kanban Board entlang der einzelnen Phasen verschoben werden. Die Work in Progress Limits definieren, wie viele Kanbans sich gleichzeitig in den entsprechenden Phasen befinden dürfen.

Wie Sie sehen, kann der optimalen Umsetzung agiler Methoden im Alltag so einiges in die Quere kommen. Doch mit ein wenig Kreativität und einer Rückbesinnung auf die Grundlagen dieses strategischen Ansatzes lassen sich auch diese Hindernisse in den Griff bekommen. Als Voraussetzung gilt jedoch stets, dass das Team als Ganzes an einem Strang zieht anstelle gegeneinander zu arbeiten.

Aufmacherbild: Conceptual image of business woman without head von Shutterstock / Urheberrecht: Hasloo Group Production Studio

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -