Agile Artefakte

Obeya kommt aus dem Japanischen und steht für "großer Raum" oder "war room". Dieser bezeichnet eine Form des Projektmanagements bei Toyota und ist ein Teil des Toyota-Produktionssystems und damit eine Komponente des Lean Managements. In der Agilen Organisation kann dieser auf allen (verbliebenen) Managementebenen zur Steuerung genutzt werden. Dabei kommen bspw. jeweils im regelmäßigen Zyklus die Product Owner und Leads eines Tribes zusammen und besprechen die wichtigsten Entwicklungen in Gegenwart des Tribe Leads. Im Idealfall stehen in diesem physischen oder virtuellen Raum alle arbeitsrelevanten Themen für alle MitarbeiterInnen visuell aufbereitet zur Verfügung.

OKR steht für “Objectives and Key Results" und ist ein Rahmenwerk zur Zielsetzung (Objectives) und Messung von Ergebniskennzahlen (Key Results).  Die OKRs sollen objektiv feststellbar bzw. messbar sein und vom gesamten Unternehmen / der gesamten Abteilung eingesehen werden können. Jedes Key Result sollte quantitativ messbar sein. Dabei gilt es sich auf wenige Indikatoren zu beschränken und nicht eine Fülle an Kennzahlen zu produzieren. Die OKRs werden regelmäßig mit den Verantwortlichen (Squads) bspw. im Obeya nachgehalten.

Scrum kommt aus der Softwareentwicklung und ist ein Vorgehensmodell des Projekt- und Produktmanagements, insbesondere zur agilen Softwareentwicklung für komplexe Aufgabenstellungen. Zwischenzeitlich hat es sich in nahezu allen Bereichen unabhängig von der Branche etablieren können. Es eignet sich hervorragend für Projektarbeit, insbesondere für Projekte, welche eine große Varianz in der Umsetzung haben. Zentrales Element ist die neue Rolle für die Projektleitenden. Diese wurden zu Teammitgliedern, und ihre Rolle ist nun eher die einer Moderatorin/ eines Moderators als die einer Managerin/eines Managers in einem hierarchischen Gefüge. In zumeist 2-wöchigen Sprints arbeiten die Squads an den Entwicklungs- und/oder Analysethemen.

Zweck des Daily Scrum ist es zuallererst den Fortschritt in Richtung des Sprint-Ziels zu überprüfen. Gerade im "Business Scrum" kann es mit dem Aufkommen neuer Erkenntnisse auch notwendig werden, das Sprint-Backlog nach Bedarf anzupassen. Dies kann auch in Refinement-Termine ausgelagert werden.

Grundsätzlich ist das Daily Scrum ein 15-minütiges Event für das Squad/Team. Um die Komplexität zu reduzieren, findet es an jedem Arbeitstag des Sprints zur gleichen Zeit und am gleichen Ort statt. Die Teams können jede beliebige Struktur und Techniken auswählen (und ausprobieren), solange ihr Daily Scrum sich auf den Fortschritt in Richtung des Sprint-Ziels konzentriert und einen umsetzbaren Plan für den anstehenden Arbeitstag zum Ziel hat. Das schafft Fokus und verbessert das Selbstmanagement. Daily Scrums fördern die Kommunikation, identifizieren Hindernisse, begünstigen eine schnelle Entscheidungsfindung und machen im Idealfall (viel)e andere Meetings überflüssig.

Gerade im Homeoffice hat sich gezeigt, dass der Daily oft das einzige "Team Event" des Tages ist, an welchem alle Kollegen aus dem Team anwesend sind. Die MitarbeiterInnen schätzen den informellen Austausch untereinander. So kann es sich in Einzelfällen auch anbieten, das Daily um z.B. 15 Min für weitere Themen zu erweitern. 

Ein Scrum Task Board ist ein integraler Bestandteil der Scrum-Methode. Grundsätzlich besteht es aus Zeilen und Spalten – jede Zeile ist eine User Story, die als Arbeitseinheit fungiert, die das Scrum-Team für sein Product Backlog verwendet.

Aufgaben (=Tasks) werden auf farbigen Karten festgehalten. Hier bietet es sich an bspw. für jede Userstory eine Farbe zu verwenden oder sich die Farben anderweitig nutzbar zu machen. 

Teammitglieder aktualisieren das Taskboard häufig, am häufigsten während der täglichen Besprechungen, basierend auf dem Fortschritt des Teams seit der letzten Aktualisierung. Während des täglichen Scrum-Meetings (Daily) werden Änderungen vorgenommen und die Karten auf dem Scrum-Board verschoben. Jede Task für den Sprint hängt im Scrum Task Board anfangs in der Spalte „To Do“. Die grundlegenden Spalten, die auf einem Taskboard verwendet werden, sind: „To Do“, „Work in Process“, „To Verify“, „Done“.

