Agile Tools – Werkzeug für agiles Arbeiten

Was versteht man unter agilen Tools?

Agile Tools oder Werkzeuge sind konkrete Maßnahmen, die bei der Umsetzung agiler Methoden unterstützen. Sie sind effizient, ermöglichen Lernen, Erkenntnisgewinn und stetige Verbesserung durch empirisches Vorgehen und unterstützen so die Wertschöpfung.

Agile Werkzeuge zum Ausprobieren

Agile tools benötigen nicht zwingend eine agile Arbeitsumgebung. Sie können auch in klassischen Arbeitsumfeldern für eine Verbesserung der Zusammenarbeit sorgen und Raum für neue Ideen auf Produktebene bieten.

Die Retrospektive – Lernkultur etablieren

Eine Retrospektive – auch Retro genannt – ist ein Format aus dem Scrum Framework. In 5 strukturierten Schritten wird dabei die Vergangenheit oder der Status-Quo reflektiert. Aus dieser Reflektion werden Schlüsse gezogen und konkrete Maßnahmen für die Zukunft entwickelt. Retrospektiven sollten in regelmäßigen Abständen durchgeführt werden. So wird eine kontinuierliche Verbesserung unterstützt und Veränderungsfähigkeit verankert. Retrospektiven können innerhalb von Teams, zwischen Teams oder Abteilungen die eng zusammenarbeiten, oder auch mit Kunden oder Lieferanten zusammen durchgeführt werden.

Die 5 Phasen einer Retrospektive:

• Rahmenbedingungen schaffen – Set the Stage
• Informationen sammeln
• Erkenntnisse gewinnen
• Entscheiden, was zu tun ist
• Abschluss

Checkliste für die Vor- und Nachbereitung:

• Gibt es einen Moderator und ist jedem klar, wer das ist?
• Hält sich der Moderator aus der inhaltlichen Diskussion heraus?
• Sind alle Materialien vorbereitet?
• Wird die Timebox für die Retrospektive eingehalten?
• Findet die Retrospektive in einer angstfreien, energiegeladenen Atmosphäre statt?
• Partizipieren alle Teilnehmenden aktiv an der Retrospektive?
• Werden die Ursachen für Probleme analysiert?
• Generiert die Retrospektive konkrete, umsetzbare Maßnahmen?
• Werden die beschlossenen Maßnahmen schnell umgesetzt?

Hier kannst Du Dir auch unser Workbook für Retrospektiven downloaden.

Das Daily Standup – Selbstorganisiert Arbeit im Team koordinieren

Das Daily Standup ist ein tägliches Treffen, indem ein (agiles) Team sich und seine Arbeit selbst organisiert – ohne die Beteiligung von Managern oder externen Entscheidern. Im Fokus stehen alle Aktivitäten, die für einen reibungslosen Projektablauf erledigt werden müssen.

Die Teilnehmer des Daily Standups stehen maximal 15 Minuten zusammen und sprechen der Reihe nach über die Ergebnisse des Vortages, was sie sich für den aktuellen Tag vorgenommen haben und ob es Hindernisse oder Fragen gibt. Auf diese Weise machen die Team-Mitglieder den Arbeitsstand sowie größere Probleme transparent und können sich gegenseitig helfen, diese aus dem Weg zu räumen. Voraussetzung ist, dass die Teammitglieder eng inhaltlich zusammenarbeiten und konkrete gemeinsame Ziele verfolgen.

Ein Daily Standup ist kein Statusreport! Der Zweck des agilen Tools ist in erster Linie, die Kommunikation und den Projektablauf durch schnelleres Feedback zu verbessern. Regelmäßigkeit und gleicher Ort verringern Komplexität, Die Limitierung des Standups auf 15 Minuten erzielt eine Fokussierung auf das Wesentliche und auf die relevantesten Themen.

Das Daily Standup ist durch 3 Kernfragen bestimmt:

• „Mit Blick auf unser gemeinsames Ziel habe ich gestern erreicht, dass …“
• “Mit Blick auf unser gemeinsames Ziel will ich heute als Nächstes erreichen, dass…“
• “Mit Blick auf unser gemeinsames Ziel blockiert mich …“

Task-Boards – Den Arbeitsfluss visualisieren

Visuelle Boards, physisch oder digital (z.B. Trello, Asana oder Jira), können helfen, den Überblick zu behalten über die Arbeit, die zu erledigen oder in Bearbeitung ist. Task-Boards können auf individueller oder auf Teamebene aufgesetzt werden. Häufig werden solche Task-Boards als Kanban-Boards bezeichnet – sie orientieren sich an Kanban und den zugrundeliegenden Prinzipien, setzen diese aber nur teilweise um. Das kann dennoch hilfreich und ein sinnvoller erster Schritt hin zu einem Kanban-System sein.

Das einfachste Setup auf einem Task-Board sind die Spalten “Zu erledigen”, “In Arbeit” und “Erledigt”. Das bietet einen schnellen Überblick über einzelne Aufgaben. Tipp: Die geschätzte Dauer für die Aufgabe notieren, das macht die Planung einfacher.

