Agiles Glossar

Es gibt keine allgemeine Definition eines agile Coaches. Für uns ist die Aufgabe eines agile Coaches die folgende:

Die Begleitung von Einzelpersonen, Teams und Organisationen in die Erfüllung der agilen Prinzipien.

Agile Coaches setzen hierfür auf Trainings, Workshops und natürlich Coaching. Sie orientieren sich dabei am Bedarf ihrer Klient*innen und können hierbei auch die Aufgaben von Scrum Master*innen übernehmen. Die Grenzen zwischen Scrum Master*innen und agile Coaches sind teils fließend. Der entscheidende Unterschied: Scrum Master*innen sind immer Teil des Teams und damit auch in der Ergebnisverantwortung. Agile Coaches nutzen ihre Distanz zur Sache, um das vorhandene System auch auf der Meta-Ebene zu challengen.

Das agile Manifest wurde in 2001 niedergeschrieben. Es handelt sich hierbei um vier Wertepaare, die sich gegenüberstehen. Dabei wollen sie vor allem eines sagen: Wenn wir uns in unserer Arbeit entscheiden müssen, entscheiden wir uns immer für den erstgenannten Teil der Wertepaare.

• Individuen und Interaktionen mehr als Prozesse und Werkzeuge.

• Funktionierende Software mehr als umfassende Dokumentation.

• Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlungen.

• Reagieren auf Veränderung mehr als das Befolgen eines Plans.

Mehr zum agilen Manifest findet ihr hier.

Die zwölf Prinzipien hinter dem agilen Manifest ergänzen dieses um handlungsleitende Prinzipien. Sie sind nicht als starre Regeln aufzufassen, sondern dienen vielmehr der Orientierung. Außerdem sind die Prinzipien häufig nicht alle gleichwertig: Ihr müsst euren eigenen Fokus setzen und herausfinden, welche agilen Prinzipien für euch die größten Hebel beinhalten.

Die agilen Prinzipien könnt ihr hier nachlesen: https://agilemanifesto.org/iso/de/principles.html

Das Wort Cynefin kommt aus dem Walisischen und steht für Lebensraum, Habitat, einen Ort mit seiner Geschichte. Das Cynefin-Framework von Dave Snowden hilft dabei, die richtige Vorgehensweise für eine Aufgabenstellung / ein Projekt auszuwählen. Denn: die eine richtige Vorgehensweise gibt es nicht. Design Thinking, Scrum, Kanban und auch Wasserfall funktionieren dann, wenn sie zum Lebensraum der Aufgabenstellung passen.

Das Daily Scrum ist ein tägliches, 15-minütiges Event des Umsetzungsteams. Ziel dieses Events ist es, im Team gemeinsam den Fortschritt des Sprints zu überprüfen und das Sprint Backlog bei Bedarf anzupassen. Product Owner*in und Scrum Master* in nehmen nach Bedarf an diesem Event teil. In der Praxis haben sich viele Teams für drei Fragen innerhalb des Daily Scrums etabliert: “Was habe ich gestern gemacht? Was werde ich heute tun? Welche Fragen/Hindernisse habe/sehe ich?” Die Nutzung dieser Fragen ist allerdings keine Pflicht. Das Umsetzungsteam entscheidet, in welcher Form das Daily Scrum stattfindet.

Das Daily Scrum findet jeden Tag zur gleichen Zeit am gleichen Ort statt und wird möglichst im Stehen durchgeführt. Das Scrum Team darf sich selbstverständlich auch außerhalb dieses Events zum Sprintfortschritt oder einzelnen Anforderungen austauschen.

Die Definition of Done beschreibt einen Standard von Qualitätsanforderungen, der von einem Inkrement, also einer fertig- gestellten Anforderung, erfüllt sein muss. Sie wird entweder - sofern vorhanden - vom Unternehmen vorgegeben oder vom Scrum Team während der Umsetzung entwickelt. Dabei ist es möglich, für unterschiedliche Kategorien von Inkrementen ggf. unterschiedliche Definitions of Done zu entwickeln, wenn eine übergreifende Definition of Done zu viel Komplexität enthält.

Userstorys, die im Planning vorgestellt werden und anschließend in die Umsetzung gehen, sollten der Definition of Ready entsprechen. Die Definition of Ready bedeutet, dass die Userstory alle notwendigen Informationen enthält, um sie erfolgreich umzusetzen.

Ziel ist es, die Zeit in der Umsetzungsphase für die tatsächlich produktiven Umsetzung von Userstorys zu nutzen und sie nicht damit zu verbringen, Informationen zu sammeln und Fragen zu klären, die im Vorfeld hätten bearbeitet werden können.