Ein Scrum-Board bietet einen schnellen und einfachen Überblick über die Elemente innerhalb des Sprints, an denen das Entwicklungsteam derzeit arbeitet und die es bereits abgeschlossen hat.

Jedes Squad kann sein Task Board individualisieren und an die Bedürfnisse des Teams bzw. Aufgaben nach Belieben anpassen. Anstöße dazu lassen sich aus den Retros oder den Refinement-Sessions ableiten. Es kann sich auch als hilfreich erweisen. jemand aus dem Team zu rollieren.

In dieser Sprint Zeremonie sprechen die agile Teams über ihre Arbeitsergebnisse und den Stand ihres Produktes und gegben ggf. einenen ausblick auf die nächsten Entwicklungsschritte.

Zu diesem Termin können stakeholder oder auch das Senior Management eingeladen werden, um sich direkt Feedback einzuholen bzw. um Entscheidungen herbeizuführen. So kann man gesonderten "Schleifen" vermeiden. Dies hat den Vorteil, dass "Alle" von Anfang an in die Entwicklung eingebunden sind und über den Fortschritt genauestens im Bilde (sein sollten). Die IMpluse der Stakheolder können dann im Nachgang im Sprint Planning eingang finden. 

Dabei übernehme ich die Kommunikation mit Stakeholdern einschließlich Senior Management und allen weiteren Projektbeteiligten wie Risk, und Legal and Compliance.

​

Eine Retrospektive ist im agilen Kontext ein regelmäßiges Treffen, in dem ein Team gemeinsam reflektiert, was in einem bestimmten Zeitraum (z.B. einem Sprint) gut gelaufen ist, was weniger gut funktioniert hat und was man in Zukunft besser machen kann. Es ist eine Gelegenheit, aus Fehlern zu lernen, Prozesse zu verbessern und die Zusammenarbeit zu stärken. Bspw. um Verbesserungspotentiale in der Zusammenarbeit zu identifizieren.

Ein Squad ist in der agilen Arbeitsweise die kleinste, selbstorganisierte Einheit, die sich auf ein bestimmtes Produkt oder einen Teilbereich konzentriert. Squads sind cross-funktional zusammengesetzt, das heißt, sie vereinen alle notwendigen Fähigkeiten (z.B. Entwicklung, Design, Testing) um ein Produkt inkrementell zu entwickeln und auszuliefern.

Die optimale Größe eines Squads liegt in der Regel zwischen 5 und 9 Mitgliedern. Diese Größe ermöglicht eine gute Kommunikation, schnelle Entscheidungsfindung und eine hohe Flexibilität. Zu große Teams können zu Koordinationsaufwand führen, während zu kleine Teams möglicherweise nicht über alle notwendigen Fähigkeiten verfügen. 

Pizza-Regel: Eine oft genannte Faustregel ist die sogenannte "Pizza-Regel": Ein Team sollte so groß sein, dass eine Pizza für alle reicht. Das klingt zunächst etwas unscharf, verdeutlicht aber, dass kleine, überschaubare Teams in der Regel effizienter arbeiten.

Ein Tribe ist in der agilen Arbeitsweise eine größere, selbstorganisierte Einheit, die mehrere Squads vereint. Während ein Squad sich auf ein spezifisches Produkt oder einen Teilbereich konzentriert, bildet ein Tribe eine Gemeinschaft von Squads, die an einem gemeinsamen Ziel oder einer gemeinsamen Vision arbeiten. Tribes ermöglichen eine Skalierung agiler Arbeitsweisen und fördern gleichzeitig die Zusammenarbeit und den Austausch zwischen verschiedenen Teams.

Die optimale Größe eines Tribes hängt von verschiedenen Faktoren ab, wie der Komplexität des Produkts, der Unternehmensgröße und der Unternehmenskultur. Es gibt keine feste Regel, aber oft wird empfohlen, dass ein Tribe aus 40 bis 150 Mitarbeitern besteht. Diese Größe ermöglicht eine ausreichende Zusammenarbeit zwischen den Squads, ohne dass die Organisation zu unübersichtlich wird. 

Um die Zusammenarbeit innerhalb eines Tribes zu fördern, ist es wichtig, gemeinsame Ziele und Werte zu definieren. Diese können in regelmäßigen Treffen diskutiert und angepasst werden. Quartalsweise können alle Mitarbeiter Zusammenfinden, um um an der Vision des Tribes zu arbeiten und diese zu verinnerlichen. Mindestens alle 2 Wochen aber sollten die POs der Squads mit dem "Tibe Lead" zusammenfinden, um die aktuellen Themen zu besprechen und Entwicklungen nachzuhalten. Der Tribe Lead kann dabei die Akzente setzen und gemeinsam mit den POs Priorisierung bestimmen.

