Willkommen zurück zum ultimativen Anleitung zu Agile! In Teil 1 haben wir uns mit den Grundlagen von Agile, seinen Prinzipien und einigen beliebten Frameworks beschäftigt.
In Teil 2 gehen wir nun näher darauf ein, wie Agilität auf Teamebene funktioniert, werfen einen detaillierten Blick auf das Scrum Framework und erörtern gängige Ansätze und Fallstricke bei der Einführung von Agilität in Teams.
Agilität auf Teamebene
Bei der Agilität auf Teamebene geht es darum, ein Umfeld zu schaffen, in dem sich Teams flexibel anpassen, zusammenarbeiten und kontinuierlich verbessern können. Dazu gehören die Verbesserung der Kommunikation und Zusammenarbeit, die Anpassung an Veränderungen und die Konzentration auf kontinuierliche Verbesserung. Schauen wir uns an, was dies in der Praxis bedeutet.
Erstens sind funktionsübergreifende Teams von entscheidender Bedeutung. Diese Teams setzen sich aus Mitgliedern mit unterschiedlichen Fähigkeiten zusammen und stellen sicher, dass sie ein komplettes Produktinkrement mit so wenig externen Abhängigkeiten wie möglich liefern können. In einem Team, das sich auf die Bereitstellung eines Softwareprodukts konzentriert, könnten beispielsweise Entwickler, Tester und UX-Designer zusammenarbeiten.
Die iterative und die fließende Entwicklung sind beide Schlüsselelemente von Agile. Bei der iterativen Entwicklung wird in kurzen Zyklen oder Iterationen gearbeitet, die in der Regel zwischen einer und vier Wochen dauern und es den Teams ermöglichen, ihre Fortschritte regelmäßig zu überprüfen, Feedback einzuholen und notwendige Anpassungen vorzunehmen. Bei einem flussbasierten Ansatz wie Kanban hingegen liegt der Schwerpunkt auf einem kontinuierlichen Arbeitsfluss ohne feste Iterationen. Je nachdem, was dem Team den größten Nutzen bringt, wird der Ansatz gewählt und weiterverfolgt.
Befähigung und Eigenverantwortung sind ebenfalls von entscheidender Bedeutung. Den Teams wird die Autonomie eingeräumt, Entscheidungen über ihre Arbeitsweise zu treffen, was das Gefühl von Eigenverantwortung und Verantwortlichkeit fördert. Dieses Umfeld verbessert nicht nur die Produktivität, sondern fördert auch die Moral und das Engagement des Teams und ermöglicht es dem Team, innovativere und bahnbrechende Lösungen zu entwickeln.
Nehmen wir das Beispiel eines Frontend- Entwicklers, der den Backend- Entwicklern in Spitzenzeiten hilft, die Ziele des Sprints zu erreichen (das habe ich selbst schon mehrfach erlebt). Diese funktionsübergreifende Zusammenarbeit hilft dem Team, auf Kurs zu bleiben und seine Ziele zu erreichen, was die Stärke der Agilität auf Teamebene verdeutlicht.
Zusammenfassung der agilen Frameworks aus Teil 1
Hier ist eine kurze Zusammenfassung der agilen Frameworks, die wir in Teil 1 besprochen haben:
Frameworks / Methods | Description |
Scrum | Scrum ist ein Rahmenwerk für das agile Projektmanagement, das den Schwerpunkt auf iterativen Fortschritt durch Time-Boxed Sprints legt. Teams arbeiten in kurzen Zyklen, um funktionale Produktinkremente zu liefern, wobei Rollen wie Scrum Master, Product Owner und Teammitglieder den Prozess unterstützen. |
Kanban | Kanban ist eine visuelle Methode zur Verwaltung von Arbeitsabläufen, bei der eine Kanban-Tafel zur Visualisierung von Arbeitsaufgaben, zur Begrenzung der laufenden Arbeiten und zur Optimierung des Arbeitsflusses verwendet wird. Der Schwerpunkt liegt auf der kontinuierlichen Lieferung ohne bestimmte zeitlich begrenzte Iterationen. |
Extreme Programming (XP) | XP ist eine Softwareentwicklungsmethodik, die darauf abzielt, die Softwarequalität und die Reaktionsfähigkeit auf sich ändernde Kundenanforderungen zu verbessern. Praktiken wie Pair Programming, testgetriebene Entwicklung und kontinuierliche Integration sind Schlüsselkomponenten von XP. |
Lean | Lean konzentriert sich auf die Beseitigung von Verschwendung, die Optimierung von Prozessen und die Schaffung von Mehrwert für den Kunden. Der Schwerpunkt liegt auf der kontinuierlichen Verbesserung und dem Respekt vor den Menschen, wobei häufig Praktiken wie die Wertstromanalyse und die Just-in-Time-Entwicklung zum Einsatz kommen. |
Crystal | Crystal ist eine Familie von Methoden, die sich auf Menschen, Interaktion, Gemeinschaft, Fähigkeiten und Talente konzentriert. Sie ist so konzipiert, dass sie anpassungsfähig ist und die Größe und Kritikalität des Projekts berücksichtigt. |
In diesem Artikel konzentrieren wir uns hauptsächlich auf Scrum:
Eine kurze Einführung in Scrum und seine wichtigsten Komponenten auf der Grundlage des Scrum Guide,
über den Scrum Guide hinausgehen und Ihnen Herausforderungen und häufige Fallstricke aufzeigen, die wir in verschiedenen Organisationen rund um Scrum gesehen haben, und dann
einige Best Practices vorzustellen, wie einige der Probleme, die wir in verschiedenen Organisationen auf Teamebene angetroffen haben, gelöst werden können.
Einführung in Scrum
Scrum ist ein beliebtes agiles Framework, das in erster Linie für die Softwareentwicklung verwendet wird und später auch auf andere Bereiche ausgedehnt wurde. Es strukturiert die Arbeit in Iterationen, so genannten Sprints, die bis zu einem Monat dauern können. Scrum hat einige Schlüsselkomponenten, die sich auf folgende Punkte konzentrieren: Rollen, Ereignisse und Artefakte.
In diesem Abschnitt werden wir zunächst den Scrum Guide zusammenfassen, um ein grundlegendes Verständnis von Scrum zu vermitteln. Anschließend werden wir diesen Rahmen mit Erkenntnissen und Best Practices erweitern, die auf unseren eigenen Erfahrungen beruhen, sowie mit häufigen Fallstricken, die in verschiedenen Organisationen beobachtet wurden. Für einen umfassenden Überblick ist der Scrum Guide selbst sehr empfehlenswert, da er detaillierte Einblicke in einem prägnanten Format bietet.
Offizielle Definition von der Scrum Guide: Scrum ist ein leichtgewichtiges Rahmenwerk, welches Menschen, Teams und Organisationen hilft, Wert durch adaptive Lösungen für komplexe Probleme zu generieren.
Scrum-Säulen
Scrum basiert auf drei Grundpfeilern, die das gesamte Framework stützen. Diese Säulen stellen sicher, dass der Prozess transparent ist, dass der Fortschritt regelmäßig überprüft wird und dass das Team sich auf der Grundlage seiner Erkenntnisse anpasst.
Transparenz: Transparenz bedeutet, dass alle Aspekte des Prozesses für diejenigen, die für das Ergebnis verantwortlich sind, sichtbar sein müssen. Dazu gehört die Einsicht in den Arbeitsfortschritt, in den Prozess und in alle auftretenden Probleme und Hindernisse. Artefakte wie das Product Backlog, das Sprint Backlog und das Inkrement müssen für alle Beteiligten transparent sein, um ein gemeinsames Verständnis zu gewährleisten.
Inspektion: Die regelmäßige Überprüfung der Scrum-Artefakte und des Fortschritts auf dem Weg zum Sprint-Ziel ist entscheidend. Häufige Inspektionspunkte (z.B. während Daily Scrums, Sprint Reviews und Retrospektiven) ermöglichen es dem Team, Abweichungen oder Probleme frühzeitig zu erkennen. Auf diese Weise wird sichergestellt, dass alle Probleme umgehend angegangen werden können, um erhebliche Abweichungen von den erwarteten Ergebnissen zu vermeiden.
Adaption: Die Anpassung umfasst die Anpassung von Prozessen und Plänen auf der Grundlage der Ergebnisse von Inspektionen. Wenn eine Inspektion ergibt, dass ein oder mehrere Aspekte eines Prozesses außerhalb der zulässigen Grenzen liegen, müssen Anpassungen vorgenommen werden. Dies kann bedeuten, dass das Product Backlog geändert wird, der Ansatz für den nächsten Sprint geändert wird oder die Teamdynamik angegangen wird. Das Ziel ist es, sich kontinuierlich zu verbessern und anzupassen, um die bestmöglichen Ergebnisse zu erzielen.
Scrum Schlüsselrollen
In Scrum gibt es drei Hauptrollen, die alle für den Erfolg des Frameworks entscheidend sind:
Scrum Master: Der Scrum Master ist ein Moderator und Coach, der dafür verantwortlich ist, dass das Scrum Team die Scrum Prinzipien und Praktiken einhält. Er hilft dem Team, Hindernisse zu beseitigen, moderiert Veranstaltungen und fördert ein Umfeld für kontinuierliche Verbesserung. Der Scrum Master ist für die Effektivität des Teams verantwortlich und stellt sicher, dass Scrum verstanden und richtig umgesetzt wird.
Product Owner: Der Product Owner ist für die Maximierung des Wertes des Produkts verantwortlich, das aus der Arbeit des Scrum-Teams hervorgeht. Er verwaltet das Product Backlog und stellt sicher, dass es sichtbar und transparent ist und entsprechend den Bedürfnissen und Zielen des Unternehmens priorisiert wird. Der Product Owner arbeitet eng mit den Stakeholdern zusammen, um Anforderungen und Feedback zu sammeln, und mit dem Entwicklungsteam, um Arbeitselemente und Prioritäten zu klären.
Entwickler: Die Entwickler, früher als Entwicklungsteam bezeichnet, sind eine sich selbst organisierende Gruppe von Fachleuten, die am Ende jedes Sprints ein potenziell lieferbares Produktinkrement bereitstellen. Sie sind funktionsübergreifend und verfügen über alle erforderlichen Fähigkeiten zur Erstellung des Produktinkrements. Die Entwickler sind dafür verantwortlich, ihre Arbeit während des Sprint Planning zu planen und sicherzustellen, dass ihre Arbeit mit dem Sprint-Ziel übereinstimmt. Nebenbemerkung: Ich verwende gerne anstelle von „Entwicklern“ das Wort „Teammitglieder“, um zu signalisieren, dass Scrum auch außerhalb der IT eingesetzt werden kann.
Scrum Events
Scrum ist um fünf Events herum strukturiert, die für Regelmäßigkeit sorgen und den Bedarf an zusätzlichen Treffen minimieren. Diese Ereignisse schaffen einen Rhythmus und bieten Gelegenheiten zur Überprüfung und Anpassung.
Sprint: Das Herzstück von Scrum ist ein Sprint, eine Zeitspanne von einem Monat oder weniger, in der ein „fertiges“, brauchbares und potenziell veröffentlichbares Produktinkrement erstellt wird. Sprints haben eine gleichbleibende Dauer über die gesamte Entwicklungszeit.
Sprint-Planung: Dieses Ereignis markiert den Beginn des Sprints, bei dem das Team zusammenarbeitet, um das Sprint-Ziel zu definieren, Product Backlog-Elemente auszuwählen, an denen gearbeitet werden soll, und einen Plan für die Bereitstellung dieser Elemente zu erstellen. Der Product Owner stellt sicher, dass das Backlog nach Prioritäten geordnet ist, und die Entwickler prognostizieren, was sie erreichen können.
Daily Scrum: Ein kurzes, zeitlich begrenztes Ereignis von 15 Minuten, das an jedem Tag des Sprints stattfindet. Das Daily Scrum ist eine Gelegenheit für die Entwickler, ihre Aktivitäten zu synchronisieren und einen Plan für die nächsten 24 Stunden zu erstellen. Sie besprechen, was am Vortag getan wurde, was heute getan werden soll und welche Hindernisse es gibt.
Sprint Review: Findet am Ende des Sprints statt, um das Inkrement zu überprüfen und das Product Backlog bei Bedarf anzupassen. Während des Sprint Reviews präsentiert das Scrum Team den wichtigsten Stakeholdern die Ergebnisse seiner Arbeit und bespricht den Fortschritt auf dem Weg zum Produktziel. Es ist eine Gelegenheit, Feedback zu sammeln und fundierte Entscheidungen über die nächsten Schritte zu treffen.
Sprint Retrospective: Diese Veranstaltung bietet dem Scrum-Team die Gelegenheit, sich selbst zu überprüfen und einen Plan für Verbesserungen zu erstellen, die im nächsten Sprint umgesetzt werden sollen. Die Retrospektive konzentriert sich auf die Prozesse und Interaktionen des Teams und sucht nach Möglichkeiten zur Verbesserung von Effizienz und Qualität.
Scrum Artefakte
Scrum Artefakte liefern wichtige Informationen, um Transparenz zu gewährleisten und Möglichkeiten zur Überprüfung und Anpassung zu bieten.
Produkt-Backlog: Eine entstehende, geordnete Liste dessen, was zur Verbesserung des Produkts benötigt wird. Es ist die einzige Quelle für die vom Scrum-Team durchgeführten Arbeiten. Der Product Owner ist für das Product Backlog verantwortlich, einschließlich seines Inhalts, seiner Verfügbarkeit und seiner Reihenfolge.
Sprint Backlog: Die Menge der für den Sprint ausgewählten Product Backlog-Elemente sowie ein Plan für die Lieferung des Produktinkrements und das Erreichen des Sprint-Ziels. Das Sprint Backlog ist ein gut sichtbares, in Echtzeit erstelltes Bild der Arbeit, die die Entwickler während des Sprints zu erledigen planen, und es gehört ausschließlich den Entwicklern.
Inkrement: Die Summe aller Product Backlog Items, die während eines Sprints fertiggestellt werden, und der Wert der Inkremente aller vorherigen Sprints. Das Inkrement muss sich in einem brauchbaren Zustand befinden, unabhängig davon, ob der Product Owner beschließt, es freizugeben. Innerhalb eines Sprints können mehrere Inkremente erstellt werden.
Erweiterung von Scrum: Herausforderungen, Anwendung in der realen Welt und Mythenbekämpfung
Trotz seiner Popularität bietet Scrum, insbesondere der Scrum Guide, keine Antworten auf viele Herausforderungen, die wir in Organisationen sehen, und einige seiner Praktiken werden oft missverstanden. Im Folgenden finden Sie die häufigsten Herausforderungen und Mythen, die wir bei der Einführung von Scrum in Unternehmen gesehen haben.
Herausforderung 1: Commitment
Engagement kann eine große Herausforderung in Scrum sein. Teams haben oft Schwierigkeiten, sich auf Sprint-Ziele festzulegen und ziehen sich auf eine Liste von Aufgaben zurück, die sie bis zum Ende des Sprints erledigen können. Dies verhindert eine große Flexibilität bei der Erreichung des Sprint-Ziels und konzentriert sich auf eine Mentalität des Outputs statt der Ergebnisse.
Das Problem entsteht, wenn Teams der Erledigung einer vordefinierten Reihe von Aufgaben Vorrang vor dem Erreichen des umfassenderen Sprint-Ziels (falls überhaupt eines definiert ist) einräumen. Dies kann zu einer starren Denkweise führen, bei der das Team mehr darauf bedacht ist, die Punkte auf einer Liste abzuhaken, als einen Mehrwert zu liefern. Infolgedessen verpasst das Team möglicherweise Gelegenheiten, seine Arbeit auf der Grundlage von Feedback und veränderten Umständen anzupassen. Diese Fokussierung auf den Output kann das Kernprinzip von Agile, auf Veränderungen zu reagieren, anstatt einem Plan zu folgen, untergraben.
Um dieser Herausforderung zu begegnen, können Teams mehrere Strategien anwenden!
Das Sprint-Ziel klar definieren und kommunizieren: Das Sprint-Ziel sollte eine klare und präzise Aussage darüber sein, was das Team bis zum Ende des Sprints erreichen will. Es dient als Leitstern für das Team und hilft ihm, sich darauf zu konzentrieren, einen Mehrwert zu liefern und nicht nur Aufgaben zu erledigen.
Probiere: Stelle zu Beginn (idealerweise schon vorher, um eine Abstimmung mit allen Beteiligten zu erreichen) jedes Sprints während der Sprintplanung sicher, dass das Sprint-Ziel klar definiert ist und von allen Teammitgliedern verstanden wird. Der Product Owner sollte das Ziel klar formulieren, und das Team sollte besprechen, wie seine geplante Arbeit zu diesem Ziel beiträgt. Bespreche das Sprint-Ziel regelmäßig während der Daily Scrums, um es für alle im Blick zu behalten.
Fördern Sie eine Kultur des ergebnisorientierten Denkens: Der Wechsel der Denkweise des Teams vom Output zum Outcome ist für das Engagement entscheidend. Das bedeutet, sich auf die Ergebnisse und den Nutzen der Arbeit zu konzentrieren und nicht nur auf die Erledigung von Aufgaben.
Probiere: Ermutige das Team, sich zu fragen, wie jedes Arbeitselement zum Sprint-Ziel und zum Gesamtwert, der dem Kunden geliefert wird, beiträgt. Verwende Messgrößen, die die Ergebnisse messen, z. B. die Kundenzufriedenheit, und nicht nur Output-Kennzahlen wie die Anzahl der erledigten Aufgaben. Erkenne das Erreichen von Ergebnissen an und belohne dieses, und nicht nur die Erledigung von Aufgaben.
Fördern Sie Flexibilität und Anpassungsfähigkeit: Flexibilität ist der Schlüssel, um auf Änderungen und neue Informationen zu reagieren, die sich während des Sprints ergeben. Ein starrer Fokus auf eine vordefinierte Liste von Aufgaben kann die Fähigkeit des Teams behindern, sich anzupassen und das Sprint-Ziel zu erreichen.
Probiere: Erlaube dem Team, seine Arbeitsaufgaben anzupassen, wenn dies dem Sprint-Ziel besser dient. Das bedeutet, dass alle offen dafür sind, Aufgaben neu zu priorisieren, neue hinzuzufügen oder weniger kritische Aufgaben auf der Grundlage der neuesten Rückmeldungen und Informationen fallen zu lassen. Ermutige alle Teammitglieder, zusammenzuarbeiten und sich gegenseitig bei der Erreichung des Ziels zu unterstützen, anstatt in Silos an ihren einzelnen Arbeitsaufgaben zu arbeiten.
Durch eine klare Definition und Kommunikation des Sprint-Ziels, die Förderung einer Kultur des ergebnisorientierten Denkens und die Förderung von Flexibilität und Anpassungsfähigkeit können Teams die Herausforderung des Engagements in Scrum meistern.
Diese Strategien tragen dazu bei, den Schwerpunkt von der bloßen Erledigung von Aufgaben auf die Lieferung von echtem Wert zu verlagern und sicherzustellen, dass das Team agil bleibt und auf Veränderungen reagieren kann.
Herausforderung 2: Keine Ziele oder mehrere Ziele
In Scrum ist es entscheidend, klare und fokussierte Ziele zu haben, um die Bemühungen des Teams zu lenken und ihren Erfolg zu messen. Teams stehen jedoch oft vor der Herausforderung, aufgrund der unterschiedlichen Anforderungen der Stakeholder mit mehreren Zielen zu jonglieren. Dies kann zu widersprüchlichen Prioritäten und einem Mangel an klarer Ausrichtung führen. So kann es beispielsweise vorkommen, dass Teams mehrere Produkt- oder Sprint-Ziele gleichzeitig verfolgen müssen. Darüber hinaus müssen sie diese Ziele oft mit operativen Aufgaben oder dem Tagesgeschäft in Einklang bringen, was ihre Fähigkeit, sich zu konzentrieren, weiter erschwert.
Auf der anderen Seite gibt es Teams, die ohne definierte Produkt- oder Sprint-Ziele arbeiten. In solchen Fällen werden Verpflichtungen auf der Ebene einzelner Arbeitsaufgaben eingegangen, und der Erfolg des Teams wird daran gemessen, ob es diese Aufgaben abschließt. Dieser Ansatz kann zu einem Mangel an Zusammenhalt und gemeinsamen Zielen führen, so dass es für das Team schwierig ist, seine Bemühungen auf ein gemeinsames Ziel auszurichten.
Setzen Sie klare und priorisierte Ziele: Ein wirksamer Ansatz besteht darin, sicherzustellen, dass die Teams klare und nach Prioritäten geordnete Ziele haben. Um dies zu erreichen, müssen Sie alle Beteiligten an Bord holen und ihnen erklären, warum die Konzentration auf ein Produkt und ein Sprint-Ziel wichtig ist.
Probiere: Schaffe ein Verständnis dafür, dass Multitasking uns verlangsamt und dass der Nutzen erst später eintritt. Du kannst versuchen, dies mit Hilfe dieses Spiels in einer unterhaltsameren Umgebung zu tun: https://www.crisp.se/gratis-material-och-guider/multitasking-name-game
Probiere: Lege in jedem Sprint ein einzelnes Sprint-Ziel fest, das das Produktziel unterstützt. Dies stellt sicher, dass das Team seine Bemühungen auf die Erreichung bestimmter Ergebnisse konzentrieren kann. Versuchen Sie, das Scrum-Team davon zu überzeugen, diesen Ansatz mindestens 2-3 Sprints lang auszuprobieren und ihn dann in einer Retrospektive gemeinsam zu überprüfen, um sicherzustellen, dass die Herausforderungen erkannt werden und über Verbesserungen nachgedacht wird.
Probiere: Legen Sie in jedem Sprint ein einzelnes Sprint-Ziel fest, das das Produktziel unterstützt. Dies stellt sicher, dass das Team seine Bemühungen auf die Erreichung bestimmter Ergebnisse konzentrieren kann. Versuchen Sie, das Scrum-Team davon zu überzeugen, diesen Ansatz mindestens 2-3 Sprints lang auszuprobieren und ihn dann in einer Retrospektive gemeinsam zu überprüfen, um sicherzustellen, dass die Herausforderungen erkannt werden und über Verbesserungen nachgedacht wird.Definiere „Health Metrics“, die wichtige KPIs für Ihr Produkt darstellen.Beispiel: Eine Gesundheitsmetrik für eine Website, die Katzenspielzeug bewirbt, könnte „Seitenladegeschwindigkeit unter 3 Sekunden“ sein. Wenn diese Kennzahl über dem Schwellenwert liegt, muss das Team so schnell wie möglich Abhilfe schaffen, da dies zum Verlust einer großen Anzahl von Kunden führen könnte. Dies würde natürlich den Sprint und das Sprint-Ziel unterbrechen. Die Idee ist, dass das Team auf diese Gesundheitsmetriken achtet und sicherstellt, dass die Qualität hoch bleibt, wenn es ein Produkt- und Sprint-Ziel verfolgt.Lege einen festen Prozentsatz der Sprint-Kapazität für operative oder geschäftsübliche Arbeitsaufgaben fest. Hier kann der Fall eintreten, dass sich die Teams mehr auf den Output als auf die Ergebnisse konzentrieren und es schwierig ist, die Kapazität innerhalb eines Sprints genau zu erreichen.Wir haben festgestellt, dass es besser funktioniert, für einen breiteren Zeitrahmen eine Vorgabe zu machen, wie viele operative oder geschäftsübliche Aufgaben in einem Quartal angegangen werden sollten. Beispiel: In einem Quartal sollte jedes Team zwischen 15 und 20 % an operativen Aufgaben arbeiten. Dies gibt dem Team die Flexibilität, sich in jedem Sprint mehr oder weniger auf operative Aufgaben zu konzentrieren, und hilft ihm, einen Ausgleich zwischen Zeiten mit hohem Einsatz für die Sprint-Ziele zu schaffen.
Herausforderung 3: Kein Produkt
In Scrum besteht das Hauptziel darin, am Ende jedes Sprints ein potenziell auslieferbares Produktinkrement zu liefern. Dies setzt voraus, dass die Teams ein klares und gut definiertes Produkt haben, an dem sie arbeiten. Allerdings kann die Unklarheit darüber, was ein Produkt ist, den Fortschritt behindern und es für Teams schwierig machen, sich auf die Lieferung von Werten zu konzentrieren.
So kann ein Team beispielsweise für eine Komponente verantwortlich sein, die Teil eines größeren Produkts ist, das von Endbenutzern verwendet wird. Wenn diese Komponente für sich genommen den Endbenutzern keinen Wert liefern kann, hat das Team möglicherweise Schwierigkeiten, die inkrementelle Produktentwicklung effektiv zu betreiben.
Wenn Teams mit der Arbeit an Komponenten und nicht an kompletten Produkten betraut sind, stehen sie oft vor mehreren Herausforderungen:
Mangel an klaren Zielen: Ohne ein klares Verständnis des Produkts fehlt es den Teams möglicherweise an einer einheitlichen Vision und Zielsetzung, was zu Fehlanpassungen und Ineffizienzen führt.
Schwierigkeiten bei der Bereitstellung von Wert: Komponenten, die den Endbenutzern keinen direkten Nutzen bringen, können es den Teams erschweren, am Ende eines jeden Sprints greifbare Fortschritte und Vorteile nachzuweisen.
Fragmentierte Arbeit: Die Arbeit an isolierten Teilen kann zu fragmentierten Bemühungen führen, bei denen sich die Teams eher auf technische Aufgaben als auf nutzerzentrierte Ergebnisse konzentrieren.
Wenn du mit diesem Problem zu kämpfen hast, kannst du einige der folgenden Ideen ausprobieren.
Probiere: Bilden Sie funktionsübergreifende Teams, denen Mitglieder mit unterschiedlichen Fähigkeiten angehören, die für eine durchgängige Wertschöpfung erforderlich sind. Das hört sich einfach an, aber um diese Veränderung zu erreichen, muss eine Menge passieren.
Wenn das nicht funktioniert, kannst du versuchen, dich trotzdem in eine Richtung zu bewegen, auch wenn sie nicht ideal ist, indem du…
Probiere: Ermitteln Sie den Wert, den jede Komponente für das Gesamtprodukt bringt. Selbst wenn eine Komponente den Endbenutzern keinen direkten Wert liefert, kann das Verständnis ihrer Rolle im größeren Produkt-Ökosystem den Teams helfen, ihre Bemühungen aufeinander abzustimmen. Sorgen Sie dafür, dass Informationen fließen und leicht zugänglich sind.
Herausforderung 4: Zu viele Meetings und Overhead
Eine der häufigsten Beschwerden über Scrum ist die Wahrnehmung, dass es zu viele Meetings gibt, was zu erheblichem Overhead und geringerer Produktivität führt. Die Teams fühlen sich oft von der Anzahl der Scrum-Events wie Sprint Planning, Daily Scrums, Sprint Reviews und Sprint Retrospectives überfordert, und dies gilt umso mehr, wenn zusätzliche Meetings stattfinden. Dies kann zu einem Gefühl der Meeting-Müdigkeit führen, bei dem sich der Fokus von der eigentlichen Arbeit auf die Teilnahme an und die Vorbereitung auf diese Events verlagert.
Haben Sie Probleme mit dem Daily Scrum? Wir beobachten häufig, dass das tägliche Scrum als Statusmeeting abgehalten wird und daher viel länger dauert als vorgesehen, wofür es überhaupt nicht gedacht ist.
Probiere: Einige dich im Team darauf, den Fortschritt auf dem Weg zum Sprint-Ziel zu betrachten, anstatt jedes Work Item im Sprint durchzugehen und den Status zu „präsentieren“.
Gibt es generell zu viele Meetings / Veranstaltungen zusätzlich zum Scrum?
Probiere: Untersuche die aktuellen Meetings und sehe, wie diese zum Erfolg des Teams beitragen. Versuche zu überlegen, ob die Meetings durch einen asynchronen Chat (MS Teams, Slack, …) oder E-Mail abgedeckt werden können. Hier hat Atlassian eine schöne Infografik zu diesem Thema erstellt: https://atlassianblog.wpengine.com/wp-content/uploads/2018/05/meeting-flowchart-update-v15.jpg
Mythos 1: Scrum ist nur für IT
Ein weit verbreiteter Mythos ist, dass Scrum nur für die Softwareentwicklung geeignet ist. In Wirklichkeit kann Scrum auf jeden komplexen, innovativen Arbeitsbereich angewendet werden, der von einem Team in Angriff genommen werden muss.
Ein Marketingteam, das für Kampagnen zuständig ist, könnte Scrum nutzen, um bestimmte Kampagnenziele in einer bestimmten Iteration zu erreichen, z. B. die Steigerung der Zugriffe auf die Landing Page eines Produkts um x % bis zum Ende des Sprints.
Mythos 2: Scrum ist starr und lässt keine Änderungen zu
Dieser Mythos kann auf 2 verschiedene Arten betrachtet werden. Einerseits ist Scrum starr in Bezug auf die Art und Weise, wie Scrum innerhalb eines Teams durch den Scrum Guide gelebt wird. Scrum bietet zwar einen strukturierten Rahmen, aber es ermutigt Teams, ihre Prozesse innerhalb dieses Rahmens anzupassen und zu verbessern. Aus diesem Grund gibt es Scrum-Events wie die Retrospektive.
Wenn Teams mit Scrum beginnen, ist es empfehlenswert, nach dem Buch zu arbeiten. Das heißt, dem Scrum Guide so weit wie möglich zu folgen. Nach ein paar Iterationen sollten die Teams jedoch die anfänglichen Einstellungen verbessern und Scrum so konfigurieren, dass es für sie optimal funktioniert.
Mythos 3: Schätzungen werden von Scrum vorgegeben
Eines der häufigsten Missverständnisse über Scrum ist, dass es eine starre Struktur für Schätzungen erzwingt und den Teams vorschreibt, wie sie ihre Arbeit zu schätzen haben. Dieser Mythos kann zu Widerstand und Verwirrung führen, insbesondere bei Teams, die neu in agilen Praktiken sind. Er führt zu der Annahme, dass Scrum eine bestimmte Methode für die Schätzung von Aufgaben vorschreibt, z. B. Story Points oder Stunden, was für manche Teams restriktiv und kontraproduktiv sein kann.
Scrum schreibt jedoch nichts vor, was mit der Schätzung von Story Points oder irgendeiner Art von Schätzung zu tun hat. Das bedeutet, dass Schätzungen nicht per se Teil von Scrum sind und höchstwahrscheinlich von Ron Jeffries stammen, der einer der Mitwirkenden am agilen Manifest war. Auch er hat einen Artikel mit dem Titel „Story Points Revisited“ veröffentlicht, in dem er erklärt, dass er kein großer Fan davon ist.
Mythos 4: Scrum schreibt das Schreiben von User Stories vor
Ein weit verbreiteter Irrglaube über Scrum ist, dass es die Verwendung von User Stories für die Dokumentation von Product Backlog Items vorschreibt. Dieser Glaube rührt wahrscheinlich von der Integration von Praktiken aus Extreme Programming (XP) in Scrum durch agile Praktiker her. XP legt den Schwerpunkt auf User Stories als primäre Methode zur Erfassung von Kundenanforderungen, und diese Methode wurde bei Teams, die Scrum einführten, sehr beliebt. Das Scrum-Framework selbst schreibt jedoch kein bestimmtes Format für die Erfassung von Anforderungen vor.
Der Scrum Guide definiert Rollen, Ereignisse und Artefakte, überlässt aber die Techniken zur Verwaltung der Arbeit dem Ermessen des Teams.
In Wirklichkeit ist Scrum ein flexibles Framework, das sich auf iterative Entwicklung und kontinuierliche Verbesserung konzentriert. Obwohl User Stories in vielen Scrum-Teams aufgrund ihrer Effektivität weit verbreitet sind, sind sie kein erforderliches Element von Scrum. Teams können verschiedene Formate wie Anwendungsfälle, funktionale Spezifikationen oder einfache Aufgabenbeschreibungen verwenden, um Product Backlog-Elemente zu beschreiben.
Entscheidend ist, dass die Elemente klar und prägnant sind und sowohl vom Team als auch von den Stakeholdern verstanden werden, so dass das Team die besten Tools und Techniken für seinen spezifischen Kontext wählen kann.
Conclusion
In diesem zweiten Teil des ultimativen Leitfadens zu Agile haben wir uns eingehender mit der Funktionsweise von Agilität auf Teamebene befasst und uns dabei vor allem auf das Scrum-Framework konzentriert. Außerdem haben wir einen detaillierten Überblick über Scrum, einschließlich seiner Rollen, Ereignisse und Artefakte, gegeben, um Ihnen eine solide Grundlage in diesem beliebten agilen Framework zu vermitteln.
Über den Scrum Guide hinaus haben wir uns mit den häufigen Herausforderungen befasst, mit denen Teams konfrontiert sind, wie z. B. Probleme mit dem Commitment, dem Jonglieren mit mehreren Zielen und der Verwirrung um Produktdefinitionen. Indem sie diese Herausforderungen mit praktischen Strategien und Best Practices angehen, können Teams ihre Effektivität steigern und sich weiterhin auf die Bereitstellung von Werten konzentrieren.
Schließlich haben wir uns mit einigen weit verbreiteten Mythen über Scrum auseinandergesetzt, indem wir falsche Vorstellungen über die Starrheit von Scrum, die Anwendbarkeit außerhalb der IT und die vermeintlichen Vorschriften für Schätzungen und User Stories aufgeklärt haben.
Wir hoffen, mit diesen Mythen aufzuräumen und ein besseres Verständnis für die Flexibilität und Anpassungsfähigkeit von Scrum zu schaffen.
Denke bei der weiteren agilen Reise daran, dass der Schlüssel zum Erfolg in der kontinuierlichen Verbesserung und der Anpassung des Frameworks an die spezifischen Bedürfnisse Ihres Teams liegt.
Bleib dran für weitere Einblicke und praktische Ratschläge in zukünftigen Teilen unseres Ultimativen Leitfadens zu Agile.
Vergesse nicht, unseren Newsletter zu abonnieren, um über die neuesten agilen Trends und Tipps auf dem Laufenden zu bleiben.
Comments