Epics dienen als Gliederungseinheit innerhalb des Product Backlogs (Sammlung der bekannten Anforderungen). Sie beschreiben Anforderungen auf einer hohen Abstraktionsebene und lassen Details bewusst außer Acht. Sie können auch als „Themenbereiche“, „Unterprojekte“ oder „Gruppierung“ verstanden werden.

Ein Inkrement oder Produktinkrement ist ein in sich fertiges Teil eines größeren Produkts / Ergebnisses.

Eine Iteration meint einen Sprint: ein Vorhaben wird in Scrum schrittweise umgesetzt. Ein Team setzt eine Anforderung um, überprüft diese und passt diese dann ggf. in einer folgenden Iteration weiter an.

Kanban ist eine Methode, in der es darum geht, anfallende Aufgaben anhand der Wertschöpfungskette mit möglichst wenig Verschwendung umzusetzen. Es nutzt eine Art Fluss-System, damit Kapazitäten optimal verteilt werden können. Dabei gilt es einige Details zu beachten, z.B. das Work-in-Progress-Limit und das Pull-Prinzip.

Bei der Umsetzung von Projekten/Produkten/Aufgabenstel- lungen mithilfe von Scrum geht es häufig darum, ein Minimum Viable Product (MVP) zu erschaffen. Das MVP ist ein minimal brauchbares/existenzfähiges Pro- dukt. Dabei kommt es in der Praxis immer wieder zu Abwä- gungsdiskussionen zwischen “minimum” und “viable”, da diese Begriffe durch Unternehmen und Teams individuell definiert werden müssen. Gemeint ist hiermit das kleinstmögliche Produkt, das entwickelt werden kann, aber dennoch die Anforderungen der Kund*innen ausreichend bedient, um vorhandene Bedürfnisse zu befriedigen. Entscheidend ist also, die Bedürfnisse der Nutzenden in den Fokus zu rücken. Daraus wird abgeleitet, welche Features an einem Produkt tatsächlich zwingend erforderlich sind, weil sie echte Bedürfnisse bedienen, und welche wiederum eher einen Zusatznutzen erfüllen, der auch zu einem späteren Zeitpunkt ergänzt werden kann, wenn sich hiervon weiterer Wert versprochen wird.

Das Planning, oder auch Sprint Planning, startet einen Sprint. Innerhalb des Plannings definiert das Scrum Team, welche Anforderungen und/oder Inkremente im kommenden Sprint umgesetzt werden sollen.

Das Product Backlog bezeichnet die Sammlung aller bekannten Anforderungen an ein Produkt bzw. Ergebnis. Es wird regelmäßig verfeinert, aufgeräumt und erweitert. Aus dem Product Backlog werden diejenigen Anforderungen ausgewählt, die in einem Sprint umgesetzt werden sollen.

Die Rolle Product Owner wird in Unternehmen unterschiedlich gelebt. Die konkrete Gestaltung der Aufgaben ist stark vom Unternehmen, Projekt/Produkt und Umfeld abhängig. Generell lässt sich aber sagen: Product Owner entwickeln das Backlog für das Projekt/Produkt. Hierfür müssen sie zunächst die Produkt-/Projektvision und/oder das Produkt-/Projektziel entwickeln und definieren. Hieraus lassen sich dann die Items für das Product Backlog erstellen. Items sind Epics oder Userstorys, welche die Anforderungen für das Produkt/Projekt enthalten.

Dabei legt die Rolle Product Owner die Priorität dieser Items fest und entscheidet anhand derer, in welcher Reihenfolge die Items umgesetzt werden sollen. Eine weitere Aufgabe der Rolle ist es, die Bedürfnisse und Wünsche der Stakeholder*innen in das Backlog aufzunehmen und dafür zu sorgen, dass das Backlog für alle Beteiligten (wie Stakeholder und den Rest des Scrum Teams) transparent, bekannt und verstanden ist.

Das Refinement ist ein Event, welches im offiziellen Scrum Guide nicht erwähnt wird. In der Praxis dient es der Rolle Product Owner, dem Umsetzungsteam und/oder Stakeholder*innen dazu, das Backlog mit seinen Anforderungen zu schärfen und zu verstehen.

Auch können Anforderungen und Userstorys hier bereits in ihrem Umfang geschätzt werden.