​Tribes sind eine effektive Möglichkeit, agile Arbeitsweisen in größeren Organisationen zu skalieren. Durch die gemeinsame Arbeit an einem Ziel und den Austausch von Wissen können Tribes die Innovationskraft und die Anpassungsfähigkeit von Unternehmen steigern.

Beschreibung folgt

Beschreibung folgt

Ein Sprint ist im agilen Projektmanagement ein zeitlich festgelegter Zeitraum, in dem ein Entwicklungsteam ein konkretes Arbeitspaket, das sogenannte Sprint-Ziel, umsetzt. Sprints sind das Herzstück von agilen Frameworks wie Scrum und dienen dazu, Arbeit in überschaubare, wiederholbare Einheiten zu unterteilen.

Die optimale Dauer eines Sprints variiert je nach Projekt und Team, liegt aber häufig zwischen einer und vier Wochen. Ein zu kurzer Sprint kann dazu führen, dass das Team zu wenig Zeit hat, um Aufgaben abzuschließen, während ein zu langer Sprint die Flexibilität einschränken kann.

Ich finde es dabei unerläßlich, durch die regelmäßige Auslieferung von funktionsfähigen Produkten bzw. Incrementen frühzeitig Feedback von den "Kunden" und Stakeholder einzuholen und einen Modus Operandi im Team zu entablieren

Das Product Backlog ist eine dynamische, priorisierte Liste aller Anforderungen, Funktionen und Verbesserungen, die für ein Produkt oder eine Dienstleistung gewünscht sind. Es ist im Grunde die "Wunschliste" aller Stakeholder. Das Product Backlog ist ständig im Wandel. Neue Anforderungen können hinzugefügt, bestehende können geändert oder entfernt werden (siehe Refinement). Die Einträge im Product Backlog werden nach ihrer geschäftlichen Wertschöpfung und ihrer technischen Machbarkeit respektive dem Kundennutzen priorisiert.

Sortierung Backlog: Anforderungen, die den größten Mehrwert für das Unternehmen oder den Kunden bringen, sollten oben stehen.

Abgrenzung Sprint Backlog: Der Sprint Backlog ist eine Untermenge des Product Backlogs, die die spezifischen Aufgaben enthält, die in einem bestimmten Sprint umgesetzt werden sollen.

​

Eine Refinement-Session (auch Backlog Grooming genannt) ist ein Treffen, in dem das Team gemeinsam mit dem Product Owner die Einträge im Product Backlog genauer betrachtet und vorbereitet. Das Ziel ist es, sicherzustellen, dass die Anforderungen für den nächsten Sprint klar und verständlich sind, bevor sie in den Sprint Backlog aufgenommen werden.

Die Anforderungen werden genauer spezifiziert, um Missverständnisse zu vermeiden.Die Anforderungen werden genauer spezifiziert, um Missverständnisse zu vermeiden. Das Team schätzt den Aufwand für die Umsetzung der Anforderungen, um die Planung des Sprints zu erleichtern. Die Priorität der Anforderungen wird überprüft und gegebenenfalls angepasst.

Praxistipp: Jeder im Team soll sich hier einrbingen und kann enstprechende User Stories und Task als "Hausaufgabe" vorbereiten. Der Product Owner muss das nicht im Alleingang erledigen

Das Sprint Planning ist ein wichtiges Ereignis im Scrum-Framework, welches den Start eines neuen Sprints markiert. In diesem Treffen definiert das gesamte Scrum-Team gemeinsam, welche Arbeit im kommenden Sprint erledigt werden soll. Das Ziel ist es, ein gemeinsames Verständnis für das Sprintziel zu schaffen und den Sprint Backlog zu erstellen. Es setzt dabei auf das Ergebnis der letzen Refinement Session auf.

Dies ist der Tag, an welchem der Sprint zuende geht und der Neue startet. Oft endet dieser mit der teaminternen Retrospektive. Danach erfolgt der Review. Diese Veranstaltung ist zumeinst für jeden Interessenten/Stakeholder zugänglich. Im Anschluss findet die Planung für den nachfolgenden Sprint statt. 

Die meisten Organsiationen "Atem" im gleichklang. Bedeutet- alle sollten am selben Tag Sprintwechsel haben, um an den darauffolgenden Tagen wieder gut erreichbar zu sein. In einer Idealen Scrum Welt mit E2E vollständig autarken Teasm wäre das nicht nötig. In der Praxis allerdings läßt isch dies kaum darstellen und beobachten. In der Praxis kann es aufgrund von Terminknappheit der Stakeholder und Ressourcenkanppheit von z.B. Agile Coaches somit notendig werden, den Sprintwechseln im Unternehmen über mehre Tage zu verteilen und ggf. auch die Reihenfolge der Rituale zu ändern.