A-Z Index für Agiles Arbeiten
Der A-Z Index bietet eine systematische Zusammenstellung zentraler Begriffe und Methoden des Agilen Arbeitens. Diese Referenz umfasst sowohl grundlegende Prinzipien wie Selbstorganisation und Feedback-Loops als auch spezifische Metriken und Frameworks. Die alphabetische Struktur ermöglicht eine effiziente Navigation durch die verschiedenen Konzepte, während die Verknüpfungen zwischen den Begriffen die systemischen Zusammenhänge agiler Methoden verdeutlichen.
12 Agile Prinzipien
Die 12 agilen Prinzipien sind eine Erweiterung des Agilen Manifests und geben konkrete Leitlinien für die Umsetzung agiler Werte in der Praxis. Sie betonen Kundenzufriedenheit, Flexibilität, Zusammenarbeit, kontinuierliche Verbesserung und die Schaffung eines nachhaltigen Arbeitstempos.
Erwähnt in folgenden Folgen
Acceptance Criteria
Acceptance Criteria sind konkrete Bedingungen, die erfüllt sein müssen, damit eine User Story als abgeschlossen gilt. Sie dienen als gemeinsame Verständnisgrundlage zwischen Team und Stakeholdern und helfen, Missverständnisse zu vermeiden. Wichtig ist dabei die Balance: Zu detaillierte Acceptance Criteria können zu Perfektionismus führen und die Flexibilität einschränken, während zu vage Kriterien zu Unklarheiten führen können. Sie sollten das 'Was' und nicht das 'Wie' beschreiben und als Grundlage für Tests dienen können.
Erwähnt in folgenden Folgen
Adjourning
Eine zusätzliche Phase im Tuckman-Modell, die nach der Performing-Phase betrachtet wird, in der das Team sich trennt oder die Zusammenarbeit beendet wird.
Erwähnt in folgenden Folgen
Agile at Scale
Ein Konzept, das darauf abzielt, agile Praktiken in großen Organisationen oder Konzernen zu implementieren und damit die Agilität auf eine breitere Ebene zu heben.
Erwähnt in folgenden Folgen
Agile Coach
Ein Agile Coach unterstützt Teams und Organisationen dabei, agile Prinzipien zu verstehen und eigenverantwortlich umzusetzen. Er befähigt zur Selbstorganisation, statt Anweisungen zu geben, und hilft beim Überwinden systemischer Hindernisse. Die Rolle geht über die Anwendung von Methoden hinaus und zielt auf echte Veränderung ab.
Erwähnt in folgenden Folgen
Agile Transition
Die agile Transition bezieht sich auf den Prozess, in dem Organisationen von traditionellen Arbeitsweisen zu agilen Methoden wechseln, um flexibler und kundenorientierter zu werden.
Erwähnt in folgenden Folgen
Agile Verwaltung
Ein Ansatz zur Anwendung agiler Methoden und Denkweisen in der öffentlichen Verwaltung, um flexibler und effektiver auf gesellschaftliche Herausforderungen reagieren zu können.
Erwähnt in folgenden Folgen
AgileEcho
AgileEcho ist ein Tool zur anonymen Feedback-Sammlung in Teams. Es ermöglicht die Durchführung regelmäßiger Umfragen zu verschiedenen Aspekten der Teamarbeit, wie Kommunikation, Zusammenarbeit und Arbeitsklima. Die Ergebnisse werden in übersichtlichen Radar-Charts visualisiert, die die Entwicklung über Zeit zeigen. Besonders wertvoll ist AgileEcho für die kontinuierliche Verbesserung der Teamarbeit und als Unterstützung für Retrospektiven.
Erwähnt in folgenden Folgen
Agiler Eisberg
Der Agile Eisberg ist eine Metapher, die das Verhältnis zwischen sichtbaren agilen Methoden (wie Scrum oder Kanban) und den weniger sichtbaren, aber entscheidenden Fundamenten agiler Arbeit (Denkweisen, Prinzipien, Kultur, technische Skills, Kollaboration) verdeutlicht. Nur wenn die 'unter Wasser' liegenden Elemente verstanden und umgesetzt werden, kann Agilität ihr volles Potenzial entfalten.
Erwähnt in folgenden Folgen
Agiles Arbeiten
Agiles Arbeiten beschreibt einen flexiblen Arbeitsansatz, der nicht von festen Methoden wie Scrum oder Kanban abhängt. Es basiert auf zehn grundlegenden Prinzipien: iterative Entwicklung, inkrementelle Lieferung, kontinuierliche Verbesserung, enge Zusammenarbeit mit dem Kunden, Selbstorganisation der Teams, Anpassungsfähigkeit, kontinuierliche Integration, Transparenz, Feedback-Schleifen und dem Prinzip der Einfachheit. Diese Prinzipien bilden das Fundament für wirkliche Flexibilität im Arbeitsalltag.
Erwähnt in folgenden Folgen
- NBA67: Agiles Arbeiten unabhängig von agilen Methoden
- NBA61: Wenn man nur noch Listenpfleger ist
- NBA60: Agiler Kaffeeklatsch? Warum unsere Austauschrunde so wertvoll ist
- NBA59: Deadlines im agilen Arbeiten
- NBA58: Meetings, Meetings, Meetings
- NBA57: Wie sieht das ideale agile Projekt aus?
- NBA56: Agilität trifft Realität: Was tun, wenn Kunden oder Stakeholder nicht mitziehen?
- NBA51: Gute Software schnell liefern – Warum überhaupt agil arbeiten?
- NBA50: Meine (kritische) Meinung: AI und agiles Arbeiten
- NBA49: Der agile Eisberg
Agiles Manifest
Das Agile Manifest ist ein Dokument, das die Werte und Prinzipien der agilen Softwareentwicklung zusammenfasst. Es wurde im Februar 2001 von 17 Softwareentwicklern verfasst, die unzufrieden mit den traditionellen, schwerfälligen Entwicklungsmethoden waren und einen besseren Weg finden wollten.
Erwähnt in folgenden Folgen
- NBA70: Post Agile
- NBA49: Der agile Eisberg
- NBA41: Die Devs bitte nicht ansprechen
- NBA32: (Nicht) agile Ausschreibungen der öffentlichen Hand
- NBA29: Agiles Manifest - Gedankenexperiment
- NBA23: Heuristics for Effective Software Development
- NBA06: Die 12 Agilen Prinzipien
- NBA05: Sind das Agile Manifest und die 12 Prinzipien noch relevant?
Agiles Mindset
Das Agile Mindset beschreibt die grundlegende Haltung und Denkweise, die hinter agiler Arbeit steht. Es geht über die bloße Anwendung von Methoden hinaus und umfasst Werte wie Eigenverantwortung, Transparenz, kontinuierliches Lernen und die Bereitschaft zur Veränderung. Ein agiles Mindset ist entscheidend für echte Agilität und unterscheidet sich von der oberflächlichen Übernahme agiler Praktiken. Es manifestiert sich in der Art, wie Teams zusammenarbeiten, wie sie mit Feedback umgehen und wie sie kontinuierlich nach Verbesserungen streben.
AI (Künstliche Intelligenz)
Ein Bereich der Informatik, der sich mit der Simulation menschlicher Intelligenz in Maschinen beschäftigt, oft verwendet zur Automatisierung von Prozessen oder zur Unterstützung in verschiedenen Aufgaben, hier im Kontext agiler Arbeit.
Erwähnt in folgenden Folgen
Aktives Zuhören
Ein Kommunikationsansatz, der darauf abzielt, dem Gesprächspartner den Raum zum Sprechen zu geben und durch Nachfragen ein tieferes Verständnis der besprochenen Themen zu ermöglichen.
Erwähnt in folgenden Folgen
Backlog
Eine priorisierte Liste der Aufgaben oder Anforderungen, die in einem agilen Projekt bearbeitet werden müssen.
Erwähnt in folgenden Folgen
Barcamp
Ein Veranstaltungsformat, das für den Austausch von Wissen und Erfahrungen in einer offenen und dezentralen Struktur steht, wo die Teilnehmer das Programm selbst gestalten.
Erwähnt in folgenden Folgen
Board
Ein Board im agilen Kontext ist eine visuelle Darstellung des Arbeitsflusses und der Aufgaben. Es hilft Teams, den Überblick zu behalten und die Prioritäten zu verstehen. Methoden wie 'Walking the Board' und 'Daily' helfen, das Board effizient zu nutzen und die Arbeit zu koordinieren.
Erwähnt in folgenden Folgen
Cargo Cult Agility
Cargo Cult Agility beschreibt das Phänomen, bei dem Teams und Unternehmen zwar agile Praktiken und Rituale übernehmen, aber das dahinterliegende Mindset und die notwendigen kulturellen Veränderungen nicht verstehen oder umsetzen. Es entsteht eine Scheinagilität, bei der zwar agile Methoden wie Scrum angewendet werden, aber die grundlegende Haltung und Zusammenarbeit sich nicht wirklich ändert. Dies führt dazu, dass die eigentlichen Vorteile agiler Arbeit nicht zum Tragen kommen.
Erwähnt in folgenden Folgen
Continuous Delivery
Ein Entwicklungsansatz, bei dem Softwareänderungen automatisiert und regelmäßig in die Produktion überführt werden, was eine schnellere Bereitstellung von Features und Wert für den Kunden ermöglicht.
Erwähnt in folgenden Folgen
Cycle Time
Die Cycle Time misst die Zeit vom Start der Arbeit bis zur Fertigstellung eines Items. Sie ist eine der wichtigsten Metriken für agile Teams, um ihren Arbeitsfluss zu analysieren. Teams müssen dabei selbst definieren, was für sie der Start der Arbeit und was die Fertigstellung bedeutet. Die Cycle Time ist ein Teil der Lead Time und fokussiert sich auf die reine Bearbeitungszeit innerhalb des Teams.
Erwähnt in folgenden Folgen
Daily (Daily Scrum)
Das Daily (auch Daily Scrum) ist ein kurzes, tägliches Meeting im agilen Arbeiten, bei dem das Team den aktuellen Stand bespricht, Blockaden identifiziert und die nächsten Schritte plant. Im Fokus steht die gemeinsame Koordination, nicht das individuelle Reporting. Methoden wie 'Walking the Board' helfen, das Daily teamorientiert und effizient zu gestalten.
Erwähnt in folgenden Folgen
Dark Agile
Eine bewusste Entscheidung, agile Methoden als Deckmantel zu verwenden, während weiterhin traditionelle, kontrollierende Managementmethoden im Hintergrund angewendet werden.
Erwähnt in folgenden Folgen
Deadline
Eine Deadline ist ein festgelegter Zeitpunkt, bis zu dem eine Aufgabe, ein Inkrement oder ein Projekt abgeschlossen sein soll. Im agilen Kontext sind Deadlines ein zweischneidiges Schwert: Sie können Orientierung und Fokus bieten, aber auch zu Stress, Scheinplanung und Qualitätsverlust führen, wenn sie zu starr oder ohne Berücksichtigung von Unsicherheiten gesetzt werden. Agile Teams nutzen Deadlines vor allem als Reflexionspunkte für Inkremente, um gemeinsam mit Stakeholdern realistische Ziele zu setzen und regelmäßig zu überprüfen, anstatt starre Endtermine zu verfolgen. Die Kunst im agilen Arbeiten besteht darin, Deadlines sinnvoll und flexibel einzusetzen, um Planungssicherheit und Lernzyklen zu verbinden.
Erwähnt in folgenden Folgen
Definition of Outcome Done
Eine erweiterte Betrachtung der Abnahmebedingungen in Scrum, die den Fokus auf den tatsächlichen Nutzen und Wert eines gelieferten Produkts legt, anstatt nur auf den gelieferten Funktionsumfang.
Erwähnt in folgenden Folgen
Delegation Board
Das Delegation Board ist ein Dokumentationswerkzeug, um die im Delegation Poker getroffenen Entscheidungen über Verantwortlichkeiten festzuhalten. Es schafft Transparenz im Team und hilft, den Lernprozess der Selbstorganisation zu visualisieren und schrittweise zu verbessern.
Erwähnt in folgenden Folgen
Delegation Poker
Delegation Poker ist eine spielerische Workshop-Methode, die Teams und Führungskräften hilft, Entscheidungsbefugnisse klar zu definieren und ein gemeinsames Verständnis für die verschiedenen Stufen der Delegation zu entwickeln. Es ist ein essentielles Werkzeug zur Förderung der Selbstorganisation und zur Vermeidung von Missverständnissen bei Entscheidungen.
Dimensional Planning
Dimensional Planning ist eine agile Planungstechnik, bei der jede Funktion oder User Story von vornherein in drei Ausbaustufen gedacht wird – Dirt Road (nur das absolut Notwendige), Cobblestone (alltagstauglicher Standard) und Highway (luxuriöse Vollausstattung). So entsteht schon nach der ersten Iteration ein lauffähiges, wenn auch einfaches Produktinkrement; weitere Sprints verfeinern es schrittweise, falls Nutzen und Budget es rechtfertigen.
Erwähnt in folgenden Folgen
DORA-Metriken
DORA (DevOps Research and Assessment) ist ein umfassendes Framework zur Messung der Softwareentwicklungs- und Lieferperformance. Es besteht aus vier zentralen Metriken: Lead Time for Changes (Zeit vom Commit bis zum Go Live), Deployment Frequency (Häufigkeit der Auslieferungen), Change Failure Rate (Rate fehlgeschlagener Deployments) und Mean Time to Restore (Zeit bis zur Wiederherstellung nach einem Fehler). Diese Metriken werden jährlich in einer großen Befragung erfasst und bieten Teams wertvolle Einblicke in ihre Lieferperformance.
Elastic Leadership
Elastic Leadership beschreibt einen flexiblen Führungsansatz, der sich an die verschiedenen Phasen der Teamentwicklung anpasst. Der Ansatz betont die Notwendigkeit, den Führungsstil je nach Reifegrad und Bedürfnissen des Teams anzupassen.
Erwähnt in folgenden Folgen
Epics
Große Benutzeranforderungen, die in kleinere User Stories unterteilt werden, um die Implementierung in agilen Projekten zu erleichtern.
Erwähnt in folgenden Folgen
Extreme Programming (XP)
Ein agiles Entwicklungsframework, das auf intensiver Zusammenarbeit, schneller Rückmeldung und ständiger Verbesserung basiert.
Erwähnt in folgenden Folgen
Fake Agile
Ein Konzept, bei dem Unternehmen agile Methoden wie Scrum einführen, jedoch deren Prinzipien und Werte missachten, was zu einer falschen Anwendung agiler Praktiken führt.
Erwähnt in folgenden Folgen
Feedback
Feedback ist ein zentrales Element agiler Arbeit und bezeichnet die systematische Rückmeldung über Prozesse, Ergebnisse und Zusammenarbeit. Im agilen Kontext dient Feedback der kontinuierlichen Verbesserung und dem gemeinsamen Lernen. Es kann in verschiedenen Formen erfolgen: als anonymes Feedback in regelmäßigen Umfragen, in Retrospektiven, durch direkte Kommunikation im Team oder durch Kundenrückmeldungen. Wichtig ist eine konstruktive Feedback-Kultur, die auf Vertrauen und Offenheit basiert.
Erwähnt in folgenden Folgen
- NBA65: Cargo Cult Agility – Wenn Agil nur gespielt wird
- NBA60: Agiler Kaffeeklatsch? Warum unsere Austauschrunde so wertvoll ist
- NBA56: Agilität trifft Realität: Was tun, wenn Kunden oder Stakeholder nicht mitziehen?
- NBA54: AgileEcho - Anonym Feedback im Team sammeln
- NBA49: Der agile Eisberg
- NBA34: Agil sein durch Feedback und Anpassung, nicht durch starre Prozess
- NBA14: Peer Feedback
- NBA11: Wertvoll: One on One mit Teammitgliedern
Fehlerkultur
Die Haltung und Praktiken eines Teams oder Unternehmens im Umgang mit Fehlern; fördert das Lernen aus Fehlern anstelle von Schuldzuweisungen.
Erwähnt in folgenden Folgen
Flight Levels
Flight Levels ist ein Modell von Klaus Leopold, das hilft, Agilität auf verschiedenen Ebenen einer Organisation zu verstehen und zu implementieren: vom Strategie-Portfolio (Flight Level 3) über die Koordination (Flight Level 2) bis hin zur Teamebene (Flight Level 1). Es geht darum, die richtigen Dinge zur richtigen Zeit auf der richtigen Ebene zu tun und den Arbeitsfluss über Teamgrenzen hinweg sichtbar zu machen und zu optimieren. Flight Levels helfen Organisationen, ihre strategischen Ziele durch agile Praktiken zu erreichen.
Erwähnt in folgenden Folgen
Flow
Flow bezeichnet in agilen Teams einen gleichmäßigen, ungestörten Arbeitsfluss. Ziel ist es, Arbeit möglichst effizient und ohne Blockaden durch das System zu bewegen. Ein guter Flow reduziert Wartezeiten, erhöht die Vorhersagbarkeit und trägt zur Teamzufriedenheit bei. Flow entsteht nicht zufällig, sondern muss aktiv gestaltet und regelmäßig reflektiert werden.
Flow-Messung
Flow-Messung beschreibt den Prozess, wie agile Teams ihren Arbeitsfluss quantifizieren und analysieren. Dabei ist Flow kein Ziel, sondern ein Zustand, den es zu optimieren gilt. Die Messung hilft Teams zu verstehen, wie gleichmäßig Arbeit durch ihr System fließt und wo mögliche Engpässe oder Verbesserungspotenziale liegen. Wichtig ist dabei, dass Messen nicht primär dem Liefern dient, sondern dem Lernen und der kontinuierlichen Verbesserung.
Erwähnt in folgenden Folgen
Hackman-Autoritätsmatrix
Die Hackman-Autoritätsmatrix (nach J. Richard Hackman) ist ein Modell zur Visualisierung der verschiedenen Stufen von Teamautonomie und Entscheidungsbefugnis. Sie unterscheidet zwischen managergeführten Teams, selbstführenden Teams, selbstgestaltenden Teams und vollständig autonomen Gruppen. Die Matrix hilft Teams und Führungskräften, den aktuellen Reifegrad der Selbstorganisation zu bestimmen und gezielt weiterzuentwickeln. Sie ist ein zentrales Werkzeug, um Klarheit über Rollen, Verantwortlichkeiten und den Grad der Delegation im Team zu schaffen.
Erwähnt in folgenden Folgen
Impediment
Hindernisse oder Blockaden, die die Arbeit eines Teammitglieds behindern und die oft im Daily Scrum thematisiert werden.
Erwähnt in folgenden Folgen
Iterative Entwicklung
Iterative Entwicklung ist ein zyklischer Prozess, bei dem Produkte oder Lösungen in wiederkehrenden Schritten entwickelt werden. Jeder Zyklus baut auf den Ergebnissen des vorherigen auf und führt zu einer verbesserten Version. Dieser Ansatz ermöglicht kontinuierliches Lernen und Anpassung an sich ändernde Anforderungen.
Erwähnt in folgenden Folgen
- NBA67: Agiles Arbeiten unabhängig von agilen Methoden
- NBA61: Wenn man nur noch Listenpfleger ist
- NBA59: Deadlines im agilen Arbeiten
- NBA56: Agilität trifft Realität: Was tun, wenn Kunden oder Stakeholder nicht mitziehen?
- NBA51: Gute Software schnell liefern – Warum überhaupt agil arbeiten?
- NBA49: Der agile Eisberg
- NBA45: Ziele, Kommunikation & Iterationen – Was bremst dein Team in agilen Projekten?
- NBA42: Warum ist iteratives Vorgehen nur so schwer?
- NBA09: Agilität von SpaceX
Kanban
Kanban ist eine agile Methode zur Visualisierung des Arbeitsflusses und zur Begrenzung der gleichzeitig bearbeiteten Aufgaben (Work in Progress, WIP). Ziel ist es, den Durchsatz zu erhöhen, Engpässe zu beseitigen und den Fluss kontinuierlich zu optimieren. Kanban ist flexibel anwendbar und fördert Transparenz sowie kontinuierliche Verbesserung.
Konsens
In der Teamentwicklung bezieht sich Konsens auf eine Entscheidungsfindungsmethode, bei der alle Teammitglieder zustimmen müssen, bevor eine Entscheidung getroffen wird.
Erwähnt in folgenden Folgen
Konsent
Eine alternative Entscheidungsfindungsmethode, bei der eine Entscheidung getroffen wird, solange niemand vehement dagegen ist, was den Prozess schneller und effizienter macht.
Erwähnt in folgenden Folgen
Kontinuierliche Verbesserung (Kaizen)
Ein Prinzip, das sich auf die ständige Optimierung von Prozessen, Produkten und Dienstleistungen konzentriert, häufig unterstützt durch Retrospektiven.
Erwähnt in folgenden Folgen
Lastenheft
Ein Dokument, das die Anforderungen und Erwartungen des Auftraggebers an ein Projekt detailliert beschreibt.
Erwähnt in folgenden Folgen
Lead Time
Lead Time bezeichnet die gesamte Zeitspanne vom Eingang eines Items ins System bis zu seiner Fertigstellung. Sie umfasst also sowohl die Zeit, in der ein Item wartet, als auch die Bearbeitungszeit (Cycle Time). Die Lead Time ist ein wichtiger Indikator für den Lieferrhythmus eines Teams und hilft, Engpässe und Verzögerungen im Prozess zu erkennen.
Erwähnt in folgenden Folgen
Little's Law
Little's Law beschreibt einen mathematischen Zusammenhang zwischen Work in Progress (WiP), Durchlaufzeit und Durchsatz. Es besagt, dass Durchlaufzeit = WiP / Durchsatz ist. In agilen Teams hilft diese Formel, den Effekt von WiP-Limits zu verstehen und fundierte Entscheidungen zur Optimierung des Arbeitsflusses zu treffen.
Erwähnt in folgenden Folgen
Meeting-Kultur
Die Normen und Regeln, die das Verhalten und die Erwartungen in Meetings bestimmen, einschließlich wie oft, warum und wie effektiv sie abgehalten werden.
Erwähnt in folgenden Folgen
Mikromanagement
Ein negativ behafteter Führungsstil, bei dem Führungskräfte übermäßig kontrollierend und detailliert in die Arbeit ihrer Teammitglieder eingreifen, was zu einem Mangel an Vertrauen und Effizienz führt.
Erwähnt in folgenden Folgen
Norming-Phase
Eine Phase im Tuckman-Modell, in der die Teammitglieder beginnen, miteinander zu kooperieren und Regeln für die Zusammenarbeit aufzustellen.
Erwähnt in folgenden Folgen
One on One
Eine individuelle, regelmäßige Besprechung zwischen einem Teammitglied und einem Teamleiter, um persönliche Themen, Herausforderungen und Feedback zu besprechen.
Erwähnt in folgenden Folgen
Open Space
Ein Format für den Wissensaustausch, bei dem Teilnehmer selbst Themen gestalten und diskutieren können, was eine dezentrale Organisation fördert.
Erwähnt in folgenden Folgen
Peer Feedback
Ein Verfahren, bei dem Teammitglieder sich gegenseitig Rückmeldungen geben, um die persönliche und teaminterne Entwicklung zu fördern.
Erwähnt in folgenden Folgen
Performing-Phase
Die Phase im Tuckman-Modell, in der das Team effektiv und effizient zusammenarbeitet, nachdem es die vorhergehenden Herausforderungen bewältigt hat.
Erwähnt in folgenden Folgen
Post-Agile
Post-Agile bezeichnet eine Diskussion und Haltung, die davon ausgeht, dass agile Methoden und Praktiken in vielen Organisationen ritualisiert und erstarrt sind. Der Begriff steht für den Versuch, Agilität weiterzuentwickeln oder sich bewusst von dogmatischen agilen Frameworks zu lösen. Dabei geht es weniger um eine Revolution als um eine Evolution: weg von starren Methoden, hin zu mehr Fokus auf Werte, Kundennutzen und echte Wirksamkeit im komplexen Umfeld.
Erwähnt in folgenden Folgen
Priorisierung
Der Prozess der Festlegung von Prioritäten für Aufgaben und Anforderungen in einem Projekt, basierend auf dem Wert für den Kunden und der Dringlichkeit.
Erwähnt in folgenden Folgen
Product Backlog
Das Product Backlog ist eine priorisierte Liste aller bekannten Anforderungen an ein Produkt im Scrum-Framework. Es enthält Features, Verbesserungen, Bugfixes und andere Arbeiten, die das Produkt wertvoller machen sollen. Der Product Owner ist für die Pflege, Priorisierung und Transparenz des Backlogs verantwortlich. In der Praxis ist das Backlog dynamisch und entwickelt sich kontinuierlich weiter. Eine besondere Herausforderung ist es, die Balance zwischen strategischen Zielen und operativen Details zu halten und das Backlog so zu gestalten, dass es für alle Beteiligten verständlich und nutzbar ist.
Erwähnt in folgenden Folgen
Product Owner
Der Product Owner ist eine zentrale Verantwortung im Scrum-Framework. Er oder sie ist für die Maximierung des Wertes des Produkts und die klare Kommunikation der Produktziele verantwortlich. Dazu gehört das Pflegen und Priorisieren des Product Backlogs sowie die enge Abstimmung mit Stakeholdern und dem Entwicklungsteam. In der Praxis ist die Rolle oft herausfordernd, da der Product Owner zwischen verschiedenen Interessen vermitteln muss und nicht immer alle notwendigen Befugnisse oder Informationen besitzt. Erfolgreiche Product Owner fördern Transparenz, priorisieren wirkungsorientiert und pflegen einen kontinuierlichen Dialog mit Stakeholdern.
Erwähnt in folgenden Folgen
- NBA71: The Scrum Guide Expansion Pack
- NBA44: Der Product Owner – Schlüsselrolle oder überforderte Schnittstelle?
- NBA41: Die Devs bitte nicht ansprechen
- NBA39: Im Gespräch mit Martin über Agilität aus C-Level Sicht
- NBA25: Im Gespräch: Marco von SCRUMschau über Scrum
- NBA20: Product Owner kann nur der Kunde sein
Projektplanung
Projektplanung umfasst alle Aktivitäten, die notwendig sind, um ein Projekt von der Initiierung bis zum Abschluss zu strukturieren, zu steuern und zu kontrollieren. Im agilen Kontext bedeutet Projektplanung vor allem, flexibel auf Veränderungen zu reagieren, kontinuierlich zu priorisieren und die Zusammenarbeit mit dem Kunden zu fördern. Methoden wie User Story Mapping, Dimensional Planning und inkrementelle Planung helfen Teams, den Überblick zu behalten und den Projekterfolg zu sichern.
Retrospektive
Die Retrospektive ist ein regelmäßiges Meeting im agilen Kontext, bei dem das Team die Zusammenarbeit reflektiert und Verbesserungen identifiziert. Sie ist ein zentrales Element für kontinuierliche Verbesserung und kann durch Tools wie AgileEcho unterstützt werden, um anonymes Feedback zu sammeln. Wichtig ist eine offene und vertrauensvolle Atmosphäre, in der alle Teammitglieder ihre Perspektiven einbringen können.
Schwungrad
Ein Konzept, das beschreibt, wie man Energie und Motivation in ein Team oder eine Organisation einbringt, um eine agile Kultur zu fördern und das Verständnis für agile Praktiken zu erhöhen.
Erwähnt in folgenden Folgen
Scrum
Scrum ist ein leichtgewichtiges agiles Framework zur Entwicklung, Lieferung und Pflege komplexer Produkte. Es ist durch selbstorganisierte, funktionsübergreifende Teams, kurze Entwicklungszyklen (Sprints), und regelmäßige Anpassung an veränderte Anforderungen gekennzeichnet. Scrum bietet einen Rahmen für effektive Zusammenarbeit und kontinuierliches Lernen, sollte aber immer im Kontext der agilen Werte und Prinzipien angewendet werden.
Erwähnt in folgenden Folgen
- NBA72: A Simple Guide To Scrum
- NBA71: The Scrum Guide Expansion Pack
- NBA49: Der agile Eisberg
- NBA44: Der Product Owner – Schlüsselrolle oder überforderte Schnittstelle?
- NBA39: Im Gespräch mit Martin über Agilität aus C-Level Sicht
- NBA28: Im Gespräch Felix - Agile at Scale
- NBA25: Im Gespräch: Marco von SCRUMschau über Scrum
- NBA20: Product Owner kann nur der Kunde sein
- NBA04: Scrum: Warum es Zeit ist, ein anderes agiles Vorgehen zu erwägen
Scrum Master
Der Scrum Master ist eine definierte Rolle im Scrum-Framework. Er fördert die Einhaltung von Scrum-Prinzipien, moderiert Meetings, beseitigt Hindernisse und unterstützt das Team in seiner Selbstorganisation. Im Gegensatz zum Agile Coach ist sein Fokus stärker auf das Scrum-Team beschränkt.
Selbstorganisation
Selbstorganisation beschreibt die Fähigkeit von Teams, ihre Arbeit und Prozesse eigenständig zu gestalten und zu optimieren. Im agilen Kontext bedeutet dies, dass Teams die Verantwortung für ihre Arbeitsweise übernehmen und sich kontinuierlich weiterentwickeln, ohne auf detaillierte Vorgaben von außen angewiesen zu sein. Selbstorganisation ist ein zentrales Element echter Agilität und unterscheidet sich von der bloßen Übernahme agiler Praktiken. Sie erfordert Vertrauen, Transparenz und die Bereitschaft, Verantwortung zu übernehmen.
Erwähnt in folgenden Folgen
Service Delivery Manager
Eine Rolle in Kanban, die dafür verantwortlich ist, den Flow im Delivery zu managen und das Team bei der kontinuierlichen Verbesserung zu unterstützen.
Erwähnt in folgenden Folgen
Service Request Manager
Der Service Request Manager (SRM) ist eine Rolle im Kanban-System, die für die Koordination und Optimierung des Arbeitsflusses verantwortlich ist. Im agilen Kontext unterstützt der SRM das Team bei der Prozessgestaltung und schafft den Rahmen für selbstorganisierte Arbeit, ohne dabei inhaltlich in die Teamarbeit einzugreifen. Die Rolle ist besonders wichtig für die Balance zwischen Führung und Selbstorganisation.
Erwähnt in folgenden Folgen
Shuhari
Ein japanisches Lernmodell, das in drei Phasen unterteilt ist: Schuh (Grundlagen lernen), H (Regeln brechen und anwenden) und Ri (Meisterschaft und Innovation). Es wird in der Agilität genutzt, um den Lernprozess in Teams zu strukturieren.
Erwähnt in folgenden Folgen
Six Hats
Eine Methode zur Entscheidungsfindung, bei der das Team verschiedene Perspektiven einnimmt, symbolisiert durch Hüte, darunter analytische, emotionale und kritische Betrachtungsweisen, um eine umfassendere Diskussion zu fördern.
Erwähnt in folgenden Folgen
Sprint Planning
Ein Meeting im Scrum-Prozess, in dem das Team plant, welche Aufgaben aus dem Product Backlog im nächsten Sprint bearbeitet werden.
Erwähnt in folgenden Folgen
Sprintziel
Das Sprintziel definiert den übergeordneten Zweck eines Sprints und gibt dem Scrum-Team Orientierung, worauf es im aktuellen Sprint hinarbeitet. Es wird zu Beginn des Sprints gemeinsam festgelegt und hilft dabei, Entscheidungen im Sprintverlauf zu steuern. Ein gutes Sprintziel ist klar, erreichbar und schafft Fokus für das Team. In der Praxis stellt die Entwicklung eines Sprintziels oft eine Herausforderung dar, besonders wenn Stakeholder nicht aktiv mitarbeiten oder keine klare Produktvision vorliegt.
Stakeholder
Stakeholder sind Personen oder Gruppen, die ein berechtigtes Interesse an einem Projekt oder Produkt haben. Im agilen Kontext sind Stakeholder besonders wichtig, da sie regelmäßiges Feedback geben und aktiv am Entwicklungsprozess teilnehmen sollten. Die erfolgreiche Einbindung von Stakeholdern ist eine zentrale Herausforderung agiler Arbeit, da diese oft noch nicht optimal in den agilen Prozess integriert sind. Wichtige Aspekte sind: schrittweise Heranführung an agile Arbeitsweisen, Vermeidung von Fachjargon, Gestaltung eines effektiven Feedback-Prozesses und Aufbau von Vertrauen durch transparente Kommunikation.
Erwähnt in folgenden Folgen
- NBA71: The Scrum Guide Expansion Pack
- NBA69: Wie wichtig sind User Stories?
- NBA59: Deadlines im agilen Arbeiten
- NBA57: Wie sieht das ideale agile Projekt aus?
- NBA56: Agilität trifft Realität: Was tun, wenn Kunden oder Stakeholder nicht mitziehen?
- NBA49: Der agile Eisberg
- NBA20: Product Owner kann nur der Kunde sein
Storming-Phase
Eine der Phasen im Tuckman-Modell, in der Konflikte in einem Team offener werden und Auseinandersetzungen stattfinden können, was für die Teamentwicklung wichtig ist.
Erwähnt in folgenden Folgen
Task-Splitting
Der Prozess, Aufgaben in kleinere, handhabbare Einheiten zu unterteilen, um die Arbeit effektiver zu gestalten und den Fortschritt besser zu verfolgen.
Erwähnt in folgenden Folgen
Team
Ein Team im agilen Kontext ist eine Gruppe von Menschen, die gemeinsam an einem Ziel arbeiten und sich durch Selbstorganisation und kontinuierliche Verbesserung auszeichnen. Wichtige Merkmale sind: Vertrauen, offene Kommunikation, regelmäßiges Feedback und die Bereitschaft zur Zusammenarbeit. Die Teamgröße sollte idealerweise zwischen 5-9 Personen liegen, um effektiv arbeiten zu können.
Erwähnt in folgenden Folgen
- NBA68: Elastic Leadership: Flexibel führen in jeder Teamphase
- NBA54: AgileEcho - Anonym Feedback im Team sammeln
- NBA53: Die Power von Teams
- NBA49: Der agile Eisberg
- NBA43: Im Gespräch mit Johanna über Motivation
- NBA41: Die Devs bitte nicht ansprechen
- NBA40: Die menschliche Seite des Task Splittings
- NBA27: Rege im Daily
- NBA19: Entscheidungen im Team treffen
- NBA14: Peer Feedback
Team Canvas
Das Team Canvas ist eine Methode zur visuellen Darstellung von Teamdynamik und -zielen. Es besteht typischerweise aus vier Quadranten: Ziele (Goals), Rollen und Skills, Werte sowie Rollen und Aktivitäten, mit einem zentralen Purpose-Bereich. Die Methode dient dazu, ein gemeinsames Verständnis im Team zu schaffen und die Teamidentität zu stärken. Wichtig ist, dass das Team Canvas als Living Document behandelt wird - es muss regelmäßig aktualisiert und in den Arbeitsalltag integriert werden, um seinen vollen Nutzen zu entfalten. Besonders geeignet ist es für neue Teams oder Teams, die sich neu formieren, während es für bereits etablierte Teams möglicherweise weniger Mehrwert bietet.
Erwähnt in folgenden Folgen
Team Health Check
Der Team Health Check ist eine Methode zur regelmäßigen Überprüfung und Verbesserung der Teamdynamik und -kultur. Im Gegensatz zum Team Canvas, das sich auf die visuelle Darstellung von Teamzielen und -strukturen konzentriert, fokussiert sich der Team Health Check auf die kontinuierliche Verbesserung der Zusammenarbeit und des Teamklimas. Die Methode hilft Teams, ihre Stärken und Schwächen zu identifizieren, Probleme frühzeitig zu erkennen und gezielte Maßnahmen zur Verbesserung abzuleiten. Sie ist besonders wertvoll für etablierte Teams, die ihre Zusammenarbeit optimieren möchten.
Erwähnt in folgenden Folgen
User Stories
User Stories sind ein Kommunikationsmittel im agilen Arbeiten, das hilft, Anforderungen aus der Nutzerperspektive zu beschreiben. Sie sollten als Gesprächsanker dienen und nicht als starres Pflichtenheft fungieren. Wichtig ist dabei, dass sie das 'Was' und 'Warum' fokussieren, nicht das 'Wie'. User Stories bieten die Chance, klare Rollen und Ziele zu definieren, sollten aber nicht zu perfektionistisch ausformuliert werden. Die Balance zwischen durchdachten Acceptance Criteria und der Vermeidung von Perfektionismus ist entscheidend.
User Story Mapping
User Story Mapping ist eine agile Methode zur Visualisierung und Strukturierung von Anforderungen aus Sicht der Nutzer. Das Team erstellt gemeinsam eine Landkarte (Map) aller User Stories, die den Weg des Nutzers durch das Produkt abbilden. Dadurch werden Zusammenhänge, Lücken und Prioritäten sichtbar. User Story Mapping fördert das gemeinsame Verständnis, erleichtert die Release-Planung und hilft, den Fokus auf den Kundennutzen zu legen.
User Tests
Große Aufgaben oder Funktionen, die ein Benutzer mit einem System durchführen möchte, dienen dazu, die Anforderungen an das System zu verstehen.
Erwähnt in folgenden Folgen
Velocity
Ein Maß für die Menge an Arbeit, die ein Team in einem Sprint erledigen kann, oft gemessen in Story-Punkten.
Erwähnt in folgenden Folgen
Vertrauen
Ein zentraler Aspekt im agilen Arbeiten, der die Basis für eine erfolgreiche Zusammenarbeit und Teamdynamik bildet, indem er den Teammitgliedern die Freiheit und Verantwortung überträgt, Entscheidungen zu treffen.
Erwähnt in folgenden Folgen
Walking the Board
Walking the Board ist eine agile Methode zur Gestaltung des Daily Scrum. Im Gegensatz zu klassischen Statusrunden steht hier die gemeinsame Arbeit am Board im Mittelpunkt. Das Team arbeitet von rechts nach links über das Board, fokussiert sich auf die oberste Story und diskutiert gemeinsam, wie diese effizient abgeschlossen werden kann. Ziel ist es, Blockaden frühzeitig zu erkennen, Wissen zu teilen und den Flow kontinuierlich zu verbessern. Walking the Board fördert eine schnelle Lieferung von Software und kontinuierliche Verbesserung.
Erwähnt in folgenden Folgen
WiP-Limit
Ein WiP-Limit (Work in Progress Limit) begrenzt die Anzahl der Aufgaben, die gleichzeitig in einem Prozessschritt oder im gesamten Workflow bearbeitet werden dürfen. Es hilft, Engpässe sichtbar zu machen, Kontextwechsel zu reduzieren und den Arbeitsfluss zu verbessern. Teams können WiP-Limits pro Person, Team oder Prozessschritt festlegen und durch regelmäßiges Anpassen kontinuierlich optimieren.
Erwähnt in folgenden Folgen
WiP-Limit-Simulator
Ein WiP-Limit-Simulator ist ein Tool, mit dem Teams den Einfluss verschiedener WiP-Limits auf ihren Arbeitsfluss testen können. Durch das Einstellen von Parametern und das Beobachten von Metriken wie Durchlaufzeit oder Durchsatz lassen sich konkrete Optimierungsmöglichkeiten ableiten. Der in der Folge vorgestellte Simulator macht die Effekte von WiP-Limits visuell erfahrbar.
Erwähnt in folgenden Folgen
Work in Progress
Work in Progress (WIP) bezeichnet die Anzahl der Items, die sich gleichzeitig in Bearbeitung befinden. Diese Metrik ist eng mit dem Konzept der WIP-Limits verbunden, die Teams helfen, ihre Kapazität zu kontrollieren und Überlastung zu vermeiden. Die Messung des WIP ist ein wichtiger Bestandteil der Flow-Messung und hilft Teams, ihren Arbeitsfluss zu optimieren und Engpässe zu identifizieren.
WSJF (Weighted Shortest Job First)
WSJF (Weighted Shortest Job First) ist eine Priorisierungsmethode, die hilft, die Reihenfolge von Arbeiten nach ihrem wirtschaftlichen Nutzen zu bestimmen. Dabei wird das Gewicht (Business Value + Time Criticality + Risk Reduction/Opportunity Enablement) durch die Dauer (Job Size) geteilt. Das Ergebnis zeigt, welche Arbeiten den größten Wert in der kürzesten Zeit liefern. WSJF unterstützt datenbasierte Entscheidungen im Product Backlog Management und fördert Transparenz im Dialog mit Stakeholdern.