Aber auch bei einem Task-Board ist zu beachten, dass es nicht zu kleinteilig wird und der Arbeitsaufwand für das Aufsetzen und die Pflege in einem guten Verhältnis zur tatsächlichen Arbeit steht.

Wichtig ist hier: ein Taskboard ist nur dann wirklich hilfreich, wenn es aktuell gehalten wird. Wer die Arbeit mit dem Task-Board ernst nimmt, wird schnell Beobachtungen machen, aus denen sich Erkenntnisse ableiten lassen. Wo staut es sich? Ist zu viel gleichzeitig in Arbeit? Sind die Aufgaben sinnvoll priorisiert? Wo verstecken sich Zeitfresser? In Kombination mit regelmäßigen Mini-Retrospektiven lässt sich schnell herausfinden, ob das Tool hilfreich ist und wo Verbesserungspotenziale liegen. Task-Boards sind auch sehr gut im privaten und familiären Bereich einsetzbar.

Delegation Poker – Selbstorganisation ermöglichen

Wer ist eigentlich wofür verantwortlich und wer macht was? Wenn zu diesen Fragen in einem Team, in Projekten oder zwischen Abteilungen kleine Klarheit herrscht, wird die Zusammenarbeit schwierig – egal ob agil oder nicht. Im agilen Umfeld wird mehr Selbstorganisation angestrebt, um die besten Lösungen zu finden.

Das Tool  “Delegation-Poker“ von Jurgen Appelo (Management 3.0) kann dabei helfen. Delegation Poker ist ein einfaches Spiel, um zu klären, wer im Team welche Verantwortlichkeiten und Entscheidungsfreiräume hat. Es ist ein gutes Tool für Führungskräfte, um Selbstorganisation und Motivation im Team zu stärken und Entscheidungsprozesse transparent zu machen. Delegation Poker unterscheidet sieben Ebenen des Delegierens:

1. Verkünden: Ich entscheide – danach informiere ich darüber
2. Verkaufen: Ich entscheide – und überzeuge nachher, dass das so richtig war
3. Befragen: Ich entscheide, aber vorher bitte ich um Rat und beziehe dies in meine Entscheidung ein
4. Einigen: Wir entscheiden gemeinsam, nachdem wir diskutiert und einen Konsens gefunden haben
5. Beraten: Du entscheidest, aber ich biete Dir meine Meinung an
6. Erkundigen: Du entscheidest und ich erkundige mich hinterher wie Du entschieden hast
7. Delegieren: Du entscheidest und ich muss nicht wissen, wie Du Dich entschiedet hast und warum

Das Spiel lässt sich im gesamten Team spielen, jede und jeder wählt zu einer bestimmten Frage oder Entscheidungssituation eine Karte und anschließend werden die gelegten Karten (Delegationslevel) diskutiert, um zu einer Lösung zu kommen.

Die Story Map – Produkte weiterentwickeln

Mit einer Story Map nach Jeff Patton können Anforderungen an Produkte oder Dienstleistungen übersichtlich dargestellt werden. Dabei steht der Kunde im Fokus. Eine Story Map kann dabei helfen, bessere Produktentscheidungen zu treffen.

Eine Story Map …

• ermöglicht, durch den zweidimensionalen Aufbau das “Big Picture” zu sehen
• ist ein Werkzeug für Produktentscheidungen und die Priorisierung
• fördert einen kollaborativen Ansatz für die Erstellung der User Stories (Anforderungen)
• fördert einen iterativen Entwicklungsansatz, bei dem Produktinkremente und Lösungen früh validiert werden können
• ist eine visuelle Alternative zu Projektplänen
• ist ein Modell für die Diskussion über den Scope des Produkts

Wie erstellt man eine Story Map?

1. Eine Gruppe von 3-5 Menschen zusammenstellen, die den Zweck des Produkts verstehen.
2. Die Gruppe: “User Tasks” erstellt mit gleichfarbigen Post-Its das „Skelett“ der Story Map.
3. Das Team gruppiert die Post-its. Ähnliche User Tasks werden zusammen gruppiert und Tasks, die sich stark unterscheiden, werden weiter voneinander entfernt angeordnet.
4. Gefundenen Gruppierungen werden mit Post-Its einer anderen Farbe benannt. Diese Gruppierungen sind die „User Activities, die das “Backbone” der Story Map bilden.
5. Gruppierungen von links nach rechts in der Reihenfolge anordnen, in der ein Benutzer die User Tasks ausführen würde.
6. Unterhalb jedes User Tasks werden User Stories hinzugefügt. Der Titel einer User Story reicht aus.
7. Anhand der gefundenen User Stories kann das Team nun Releases planen, Abhängigkeiten erkennen oder Risiken identifizieren.
8. Alle User Stories aus dem ersten Release werden anschließend genauer ausgearbeitet. Das erste Release sollte so klein wie möglich sein, gleichzeitig aber den wichtigsten Funktionsumfang abbilden.

Wenn Du mehr über agile Tools und Agilität erfahren möchtest, dann schau doch in unserem Kurs Agile Methoden verstehen und anwenden vorbei!