Mut, Respekt und Transparenz: Was bedeutet agiles Arbeiten?

Kaum ein Unternehmen wirbt heute nicht mit Schlagwörtern wie „agile“, „agiles Arbeiten“ oder „agiles Projektmanagement“ um Fachkräfte und Kunden. Jeder, der irgendwie in Projektarbeiten oder ins Projektmanagement involviert ist, hat sofort eine Idee, was sich hinter agilen Methoden verbirgt. Auch den Namen der gebräuchlichsten Methode des agilen Projektmanagements – „Scrum“ – haben die meisten schon einmal gehört. Doch was steckt dahinter? Was ist ein „Scrum Team“? Für wen eignen sich diese Methoden ‒ und für wen nicht?

Agil arbeiten heißt effizient arbeiten ‒ nicht nur in der Softwareentwicklung

Bereits Mitte der 1990er-Jahre beschäftigten sich Manager damit, wie sich Projekte effizienter umsetzen lassen beziehungsweise damit, warum dies bis dahin oft nicht möglich war. Der „CHAOS Report“ der Standish Group hat seit 1994 rund 50.000 Projekte daraufhin untersucht, ob sie erfolgreich, verspätet beziehungsweise teurer als geplant oder gar nicht zu einem erfolgreichen Ende gekommen sind. Das Ergebnis 2020: Ein Viertel der mit klassischem Projektmanagement bearbeiteten Aufgaben war im Zeit- und Budgetplan und kam erfolgreich zum Abschluss. Bei den agil gemanagten Projekten waren es mit 71 Prozent deutlich mehr.

Agiles Projektmanagement zahlt sich also offenbar aus – sowohl zeitlich als auch finanziell. Deshalb müssten eigentlich alle Unternehmen großes Interesse daran haben, agil zu werden oder wenigstens im Rahmen des Projektmanagements agile Methoden anzuwenden. Doch die Prozesse unterscheiden sich – und nicht für alle Unternehmen und Projekte eignet sich das agile Arbeiten.

Die Vorteile agiler Projekte

Die am häufigsten verwendete agile Methode ist Scrum, so das Ergebnis einer Studie des Marktforschungsunternehmens Bitkom Research ergeben. Die Gründe, weshalb sich das Management für Scrum entscheidet: 72 Prozent der befragten Unternehmen sehen vor allem Projektergebnisse in besserer Qualität als entscheidenden Vorteil an, 53 Prozent begrüßen die einfachere Zusammenarbeit mit IT-Freelancern als einen positiven Effekt. Jeweils etwa die Hälfte aller deutschen Unternehmen sieht die Chance von agilem Projektmanagement vor allem in der schnelleren Projektumsetzung und im schnelleren Erkennen und Reagieren auf auftretende Probleme.

Ein ebenfalls nicht ganz unwichtiger Faktor: Gut jedes dritte Unternehmen, das agiles Projektmanagement betreibt, sieht die Mitarbeitermotivation durch mehr Verantwortung und selbstständiges Arbeiten steigen ‒ ein wichtiger Pluspunkt für agile Prinzipien, ein Nachteil für klassisches Projektmanagement.

Welches ist die beliebteste Methode?

Methoden des agilen Projektmanagements gibt es viele; sie werden Frameworks genannt. Ihnen gemein ist, dass sich die Teammitglieder mindestens einmal täglich über ihre Arbeit austauschen. So ist es allen Beteiligten möglich, frühzeitig auf Probleme oder veränderte Gegebenheiten zu reagieren; die Prozesse bleiben flexibel.

SCRUM

Die Definition von Scrum

Scrum ist keine Abkürzung, sondern steht für das, was das englische Wort bedeutet: geordnetes Gedränge. Der Begriff stammt aus dem Rugby und bezeichnet die Formation, bei der alle Spieler eines Teams gemeinsam und mit Hochdruck versuchen, den Ball zu ergattern und ihn auf die richtige Spielfeldseite zu schieben.
Die Idee, diese Art von Teamarbeit auf das Projektmanagement zu übertragen, stammt von den japanischen Wissenschaftlern Ikujiro Nonaka und Hirotaka Takeuchi. Die US-Amerikaner Jeff Sutherland und Ken Schwaber haben sie in den 1990er-Jahren weiterentwickelt. Die beiden haben auch 2001 das sogenannte Scrum-Manifest, auch „Agile Manifesto“ genannt, veröffentlicht und überarbeiten das Regelwerk regelmäßig, das in der jeweils aktuellen Form auf scrum.org abrufbar ist. Ausführlicher ist Scrum und die dahinterstehende Idee im Scrum Guide erklärt.

Scrum ist eines von vielen Frameworks, sprich eine von vielen Methoden des Projektmanagements. Wer mit Scrum als Framework arbeitet, gehört einem Scrum Team an. Zwar hat Scrum seine Wurzeln in der Softwareentwicklung, dennoch lässt es sich auch in anderen Bereichen anwenden.