Die Rolle Product Owner lädt zum regelmäßigen Refinement des Backlogs ein. Ziel des Termins ist es, die Userstorys auf Unklarheiten und Ungenauigkeiten zu überprüfen, sodass diese zum Sprint Planning geklärt werden können. Das Refine- ment des Product Backlog kann durch die Rolle Product Owner alleine erfolgen, in Zusammenarbeit mit Teilen oder dem gesamten Umsetzungsteam, ebenso wie mit den Stakerholder *innen, wenn deren Wünsche und Bedürfnisse im Backlog aufgeführt sind.

In der Retrospektive überprüft das Scrum-Team, wie der letzte Sprint in Bezug auf das Sprintziel, die Kommunikation und Zusammenarbeit und die Definition of Done gelaufen ist.

Ziel der Retrospektive ist es, Maßnahmen und Teamregeln zu entwickeln, die die Ergebnisqualität und Effektivität des Teams steigern. Die Beschlüsse der Retrospektive werden möglichst schnell umgesetzt, damit die erwarteten Verbesserungen eintreten können. Gegebenenfalls übernimmt das Umsetzungsteam sie in das Sprint Backlog.

Für einen einmonatigen Sprint dauert die Retrospektive ungefähr drei Stunden. Bei kürzeren Sprints ist die Dauer entsprechend anzupassen.

Die Rolle Scrum Master moderiert üblicherweise die Retrospektive und bereitet diese auch individuell vor.

Im Review wird das Ziel des Sprints überprüft. Innerhalb dieses Events stellt entweder das Umsetzungsteam der Rolle Product Owner die Ergebnisse vor oder das gesamte Scrum-Team zeigt den Stakeholder*innen, was im Sprint erreicht wurde.

In vielen Teams hat es sich etabliert, sowohl ein internes als auch ein externes Reviews durchzuführen. Entscheidend ist, dass die Erkennt- nisse aus dem Review unmittelbar in das Product Backlog aufgenommen werden oder dieses entsprechend angepasst wird. Auch kann das Review der Ort sein, an dem sich Stakeholder*innen und Scrum-Team über das Projekt/Produkt austauschen.

Das Review ist ein Arbeitstermin, weniger ein Präsentationstermin, auch wenn es zum Teil aus einer Präsentation besteht.

Die Rolle Scrum Master kann im Review nach Bedarf sowohl moderierend als auch coachend unterstützen.

Der Begriff Scrum kommt aus dem Rugby -- er lässt sich mit “Gedränge” übersetzen.

Scrum ist ein Methoden-Framework, welches bei komplexen Vorhaben die Möglichkeit bietet, in Teilschritten (sog. Sprints und Inkremente) vorzugehen, um sich so schrittweise an das eigentliche Ziel heranzuarbeiten.

Die Rolle Scrum Master unterstützt Product Owner*in, Umsetzungsteam und ggf. andere im Unternehmen darin, Scrum zu verstehen und anzuwenden. Die Rolle trägt die Verantwortung dafür, dass die Praktiken von Scrum angewendet und stetig verbessert werden.

So übernimmt die Rolle die Moderation einzelner Events, wie z. B. Planning, Review und Retrospektive. Dabei dient die Rolle Scrum Master dem Team, in dem sie es dabei unterstützt, Hindernisse und Schwierigkeiten zu identifizieren und aus dem Weg zu räumen.

Sie begleitet das Team dabei, einen Rahmen zu entwickeln, in dem Scrum erfolgreich umgesetzt werden kann.

Ein Sprint bezeichnet die Folge von Planning, Umsetzung, Review und Retrospektive innerhalb des Scrum-Frameworks.

Das Sprint Backlog enthält die Anforderungen, die im aktuellen Sprint umgesetzt werden sollen.

Dabei benennt es außerdem möglichst das Sprintziel (Wozu machen wir das? Welchen Wertzuwachs erwarten wir?) und gibt anhand der Userstorys und ggf. Tasks einen Überblick über das “Was” und “Wie”.

Das Sprint Backlog fungiert als Echtzeitplan für den Sprint. Aus ihm lässt sich ablesen, welchen Status die einzelnen Anforderungen, Userstorys und Tasks haben. Das Sprint Backlog dient im Daily Scrum als Unterstützung zur Überprüfung des aktuellen Fortschritts. Aus diesem Grund hat sich die Nutzung eines analogen oder digitalen Boards etabliert, welches die einzelnen Prozessschritte des Teams (z. B. To do, Doing, Done) visualisiert.

Userstorys bringen durch ihre Formulierung den Kund*innen- nutzen in den Fokus. Sie bestehen immer aus der Anforderungsbeschreibung in Form der Userstory und der zugehörigen Akzeptanzkriterien.

Formulierung: In der Rolle ABC mache ich DEF, um XYZ zu erreichen.