Die Rollen im Scrum Team

Die Scrum-Regeln besagen: Ein hohes Maß an Eigenverantwortung ist notwendig, damit die Prozesse geschmeidig bleiben. Dies impliziert, dass alle Beteiligten wissen, was von ihnen erwartet wird. Dazu gibt es verschiedene Rollen. Im Folgenden sind diese definiert.

Was macht der Product Owner?

In jedem Scrum Team gibt es einen Product Owner. Er ist die einzige Person im Projektmanagement, die den Kontakt zum Kunden hält, für den ein Produkt oder ein Service entwickelt werden soll. Der Product Owner kennt die Wünsche des Kunden am besten und arbeitet eng mit dem Team zusammen. Er gibt dem Team vor, welche Eigenschaften das Produkt haben muss und priorisiert diese. Alle Infos stehen im Product Backlog, dem ausformulierten Briefing für das Produkt. Wie die Ziele erreicht werden, erarbeitet das Team.
Zudem holt sich der Product Owner durch regelmäßige Präsentationen von Zwischenlösungen das Feedback vom Kunden ein. Auf diese Weise ist es möglich, schnell auf veränderte Bedingungen zu reagieren. Jeder Product Owner sollte nur ein Produkt zugleich verantworten, das seine volle Aufmerksamkeit fordert.

Welche Aufgabe hat der Scrum Master?

Wie den Product Owner gibt es auch den Scrum Master nur einmal in jedem Team. Er ist so etwas wie der Assistent der Developer, also der übrigen Teammitglieder, und sorgt dafür, dass diese gut arbeiten können. Das bedeutet konkret, dass der Scrum Master die Daily Scrums, also die täglichen Meetings, moderiert. Er ist dafür zuständig, dass Scrum im Team erfolgreich umgesetzt wird. Sobald irgendwo Fragen oder Probleme auftauchen, steht der Scrum Master bereit, um diese zu lösen.

Während der Product Owner für die inhaltlichen Anforderungen zuständig ist, verantwortet der Scrum Master die technischen Gegebenheiten und die Arbeitsabläufe. Außerdem moderiert der Scrum Master den Sprint Review. Das ist eine Art Manöverkritik am Ende jedes Arbeitsabschnittes, die Sprint genannt werden.

Die Arbeit der Developer

Developer werden die übrigen Mitglieder des Scrum Teams genannt, welche die Arbeit mithilfe agiler Methoden ausführen. An dieser Bezeichnung ist am deutlichsten erkennbar, dass Scrum aus der Programmierung kommt. In jedem Entwickler-Team sitzen Kollegen aus allen für das Produkt erforderlichen Gewerken, so dass sie gemeinsam das Produkt fertigstellen können.

Wie ist der Ablauf bei Scrum organisiert?

Bei einem Scrum-Projekt wird in sogenannten Scrum-Sprints gearbeitet. Damit wird der Arbeitsrhythmus respektive das Tempo bereits angedeutet. Sprints bezeichnen einzelne Abschnitte, die zwischen einer und vier Wochen dauern können und während derer die einzelnen Arbeitsabschnitte erledigt werden.

Für jeden Arbeitsschritt wird die „Definition of Done“ festgelegt: Welchen Anforderungen muss er genügen, damit er als fertig gelten kann? Bei Programmen zählt: Wie lautet die User-Story, welchen Anforderungen eines Anwenders muss das Programm genügen? Hier wird zudem deutlich: Für Perfektionismus bleibt in einem Sprint keine Zeit.

Die Sprints laufen in festgelegter, immer gleichbleibender Form ab. Da auch die Dauer identisch bleibt, ist es notwendig, dass die Arbeitsschritte in ähnlich große Abschnitte geteilt werden. Diese Aufteilung ist die Aufgabe des gesamten Teams.

Ein Sprint verläuft in mehreren Schritten, die sich vor allem durch offene Kommunikation untereinander auszeichnen.

1.Sprint-Planning: Der Product Owner lädt zum Sprint Planning oder zur Sprint-Planung ein, der Scrum Master moderiert, alle Developer des Scrum Teams sind dabei. Besprochen werden zwei grundlegende Fragen:

• Welche Aufgabe aus dem Backlog des Product Owners soll bearbeitet werden?
• Wie soll dieses Sprint-Ziel erreicht werden?
• Die einzelnen Ziele werden im Sprint-Backlog aufgeführt, ebenfalls nach Priorität.

2. Daily Scrum: Während eines Sprints findet täglich ein Meeting statt, das Daily Scrum. Jeder Developer beantwortet drei Fragen:

• Was habe ich gestern für unser gemeinsames Ziel erreicht?
•  Was werde ich heute dafür tun?
• Was hindert mich oder das gesamte Team an der Erreichung des Sprint-Ziels?

Diese Auseinandersetzung dient dazu, Probleme wirklich anzugehen. Das Team darf ihnen nicht ausweichen. Deshalb gilt: Sprints werden niemals abgebrochen. Zudem werden die anfänglich erarbeiteten Ziele nicht verändert – es sei denn, der Product Owner verlangt dies nach Rücksprache mit dem Kunden.

3. Sprint Review: Am Ende des Sprints findet der Sprint Review statt, an dem das gesamte Team sowie eventuell Stakeholder wie Kunden oder Lieferanten teilnehmen. Die Ergebnisse aller Beteiligten werden besprochen und präsentiert. Feedback zum Ablauf oder den Ergebnissen lässt sich in die Planung des kommenden Sprints integrieren.

Es geht darum, sich einen Überblick zu verschaffen, welche Punkte aus dem Product Backlog zuletzt erreicht wurden und welche noch fehlen. Und es geht um die Planung des nächsten Sprints: Welche Veränderungen müssen aus Sicht des Product Owners bei den Zielen vorgenommen werden? Diese hohe Flexibilität ist wichtiges Merkmal von agilem Projektmanagement.

4. Sprint Retrospektive: Auch die Retrospektive findet regelmäßig nach einem abgeschlossenen und vor dem nächsten Sprint statt. Im Gegensatz zum Review, bei dem es um die erreichten Ziele geht, wird bei der Retrospektive über das Team selbst gesprochen: Wie lief die Zusammenarbeit? Was lief nicht gut, wie lässt sich dies verbessern? Gute Zusammenarbeit im Team ist ein wesentliches Merkmal von agilen Methoden.

Die Instrumente

Das Scrum-Modell kennt drei Scrum-Artefakte: das Product Backlog, das Sprint Backlog und das Product Increment. Dabei handelt es sich um Dinge, Aufgaben oder Produkte, die hergestellt oder erledigt werden müssen.

1.  Das Product Backlog wird von Product Owner geführt. Es umfasst die einzelnen priorisierten Arbeitsschritte bis zur Fertigstellung des Gesamtauftrags. Es wird einmal als Ganzes geschrieben und verändert sich mit den Gegebenheiten – etwa bei veränderten Kundenwünschen oder neuen gesetzlichen Vorgaben. Im Product Backlog ist auch die User Story enthalten.
2. Das Sprint Backlog wird jeweils beim Sprint Planning zusammengestellt und speist sich aus dem Product Backlog. Es stellt quasi die Checkliste für den aktuellen Sprint dar. Verantwortlich für das Sprint Backlog ist das gesamte Team, das in die Planung involviert war.
3. Das Product Increment ist die Summe aller bereits erledigten Aufgaben aus dem Product Backlog. Am Ende eines jeden Sprints sollte ein neues Increment entstehen. Das gesamte Product Increment dokumentiert, wie stark das Produkt wächst.

Die Scrum-Prinzipien

Voraussetzung für agiles Arbeiten ist eine entsprechende agile Haltung. Sie muss vom Management vorgelebt werden. Diese Haltung ist in den vier Werten des „Agile Manifesto“ festgehalten, das regelmäßig im Scrum Guide aktualisiert wird. Die Werte lauten wie folgt:

1. Individuen und Interaktionen sind wichtiger als die Prozesse und Werkzeuge.
2. Eine funktionierende Software ist wichtiger als eine umfassende Dokumentation.
3. Die Zusammenarbeit mit dem Kunden ist wichtiger als Vertragsverhandlungen.
4. Das Reagieren auf Veränderungen ist wichtiger als das Verfolgen eines Plans.

Diese Werte bedeuten für agile Arbeitsgruppen ein hohes Maß an Eigenverantwortung bei gleichzeitig flachen Hierarchien. Es ist zudem wichtig, dass das Beheben der konkret auftretenden Probleme oberste Priorität hat. Die Autoren von Scrum.org Jeff Sutherland und Ken Schwaber sagen: „Scrum ist leichtgewichtig, einfach zu verstehen, aber schwierig zu meistern.“

Warum sollte man auf Scrum setzen?

Scrum ist eine der beliebtesten Projektmanagement-Methoden für das agile Arbeiten. Indem eine große Aufgabe in viele Häppchen geteilt wird und diese während der Sprints erledigt werden, bleibt das Gesamtprojekt übersichtlich. Die agile Arbeitsweise ist transparent, weil jeder Beteiligte sofort erkennt, auf welchem Stand sich das Projekt gerade befindet.

Und, noch wichtiger: Sollte es an einer Stelle zu Problemen kommen, werden diese sofort sichtbar und das Team ist dank Scrum dazu gezwungen, sich mit einer Lösung zu befassen.

Agile Methoden erfordern die Offenheit und den Mut, Lücken und Defizite anzusprechen. Mitglieder von Teams, die agil arbeiten, vertrauen aufeinander und haben sich zu einem gemeinsamen Ziel verpflichtet. Das Entwicklungsteam ist gemeinsam verantwortlich für die Ergebnisse seiner Arbeit, indem sie sich ehrlich austauschen.

KANBAN

Was ist Kanban?

Kanban, die zweithäufigste Methode für agiles Projektmanagement, stammt ebenfalls ursprünglich aus Japan – genauer gesagt aus dem Toyota-Production-System und der Just-in-time-Produktion.

Kanban ist deutlich älter als Scrum. Das Wort bedeutet „visuelles Signal“. Augenfälligstes Merkmal ist eine weiße Tafel mit verschiedenen Spalten, etwa „in Auftrag“, „in Bearbeitung“ und „erledigt“. Auf diesem Kanban-Board kleben Post-its mit den einzelnen Aufgaben, die je nach Fortgang in die entsprechende Spalte wandern.

Gemeinsamkeiten und Unterschiede zwischen Scrum und Kanban

• Zunächst eine Gemeinsamkeit: Die Kanban-Methode hat seinen Ursprung ebenfalls in Japan und ist sogar noch älter als Scrum. Die Methode wurde in den 1940er-Jahren entwickelt und stammt aus dem Toyota-Production-System, einer Just-in-time-Produktion ‒ einem System also, das schnell auf Nachfrage reagiert.
• Eine weitere Gemeinsamkeit mit Scrum ist das Abhalten von täglichen Meetings, hier Stand-ups genannt, was die kurze Dauer illustriert. Ziel ist die Verbesserung der Zusammenarbeit der Kolleginnen und Kollegen sowie das Identifizieren von Problemen, die es zu beheben gilt.
• Anders als bei Scrum gibt es bei Kanban keine agile Rollenverteilung. Es gibt also weder Product Owner noch Scrum Master, sondern die klassische Rollenverteilung inklusive bestehender Hierarchien bleibt bestehen. Dies soll verhindern, dass die Einführung von neuen Projektmanagement-Methoden Ängste auslöst, die das Arbeiten behindern.
• Auch bei Kanban geht es darum, dass alle den Überblick haben. Aber: Während bei Scrum das große Ganze in zeitliche und inhaltliche Sprints aufgeteilt wird, die regelmäßig besprochen werden, sorgt hier das große Whiteboard für Übersichtlichkeit.

Die Kanban-Prinzipien

1.Visualisierung

Genau wie bei Scrum werden die Aufgaben priorisiert. Sie werden etwa auf Klebezettel geschrieben und am weißen Brett in die Spalte „in Auftrag“ geklebt. Sobald sich jemand der Aufgabe annimmt, wandert der Klebezettel weiter in die Spalte „in Arbeit“, bis er am Ende bei „erledigt“ klebt. Das Product Backlog und das Sprint Backlog hängen also in Form von Post-its am Whiteboard.

2.Begrenzung

Am Whiteboard ist ablesbar, woran jeder Mitarbeiter zu einem Zeitpunkt gerade arbeitet. Der „work in progress“ muss dabei limitiert sein. Jeder Mitarbeiter darf also nur eine bestimmte Anzahl von Aufgaben zugleich zu erledigen haben, denn sonst „verzettelt“ er sich buchstäblich. Auch freie Kapazitäten werden so sichtbar gemacht.

3.Workflow

Wird auf Kanban gesetzt, sollen Übergänge zwischen einzelnen Aufgaben und Beteiligten geschmeidig sein; der Arbeitsfluss ist gut organisiert und gerät nicht ins Stocken.

4.Richtlinien

Alle wissen, warum sie etwas machen. Alle Beteiligten können sich einbringen und aufgrund ihres Know-hows die richtigen Entscheidungen zur Prozessoptimierung treffen.

Methode oder Einstellung

Die Nachteile von agilen Projektmanagementmethoden hängen eng mit deren Chancen zusammen. Agiles Arbeiten erfordert Mut, Respekt und Offenheit. Dort, wo Teams aber nicht gut funktionieren, gehen auch diese Chancen verloren. Ein Leitsatz lautet daher: „Scrum beseitigt keine Probleme, sondern macht sie sichtbar.“

Wichtig für das Gelingen ist die richtige Besetzung der Scrum-Rollen des Product Owners und des Scrum Masters. Für beide Rollen vermitteln entsprechend zertifizierte Kurse das notwendige Know-how. Wichtig ist, sich immer über eines im Klaren zu sein: „Agilität ist die Fähigkeit einer Organisation, sich auf Veränderungen einzustellen und flexibel zu reagieren.“