Agile Teams

In ein agiles Umfeld, es gibt keine erfolgreicher Sprint oder Projekt ohne ein ⭐⭐⭐⭐⭐ agiles Team. Sie haben alles, was es braucht, um große Ziele in kurzen Zeiträumen zu erreichen. Wie? Jeder im Team kennt seine Macht und weiß, wie man sie einsetzt. 🧙 Das Endergebnis ist das Erreichen großer Ziele, ohne auszubrennen.

Die Struktur eines agilen Teams ist der erste Schritt zur erfolgreichen agilen Entwicklung. Nehmen wir das Beispiel der Feuerwehren. Würde eine Feuerwehr Brände löschen, wenn sie nicht die richtigen Mitglieder, Leutnant oder Kapitän hätte? Die Antwort ist kurz: Nein. Die Teamstruktur ist der Inbegriff.

Daher sollte in einem agilen Entwicklungsprozess jedes Mitglied wissen, was jede Rolle im Team beinhaltet. Heute besprechen wir die Rollen in einem agilen Team und einige Merkmale großartiger agiler Teams. Aber zuerst sollten wir ein wenig darüber sprechen, was ein agiles Team ist.

Was ist ein agiles Team?

In jedem Entwicklungszyklus — oder Sprint — eines agilen Projekts iteriert jedes agile Team das Produkt entsprechend dem Kundenfeedback. Das erhöht die Geschwindigkeit von Produktentwicklung 🏃 und die Effizienz dieses Prozesses. Und bei jeder Iteration veröffentlicht oder lanciert das Team entweder neue oder verbesserte Produktfunktionen.

Agile Teams haben ähnliche Eigenschaften. Sie sollten sein:

• Klein — 5-6 Mitglieder
• Konzentriert sich darauf, das Ziel pünktlich zu treffen
• Koordiniert in Bezug auf die Aufgabenausführung
• Im Bewusstsein des Beitrags, den jede Rolle leistet
• Flexibel, damit Mitglieder proaktiv sein und sich selbst übertreffen können
• Tolerant gegenüber sich ändernden Kundenbedürfnissen

Die Struktur agiler Teams hängt jedoch vom agilen Framework ab. Sie können zum Beispiel ein Scrum-Team haben oder Kanban-Team. Und während die auf Scrum basierenden Rollen klar definiert sind, sind es Kanban-Teams nicht.

An dieser Stelle sollten wir die Struktur eines agilen Teams besprechen. Gehen Sie zum nächsten Abschnitt über. 👇

Das Skelett eines agilen Teams

Ein agiles Team besteht aus 3 ️ Hauptrollen. Die kontinuierliche Verbesserung sowohl der Teams als auch der Unternehmen erfordert, dass die richtigen Leute die richtige Rolle spielen. Lassen Sie uns diese Rollen nacheinander durchgehen.

Inhaber des Produkts

Der Product Owner ist der Spieler mit den tiefsten Kenntnissen des Produkts. Sie essen, trinken und atmen das Produkt ein.

Sie sind die obersten Befürworter des Produkts. Wenn also etwas mit dem Produkt nicht stimmt, sollten sie das schnell wissen. Außerdem wissen sie genau, wie das Produkt zur Vision und den Zielen des Unternehmens beiträgt. 🎯

Ihre Kommunikationsfähigkeiten 🎙️ müssen erstklassig sein, da der Großteil ihrer Arbeit Folgendes erfordert:

• Das Team dazu bewegen, sich mit wichtigen Produktentwicklungen zu beschäftigen und diese durchzuführen
• Eingreifen, um diesen Prozess bei Bedarf anzupassen
• Tarife ändern, falls unbedingt erforderlich
• Auf unterschiedliche Kundenbedürfnisse reagieren

In einem Sprint ist das Ziel eine Erhöhung der Gesamtleistung. Am Ende des Tages definiert und kommuniziert der Product Owner die Ziele und Qualitätserwartungen. 📣

Die oberste Priorität von Product Ownern ist der Kunde und die Kundenbedürfnisse. In diesem Sinne fungiert ein Product Owner als Schnittstelle zwischen dem Kunden und dem Rest des Teams. Sie erhalten auch Kundenfeedback.

Der Product Owner erstellt und verwaltet auch die Produkt-Backlog. Darüber hinaus überprüfen sie die Ergebnisse vor der Produktveröffentlichung oder Markteinführung. 🧐

Denken Sie daran: Der Product Owner ist bestrebt, den Produktwert zu maximieren. Und der einzige Weg, dies zu erreichen, ist Teamarbeit.

In kleinen Unternehmen kann der Product Owner manchmal der CEO sein.

Einige agile Events sind für einen Product Owner besonders wichtig:

• Sprint-Planung. Das agile ZeremonieZiel ist es, die Iteration vorzubereiten. Es ist die richtige Zeit und der richtige Ort für den Product Owner, um den Teammitgliedern das Produkt-Backlog zu präsentieren und ihre Fragen zu beantworten.
• Sprint-Überprüfung. Das ist das Treffen, bei dem die während der Iteration geleistete Arbeit vorgestellt wird. Der Product Owner holt Feedback von externen Stakeholdern und internen Mitarbeitern ein und beantwortet deren Fragen. Nach der Überprüfung passt der Product Owner möglicherweise das Produkt-Backlog an und veröffentlicht die vollständige Produktfunktionalität.

Scrum Master

Während der Product Owner produktorientiert ist, ist der Scrum Master prozessorientiert. Sie befassen sich mit:

• Sicherstellen, dass das Team die besten agilen Praktiken für den Kontext befolgt, in dem es arbeitet
• Wir überprüfen täglich den Arbeitsfortschritt der Teammitglieder, um sicherzustellen, dass sie die Termine einhalten
• Den Teammitgliedern konstruktives Feedback zu ihrer Leistung geben
• Schutz der Zeit der Teammitglieder, damit sie sich dem widmen können, was den größten Nutzen bringt
• Kundenfeedback vom Product Owner einholen
• Stellen Sie sicher, dass sich der Product Owner über das Ziel und die Qualitätserwartungen im Klaren ist
• Begleitung des Teams während des gesamten Sprints, Klärung aller Zweifel an Aufgaben und deren Ausführung
• Teammitglieder motivieren
• Beseitigen Sie alle Blockaden, die den Erfolg eines Teammitglieds behindern

Der Scrum Master ist auch derjenige, der die verwaltet Scrum-Board. Dieses Board sollte jederzeit aktuell und detailliert sein.

Manager mit einem umfangreichen Lebenslauf erfolgreicher Produktentwicklungsprojekte sind gute Kandidaten für Scrum Master. Sie wissen aus Erfahrung, wo bei der Ausführung schief gehen kann und was zu tun ist, um dies zu verhindern oder zu korrigieren. Sie sind auch hervorragend darin, Fortschritte zu beurteilen. 📈

So nimmt der Scrum Master an agilen Events teil:

• Sprint-Planung. Der Scrum Master moderiert diese Zeremonie und beteiligt sich an den Bemühungen oder Storypoint Schätzungen.
• Tägliches Aufstehen. Während dieses Treffens konzentriert sich der Scrum Master darauf, alle Hindernisse zu beseitigen, die dem Erfolg des Teammitglieds im Wege stehen. Und wenn sich der Entwicklungsprozess ändern sollte, wird der Scrum Master dafür sorgen, dass dies geschieht.
• Sprint-Überprüfung. Der Scrum Master bereitet diese Veranstaltung logistisch vor. Wenn externe Stakeholder an dem Meeting teilnehmen, muss es reibungslos ablaufen.
• Sprint-Rückblick. Während dieser Zeremonie sollten die Teammitglieder besprechen, was während der Iteration schief gelaufen ist. Der Scrum Master sollte einen Geist des Austauschs und der Transparenz fördern, nicht nur in Bezug auf technische und verfahrenstechnische Aspekte, sondern auch in Bezug auf relationale Fragen.

Teammitglied

Das sind die ultimativen Macher. ⛑️ Je nach Art des Produkts können das Entwickler, UX-Designer und viele andere Profis sein.

Natürlich variiert ihre Rolle innerhalb des Teams je nach ihren Fähigkeiten. Dennoch sind sie diejenigen, die für die termingerechte Umsetzung großartiger Ergebnisse verantwortlich sind.

Sie sind in der Regel autonom und kreativ, unabhängig davon, ob sie als Gruppe zusammenarbeiten und sich gegenseitig unterstützen. Tatsächlich ergänzen sich die Teammitglieder gegenseitig in Bezug auf Fähigkeiten und Erfahrung. ☯️

Es ist nicht ungewöhnlich, dass Teammitglieder Ideen diskutieren, wie man schneller und einfacher arbeiten kann. Das kann zum Beispiel ein neues Tool oder eine neue Technik sein. Und ein einzelnes Teammitglied kann mehreren Teams angehören.

Nun, was können wir Ihnen noch über ideale Teammitglieder sagen?

• Sie vertrauen und unterstützen sich gegenseitig viel mehr. Gleichzeitig nutzen sie die Stärken des jeweils anderen und arbeiten intensiv zusammen. Am Ende sollten Sie feststellen, dass die Arbeit reibungslos abläuft.
• Sie lernen und betreuen sich gegenseitig. An einem Tag unterrichtet ein Teammitglied vielleicht ein anderes, und am Tag danach lernen sie vielleicht von dem Mitglied, das sie unterrichtet haben. Das ist kontinuierliches Mentoring.
• Durch gemeinsame Fähigkeiten sind die Teammitglieder besser gerüstet, um sich gegenseitig zu unterstützen. Sie sind auch besser darauf vorbereitet, bei Bedarf zwischen technischen Fachgebieten zu wechseln.
• Die Teammitglieder stellen den Erfolg in Frage und finden alternative Wege, um die kontinuierliche Verbesserung ständig voranzutreiben. Es ist in ihrem 🧬, was bedeutet, dass sie nichts dafür können. Und das ist eine großartige Eigenschaft, da sie der Schlüssel zu kontinuierlich wachsenden Produkten ist.
• Schließlich setzen sich die Teammitglieder selbst dafür ein, das absolut beste Ergebnis aus einer Iteration herauszuholen.

Hinweis: Projektbeteiligte sind in der Regel nicht Teil des agilen Teams selbst, aber sie sind Teil der Gesamtgleichung. Sie können Mitglieder der Geschäftsleitung, Marketingspezialisten oder andere Personen sein, die Arbeit vom Team anfordern oder überprüfen.

Hier sind die Rollen der Teammitglieder bei den folgenden Agile-Events:

• Sprint-Planung. Die Teammitglieder besprechen das Produkt-Backlog mit dem Product Owner, um zu entscheiden, welche Arbeiten sie während der Iteration abschließen werden.
• Tägliches Aufstehen. Jeden Tag beschreiben die Teammitglieder kurz den Status ihrer Arbeit und was sie als Nächstes tun werden. Wenn sie irgendwelche Blockaden haben, sollten sie um Hilfe bitten.
• Sprint-Überprüfung. Die Teammitglieder präsentieren die komplette Arbeit.
• Sprint-Rückblick. Während dieser Veranstaltung sollten die Teammitglieder über Probleme sprechen, mit denen sie während der Iteration konfrontiert waren. Das können technische Probleme, Probleme mit ihrer Arbeitsweise oder zwischenmenschliche Probleme sein.

Majestätische agile Teams

Ohne eine sorgfältig durchdachte Struktur wäre es ein Albtraum, eine Teamherausforderung zu gewinnen. Die Rolle jedes Einzelnen in einem agilen Team sollte glasklar sein. Das ist die Grundlage dafür, dass jeder das Gefühl hat, auf wertvolle Weise zum Ziel beizutragen.

Im täglichen Leben eines großartigen agilen Teams gibt es keine Einzelpersonen. Sie zielen auf Gruppenerfolge ab, nicht auf individuelle Erfolge. Ein agiles Team ist eine Gruppe von Fachleuten, die zusammenarbeiten, um Sprintziele zu erreichen. Lange Rede, kurzer Sinn: kein Teamwork, kein agiles Team.

Sie möchten Ihr agiles Team auf Erfolgskurs bringen? Auschecken Einfache agile Programme oder Einfache Agile User Story Maps.

Ihr Unternehmen hat sich endlich dazu verpflichtet, Scrum zu praktizieren. SCHREI!! 🎉 Das gelobte Land liegt vor dir — selbstorganisierte Teams, nachhaltiges Liefertempo und Autonomie, um das Richtige für das Produkt und das Team zu tun. Du kannst es kaum erwarten, loszulegen! (Spoiler-Alarm: In deiner Zukunft gibt es einen agilen Release-Train.)

Das war vor drei Monaten. Heute ist Ihre Produktentwicklungsorganisation ein großes Durcheinander. Die Teams liefern die falsche Arbeit zur richtigen Zeit. Der Code steckt in einem Regal fest und wartet darauf, dass ein anderes Team eine Abhängigkeit bereitstellt. Und das obere Management denkt darüber nach, den Stecker zu ziehen und zu den alten Wasserfallzeiten zurückzukehren.

Wenn Sie in einer großen Organisation mit mehr als 50 Softwareentwicklern und Ingenieuren arbeiten, kann Scrum eine harte Nuss sein. Je größer das Unternehmen, desto wahrscheinlicher sind teamübergreifende Abhängigkeiten, Planungskonflikte und Herausforderungen, die für Transparenz zwischen den Geschäfts-, Produkt- und Entwicklungsteams sorgen. Aber keine Angst...

SAFe zur Rettung! SAFe ist die Abkürzung für skaliertes agiles Framework. SAFe soll großen Unternehmen bei der Implementierung von Scrum helfen und bietet einen Rahmen für die Koordination der Arbeit vieler Scrum-Teams.

Teil des SAFe-Frameworks ist das Konzept eines Agile Release Trains (ART). Wenn Sie mit ARTs nicht vertraut sind, sind Sie hier richtig. Wir erklären, was eine ART ist, warum sie großen Unternehmen hilft, Softwarelösungen effizienter bereitzustellen, und wie Sie eine ART in Ihrem Unternehmen starten können.

Möchten Sie Ihr Team befähigen, das Scaled Agile Framework (SAFe) zu implementieren?

Probieren Sie einfache Agile-Programme aus

Nehmen Sie an einer Demo teil

Also, was ist ein Agile Release Train?

Lassen Sie uns zunächst die Zug-Metapher erklären. Ein Zug fährt die Gleise hinunter, um ein bestimmtes Ziel zu erreichen. Unterwegs kann der Zug an mehreren Depots anhalten und neue Fracht oder Passagiere aufnehmen. Ihre Softwarelösung sind die Bahngleise. Der Beitrag des Teams zu dieser Lösung ist die neue Fracht, die Sie in den Depots abholen. Und das Ziel ist der Geschäftswert, den Sie Ihren Benutzern bieten. Einfach genug, oder?

ARTs helfen einer Gruppe von Teams, sich auf den Geschäftszweck ihrer Arbeit zu konzentrieren und die Bereitstellung von Lösungen zu koordinieren. Ihre Teams sind wahrscheinlich nach Funktionen oder Wertströmen organisiert. Ein ART identifiziert den Input und den Zeitpunkt der Beiträge der einzelnen Teams, die zur Erreichung des Geschäftsziels für den Wertstrom beitragen. Stellen Sie sich das als funktionsübergreifende Koordination bei der Einnahme von Steroiden vor.

Hier sind einige grundlegende Anforderungen für eine ART:

• Der Zeitplan ist fest, sodass der Umfang variabel ist. Aber keine Panik — sobald Ihre Teams ein gleichbleibendes Tempo erreicht haben, wird das Vertrauen in den Umfang zunehmen.
• Alle Teams müssen den gleichen Sprint- und Release-Rhythmus einhalten.
• Jedes Team folgt den Werten und Prinzipien der Agiles Manifest.
• ARTs nehmen an Planungsveranstaltungen für Programminkremente (PIs) und Inspektions- und Anpassungszeremonien (I&A) teil, die Retrospektiven und Systemdemos ähneln.
• Zwischen den Programminkrementen müssen regelmäßig Iterationen für Innovation und Planung (IP) geplant werden. Dies gibt Ihrem großen Team aus einzelnen agilen Teams Zeit, um Innovationen zu entwickeln, die Infrastruktur zu aktualisieren oder an speziellen Schulungen oder einer Hot-Tech-Konferenz teilzunehmen. IP-Iterationen bieten auch einen guten Puffer für den Fall, dass Ihr PI hinter dem Zeitplan zurückbleibt.

Wenn Ihr Unternehmen groß genug ist, benötigen Sie möglicherweise mehrere Agile Release Trains, die sich auf unabhängige Wertströme konzentrieren. Wenn das der Fall ist, benötigen Sie möglicherweise eine zusätzliche Koordinationsebene, die in einer Lösungszug. Aber lassen Sie uns nicht überholen.

Prinzipien eines agilen Release-Trains

Ein Agile Release Train (ART) orientiert sich am Scaled Agile Framework (SAFe), um sicherzustellen, dass mehrere agile Teams sich aufeinander abstimmen und nahtlos zusammenarbeiten können. Hier sind die Kernprinzipien, die einem Agile Release Train zugrunde liegen:

Fester Zeitplan

ARTs halten sich an einen vordefinierten Zeitplan, um die Arbeit konsistent abzuliefern. Dieser Zeitplan ist in Form von Programminkrementen (PIs) organisiert, die in der Regel 12 Wochen lang sind. Der feste Rhythmus hilft den Teams, ihre Arbeit effizient zu planen und durchzuführen.

Zweiwöchentliche Trittfrequenz

Ähnlich wie einzelne agile Teams in Sprints arbeiten, arbeiten ARTs in zweiwöchigen Segmenten, den sogenannten Systeminkrementen. Dieser regelmäßige Rhythmus ermöglicht kontinuierlichen Fortschritt und schnelle Feedback-Zyklen.

Bekannte Geschwindigkeit

Die Kapazität des Zuges, Arbeit mit einem bestimmten Pi — der sogenannten Geschwindigkeit — zu produzieren, wird aus historischen Leistungsdaten abgeleitet. Durch die Aufteilung von Projekten in kleinere Aufgaben können Teams Prioritäten setzen und wichtige Funktionen effektiver bereitstellen.

Schrittweise entwickeln, auf Abruf veröffentlichen

Während die Entwicklung einem starren Zeitplan folgt, ist das Veröffentlichungsdatum flexibel und hängt vom Projektabschluss ab. Dieser Ansatz ermöglicht es den Teams, den Kunden kontinuierlich einen Mehrwert zu bieten, ohne durch feste Veröffentlichungsdaten eingeschränkt zu sein.

Planung der Programminkremente

Die PI-Planung ist ein Eckpfeiler, bei dem alle agilen Teams innerhalb der ART zusammenkommen, in der Regel persönlich, um strategische Ziele für das bevorstehende Inkrement festzulegen. Diese kollaborative Planung stellt sicher, dass alle an einem Strang ziehen und auf gemeinsame Ziele hinarbeiten.

Innovation und Planung

Am Ende jedes PI nehmen die Teams an einer Innovations- und Planungsveranstaltung (IP) teil. Dieser Zeitraum ist der Planung der nächsten Stufe, der Durchführung von Bildungsaktivitäten und der Erfüllung der Infrastrukturanforderungen gewidmet.

Prüfen und anpassen

Um die kontinuierliche Verbesserung zu fördern, veranstalten ARTs am Ende jedes PI eine Veranstaltung zur Überprüfung und Anpassung (IA). Die Teams bewerten ihre Fortschritte und identifizieren Verbesserungsmöglichkeiten im Rahmen eines Workshops zur Problemlösung. So stellen sie sicher, dass sie ihre Prozesse ständig verfeinern und bessere Ergebnisse erzielen.

Rollen in einem SAFe Agile Release Train

Im Allgemeinen verwenden Teams eine ART in einer Scrum-Umgebung, aber SAFe- und agile Release-Train-Konzepte können auf jede agile Methodik angewendet werden, einschließlich Extreme Programming (XP), Lean oder Kanban. Unabhängig von der von Ihnen gewählten agilen Methode sind bestimmte Rollen erforderlich, um eine ART durchzuführen.

Agile Teams

Ohne agile Teams kann es keine ART geben. Danke, Captain Obvious. 🙄

Ein Unterschied zwischen SAFe und traditionellem Scrum besteht darin, dass ARTs es Ihnen ermöglichen, mit Teams zusammenzuarbeiten, die sich einer bestimmten Funktion widmen, wie Frontend- oder Backend-Entwicklung, Qualitätssicherung, DevOps, Sicherheit sowie Geschäfts- oder Produktfunktionen. ART selbst ist funktionsübergreifend, sodass Ihre Teams dies nicht tun müssen.

Jedes Team muss einen Scrum Master und Product Owner haben, genau wie in Scrum.

Release Train Engineers (RTEs)

So wie Scrum Master ihren Teammitgliedern helfen, die Scrum-Prinzipien und Best Practices zu befolgen, sind Release Train Engineers dienende Führungskräfte, die dasselbe für den agilen Release Train tun. RTEs helfen dabei, die korrekte Ausführung von Programminkrementen sicherzustellen, Blockaden zu beseitigen, Risiken zu managen und mit den Teams an Verbesserungen zu arbeiten.

Release Train Engineers berichten in der Regel an ein Agile Management Office oder im Fall von Lean an das Portfoliomanagement-Team.

Produktmanager

Während einige traditionelle Scrum-Teams beide verwenden Produktmanager SAFe arbeitet in einer solchen Größenordnung, dass beide Rollen erforderlich sind. Der Produktmanager bestimmt die Vision, die Roadmap und den Feature-Backlog, während der Product Owner dafür verantwortlich ist, das PI-Ziel mit dem Team zu definieren und die Funktionalität auszuführen.

Einfache agile Programme ermöglicht es Release Train-Ingenieuren und Programmmanagern, Programme effektiv zu verwalten, um eine Abstimmung im großen Maßstab zu gewährleisten.

Probieren Sie einfache Agile-Programme aus

Systemarchitekten

Auch hier ist aufgrund der Größe, in der SAFe-Teams arbeiten, ein Systemarchitekt erforderlich, um die übergeordnete Struktur des Gesamtsystems zu entwerfen, zu bestimmen, wie jedes Teil in das Puzzle passt, und stabile Integrationspunkte zu schaffen, um Daten und Prozesse in ein zentralisiertes ERP zu integrieren.

Geschäftsinhaber

Die Geschäftsinhaber sind dafür verantwortlich, Geschäftsergebnisse wie Umsatz- oder Kundengewinnungsziele zu erreichen. Als Hauptakteur von ARTS agieren Geschäftsinhaber auf strategischer Ebene und werden an Diskussionen über Vision, Roadmap und Programminkrementierung teilnehmen. Ihre Aufgabe besteht darin, sicherzustellen, dass die Produkte so gebaut werden, dass sie bestimmte Geschäftsziele erfüllen.

Kunden

Kunden sind die ultimativen wirtschaftlichen Käufer oder werthaltigen Nutzer der Lösung. Ihr Feedback und ihre Bedürfnisse sind entscheidend für den Erfolg der ART.

Systemteams

Systemteams helfen in der Regel beim Aufbau und der Wartung von Entwicklungs-, kontinuierlichen Integrations- und Testumgebungen. Sie spielen eine entscheidende Rolle dabei, sicherzustellen, dass die Infrastruktur die ART effektiv unterstützt.

Geteilte Dienste

Zu den gemeinsamen Diensten gehören Spezialisten, die für den Erfolg einer ART erforderlich sind, die aber nicht einem bestimmten Zug gewidmet werden können. Dazu gehören häufig Datensicherheitsexperten, Informationsarchitekten, Site Reliability Engineers (SRE), Datenbankadministratoren (DBAs) und viele mehr.

Starte mit deinem Agile Release Train

Also, du bist bereit, auf die ART zu springen! Großartig! Lassen Sie uns die Schritte durchgehen, um Ihnen den Einstieg in Ihre Reise zu erleichtern.

1. Beginne mit dem Training

Sparen Sie nicht an diesem. Sie haben Ihre agilen Praktiken wahrscheinlich mit etwas Training begonnen. Machen Sie das Gleiche hier. All die harte Arbeit und die besten Absichten der Welt können dir nicht helfen, wenn du kein solides Verständnis der Grundlagen hast.

Neben der Schulung der Teams sollten Sie auch Ihre Führungsteams und Führungskräfte schulen. Genau wie zu der Zeit, als Ihr Unternehmen agile Prinzipien eingeführt hat, sollten Sie sicherstellen, dass Sie die Zustimmung dazu haben, ein Verständnis dafür haben, wie agile Release Trains funktionieren und welche Rollen zu ihrer Unterstützung erforderlich sind.

2. Identifizieren Sie Ihre Wertströme

In SAFe gibt es zwei Arten von Wertströmen: betriebliche und entwicklungsorientierte. Ein operativer Wertstrom konzentriert sich darauf, den Endnutzern den Wert zu bieten, der durch den Wertstrom aus der Entwicklung geschaffen wurde. Ein Beispiel könnte die Erfüllung einer Bestellung von einer E-Commerce-Website sein.

Ein Entwicklungswertstrom konzentriert sich auf die Entwicklung der Geschäftslösung, beispielsweise auf den Aufbau einer E-Commerce-Website.

Die Identifizierung Ihrer Wertströme ist wichtig, bevor Sie Personen und Teams auswählen, die an dem Wertstrom arbeiten, und die zusätzlichen Rollen besetzen, die für die ART erforderlich sind. Sobald die Spieler ausgewählt wurden, können Sie mit der Planung beginnen.

3. Bereiten Sie das Programm Increment Backlog vor

Es ist Zeit, deine zu verfeinern Programm-Rückstand und machen Sie sich bereit für die PI-Planung. Planung und Verfeinerung ist am besten, wenn Sie sich persönlich treffen können, aber manchmal ist das in großen Organisationen unmöglich. Wenn Sie ein verteiltes Team haben, stellen Sie sicher, dass Sie einen guten Backlog haben Tool wie Jira um virtuelle Besprechungen zu ermöglichen.

🚨 Auf der Suche nach der kompletten PI Planning-Lösung für Jira?

Probieren Sie einfache Agile-Programme aus

Ideal für die dezentrale, ferngesteuerte oder persönliche Planung von Programminkrementen.

Nehmen Sie an einer Demo teil!

Erstellen Sie Ihre User Stories auf Programmebene, damit sie in eine zweiwöchige Timebox passen, und planen Sie Ihre erste Veröffentlichung. Lassen Sie in der Iteration etwas Spielraum, bis Ihre Teams eine vorhersehbare Geschwindigkeit erreicht haben.

4. Starten Sie das Programm Increment

Jetzt ist es wie immer Scrum. Sie haben Ihren Sprint startklar — führen Sie ihn einfach wie gewohnt aus. Am Ende des Sprints kannst du den Beitrag deiner Teams zum Release Train hinzufügen.

5. Spülen und wiederholen

Agile Release Trains sind ein kontinuierlicher, iterativer Bereitstellungsmechanismus. Genau wie bei traditionellem Scrum werden Ihre Teams etwas entwickeln, veröffentlichen, lernen und dann wieder mit der Entwicklung beginnen. Vergessen Sie nicht, eine Innovations- und Planungsiteration einzuplanen, um dem Team eine Pause vom Trubel zu geben und Zeit zu geben, ihre Systeme oder ihr Team zu verbessern.

Bist du bereit, an Bord zu springen?

SAFe- und Agile Release Trains helfen Teams dabei, agile Entwicklungspraktiken beizubehalten, wenn sie an Größe zunehmen. Was auf den ersten Blick kompliziert erscheinen mag, ist in Wirklichkeit ein gut orchestrierter Prozess, der für die Teamsynchronisierung gemäß den Geschäftswertströmen konzipiert ist.

Nutze das Scrum-Wissen, das du in den einzelnen Teams hast, und trainiere dann in SAFe-Praktiken und bereite dich darauf vor, deinen ersten agilen Release-Train zu erstellen. Sie lernen, indem Sie es tun, aber ersparen Sie sich und Ihrem Unternehmen einige Kopfschmerzen und Geld und investieren Sie zuerst in Schulungen.

Wir haben in diesem Artikel auf einige großartige Lernartikel verlinkt, aber hier sind noch ein paar weitere, die Ihnen helfen sollen, Ihr SAFe-Lernen zu beschleunigen:

• Der ultimative Leitfaden zur PI-Planung [2021 SAFe Edition]
• SAFe Program Board 101: Alles, was Sie wissen müssen
• Scaled Agile Framework (SAFe) 5.0 — Der einfache Agile Review
• Optimieren Sie Ihre Arbeitsabläufe mit einer besseren PI-Planungssoftware
• So bereiten Sie sich auf die verteilte PI-Planung vor

Viel Glück auf deiner agilen Reise und bleib SAFe! (Zu kitschig? 🤦🏽 ‍ ♀️)

Bei Easy Agile orientieren wir uns (natürlich) an agilen Prinzipien und bemühen uns, Softwareentwicklungsteams dabei zu unterstützen, agile Methoden in die Praxis umzusetzen. Da jedoch jeden Tag so viel zu erledigen ist, ist es leicht, die Kernprinzipien der agiles Manifest.

Sie denken wahrscheinlich, dass Sie die agilen Prinzipien schon einmal gelesen haben und sie jetzt in die Praxis umsetzen... den ganzen Tag, jeden Tag. Warum müssen wir sie noch einmal überdenken?

Sie müssen die Prinzipien nicht auswendig lernen. Sie sind viel mehr ein Leitfaden als ein Routineprozess. Aber wenn Sie die agilen Prinzipien mit Ihren täglichen agilen Praktiken abgleichen, wird bestätigt, dass Sie sie in die Tat umsetzen. Dies hilft Ihnen auch dabei, Bereiche zu identifizieren, in denen Verbesserungen möglich sind. 🙌

Die anhaltende Relevanz der Prinzipien des agilen Manifests

Das agile Manifest konzentriert sich auf:

• Kontinuierliche Verbesserung durch Reaktion auf Feedback und Änderungen
• Es ermöglicht Softwareentwicklern und funktionsübergreifenden Teams, sich so zu organisieren, dass Zusammenarbeit und Interaktion gefördert werden
• Kunden in den Entwicklungsprozess einbeziehen und auf ihr Feedback reagieren

Das Manifest skizziert 12 agile Prinzipien, die das A und O der agilen Softwareentwicklung sind. Wir möchten diesen agilen Prinzipien einen praktischen Kontext bieten und werden sie daher in drei Kategorien unterteilen: Entwicklung funktionierender Software durch Organisation, Unterstützung der Teams bei der Zusammenarbeit und Taktiken zur Kundenzufriedenheit.

Organisieren Sie sich, damit Sie funktionierende Software erstellen können

Die ersten agilen Prinzipien, die wir besprechen werden, drehen sich um das Konzept einer funktionierenden Software — ein Produkt, das Ihre Kunden so früh wie möglich im Softwareentwicklungsprozess verwenden können. Sie passen es an, sobald Sie Feedback darüber erhalten, was gut funktioniert und was verbessert werden könnte. Dies steht im Gegensatz zu einem Wasserfall von der Methodik bis zur Entwicklung, bei der es sich um einen lineareren Ansatz handelt, der in der Regel keine iterativen Aktualisierungen zulässt.

Ein Ziel ist es, funktionierende Software zu entwickeln, die kontinuierlich aktualisiert werden kann. Aber das ist leichter gesagt als getan ohne die Hilfe von speziell entwickelten Tools wie Jira, dessen Ziel es ist, agilen Teams bei der Verwaltung ihres gewählten agilen Frameworks zu helfen, sei es Kanban oder Gedränge. (Sie können unseren Leitfaden zu den Unterschieden zwischen lesen Kanban und Scrum... oder wie man sie zusammen benutzt. 💪)

Schauen wir uns nun an, welche der 12 agilen Prinzipien in diese Kategorie fallen — #3, #7 und #8 — und wie Jira dabei hilft, ein Framework zu implementieren, das diesen Prinzipien entspricht.

Agiles Prinzip #3

„Stellen Sie häufig funktionierende Software bereit, von ein paar Wochen bis zu ein paar Monaten, wobei Sie den kürzeren Zeitrahmen bevorzugen.“

Atlassian (die Macher von Jira) fasst zusammen die Verkörperung dieses Prinzips perfekt in seiner Definition eines Sprints: „Ein Sprint ist ein kurzer, zeitlich begrenzter Zeitraum, in dem ein Scrum-Team daran arbeitet, eine bestimmte Menge an Arbeit zu erledigen.“

Agile Sprints laufen zwar über einen kurzen Zeitraum, aber ihre reibungslose Ausführung erfordert für Produktbesitzer und Softwareentwickler viel Arbeit. Zum Glück bietet Jira Möglichkeiten, diese Arbeit zu rationalisieren — sieh dir unseren Leitfaden an Teile deines Sprints automatisieren.

Agiles Prinzip #7

„Funktionierende Software ist das wichtigste Maß für Fortschritt.“

Mit Sprints können Sie sicherstellen, dass Ihr Team schrittweise funktionierende Software bereitstellt. Wenn ein Sprint gut genug geplant ist, kann er als Stopp für die Veröffentlichung Ihrer nächsten Reihe von Features und Funktionen für Ihre Endbenutzer dienen.

Agiles Prinzip #8

„Agile Prozesse fördern eine nachhaltige Entwicklung. Die Sponsoren, Entwickler und Nutzer sollten in der Lage sein, auf unbestimmte Zeit ein konstantes Tempo beizubehalten.“

Agile Frameworks wie Scrum können dabei helfen zu messen, ob ein Team ein konsistentes Tempo einhält. Innerhalb von Sprints kann der Aufwand auf verschiedene Arten gemessen werden, wie agile Storypoints. Wenn Sprints abgeschlossen sind, erstellt Jira automatisch einen visuellen Bericht darüber, wie viele Storypoints ein Team in seinem Team von Sprint zu Sprint abschließt Geschwindigkeitstabelle.

Zeit für Teamzusammenarbeit

Du bist ein agiles Team, das funktionierende Software bereitstellt und ein Super-Tool wie Jira nutzt, um deine Arbeit zu planen und deine Fortschritte zu verfolgen. Aber du brauchst eine menschliche Berührung, um wirklich agilen Werten zu folgen. Bitte begrüßen Sie die agilen Prinzipien #4, #6, #11, #5 und #12 auf der Bühne.

Agiles Prinzip #4

„Geschäftsleute und Entwickler müssen während des gesamten Projekts täglich zusammenarbeiten.“

Tägliche Stand-up-Meetings sind eine Manifestation dieses Prinzips. In diesem Meeting ging jedes Teammitglied auf drei Themen ein: (1) woran sie gestern gearbeitet haben; (2) woran sie heute arbeiten; und (3) was sie daran hindert, heute Fortschritte zu erzielen.

Agiles Prinzip #6

„Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteams zu vermitteln, ist ein persönliches Gespräch.“

Ob in einem persönlichen Meeting oder in einem Remote-Meeting, die Vermittlung von Informationen ist schwierig — aber (puh) wir haben das bereits mit Methoden wie täglichen Sprints und Geschwindigkeitsdiagrammen angegangen, um Informationen zwischen den Teammitgliedern auszutauschen und den Teamfortschritt visuell zu überprüfen. Und schon bald werden Sie andere Möglichkeiten sehen, wie agile Softwareentwicklungsteams sich organisieren und miteinander kommunizieren.

Agiles Prinzip #11

„Die besten Architekturen, Anforderungen und Designs entstehen in Teams, die sich selbst organisieren.“

Nun, zunächst, was genau ist ein sich selbst organisierendes Team? Es bedarf keiner Anleitung oder eines Mikromanagements von außen, um herauszufinden, woran gearbeitet werden muss und wie diese Arbeit definiert und priorisiert wird. Diese Teams finden heraus, wie sie ihre Arbeit planen, iterieren, um diese Arbeit zu erledigen, und arbeiten dann gemeinsam daran, wie sie sich kontinuierlich verbessern können. Das agile Scrum-Zeremonien — Stand Up, Sprint Planning, Sprint Review und Retrospektive — sind ein praktisches Beispiel dafür.

Agiles Prinzip #5

„Baue Projekte rund um motivierte Menschen auf. Bieten Sie ihnen das Umfeld und die Unterstützung, die sie benötigen, und vertrauen Sie darauf, dass sie die Arbeit erledigen.“

Ok, nach diesem Prinzip sind wir aus dem Ruder gelaufen — aber aus gutem Grund. Das Befolgen des Prinzips #11 ist sinnvoll, da gute, selbstorganisierte Teams von Natur aus motiviert sind. Sie arbeiten zusammen, um herauszufinden, wie die Arbeit erledigt werden kann, und um sich gegenseitig zu helfen, wenn jemand nicht weiterkommt. Nichtsdestotrotz ist es wichtig, dass definierte Rollen in einem agilen Team, wie ein Scrum Master, der Teammitglieder motivieren und ihnen Feedback geben kann.

Agiles Prinzip #12

„In regelmäßigen Abständen denkt das Team darüber nach, wie es effektiver werden kann, und passt dann sein Verhalten entsprechend an.“

Dieses Prinzip beschreibt perfekt eine Rückblick — eine Teambesprechung, um über deinen letzten Sprint oder deine letzte Iteration nachzudenken und zu besprechen, wie du dich für den nächsten Sprint verbessern kannst. Indem du diese Fragen beantwortest: (1) Was lief gut? ; (2) Was hätte besser laufen können? ; und (3) Was können wir anpassen, um uns beim nächsten Mal zu verbessern? Ihr Team arbeitet zusammen und interagiert, um effektiver zu werden.

Kundenzufriedenheit erreichen

Nicht zuletzt gehören zu den agilen Prinzipien auch Kundenbedürfnisse. Wer ist Ihr Kunde? Was sind ihre Bedürfnisse? Wie reagieren Sie auf ihr Feedback, um sicherzustellen, dass Sie ein funktionierendes Produkt anbieten, das sie lieben? Geben Sie die Prinzipien #1, #2, #9 und #10 ein.

Agiles Prinzip #1

„Unsere höchste Priorität ist es, den Kunden durch frühzeitige und kontinuierliche Lieferung wertvoller Software zufrieden zu stellen.“

Es stellt sich heraus, dass Sie wissen müssen, wer Ihr Kunde ist, um Ihren Kunden zufrieden zu stellen. 😉 Das erfordert Arbeit. Eine bewährte Methode, um herauszufinden, wer Ihre Kunden sind, besteht darin, Kundenpersönlichkeiten. Dabei handelt es sich um fiktive Profile Ihrer Kunden, die Dinge wie ihre Verhaltensmuster, ihre gemeinsamen Probleme und das Aussehen ihrer allgemeinen demografischen Informationen dokumentieren.

Agiles Prinzip #2

„Wir begrüßen die sich ändernden Anforderungen, auch in der späten Entwicklungsphase. Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden.“

Anforderungen können nur wirksam geändert werden, wenn sie definiert und den Stakeholdern zur Rückmeldung zur Verfügung gestellt werden. Selbst wenn dieses Feedback spät in einem Entwicklungszyklus zu Veränderungen führt, ist das in Ordnung! (Wahrscheinlich erhalten Sie auch Feedback zu der funktionierenden Software, die Sie bereits geliefert haben. 😎) Tools wie ein Produkt-Roadmap oder ein User-Story-Map die visuelle Ansicht Ihres Produkt-Backlogs bieten Ihren Kunden und Stakeholdern eine Plattform, auf der sie Feedback geben können.

Agiles Prinzip #9

„Kontinuierliches Augenmerk auf technische Exzellenz und gutes Design erhöht die Agilität.“

Ein Wort: Rückblick.

Ok, noch zwei Worte: Sprint Review.

Im Zusammenhang mit Prinzip #9 sind die Retrospektive und das Sprint-Review zwei agile Zeremonien, mit denen Sie die Qualität und das Design Ihrer Software kontinuierlich anpassen können, um die Bedürfnisse Ihrer Kunden bestmöglich zu erfüllen.

Agiles Prinzip #10

„Einfachheit — die Kunst, die Menge der nicht geleisteten Arbeit zu maximieren — ist unerlässlich.“

Stellen Sie sich vor, Sie hätten Ansichten Ihrer Kundenprofile (Personas), eine visuelle Abbildung ihrer Reise durch Ihr Produkt (User Story Map) und eine priorisierte Ansicht Ihres Plans zur Auslieferung Ihres Produkts (Roadmap). Was für eine Zeit, um am Leben zu sein! Wenn Sie alle drei Dinge tun, hat Ihr Team wahrscheinlich ziemlich gute Einblicke in die Frage, ob Sie die richtige Arbeit erledigen oder nicht. 💪

Die 12 agilen Prinzipien in die Tat umsetzen

Jetzt verstehst du, wie die agilen Prinzipien in agile Frameworks umgewandelt wurden und wie Tools wie Jira agilen Teams helfen können, mit diesen Frameworks zu arbeiten. Wir haben auch drei effektive Möglichkeiten erwähnt, um diese Prinzipien in die Tat umzusetzen, und unsere Produkte machen es einfach.

• Einfacher agiler Teamrhythmus unterstützt agile Teams von der Planung bis zur Überprüfung mit Funktionen, die User Story Mapping, Backlog-Refinement, Sprint- und Versionsplanung sowie Team-Retrospektiven unterstützen.
• Einfache Agile Personas für Jira bietet Teams einen kundenorientierten Ansatz zur Verfeinerung von Backlogs.
• Einfache Agile Roadmaps für Jira bietet Teams und Stakeholdern visuelle Einblicke in die Vision und den Plan für ein Produkt.
• Einfache agile Programme ist eine komplette PI-Planungslösung, die eine skalierte teamübergreifende Planung und Ausführung einfach macht.

Schauen Sie sich alle unsere agilen Lösungen an in Der Marktplatz von Atlassian!

Agile Softwareentwicklung ist wie eine Roadmap, um Software richtig zu machen. Wie im Agile-Manifest hervorgehoben, werden echte Konversationen wichtiger als Tools, die Bereitstellung funktionierender Software, anstatt in der Dokumentation zu ertrinken, die Zusammenarbeit mit Kunden, anstatt nur Verträge auszuhandeln, und man passt sich schnell an Veränderungen an. Das Manifest betont die Macht der Zusammenarbeit in funktionsübergreifenden Teams und macht es für das Projektmanagement in verschiedenen Kontexten relevant.

Stellen Sie sich Agile als Denkweise vor, nicht nur als Methode. Es ermöglicht Projektteams, Feedback in einer freundlichen, iterativen Umgebung zu geben und zu erhalten, die zu großartigen Ergebnissen führt. Obwohl agile Prinzipien in der Softwareentwicklung immer beliebter wurden, können sie tatsächlich Wunder für jedes Projektteam bewirken. Egal, ob es um das Baumanagement, das Content Marketing oder sogar die Planung von Hochzeiten geht, Agile bietet Ihnen alles.

Lassen Sie uns herausfinden, warum agiles Projektmanagement für jedes Team hervorragend geeignet ist. Wir werden untersuchen, wie sich seine Prinzipien nahtlos in Ihre Projektprozesse einfügen lassen. Denken Sie daran, dass es egal ist, für welches agile Framework — wie Scrum oder Kanban — Sie sich entscheiden, solange es zu Ihrem Team passt. Kurz gesagt:

• Agile Prinzipien eignen sich perfekt für die Zusammenarbeit im Team.
• Agile Arbeitsabläufe für Projektteams tragen zur kontinuierlichen Iteration und Verbesserung bei.
• Das Framework, das Sie wählen, Scrum oder Kanban, ist weniger wichtig als Ihre Teammentalität.
• Der Einsatz von agilem Projektmanagement in Ihrem gesamten Unternehmen erhöht die Sichtbarkeit und Koordination.

Agile Prinzipien im Projektmanagement

Die Kernprinzipien von Agile — Zusammenarbeit, Empowerment und Transparenz — eignen sich ideal für das Projektmanagement. Unabhängig von der Art des Teams sollte das Ziel eine kontinuierliche Verbesserung sein. Teams erreichen dieses Ziel, indem sie bei der Umsetzung ihrer Projekte nach einem iterativen Ansatz zusammenarbeiten.

Agile ist eine Denkweise der Anpassungsfähigkeit, des Teilens von Fortschritten und des Lernens aus dem, was funktioniert hat und was nicht. Sie verbessern sich im Laufe der Zeit.

Thomas Edison bringt den Geist eines iterativen Ansatzes perfekt auf den Punkt: „Ich bin nicht gescheitert. Ich habe gerade 10.000 Möglichkeiten gefunden, die nicht funktionieren.“ 💡 Es ist diese Einstellung, die die agile Denkweise ausmacht.

Entitäten wie die Institut für Projektmanagement setzen Sie sich für die Vorzüge des agilen Projektmanagements und seine Auswirkungen auf die Zusammenarbeit der Teams ein:

• Die Teams sind für die Projektabwicklung verantwortlich und organisieren sich selbst, um ihre Erfolgschancen zu maximieren.
• Agile Projektmanager fördern die Diskussion von Frameworks und Prozessen, fördern aber auch eigenständiges Denken.
• Agile Werte fördern Vertrauen und gesunde Arbeitsbeziehungen.
• Als Entscheidungsrahmen fördert agiles Projektmanagement die Rechenschaftspflicht und fördert gleichzeitig die kontinuierliche Entscheidungsfindung und Umsetzung.

Agile Workflows für Projektteams

Wie kann ein traditionelles Projektteam selbstorganisiert genug werden, um agiler zu werden? Lassen Sie uns einen Schritt durchgehen Scrum-Arbeitsablauf im Rahmen eines allgemeinen Projekts.

Rückstand

Entwicklungsteams arbeiten auf der Grundlage eines Produkt-Backlogs, bei dem es sich um eine Liste priorisierter Funktionen handelt, die von einem Kunden gewünscht werden. Diese Liste muss jedoch nicht aus einer Reihe von Softwarefunktionen bestehen. Es kann sich um eine beliebige Reihe von Aufgaben oder Ergebnissen handeln, die ein Projektteam erledigen muss.

Besprechung zur Sprint-Planung

Agile Teams arbeiten in Sprints, bei denen es sich um festgelegte Zeiträume (z. B. zwei Wochen) handelt, um einen vereinbarten Arbeitsaufwand zu erledigen. Während der Sprint-Planung überprüft und bespricht das Team die wichtigsten Prioritäten aus dem Backlog. Anschließend entscheiden sie, was im Sprint erreicht werden kann, und verpflichten sich zu dieser Arbeit.

Nehmen wir als untypisches Beispiel ein Marketingteam, das an einer Kampagne arbeitet. In einer traditionellen Projektmanagementumgebung kann das Team einen Wasserfallansatz verfolgen. Sie würden einen monatelangen Inhaltskalender mit sozialen Medien, Blogartikeln, Videos und anderen Inhalten erstellen. Im Rahmen von Agile würden sie sich nur auf die nächsten zwei Wochen der Inhaltsproduktion festlegen, bevor sie entscheiden, was als Nächstes kommt.

Stehaufsteher

Ein Stand-up ist ein tägliches Treffen der Teammitglieder. Dabei beantwortet jedes Mitglied drei Fragen:

• Woran hast du gestern gearbeitet?
• Woran wirst du heute arbeiten?
• Gibt es Probleme, die Ihre Arbeit daran hindern, abgeschlossen zu werden?

Die Fragen bieten jeder Person die Möglichkeit, ihre Fortschritte mitzuteilen und Unterstützung zu leisten, falls sie die Arbeit eines Teamkollegen entsperren können, indem sie zur Lösung seines Problems beitragen.

Sprint-Bewertung

Wenn der Sprint abgeschlossen ist, treffen sich die Teams, um die gerade abgeschlossene Arbeit zu überprüfen und vorzuführen. In unserem Marketing-Fall kann es eine Zeit sein, in der das Team zusammenkommt, um sich ihre Inhaltsvideos anzusehen, die Kommentare und das Feedback aus ihren Social-Media-Posts zu lesen und wichtige Kennzahlen aus all ihren Inhalten zu überprüfen.

Sprint-Retrospektiven

Die Produktentwicklungsteams treffen sich nach jedem Sprint, um zu besprechen, wie sie die Dinge für ihren nächsten Sprint verbessern können. In diesem Meeting bespricht das Team:

• Was ist gut gelaufen?
• Was lief nicht so gut?
• Was können wir in Zukunft verbessern?

Angenommen, Ihr Marketingteam hatte einen Beitrag, der unerwartet viral geworden ist. Warum war es so effektiv? Was können wir daraus lernen, um die Inhalte der nächsten zwei Wochen anzupassen? Diese Art von Fragen sollten Sie sich stellen, damit Sie weiter iterieren und als Team gemeinsam lernen können.

Scrum oder Kanban?

Der oben skizzierte Workflow ist ein typisches agiles Scrum-Framework. Es muss jedoch nicht die Art und Weise sein, wie agile Praktiken im Projektmanagement implementiert werden. Verschiedene Arten von Projekten erfordern möglicherweise unterschiedliche Frameworks. Beispielsweise sind in Scrum die Rollen klarer definiert als in Kanban.

Gedränge

Ein Scrum-Team besteht aus bestimmten Rollen, denen unterschiedliche Verantwortlichkeiten übertragen werden, um das Team durch den Entwicklungsprozess zu führen. Laut dem Scrum-Leitfaden:

• Entwickler erstellen einen Plan für jede Sprint-Iteration, definieren die Vollständigkeit der Arbeit, passen ihren Plan täglich an und ziehen sich gegenseitig zur Rechenschaft.
• Ein Product Owner ist für die Verwaltung des Produkt-Backlogs verantwortlich, indem er die Produktziele kommuniziert, Artikel priorisiert und für Transparenz über den gesamten Backlog sorgt.
• Der Scrum Master coacht und leitet das Team bei der Einführung von Scrum.

Kanban

Einige Projekte eignen sich möglicherweise besser für Kanban als für Scrum. Es gibt wichtige Unterschiede zwischen den beiden Frameworks, die den Ansatz eines Teams für agiles Projektmanagement beeinflussen können:

• Kontinuierlicher Workflow im Vergleich zu festen Sprint-Iterationen
• Kontinuierliche Lieferung im Vergleich zur Auslieferung nach Abschluss jedes Sprints
• Keine festen Rollen im Vergleich zu definierten Scrum-Rollen

Kanban-Teams verwenden ein Kanban-Board, um ihre Aufgaben zu visualisieren und den Umfang der zu einem bestimmten Zeitpunkt laufenden Arbeit zu begrenzen.

Das agile Framework, das Sie verwenden, ob es Scrum oder Kanban, ist weniger wichtig als das gemeinsame Verständnis Ihres Teams darüber, wie Sie zusammenarbeiten, um gemeinsame Ziele zu erreichen. Das Schöne an einem agilen Ansatz ist, dass er dazu beiträgt, Ihr Framework und die Art und Weise, wie Sie es bei Wiederholungen und Rückblicken verwenden, zu optimieren.

Agiles Projektmanagement für Ihr gesamtes Unternehmen

Da Softwareentwicklungsteams weiterhin agile Prozesse einsetzen, können sie andere Teams ermutigen, sich ihnen anzuschließen. Der Einsatz agiler Methoden in anderen Abteilungen verbessert die Fähigkeit dieser Teams zur Zusammenarbeit. Es schafft auch ein gemeinsames Gefühl der Einheit in Ihrem gesamten Unternehmen, da Sie alle dieselbe Methode anwenden, um jedes Ihrer Ziele zu erreichen.

Versuchen Sie, täglich für Abteilungsleiter zu stehen, um die organisationsübergreifende Kommunikation zu verbessern. Halten Sie es kurz und bündig und konzentrieren Sie sich auf die Themen, die den Arbeitsfortschritt fördern.

Die Planung ist eine kritische Phase des agilen Prozesses. Sie bietet die Gelegenheit, sich als Team auf Prioritäten zu einigen und die Arbeit in einer Reihenfolge zu organisieren, die für einen reibungslosen Ablauf sorgt. Der Planungsprozess hilft agilen Softwareentwicklungsteams und anderen Produktentwicklungsteams dabei, neue Informationen zu sortieren, sich an Abhängigkeiten anzupassen und auf sich ändernde Kundenbedürfnisse einzugehen.

Agile ist das Gegenteil der traditionellen Wasserfall-Projektplanung, die einen schrittweisen Ansatz verfolgt. Waterfall dominiert seit vielen Jahren die Projektplanung. Zu Beginn eines Projekts wurden detaillierte Pläne erstellt, die strikt eingehalten werden mussten. Dies mag ein Projekt oder Produkt voranbringen, aber neue Entwicklungen, die außerhalb des „Masterplans“ auftreten könnten, werden dabei nicht berücksichtigt.

Agile ist ein iterativer Prozess, der Teams dabei hilft, Verschwendung zu reduzieren und die Effizienz zu maximieren, um letztlich den Kunden einen Mehrwert zu bieten. Dieser kundenorientierte Ansatz hilft Teams, während des gesamten Entwicklungsprozesses fundierte Entscheidungen zu treffen — Entscheidungen, die den Stakeholdern kontinuierlich und konsistent einen Mehrwert bieten.

Einer der größten Vorteile eines iterativen agilen Ansatzes besteht darin, dass er frühzeitiges Feedback von Stakeholdern ermöglicht. Sie müssen nicht raten, ob Sie die richtigen Entscheidungen treffen oder nicht — Sie können jeden Schritt herausfinden, indem Sie die Beteiligten direkt in Ihren Prozess einbeziehen. Sie können Ihren Plan nach Bedarf anpassen, je nachdem, was den Kunden zu jedem Zeitpunkt den größten Mehrwert bietet.

Auch wenn Sie Teil eines erfahrenen agilen Teams sind, gibt es immer Verbesserungsmöglichkeiten und Prozesse, die optimiert werden müssen. In diesem Beitrag werden einige unproduktive Fehler beschrieben, die Teams bei der agilen Planung machen, einschließlich der Frage, wie agile Teams diese häufigen Fallstricke vermeiden können.

Agiler Planungsfehler #1: Nicht auf derselben Wellenlänge wie die Stakeholder zu sein

Binden Sie Interessengruppen in Ihren Planungsprozess ein? Verstehen sie Ihre Ziele und warum Sie jede Entscheidung treffen? Die direkte Zusammenarbeit mit allen Beteiligten, sowohl internen Interessenvertretern als auch Nutzern Ihres Produkts, wird Ihnen helfen, sich ein klares Bild von Bedürfnissen und Einschränkungen zu machen. Außerdem erhalten Sie die Informationen, die Sie benötigen, um zu entscheiden, was wann getan werden sollte.

Es ist niemals eine gute Idee, sich auf Annahmen auszuruhen. Ihre Stakeholder leben in einer anderen Welt als der, in die Sie tief verwurzelt sind, mit anderen eigenen Prioritäten und Annahmen. Damit Sie Ergebnisse erzielen können, die die Erwartungen Ihrer Stakeholder erfüllen, müssen Sie sich auf diese Erwartungen einigen. Binden Sie Ihre Stakeholder in die Planung ein, aber stellen Sie sicher, dass jeder versteht, dass sich die Erwartungen im Laufe des Prozesses ändern können, basierend auf neuen Informationen, die aus Erfolgen, Misserfolgen und Kundenreaktionen gewonnen werden.

Agiler Planungsfehler #2: Abhängigkeiten nicht berücksichtigen

Die Nichtberücksichtigung von Abhängigkeiten in der agilen Planung führt zu Engpässen, verzögerten Releases und untergräbt die Zusammenarbeit im Team. Die Zusammenarbeit innerhalb und zwischen Teams ist erforderlich, damit ein Unternehmen effektiv liefern kann. Wenn mehrere Teams an miteinander verbundenen Funktionen arbeiten und der Fortschritt eines Teams durch ein anderes blockiert wird, verlangsamt sich der gesamte Entwicklungszyklus. Ohne klare Sichtbarkeit der Abhängigkeiten kann sich die Arbeit verzögern und Termine nicht eingehalten werden.

Um Unterbrechungen des Arbeitsablaufs zu minimieren und zu vermeiden, sollten Sie sich die Zeit nehmen, die Beteiligten zu konsultieren und Abhängigkeiten frühzeitig zu antizipieren. Tools, die Ihnen helfen, Abhängigkeiten zu visualisieren und abzubilden, und gemeinsame Roadmaps zur Verfolgung teamübergreifender Abhängigkeiten ermöglichen es Ihnen, sich ein Bild von Abhängigkeiten zu machen und die Arbeit so abzufolgen, dass Hindernisse vermieden werden. Die proaktive Verwaltung von Abhängigkeiten sorgt für reibungslosere Iterationen, eine schnellere Markteinführung und einen besser vorhersehbaren agilen Prozess.

Agiler Planungsfehler #3: Verwendung langweiliger, flacher Produktlandkarten

Flache Produktrückstände sind fad und langweilig 😴. Denken Sie an Karottenkuchen ohne Zuckerguss. Ihnen fehlen die Details und Funktionen, die Sie benötigen, um die gesamte Geschichte Ihres Produkt-Backlogs zu erfassen.

Sobald Sie mehr als eine Handvoll Artikel haben, werden sie außerdem überwältigend und es ist schwierig, sie sinnvoll zu organisieren. Es wird weniger klar, welcher Punkt der wichtigste ist, und es wird schwieriger, sicherzustellen, dass Ihre Entscheidungen mit dem übergeordneten Ziel des Projekts übereinstimmen.

Wenn Sie Ihre Roadmap planen, benötigen Sie einen Kontext, und Sie müssen in der Lage sein, die Kundenreise klar zu erkennen. User-Story-Maps visualisieren Sie die Kundenreise im Planungsprozess und während des gesamten Prozesses der Produktentwicklung. Sie nutzen User Stories — die kleinste Arbeitseinheit, die dem Kunden einen Mehrwert bieten kann —, sodass Sie den Backlog aus Kundensicht planen und organisieren können.

📕 Lesen Sie unsere ultimativer Leitfaden für User Story Maps um mehr zu erfahren.

Agiler Planungsfehler #4: Dem Plan nicht zu erlauben, zu leben, zu atmen und sich anzupassen

Wie wir bereits besprochen haben, ist Agile ein iterativer Ansatz. Das bedeutet, dass Ihre agile Planung Raum für Änderungen lassen muss. Ihr Plan sollte in der Lage sein, mit jedem Sprint oder jeder Produkt-Roadmap zu wachsen und sich anzupassen.

Zu Beginn eines Sprints fehlen Ihnen die Informationen, die Sie benötigen, um das Gesamtbild zu sehen. Sie haben nicht alles, was Sie benötigen, um die perfekte Lösung zu entwickeln, und das ist in Ordnung. Das ist alles Teil des Prozesses. Stunden oder Tage damit zu verbringen, den perfekten Plan auszuarbeiten, verschwendet nur Zeit, die besser damit verbracht werden könnte, zu lernen und Probleme zu lösen, sobald sie auftauchen. Was Sie in der Planungsphase für den größten Nutzen hielten, könnte im Laufe der Zeit völlig anders sein.

Möglicherweise müssen Sie Ihren Plan ändern, nachdem eine Straßensperre in einem täglichen Gespräch auftaucht, oder Sie erfahren von einem Kundenproblem, das Ihre Richtung völlig ändert. Wiederholungen sind unvermeidlich und willkommen! Sie helfen Ihnen, mit eingehenden Informationen Schritt zu halten, während Sie voneinander, von Stakeholdern und Ihren Kunden lernen.

Agile Planung ist kein Versprechen. Es ist eine Gliederung, die Ihnen hilft, Ihr Ziel zu erreichen, und die sich mit Ihren Zielen und Umständen ändert.

Agiler Planungsfehler #5: Rückblickende Erkenntnisse nicht in die folgende Planungssitzung einfließen lassen

Rückblicke sind ein wesentlicher Bestandteil des agilen Prozesses. Sie geben Teams die Möglichkeit, über alles nachzudenken, was in einem einzelnen Sprint oder nach der Fertigstellung eines Produkts passiert ist.

Eine effektive Retrospektive stellt dem gesamten Team wichtige Fragen, die den Prozess beim nächsten Mal verbessern können. Was ist gut gelaufen? Was ist es wert, es noch einmal zu wiederholen? Was lief nicht so gut? Was könnte beim nächsten Mal verbessert werden? Welche Hindernisse oder Abhängigkeiten sind entstanden? Was hast du gelernt? Wie hast du dich am Ende des Sprints gefühlt?

Eine Retrospektive bietet Einblicke, die die Effizienz, die Teamarbeit und die Teamdynamik, die Effektivität der Tools und die Kommunikation mit den Stakeholdern verbessern werden.

Es reicht nicht aus, einfach eine Retrospektive abzuhalten oder rückwirkendes Feedback zu sammeln, um an Wert zu gewinnen. Sie müssen sicherstellen, dass Sie das Feedback in das folgende Sprint-Planungsgespräch einbeziehen und Maßnahmen ergreifen, die zu einer spürbaren Verbesserung führen. Die nächste Iteration wird umso besser für die Zeit sein, die Sie damit verbringen, auf der Grundlage des Gelernten nachzudenken und sich zu verbessern.

Agiler Planungsfehler #6: Auswahl von Tools, die keinen kundenorientierten Ansatz verfolgen

Unabhängig davon, ob Ihr Team einen Scrum-Prozess, Kanban-Boards oder andere agile Methoden verwendet, sollten die von Ihnen ausgewählten Tools immer kundenorientiert sein. Und Sie müssen sie weiterhin so einsetzen, dass der Kunde bei der Entscheidungsfindung immer an erster Stelle steht.

Teams können in die Falle tappen und glauben, dass sie sich auf den Kunden konzentrieren, wenn sie nicht viel tun, außer einfachen agilen Methoden und generischen Prozessen zu folgen. Kunden müssen bereits in der Planungsphase in Ihren Entwicklungsprozess eingebunden werden, sodass bei jeder Entscheidung, die ein Teammitglied trifft, zuerst die Kundenbedürfnisse berücksichtigt werden.

Wählen Sie Planungstools, die Ihrem gesamten Team helfen, genau zu verstehen, was Ihre Kunden bewegt, und schauen Sie immer vorbei, um sicherzustellen, dass Sie Entscheidungen im Einklang mit Ihren Kunden treffen.

Zum Beispiel Personas bieten ein tiefes Verständnis dafür, was Kunden wollen, brauchen, nicht wollen usw. Sie geben wichtige Informationen über Kundenprobleme, Wünsche, demografische Merkmale, Ziele, Einkaufsmuster und vieles mehr preis. Wir empfehlen dringend, Kunden-Personas zu entwickeln, um ein umfassendes Bild von allen Personen zu erhalten, die Ihr Produkt verwenden werden. Es reicht jedoch nicht aus, Personas einfach herumliegen zu lassen.

Sie müssen diese Personas in Ihren agilen Planungsprozess einbeziehen und sie bei der Bearbeitung von Problemen und der Weiterentwicklung Ihres Produkts in den Mittelpunkt stellen.

Wir gehen zu den Rennen! 🏃🏃 ‍ ♀️ Sprints sind ein wichtiger Bestandteil der agilen Methodik. Ein Sprint ist ein vordefinierter Zeitraum, in dem agile Teams gemeinsam auf ein vereinbartes Sprintziel hinarbeiten. Es gibt vier Arten von Agile-Meetings, die im Laufe eines Sprints stattfinden, und jede davon ist entscheidend, um den Erfolg des agilen Prozesses sicherzustellen. Es geht darum, durch eine vorgegebene Menge an Arbeit zu sprinten, um die Ziellinie zu erreichen, wo Sie aus Ihrem Prozess lernen und das Rennen erneut beginnen (nur besser dran aufgrund dessen, was Sie im vorherigen Sprint gelernt haben).

Agile Meetings werden genutzt, um Teammitglieder, Führungskräfte und Stakeholder auf den gleichen Stand zu bringen, und sie leiten den Prozess eines agilen Sprints oder Gedränge.

In diesem Beitrag werden die vier wichtigsten Agile-Meetings behandelt, zu denen Sprint-Planung, tägliche Standups, Sprint-Reviews und Sprint-Retrospektiven gehören. Außerdem besprechen wir ein zusätzliches Agile-Meeting, das zur Verfeinerung des Backlogs genutzt wird.

Agile Besprechungen im Vergleich zu Scrum-Besprechungen

Scrum ist agil Methodik das wird am häufigsten in der Softwareentwicklung verwendet. Scrum-Meetings sind technisch gesehen eine Art agiles Meeting, aber sie haben spezifischere Parameter, die so konzipiert sind, dass sie in das Scrum-Framework passen. Der Prozess dreht sich um einen 2-4 wöchigen Sprint, an dem ein Product Owner, ein Scrum Master und das gesamte Scrum-Team beteiligt sind.

Wir haben es abgedeckt Scrum-Meetings (Zeremonien) ausführlich in einem anderen Artikel. In diesem Beitrag konzentrieren wir uns auf die vier wichtigsten agilen Meetingtypen. Diese Prozesse und Best Practices können überall angewendet werden mehrfach agil Methodologien, einschließlich Scrum und Kanban. Dieses Framework kann auch über die Softwareentwicklung hinaus branchenübergreifend angewendet werden und sich an die Bedürfnisse der meisten Teams anpassen.

Einfach ausgedrückt: Scrum hat einen starreren Rahmen, der auf vier Zeremonien/Treffen folgt. Der agile Prozess ist fast derselbe, mit vier sehr ähnlichen Meetings, aber es gibt mehr Flexibilität, um den Zeitrahmen des Sprints anzupassen und den Prozess anzupassen, wenn nicht speziell die Scrum-Richtlinien befolgt werden. Okay, vielleicht ist das immer noch nicht einfach ausgedrückt, aber es wäre nicht agil, wenn es linear und unkompliziert wäre.

Die 4 Arten von agilen Meetings

Es gibt vier zentrale Agile-Meetings: Sprint-Planung, tägliche Standups, Sprint-Reviews und Sprint-Retrospektiv-Meetings. Ein Sprint beginnt mit einem Sprint-Planungsmeeting. Jeden Tag findet ein tägliches Standup-Meeting statt. Schließlich finden am Ende des Sprints ein Sprint-Review und eine Retrospektive statt. Der Vorgang wiederholt sich mit neuen Federn, bis das Produkt, das Projekt oder die Arbeit abgeschlossen ist.

1. Besprechung zur Sprint-Planung

Das Sprint-Planungsmeeting findet zu Beginn eines Sprints statt und bezieht das gesamte Team mit ein. Bei der Sprint-Planung trifft sich das gesamte Team, um zu besprechen und zu vereinbaren, welche Arbeitsaufgaben (Backlog-Elemente) in das Sprint-Backlog verschoben werden sollen — die Elemente, die bis zum Ende des Sprints erledigt sein müssen. Während des Meetings werden die Sprintziele festgelegt und das Team orientiert sich an den Erwartungen.

Ohne ein Sprint-Planungstreffen zur Erläuterung der Sprint-Backlog (Aufgaben, die erledigt werden müssen), das Team wird während des Sprints Zeit damit verschwenden, herauszufinden, welche Arbeit Vorrang hat.

Zu vermeidende Fehler bei der Sprint-Planung:

• Beginnen Sie mit der Planung ohne verfeinerter Backlog
• Nicht auf derselben Wellenlänge wie Ihre Stakeholder
• Den Kunden und die Kundenreise bei der Planung ignorieren
• Erstellung eines starren Plans, der keinen Raum für Wachstum oder Anpassung bietet
• Mit fad flache Produktkarten denen ein kritischer Kontext fehlt
• Versäumnis, rückblickende Erkenntnisse in die folgende Planungssitzung einzubeziehen

Erfahre mehr über häufige Fehler bei der agilen Planung und wie Ihr Entwicklungsteam diese Fallstricke vermeiden kann.

2. Tägliches Standup-Meeting

Das tägliche Standup-Meeting findet an jedem Tag des Sprints statt. Im Scrum-Prozess könnte dieses Meeting auch als tägliches Scrum-Meeting bezeichnet werden. Es ist eine Gelegenheit für das Team, sich über die Arbeit auszutauschen, die am Vortag erledigt wurde, und darüber, was jede Person oder jedes Team in den nächsten 24 Stunden erledigen will.

Das Treffen zielt darauf ab, drei wichtige Fragen zu beantworten:

• Welche Arbeiten wurden seit dem letzten Standup abgeschlossen, um dem Team zu helfen, das Sprintziel zu erreichen?
• Welche Arbeiten planen Sie heute abzuschließen?
• Steht dir derzeit etwas im Weg oder behindert es deinen Fortschritt?

Dies ist ein guter Zeitpunkt, um etwaige Engpässe zu beheben. Was hat die Verzögerung verursacht, wenn die vom Vortag geplanten Arbeiten nicht abgeschlossen wurden, und wie kann das Team zusammenarbeiten, um Probleme zu lösen, die verhindern, dass die Arbeit voranschreitet?

Ein Standup-Meeting ist kurz und auf den Punkt gebracht, sodass jeder wieder zu der Arbeit zurückkehren kann, die er zu Ende bringen möchte. So kurz, dass oft Teilnehmern empfohlen wird stehen für die Dauer des Treffens. Daher der Name Daily Standup. Es umfasst alle Teammitglieder und findet idealerweise jeden Tag zur gleichen Zeit statt, um sicherzustellen, dass jeder immer teilnehmen kann.

Tägliche Standup-Fehler, die es zu vermeiden gilt:

• Die Zeit während des Meetings nicht im Auge behalten
• Kontinuierliches Überschreiten der zugewiesenen Besprechungszeit
• Umherschweifende Teilnehmer, die nicht bereit sind, die wichtigsten Fragen des Treffens zu beantworten
• Das Meeting aus Zeitgründen überspringen
• Teammitglieder kommen zu spät zum Meeting oder verpassen es ganz
• Den lautesten Stimmen erlauben, den Rest des Teams zu überschatten
• Jemanden dieselbe Aufgabe an mehreren aufeinanderfolgenden Tagen angeben lassen
• Unfähigkeit, potenzielle Engpässe zu beheben
• Zuweisung von Arbeiten, die über die Kapazität einer Person hinausgehen

3. Sitzung zur Sprint-Überprüfung

Das Sprint-Review ist eine Gelegenheit für das Team, die Arbeit, die es während des Sprints geleistet hat, zu präsentieren. Bei diesem Meeting kann es sich um eine interne Präsentation oder eine formellere Demonstration für die Beteiligten handeln, je nachdem, welche Anforderungen das Projekt hat und wie weit die Arbeit bereits fortgeschritten ist.

Zu vermeidende Sprint-Review-Fehler:

• Nicht richtig auf das Meeting oder die Demonstration vorbereitet
• Stakeholder nicht in Ihren Prozess einbeziehen
• Versäumnis nachzuweisen, wie die Arbeit dem Kunden einen Mehrwert bringt
• Erfolge übertreiben oder verschönern
• Versäumnis, Probleme zu lösen und wie sie gelöst wurden
• Das Feedback zum Sprint-Review wird nicht in das nächste Sprint-Planungstreffen einbezogen

4. Sitzung zum Rückblick auf den Sprint

Die Retrospektive ist ein entscheidender Teil des agilen Prozesses. Das Meeting findet am Ende des Sprints statt und bringt das gesamte Team zusammen, um seine Prozesse zu bewerten und zu besprechen, wie es sich beim nächsten Mal verbessern kann.

Welche Aspekte des Sprints verliefen gut und was können Sie aus diesem Erfolg lernen? Was lief nicht so gut und auf welche Engpässe ist das Team gestoßen? Was könnte beim nächsten Mal besser gemacht werden? Da es bei Agile vor allem um Lernen und Iterieren geht, gibt es nach jedem Sprint etwas zu lernen. Alles, von gut über schlecht bis mittelmäßig, kann in umsetzbare Verbesserungen umgewandelt werden.

Zu vermeidende Fehler im Nachhinein:

• Einzelne Teammitglieder für Engpässe verantwortlich machen
• Nur die lautesten Stimmen geben Einblick
• Es gelingt nicht, die leisen Stimmen im Raum zu stärken
• Immer wieder dieselben Fragen wiederholen, ohne die Dinge zu ändern
• Zulassen, dass die Retrospektive zu lang ist (zwei Stunden für einen zweiwöchigen Sprint anstreben)
• Überspringen einer Retrospektive aus Zeit- oder Ressourcenmangel
• Erkenntnisse oder Bedürfnisse von Stakeholdern vergessen oder nicht mit einbeziehen
• Versäumnis, das zu verbessern Sprint-Rückblick Prozess (Rückblick — der Rückblick!)
• Fehlende Berücksichtigung rückwirkender Erkenntnisse in den nächsten Sprint

Bonus: Besprechung zur Verfeinerung des Backlogs

Man könnte argumentieren, dass es ein fünftes Agile-Meeting gibt, insbesondere in der Welt der Produktentwicklung. Vor dem Sprint-Planungsmeeting muss der Product Owner ein Produkt-Backlog erstellen, das alle Aufgaben und Elemente umfasst, die das Team erledigen muss, um das Endprodukt oder Projekt vollständig zu entwickeln. Zu den Elementen gehören Benutzerberichte, Bugfixes, Funktionen und andere Aufgaben, die angegangen werden müssen, um das Endziel zu erreichen.

Verfeinerung des Backlogs bereitet das Backlog für die Sprint-Planung vor, indem Artikel so angeordnet werden, dass sie im nächsten Sprint die größte Wirkung erzielen. Bei der Backlog-Verfeinerung stellt ein Product Owner sicher, dass die Backlog-Elemente genügend Informationen, Details und Prioritäten enthalten, sodass das Team kluge Entscheidungen darüber treffen kann, was wann angegangen werden soll.

Je nach dem aktuellen Stand des Produkt-Backlogs kann vor Beginn der Sprint-Planung ein Meeting zur Feinabstimmung des Backlogs stattfinden. Außerhalb der Produktentwicklungsbranche könnte der Produkt-Backlog einer Aufgabenliste für ein Hauptprojekt ähneln.

Bei der Verfeinerung des Backlogs sollten folgende Fehler vermieden werden:

• Die Backlog-Verfeinerung wurde nicht rechtzeitig für die Sprint-Planung abgeschlossen
• Für das Planungstreffen bleibt zu viel Verfeinerung des Rückstands übrig
• Fehlende Priorisierung von Artikeln, die dem Kunden einen Mehrwert bieten
• Keine Berücksichtigung neuer Rückmeldungen, Fragen und Bedenken von Stakeholdern

Agile Meetings: Abschließende Überprüfung

Da hast du es also! Die vier wichtigsten Agile-Meetings sind Sprint-Planung, tägliche Standups, Sprint-Reviews und Sprint-Retrospektiven. Eine lobende Erwähnung geht an die Verfeinerung des Backlogs.

Lassen Sie uns den Zweck der einzelnen Besprechungen überprüfen:

• Sprint-Planung bringt alle auf den gleichen Stand darüber, was im Laufe des kommenden Sprints erreicht werden muss.
• Tägliche Standups stellen Sie sicher, dass das Team auf Kurs bleibt und hilft ihnen, potenzielle Engpässe zu beheben und zu lösen.
• Sprint-Bewertungen sind eine Gelegenheit für das Team, den Stakeholdern die während des Sprints geleistete Arbeit zu präsentieren und kritisches Feedback zu erhalten.
• Sprint-Retrospektiven Ermöglichen Sie dem Team, zusammenzukommen, um zu besprechen, was gut und was nicht gut gelaufen ist und wie es sich beim nächsten Mal verbessern kann.
• Verfeinerung des Backlogs bereitet das Backlog für die Sprint-Planung vor, um im nächsten Sprint die größtmögliche Wirkung zu erzielen.

Halten Sie effektive agile Meetings mit Easy Agile ab

Easy Agile setzt sich dafür ein, Teams dabei zu helfen, mit Agile besser zu arbeiten. Easy Agile entwickelt Produkte, die speziell für Jira-Benutzer entwickelt wurden, um agilen Teams zu helfen, effizienter und effektiver zu arbeiten.

Wir veröffentlichen regelmäßig Listen mit Tools, Ratschlägen und Anleitungen für agile Teams. Wenn Sie mit Jira arbeiten, werden Sie feststellen, dass unsere Ressourcen besonders hilfreich sind, um sich in der Produktentwicklung zurechtzufinden und Jira-Apps das wird die Art und Weise verbessern, wie Ihr Team zusammenarbeitet.

“Agile” is a simple word that means quite a lot today. What was once resigned to software developers and product development is now commonplace in many businesses, and agile implementation is showing no sign of slowing down.

It all boils down to this: Businesses today must be able to adapt fast.

The rigid approaches that worked for years don’t fit our rapidly changing business landscapes. Businesses of all shapes and sizes need to continually adapt to changing requirements, the changing needs of a global economy, cultural shifts, and evolving technological advancements.

It’s clear that agile is the way of the future, but how do you implement such a massive change across an organization, especially enterprises? Do you need a top-down approach, a bottom-up approach, or something in between? Let’s take a closer look at the benefits of agile and how to choose the best agile implementation approach.

Are you practicing SAFe®?

Bring the SAFe® Program Board into Jira

Try Easy Agile Programs

Why switch to an agile approach?

We’ve covered the benefits of agile in detail in our Beginner's Guide to Agile Methodology, but let’s recap some of the key points and why so many businesses are choosing to make the switch.

Agile practices focus on an iterative approach that continually adapts to new information and circumstances. By contrast, traditional project management generally adopts a waterfall approach — the project manager lays out a plan at the beginning of a project that the project team is expected to follow to the letter.

The problem with the traditional project management process is that it leaves little room to quickly grow and evolve. Agile project management and agile software development, on the other hand, need feedback and iterations at every turn. Agile teams test early and often to ensure they are on the right path, and they make adjustments in real-time.

The benefits of agile methods are far-reaching — that’s why we love it! Though it may take time to implement, agile is a worthy investment for any future-focused organization.

Additional benefits of agile:

• Managers can more easily account for the capacity of individuals and entire teams.
• The team can better manage work in progress (WIP).
• Everyone can clearly visualize the prioritization of tasks.
• Bottlenecks or roadblocks are addressed before they halt progress.
• Wasteful processes are eliminated or changed to improve efficiency.
• Multiple voices are included in the decision-making process.
• Teams can make iterations on products or projects in real-time.
• Stakeholders, customers, and end users are involved in your processes.
• Teams can provide continuous delivery to customers and stakeholders.
• Collaboration and teamwork improve.

With Easy Agile Programs you can equip your distributed or co-located teams to implement the Scaled Agile Framework® (SAFe®) without leaving Jira.

Join a demo

Agile implementation: Top-down or bottom-up?

So, you believe in agile and you’re ready to make it happen, but what’s the best approach? Do you implement it from the top-down or bottom-up? Let’s find out!

A top-down approach to agile implementation starts with those in charge. It often begins with management or business owners who hear about the benefits of agile and want their business to adopt agile practices. The problem is, when an idea only comes from the top, it can catch the rest of the organization off guard. If those in charge don’t give enough notice or provide all of the necessary resources and time to implement new ways of working, employees can become resentful and push back against the change.

On the other hand, when agile implementation comes from the bottom-up, leadership can push back. Teams and team leaders may want to improve their processes and adopt new ways of working, but they may not get adequate support or resources when they need them. It can take time to convince those in charge of the benefits of agile, which can take away from the time needed to actually learn and implement agile practices.

A hybrid approach

The good news is you don’t need to pick just one. The best approach for your business may turn out to be a hybrid approach. The more people you have on board, the better.

Agile implementation is easiest and most effective when as many people as possible buy into the process. It’s best if you have buy-in throughout multiple levels of your organization, from employees to managers to owners to CEOs.

Push-back on change is quite common in organizations, no matter the industry. It’s important to have people throughout the company who believe in the value of agile, are passionate about agile processes, and are excited about the possibilities agile presents.

Choosing an agile framework

As you implement agile principles, you’ll need to choose the framework that works best for your team. Depending on the needs of your team and organization, you may choose to adopt one framework or establish a mixture of frameworks.

Below, we’ll outline a few popular agile methodologies.

Scrum

Scrum is a strange word that’s very popular as a software development process. It’s a series of events that revolve around repeating sprints. One sprint (or Scrum) begins with sprint planning. The product owner reviews the product backlog, which represents all of the work that needs to be completed. They choose which items/tasks are the most important for the upcoming sprint and move those tasks into the sprint backlog.

Next, the development team, guided by the Scrum Master, works over a two-week span to complete the sprint backlog. Each day, the team meets for daily standups, which allow the team to go over what was accomplished over the previous 24 hours and discuss any possible roadblocks that stand in the way of the team completing work.

Lastly, the team completes a sprint review to gather feedback from stakeholders. They also conduct a sprint retrospective to discuss what went well and what didn’t over the course of the sprint. The insights are carried over into the next sprint to help all team members keep improving.

Wow! 🤯 That was a whirlwind explanation of Scrum. If you want to understand the process in more detail, we cover Scrum in a number of other guides, including the difference between Kanban and Scrum and guides to Scrum sprint planning and Scrum retrospectives.

Kanban

The Kanban framework is a visual process that helps teams manage the amount of work in progress. It allows teams and team leaders to see an at-a-glance view of what’s currently in progress and what’s on the horizon.

A Kanban board has three sections: to-do, doing, and done. Tasks flow throughout these sections one at a time to ensure no one is taking on more than one task at once. This ensures focus is always put on work in progress, no one gets bogged down with too many tasks, and potential bottlenecks are discovered before they impede productivity.

Chances are you’ve seen a Kanban board in action in some form or another. Trello is an example of an interactive Kanban board. The Kanban framework can be used on its own or paired with other frameworks, such as Scrum.

Lean

The lean methodology focuses on eliminating waste to improve efficiency. Lean follows five main principles: identify value, map the value stream, create flow, establish a pull system, and seek perfection.

Lean aims to waste less time by ensuring processes, communication, and the transfer of products or services run smoothly. When waste is eliminated and time is optimized, businesses can reduce costs. Efficiency is paired with a continuous improvement mindset, which helps teams work better together and deliver ever-improving products and services.

➡️ Learn more: Understanding Lean Agile and the 5 Lean Principles.

These are only a few popular agile methodologies. To learn more, read our article on 8 Software Development Methodologies Explained.

Seamless agile implementation

Agile implementation works best when people at all levels of the organization buy into the agile transformation. A top-down approach means the leadership is on board, but it forces employees to adopt a new way of working, and they may not be comfortable with the change. When it’s the other way around, employees, team members, and team leaders will struggle to implement agile without the support from those in charge and the people who allocate resources. A hybrid approach is often ideal, where as many people as possible are excited about and invested in the transition.

With the right tools, agile implementation becomes even easier. Easy Agile is dedicated to helping teams work better with agile. We design products that highlight the customer journey and allow teams to collaborate with each other seamlessly.

Easy Agile Programs is simple to use, collaborative, flexible, and it integrates directly with Jira. You can contact our team at any time to learn more about our suite of Jira products!

Join a demo

Try Free for 30 days

Agile Softwareentwicklung verwendet Iteration, um agile Praktiken zu verbessern. More as the use development teams agile Principes zur Verbesserung der Selbstorganisation. The improvement of the Scrum Frameworks has to improve the quick results and the product results through iteration.

Aber agil werden if you are not familiar with this approach, this can be a challenge. The team members need a tool to overbrücking. Ein Brückentool wie virtuelle Teambuilding-Aktivitäten unterstützt neue Lernaktivitäten. Neues Lernen fördert neue Denkweisen, die eine kontinuierliche Verbesserung fördern. Treten Sie ein, Agile Games!

Erfahre, wie diese Spiele Teambildung unterstützen und die Problemlösung für bessere Softwareentwicklungsprozesse fördern können und nach welchen agilen Spielen du Ausschau halten solltest.

Was sind agile Spiele?

Agile Games are Online games, the whole teams can play. This games were developed for teambuilding activities. Sie helfen dabei, effektive Teams zu fördern, indem sie alle dazu bringen, auf ein gemeinsames Ziel hinzuarbeiten. Wenn agile Teams ihre Köpfe zusammenfügen, effektiv kommunizieren und neues lernen, gewinnen alle — auch der Product Owner.

Teambuilding-Games treiben Innovationen voran, indem sie durch Teambuilding-Übungen eine neue Perspektive fördern. Agile Games machen Spaß, sind aber auch praktisch. This practical approach allows es the team members, new behavior approach.

If they play agile games, implementation teams better work methods in the software development. Agile Games support the teambildung by new learning activities and repetations.

Final improve agile games the good communication and self-organization of devOps-teams. The result agile games is, that your team members agile software faster assimilieren.

Wenn agile Teams ihre Fähigkeiten zur Problemlösung verbessern, profitieren sie von zahlreichen Vorteilen, die möglicherweise auf der Strecke geblieben sind, wenn sie keine agile Methodologie oder diese agilen Spiele verwendet haben.

Arten von agilen Spielen

Es gibt mehrere agile Spiele, mit denen sie neue Teams mit agiler Software vertraut machen können. Leckere Cupcakes entwickelte viele dieser einfachen Spiele als Eisbrecher, die Introvertierten dazu ermutigen, stärker an Scrum-Übungen teilzunehmen. This games help also to develop Multitasking-Fähigkeiten in anspruchsvollen DevOps-Umgebungen, die jeder agile Coach gerne einsetzen wird.

Nun, da Sie einige Grundlagen haben, die Ihnen helfen, die Denkweisen hinter agilen Spielen zu verstehen, würden Sie wahrscheinlich herausfinden, welche Arten von Spielen Sie spielen können, um Teamwork aufzubauen.

Hier sind ein paar agile Spiele, um deinen Appetit anzuregen. This list of games reicht von der kürzesten bis zur längsten Spieldauer, jeder hat sein eigenes Ziel.

1. Schokoriegel-Spiel

Spieldauer Erforderliche Spieldauer FormatZiele 5 Minuten+4 virtuelle und persönliche Teambuilding-Aktivitäten für Kundenfeedback und Iterationen

Das Chocolate Bar Game ist ideal für neue Teams, die mit agilen Praktiken nicht vertraut sind. The team work is improve if the members play and more about iteration. Ganze Teams können dieses Spiel auch spielen, um zu verstehen, wie Kundenfeedback in ihre Retrospektiven integriert werden kann.

Sie können das Spiel entweder persönlich oder ein Online-Spiel mit Remote-Teams spielen.

The Chocolate Bar Game works as Scrum Simulation. Es ist das Ziel, ein Schokosiegel herzustellen, als ob sie die Anweisungen des Produktbesitzers befolgen würden. Entwicklungsteams wählen ihren Produktmanager, der auch der Product Owner sein kann. Der Rest der agilen Teams sind die Kunden.

The Product Owner fungiere as moderator and allows the team members to made a schokoriegel, the target market. This schokoriegel must be köstlich and can either be made from dunkler chocolate, milk chocolate or white chocolate.

Darüber hinaus kann das Team eine Reihe von Füllungen auswählen, um sein Produkt zu verbessern. Toppings und andere einzigartige Eigenschaften kommen ebenfalls ins Spiel, da die Teams biologische oder glutenfreie Zutaten hinzufügen können, die auf einen Nischenmarkt zugeschnitten sind.

Nach jeder Iteration gibt der Projektmanager dem Team Kundenfeedback. Customers can give an the software development team (or the team for the create of schokoriegeln) a high for your creation, if they agree with the the agile team made chocolate. Customers can give an the team members also a time after below, if they not failed the first phase their chocolate iegels.

In der Teamarbeit werden die Reaktionen der Kunden auf Änderungen vor der nächsten Iteration, bei der es um die Schockoriegelfüllungen geht, aufgenommen. The team members build their schokoriegel and added filling and charges or remove to remove to the most customers are satisfied with their created.

Wie Sie sehen können, erfordert das Spielen von Chocolate Bar Game wiederholte Wiederholungen auf der Grundlage von Kundenfeedback, was das Ziel dieses agilen Spiels ist.

2. Wie umarmt man

Spieldauer Erforderliche SpielerFormatObjective5 Minuten (oder weniger) 3+Nur virtuelle Agile Teamzusammenarbeit

How to Hug ist ein einfaches Spiel zur Verbesserung der Teamzusammenarbeit, insbesondere in einem Remote-Team. How to Hug is a großartiger Eisbrecher, wenn es darum geht, neue Teammitglieder vorstellen.

The Scrum Team can access on this agile Teambuilding activity. Das gesamte Team lädt seine Fotos hoch, um sie auf dem virtuellen Kreis How to Hug anzuzeigen. The total team can then to votes, his image to place in the middle of the circle.

Sobald das agile Team ein zentrales Bild hat, bewegen die anderen Mitglieder ihre Bilder so, dass sie das Bild des Scrum Masters in der Mitte des Kreises berühren.

Jeder hat die Möglichkeit, sein Bild in der Mitte des Kreises zu platzieren, und das Team wiederholt den Vorgang. Obwohl es um ein einfaches Spiel geht, ist das eine dieser virtuellen Teambuilding-Aktivitäten, bei denen viel gelacht wird.

Die Teammitglieder lernen während dieser virtuellen Umarmungssitzung voneinander. Collaboration and team bindung to make a großartiges team.

3. Kugelschreiberspiel

Spieldauer: Spieler benötigen FormatZiel: 15 Minuten, aufgeteilt in 3-minütige Sessions, 4 plus persönlicher und virtueller Produktionsprozess

Das Ziel beim Spielen von Ball Point ist es, dass das Scrum-Team agile Projekte besser steuert. Durch das Verständnis des agilen Produktionsprozesses weiß das Team die Bedeutung der Selbstorganisation zu schätzen. Self-organization is the eckpfeiler for the creation of Scrum processes, that the entire team can perform efficient iterations.

Ganze Teams können dieses Spiel physisch oder online spielen, indem sie die Spielsymbole auf dem virtuellen Whiteboard verwenden.

Das gemeinsame Ziel besteht darin, dass die Mannschaft einen Ball oder mehrere Bälle um den Tisch bewegt. The team members must be the ball or the balls all once. When a team member has touch the ball, the following person must do same. Das Scrum-Team verdient einen Punkt, wenn es erfolgreich ist, den Ball auf den Tisch zu bewegen.

Jeder Sprint dauert drei Minuten, und das gesamte Team muss an fünf Sprints teilnehmen, um zu sehen, wer das Ballpunktspiel gewinnt. When the first sprint, the team is his strategy and make notes, to previsto, how many points is achieve in the first minute.

In der zweiten Minute bewegt sich der Ball um den Tisch. The Scrum team zeichnet in der dritten Minute seine Punkte auf und das neue Lernen.

Im Lauf des Spiels wird die Teamarbeit intensiviert, da die Mitglieder in den folgenden Sprintrunden weitere Bälle hinzufügen. Wenn das Team gleichzeitig Bälle weitergibt, wird das Spiel komplexer. Im Iterationsprozess ist mehr Nachdenken erforderlich, da die Teammitglieder versuchen, ihre Punktzahlen zu erhöhen. Nach jeder Runde werfen die Teams einen kurzen Rückblick, um zu sehen, mit welcher Taktik sie als nächstes im Sprint mehr Punkte erzielen können. Simply but effective!

4. Marshmallow-Turm

Spieldauer Erforderliche Spieldauer Formatziele 20 Min.4+ Nur persönliche Wiederholung und Zusammenarbeit

This is a personal teambuilding activity, and the team requires a paar pre-rates:

• Trockene Spaghetti
• Ein Meter Band
• Ein Meter Schnur
• Marshmallows

The team members must participate in groups of four people to this learning activity. The Scrum Master verteilt 20 Stück Spaghetti an jedes Team, zusammen mit den anderen Lebensmitteln.

Das Ziel ist es, mit diesen Gegenständen den höchsten Marshmallow-Turm zu bauen. The Marshmallow Tower must be freistehend and the team members must place all marshmallows above on the structure. Bei einigen agilen Spielen wird ein Marshmallow verwendet, während die Marshmallow-Zahlen den Spaghettistäbchen zugeordnet werden.

Unweigerlich stürzt der Turm ein, als das Team den Marshmallow darauf legt. Ziel ist es jedoch, die Scrum-Retrospektive durch mehrere Iterationen zu simulieren. The entire team must be quickly new form by good communication and work to improve in any further round.

Das Konzept klingt einfach, aber die Umsetzung ist täuschend knifflig. Teams müssen schnell zusammenarbeiten, und sie werden in letzter Sekunde viele Türme mit Sicherheit sehen, wenn die Teams sich bemühen, den Marshmallow auf ihren Gebäuden zu platzieren.

Wenn Sie die Herausforderung jedoch mehrmals wiederholen, werden Sie sehen, wie Teams ihre Ansätze zur Zusammenarbeit verfeinern und ihre früheren Kreationen wiederholen.

5. LEGO Flow-Game

Spieldauer Erforderliche Formatziele 60-90 Minuten 3-9 Scrum-Simulation, Iteration, Zusammenarbeit, Workflow nur vor Ort

Das LEGO Flow Game sie konzentriert sich auf eine Scrum-Simulation. Agile Teams erstellen einen virtuellen LEGO-Adventskalender, um Arbeitsaufgaben in einem effizienten Arbeitsablauf detailliert zu beschreiben. In jedem Abschnitt des Workflows sind bestimmte Rollenspieler involviert.

The common goal is into build the items, find the following adventskalender number (analysis) and then identify a series of LEGO-parts, which must conform with the reference source (suppliers).

Das Scrum-Team baut (baut) den LEGO-Gegenstand, während es im Spiel voranschreitet. The team members must to repeat, to be specified, if the build correct and is acceptable for the market representatives or the product components (accept).

Agile-Trainer werden dieses Spiel lieben, da es ein hervorragendes Tool ist, um neue Teams an Agile heranzuführen. LEGO Flow bietet neuen Teams die Möglichkeit, mithilfe einer simulierten Scrum-Übung an neuen Lernaktivitäten teilzunehmen.

LEGO Flow is a agile game, the three runds with each own goal requires. This goal are stapelweise and phase based processes as as time managed and flow based processes.

After each of three runds includes the team work sprint-retrospectives, to know to know, was good running and which challenges the team is made. Ziel ist es, die Vor- und Nachteile der einzelnen Sprintansätze zu analysieren und die Vorteile der Teamarbeit aufzuzeigen. Das Spiel endet mit der Erstellung eines kumulativen Gesamtflussdiagramms.

This chart allows the whole team, his strategies and decisions, to consider that it in each round this agile game is not run, and improve its workflow.

Wenn es die Zeit erlaubt, kann der Scrum Master die Teammitglieder fragen, welche Richtlinien-Änderungen sie für zukünftige Sprints vornehmen würden.

Agile Games and Teambuilding Activities

Das gesamte Team kann sein Arbeitsleben mit virtuellen Teambuilding-Aktivitäten über Zoom verändern. Spass beim Lernen zu haben, ist definitiv besser als ein physisches Whiteboard und Haftnotizen zu verwenden, um neuen Teams das Scrum-Framework vorstellen zu können.

Simple Agile Apps are a further innovation possible to make your new team to make into the agile family. Sie tauchen ein in die Welt von Einfacher agiler Scrum-Workflow für Jira die du mit LEGO Flow kombinieren kannst.

Agile Schätzungstechniken sind erstaunlich einfach, können aber für Softwareentwicklungsteams manchmal komplexer als nötig gestaltet werden. Nachdem sie in den letzten Wochen eines großen Projekts den Zorn erlebt haben, bei früheren Aufträgen eine Frist zu verpassen und Angst vor 20-Stunden-Arbeitstagen zu haben, ist es kein Wunder, dass agile Teammitglieder vorsichtig mit Schätzungen umgehen. Wie oft hat Ihre Schätzung Sie schon einmal getroffen? 😱

Agile Schätztechniken wurden entwickelt, um ein nachhaltiges Entwicklungstempo zu erreichen und den Stakeholdern realistischere Terminerwartungen zu bieten. Sie verwenden relative Größenangaben, anstatt Schätzungen in Echtzeit vorherzusagen.

Zu den beliebten Schätzmethoden in einer agilen Entwicklungsumgebung gehören Story Points, Punktabstimmung, ein Bucket-System, Affinitäts-Mapping und T-Shirt-Größen. Die Größe von T-Shirts ist eine gängige Methode zur agilen Schätzung, die sich bei der langfristigen Planung als sehr effektiv erweisen kann oder Ihrem Team hilft, sich an relative Schätzungen zu gewöhnen.

Wir geben Ihnen einen kurzen Überblick über diese agilen Schätztechniken, aber dann werden wir uns mit der Größe von T-Shirts und den verschiedenen Möglichkeiten befassen, wie Sie diese Technik anwenden können.

Notieren Sie sich Ihre Schätzungen in Jira mit

Einfache Agile User Story Maps

Kostenlose Testversion

Ein kurzer Überblick über einige beliebte agile Schätztechniken

Wenn Sie diesen Artikel lesen, sind Sie wahrscheinlich bereits mit Story Points vertraut, die normalerweise für die Sprint-Planung verwendet werden, daher werden wir keine Zeit damit verbringen, diese aufzuarbeiten. Wenn Storypointing jedoch keine vertraute agile Schätztechnik ist, gehen Sie wie folgt vor ein Artikel, der Storypoints definiert und noch eine über bestimmte Zeiten, zu denen Storypoints könnte in Ihrem Team am besten funktionieren.

Die anderen agilen Schätzungstechniken, die wir uns zuerst ansehen werden, eignen sich eher für Road Mapping oder Release-Planung als für die Sprint-Planung. Lassen Sie uns einen kurzen Überblick über Affinitäts-Mapping, Bucket-Systeme und Punktabstimmung geben.

Affinitätszuordnung

In der Produktentwicklung bezieht sich „Affinität“ auf ähnliche Backlog-Elemente, entweder in Bezug auf Codetypen, Produktbereiche oder Aufwand. Bei der Abbildung von Affinitäten im Rahmen der agilen Schätzung sprechen wir von der Gruppierung von Arbeitselementen ähnlicher Größe. Geh und finde es heraus.

Um ein Affinitäts-Mapping durchzuführen, klebt der Moderator die Backlog-Elemente auf einzelne Haftnotizen und befestigt sie an einer Wand. Identifizieren Sie an einer anderen Wand eine Seite als „Kleiner“ und die andere Seite als „Größer“. Bitten Sie dann das Scrum-Team, die Elemente im Hintergrund von der Backlog-Wand auf die Größenordnung zu verschieben, in die sie passen, je nachdem, wie groß das Objekt wahrgenommen wird oder wie lange das Team voraussichtlich benötigen wird, um es fertigzustellen.

Der Schlüssel zu dieser Technik liegt darin, schnell vorzugehen, nicht zu viel darüber nachzudenken und nicht darüber zu diskutieren. Sobald alle Gegenstände an der Wand angebracht sind, können die Teammitglieder besprechen, welche Gegenstände möglicherweise falsch dimensioniert sind. Nach einer kurzen Diskussion kann das Team entscheiden, ob die Gegenstände verschoben werden sollen.

Nachdem alle mit der Platzierung zufrieden sind, kann sich der Product Owner vertikale Linien an der Wand vorstellen, die den Backlog in Abschnitte unterteilen, und jedem Artikel einfach eine T-Shirt-Größe zuweisen und ihn auf einer Roadmap platzieren.

Schaufelsysteme

Ein Bucket-System ähnelt dem Affinitäts-Mapping, außer dass es erwartet, dass Sie etwas spezifischer werden. Es verwendet die Zahlen 0, 1, 2, 3, 4, 5, 8, 13, 20, 30, 50, 100 und 200 als relative Größen, und die Teammitglieder legen alle Backlog-Elemente in einen der Buckets. Auch dies geschieht im Hintergrund, aber das Team kann am Ende alle Elemente besprechen, die ihrer Meinung nach in den falschen Eimer gelegt wurden.

Punktabstimmung

Eine weitere Möglichkeit, wie agile Entwicklungsteams Schätzungen vornehmen können, ist die Punktabstimmung. Ja, es geht wirklich darum, Punktaufkleber auf Notizkarten oder Haftnotizen zu kleben. Aber das ist eine interessante Technik, die andere Konzepte als die relative Größe beinhaltet.

Bei der Punktabstimmung erhalten die Teammitglieder fünf Punkte. Diese Punkte beziehen sich auf das, was jedes Teammitglied für die wichtigste Arbeit im Backlog hält. Die Bedeutung könnte aus technischen Gründen wie der Überarbeitung einer Datenbank zur Skalierung vor der nächsten Hauptsaison oder aus geschäftlichem Nutzen wie den am häufigsten nachgefragten neuen Funktionen aufgrund von Kundenfeedback resultieren.

Backlog-Elemente werden dann auf der Grundlage ihres Werts (der Anzahl der Punkte) zur Roadmap hinzugefügt und können dann mithilfe einer anderen Technik an den Aufwand angepasst werden.

Wie Sie sehen, sind diese agilen Schätztechniken besonders nützlich, wenn Sie einen großen Rückstand haben, bei dem Sie jedes Mal, wenn Sie versuchen, ihn zu organisieren, das Gefühl haben, Katzen zu hüten. In der Regel werden diese Schätzprozesse zu Beginn eines Projekts, bei der Erstellung wichtiger Funktionen oder bei der jährlichen oder halbjährlichen Roadmap-Planung eingesetzt.

Lassen Sie uns nun tief in die Größe von T-Shirts eintauchen.

T-Shirt-Größen für Artikel aus dem Produktrückstand

Ahhhh, die T-Shirt-Größe. XS, S, M, L, XL — wie kann das einschüchternd sein? Es ist so einfach und doch so flexibel. Die T-Shirt-Größe wird hauptsächlich für die Roadmap- und Release-Planung verwendet und ist nichts weiter als eine Schätzung des Aufwands auf der Grundlage der zum Zeitpunkt der Schätzung verfügbaren Informationen. Deshalb ist es so einfach. Das ist eine Schätzung, und das ist okay. 👌

Sie fragen sich vielleicht, warum die Größe von T-Shirts so wichtig ist, wenn es sich um eine solche ungefähre Zahl und eine relative Schätzung handelt. Es ist hilfreich für die langfristige Planung. Ja, du hast es richtig gehört. Agile Teams planen. Wenn Sie einen kurzen Blick auf die werfen Agiles Manifest, der vierte Wert agiler Entwicklungsteams lautet:

„Auf Veränderungen zu reagieren, anstatt einem Plan zu folgen.“

Ein Team kann nicht auf Veränderungen reagieren, wenn es nie von Anfang an einen Plan befolgt hat. Durch eine langfristige agile Planung wissen Sie, ob Sie den Stakeholdern realistische Erwartungen für die nächsten 6 bis 12 Monate stellen. Oder wenn sich die Bedürfnisse des Unternehmens ändern oder die vorhandenen Ressourcen nicht ausreichen und Sie ein zusätzliches Team zusammenstellen müssen. Schätzungen von T-Shirts helfen auch dabei, zu ermitteln, wie viele Iterationen in jeder Version enthalten sein müssen, um den Endbenutzern den größtmöglichen Nutzen zu bieten.

Agile Estimation beginnt mit einer T-Shirt-Größe für die Planung zukünftiger Releases, wird dann für die Sprint-Planung in Story Points aufgeteilt und kann für die Sprint-Ausführung sogar noch weiter in Stunden unterteilt werden. Unabhängig davon ist der Hauptpunkt folgender: Je näher die Arbeit der Tastatur eines Entwicklers kommt, desto kleiner und einfacher ist es, sie genau abzuschätzen. Die T-Shirt-Größe ist am weitesten von der Ausführung entfernt, daher wird nicht erwartet, dass die Schätzung perfekt ist.

Die Größe des T-Shirts ist schnell

Wenn Sie schon einmal einen Backlog mit Hunderten von Arbeitselementen geerbt haben und dann die Frage erhalten haben: „Wie lange wird es dauern, all das zu erledigen?“ du bist nicht allein. Ihr erster Versuch, die Beantwortung dieser unmöglichen Frage zu vermeiden, könnte eine gute Bereinigung des Backlogs sein. Nehmen wir an, Sie löschen ein Arbeitselement, das älter als sechs Monate ist. Ich meine, hey, wenn es schon so lange im Produkt-Backlog ist, ist es vielleicht nicht wirklich so wichtig.

Aber wenn Sie einem Team beigetreten sind, das gerade erst mit agilen Methoden angefangen hat, werden Sie wahrscheinlich mit einem großen Rückstand feststecken und Produktmanager erwarten eine altmodische Schätzung.

Die Größe von T-Shirts ist hier praktisch. Da bekannt ist, dass Sie Schätzungen aus dem Bauch heraus abgeben, kann Ihr Team einen riesigen Rückstand im Handumdrehen bewältigen. Beschränken Sie die Entscheidungsfindung auf 30 Sekunden pro Artikel, um sicherzustellen, dass die Teammitglieder bei Übungen zur Größe von T-Shirts nicht zu viel über jeden Artikel nachdenken.

Das Ergebnis ist ein einigermaßen organisierter Rückstand mit relativen Schätzungen. Der Produkteigentümer und die Interessengruppen können anhand dieser Informationen entscheiden, was kurzfristig geschehen soll.

Wie funktioniert die Größe von T-Shirts?

Abhängig von Ihrer Backlog-Größe gibt es verschiedene Möglichkeiten, wie Sie die Größe von T-Shirts angehen können. Bei einer kleinen Anzahl von Artikeln funktioniert Planungspoker hervorragend. Bitten Sie einfach Ihren Scrum Master, die Karten mit den Fibonacci-Sequenznummern gegen Buchstaben in T-Shirt-Größe auszutauschen.

Diese Technik eignet sich auch gut, wenn Sie eine Teilmenge eines umfangreicheren Backlogs schätzen müssen.

Sie sollten wahrscheinlich einen Prozess verwenden, der Affinitätszuordnungen und Bucket-Systemen für große Backlogs ähnelt. Jeder arbeitet unabhängig daran, die Größe zuzuweisen, und am Ende bespricht er dann Konflikte. Diese Technik ermöglicht es auch kleinen Teams, einen großen Backlog relativ schnell zu überwinden.

Schließlich möchten einige neue agile Teams vielleicht ihre Schätzungsreise beginnen, indem sie T-Shirt-Größen für User Stories und die Sprint-Planung verwenden. Mike Cohn, einer der Gründer der Scrum Alliance und ein Experte für agile Prozesse, schlägt vor dass Teams, die sich für diesen Ansatz entscheiden, jeder T-Shirt-Größe einen Story-Point-Wert zuweisen. Diese Technik hilft den Teams, sich mit den Storypoints vertraut zu machen, die innerhalb des Sicherheitsnetzes bei der Schätzung der T-Shirt-Größe liegen.

Übung macht den Meister mit agilen Schätztechniken

Unabhängig von der Art des agilen Projekts, an dem Sie arbeiten oder für welchen Schätzprozess Sie sich entscheiden, je mehr Sie üben, desto schneller wird Ihr Team zu Meisterschätzern. 👑 Wir empfehlen, ein paar verschiedene Methoden auszuprobieren, um herauszufinden, welche für Ihr Team am besten geeignet ist.

Eine letzte Sache: Denken Sie daran, dass Story-Point-Schätzungen am besten für die Sprint-Planung geeignet sind. Affinitäts-Mapping, Bucket-Systeme, Punktplanung und T-Shirt-Größe eignen sich besser für die Roadmap- und Release-Planung.

Wenn du Hilfe brauchst, um deine Planung von der Wand auf Jira zu übertragen, solltest du es versuchen

Einfache agile Roadmaps

Vergessen Sie nicht, sich unsere anzusehen weitere Blogartikel um Ihrem Team auf seiner agilen Reise zu helfen.

Die Priorisierung von Backlogs ist eine nie endende Aufgabe für Product Owner und Produktmanager. Wenn sich die Prioritäten als Reaktion auf sich ändernde Geschäftsanforderungen weiterentwickeln oder sogar die Arbeit abgeschlossen ist oder Anpassungen an der Teamausstattung vorgenommen werden, ist es wichtig, dass Sie sich weiterhin auf die Arbeit konzentrieren, die den größten Nutzen bringt, indem Sie Ihren Backlog in einem guten Zustand halten. Agile Schätzungstechniken können die Priorisierung Ihres Backlogs schneller und einfacher machen.

Schauen wir uns also einige spezifische Methoden an, um priorisiere deinen Backlog und erfahren Sie, wie agile Schätzungen dazu beitragen können, Ihren Endbenutzern und Stakeholdern den größtmöglichen Nutzen zu bieten.

5 Möglichkeiten, einen Backlog zu priorisieren

Natürlich gibt es mehr als fünf Möglichkeiten, Arbeitselemente in einem Backlog zu priorisieren. Wir haben jedoch einige unserer Favoriten ausgewählt, die in Kombination mit einem agilen Schätzprozess dazu beitragen, dass unser Produkt-Backlog stets priorisiert bleibt, sodass wir die Sprint-Planung im Handumdrehen durchführen können.

1. Gewichteter kürzester Job zuerst

Wow, ist das ein Schluck voll! Verwenden wir das Akronym „WSJF“, um uns darauf zu beziehen SAFE-Technik. WSJF ist nicht so einschüchternd, wie es klingt. Es handelt sich um eine einfache Formel, die Artikeln aus dem Produktrückstand einen Geschäftswert zuweist.

WSJF = Kosten der Verzögerung ÷ Auftragsdauer

Kosten der Verzögerung ist die Summe von drei relativen Metriken:

• Nutzer-/Geschäftswert: Die relative Wichtigkeit des Arbeitselements.
• Zeitkritikalität: der Rückgang des Nutzer-/Geschäftswerts im Laufe der Zeit.
• Reduzierung des Risikos: die Reduzierung des geschäftlichen oder technischen Risikos.

Um die relative Größe der Verzögerungskosten zu ermitteln, stellen Sie sich den niedrigsten Geschäftswert, den geringsten Wertverlust im Laufe der Zeit und die geringste Risikominderung als Wert 1 vor. Das Gleiche wie bei Schätzung des Storypoints der Fibonacci-Sequenz, passen Sie diese Punktzahl entsprechend an, wenn Sie Arbeitselemente vergleichen, um sie relativ zueinander zu bewerten.

Die Jobdauer wird ebenfalls relativ ausgedrückt. Wenn Sie Ihre Arbeitselemente mithilfe einer relativen Schätzung anhand von Story Points schätzen, entspricht der Story-Point-Wert der Auftragsdauer.

Wenn du diese Technik verwendest, um eine große Menge an Arbeit in einem Backlog zu priorisieren, in dem einige Artikel nur T-Shirt-Größe hatten, konvertiere deine T-Shirt-Größen in Standard-Fibonacci-Zahlen und verwende diesen Wert.

Warnung: Seien Sie vorsichtig bei der Umrechnung von T-Shirt-Größen in Story Points. Sie benötigen eine Möglichkeit, die Arbeitselemente in T-Shirt-Größe zu kennzeichnen, die Sie in Story Points umgewandelt haben. Sie und Ihr Scrum Master müssen diese Schätzungen als Schätzungen der T-Shirt-Levels erkennen und nicht als tatsächliche Schätzungen der Storypoints, die mit vollständig verfeinerten Arbeitsaufgaben einhergehen.

Sehen Sie in Easy Agile TeamRhythm mehr auf einen Blick, um die Priorisierung Ihres Backlogs zu beschleunigen

💡 Tipp: Füge bis zu drei zusätzliche Felder auf Ausgabekarten hinzu

SEHEN SIE WIE

2. Moskau

Ein Muss, ein Muss, ein Könnten-Hättest und ein Nicht-Haben sind die Kriterien, die verwendet werden, um einen Backlog mit der MoSCoW-Technik zu priorisieren. Das Produktteam definiert diese Bezeichnungen auf der Grundlage der einzigartigen Eigenschaften des Produkts und der Konkurrenzangebote.

Jedes Arbeitselement fällt in eine dieser Kategorien. Der einfachste Teil dieses Vorgangs besteht darin, Won't-have-Elemente direkt in den Papierkorb zu schicken und sie dir aus dem Weg zu räumen. Als Nächstes priorisieren Sie zuerst die Must-Haves und dann die Soll-Haves. Die Elemente, die man haben könnte, fallen natürlich an das Ende des Backlogs.

Nehmen Sie diese Artikel in Ihre regelmäßigen Verfeinerungsgespräche mit Ihren Teammitgliedern auf und weisen Sie jedem Artikel eine T-Shirt-Größe oder einen Storypoint-Wert zu. Dann bist du bereit, deinen Sprints oder Releases die richtige Menge an Arbeitselementen hinzuzufügen, basierend auf der Geschwindigkeit deiner Teams oder der Anzahl der Storypoints, die sie während eines Sprints voraussichtlich abschließen werden.

3. Kano

Das Kano-Modell der Priorisierung verwendet fünf Klassifizierungen:

• Muss sein: die grundlegende Funktionalität, die Ihre Benutzer erwarten.
• Attraktiv: eine angenehme Überraschung für Ihre Benutzer, aber niemand wird verärgert sein, wenn es nicht da ist.
• Eindimensional: Arbeitselemente, die Ihre Nutzer glücklich machen und sie enttäuschen werden, wenn sie nicht Teil Ihres Produkts sind.
• Gleichgültig: Arbeitselemente, die für Ihre Kunden unwichtig sind. Oft handelt es sich bei diesen Arbeitsaufgaben um technische Probleme oder Verbesserungen, die dem Softwareentwicklungsteam helfen, effizienter zu entwickeln oder mit den neuesten Versionen seines Tech-Stacks zu arbeiten — aber Ihren Kunden sind sie wirklich egal.
• Umgekehrt: Der Vorgang, bei dem eine frühere Funktion oder ein vorheriges Update rückgängig gemacht wird. Wenn Sie jemals eine Funktion entwickelt oder eine Benutzeroberflächenaktualisierung vorgenommen haben, die Ihre Benutzer gehasst haben, dann kennen Sie sich mit Reverse-Work-Aufgaben aus. Hoppla. Leider sind dies manchmal notwendige Übel, insbesondere wenn es um Sicherheitsfunktionen oder die Umstellung von Benutzern auf ein neues Produkt geht, nachdem sie ein veraltetes Produkt außer Dienst gestellt haben.

Wie bei der MoSCoW-Methode schätzen Sie diese Arbeitselemente während der Verfeinerung und fügen sie dann Ihrem Iterations- oder Release-Plan hinzu. Aber anders als bei MoSCow möchten Sie vielleicht Ihre Sprints und Releases mit Arbeitselementen aus jeder Klassifizierung ausgleichen.

4. Rangliste stapeln

Die brutalste aller Priorisierungstechniken, das Stack-Ranking, zwingt Teams dazu, eine lineare Rangfolge der Arbeitsaufgaben zu haben, was bedeutet, dass es nur eine oberste Priorität, eine zweite Priorität, eine dritte Priorität usw. gibt. Brutal!

Sobald du dich daran gewöhnt hast, ist Stack-Ranking eine nützliche Methode, um zu erzwingen Produktmanager um schwierige Entscheidungen zwischen Arbeitselementen zu treffen. Selbst wenn zwei Arbeitselemente während desselben Sprints abgeschlossen werden können, ist es Sache des PO, zu bestimmen, welches zuerst erledigt wird, und dann spiegelt sich diese Wahl im Sprint-Backlog wider.

Oft wird dieser Job einfacher, wenn er schlecht formuliert wird. Wenn Sie zum Beispiel nur einen Tag Zeit hätten, um neue Nutzer für Ihr Produkt zu gewinnen, welche Arbeit würden Sie in der Produktion erwarten? BUMM! Da ist deine oberste Priorität.

Das Schöne am Stack-Ranking ist, dass es PoS ermöglicht, kleinere Arbeitselemente in aktuelle Sprints zu verschieben, wenn andere Arbeiten mit höherer Priorität zu umfangreich sind. Wenn das größere Arbeitselement hinzugefügt wird, wird das Team aufgrund seiner Geschwindigkeit zu viel beansprucht. Diese kleinen Arbeitselemente dienen dazu, die Sprints zu füllen, damit die Teams ihr Tempo beibehalten und so produktiv wie möglich arbeiten können. Nur weil ein Arbeitselement, das zwei Stockwerke hoch ist, zu zwei Dritteln im Backlog liegt, heißt das nicht, dass es niemals erledigt werden kann.

5. Zuordnung von Geschichten

Mithilfe von Story Mapping können Sie die Reise des Kunden durch Ihr Produkt von Anfang bis Ende visualisieren. (Ja, das haben wir direkt von unserem anderen gestohlen ausgezeichneter Artikel zum Thema Story-Mapping.) Fortgeschrittene Story-Mapper sollten das, was Sie über Story-Mapping gelernt haben, nutzen und darüber nachdenken, wie Sie MoSCOW- oder Kano-Techniken zu Ihren Story-Maps hinzufügen können.

Vielleicht könnte dein episches Rückgrat oben auf der User-Story-Map die Buckets in der MoSCoW-Methode repräsentieren?

Wenn Sie wie wir sind, sind Ihre Story-Mapping-Sitzungen produktive Brainstorming-Aktivitäten, und Sie werden die Sitzungen mit viel mehr Arbeit verlassen, als Sie erledigen können. Indem Sie die MoSCoW- oder Kano-Prinzipien auf die Geschichten in Ihren Benutzererlebnissen anwenden, werden Sie die wichtigsten Geschichten entdecken, die Sie priorisieren müssen, und die Geschichten, die auf eine spätere Veröffentlichung warten können.

Agile Schätzung in die Backlog-Priorisierung einbauen

Wir haben Ihnen fünf verschiedene Techniken an die Hand gegeben, mit denen Sie Ihre Arbeitselemente in einem organisierten, priorisierten und wertschöpfenden Produkt-Backlog zusammenfassen können:

1. Gewichteter kürzester Job zuerst
2. MOSKau
3. KANO
4. Rangfolge stapeln
5. Storymaps

Wir haben Ihnen auch Möglichkeiten aufgezeigt, wie Sie agile Schätzungen wie T-Shirt-Größen und Storypoints in Ihren Priorisierungsprozess einbeziehen können, damit Ihr Team die wichtigsten Aufgaben erledigt und gleichzeitig die Geschwindigkeit beibehalten und Ihre Kunden und Stakeholder beeindrucken kann.

Wir empfehlen Ihnen, diese Ideen aufzugreifen, sie mit Ihrem Team zu teilen und sie auszuprobieren. Wenn Sie Hilfe bei der Verwendung des Story-Map-Konzepts benötigen, versuchen Sie es Einfacher agiler Teamrhythmus. Wie auch immer Ihr Team seinen Produkt-Backlog priorisiert, denken Sie daran, die wichtigsten Arbeiten an die erste Stelle zu setzen und diese Prioritäten dann nach Bedarf anzupassen. Machen Sie es einfach und bleiben Sie agil!

Du bist Teil eines agilen Teams. Du kennst die Übung. Sie haben eine agile Denkweise, Sie und Ihre Teammitglieder nehmen an den agilen Zeremonien teil und Sie verwenden agile Tools wie Jira. Alles gut! Es besteht aber auch eine gute Chance, dass Sie Teil einer größeren Organisation sind, die entweder agile Praktiken nicht vollständig versteht oder selbst eine agile Transformation benötigt. An dieser Stelle kann ein agiler Coach einspringen.

Seien wir ehrlich — wenn Ihr Unternehmen in seinem agilen Framework perfekt aufeinander abgestimmt wäre, würden Sie diesen Beitrag nicht lesen. 😉 In vielen großen Unternehmen ist die Einführung agiler Praktiken auf eine Untergruppe von Teams beschränkt, insbesondere auf die Softwareentwicklungs- und Projektmanagementteams.

Aber du willst mehr — du willst ein Meister in Sachen Agilität sein. Ein altes Sprichwort lautet etwa: „Der beste Weg, etwas zu lernen, ist, es zu vermitteln.“ Oder, wie Yoda es ausdrückte: „Es gibt immer zwei, nicht mehr und nicht weniger. Ein Meister und ein Lehrling.“

In diesem Beitrag erklären wir, was den Kern eines effektiven Agile-Coaches ausmacht, welche Unterschiede zwischen einem agilen Coach auf Teamebene und auf Organisationsebene bestehen, und geben einen Beispielpfad, um ein zertifizierter Agile-Coach zu werden. Wir stellen dir auch einige unserer besten Bildungsressourcen zur Verfügung, um dich auf dem Laufenden zu halten, egal in welcher Phase deiner agilen Reise du dich gerade befindest.

Was ist ein Agile Coach?

Lassen Sie uns eine Sache aus dem Weg räumen. Ein agiler Coach ist kein Instruktor mit katzenähnlichen Reflexen.

Unser Agile Coach bietet professionelles Coaching und Fachwissen, indem er Organisationen hilft, die agile Methodik und ihre Vorteile gut genug zu verstehen, um sie in großem Maßstab in funktionsübergreifenden Teams umzusetzen. Dies wird in zwei Buckets bereitgestellt:

• Zusammenarbeit mit einer Untergruppe einer Organisation (Teams, Manager und Stakeholder) an agilen Best Practices zur Verbesserung von Leistung und Ergebnissen
• Förderung organisatorischer Veränderungen durch die Zusammenarbeit mit der Führung, um Hindernisse zu beseitigen, die eine vollständige agile Transformation ermöglichen

Eine agile Coaching-Rolle ist kein Patentrezept. Es kann sich um eine feste oder vorübergehende Stelle in einem Unternehmen handeln. Agile Coaches haben eine Vielzahl von Hintergründen, darunter Softwareentwickler, Product Owner, Scrum Master und Projektmanager.

Ein agiler Coach ist ein Facilitator. Da es sich um eine Mentorenrolle handelt, sollte ein agiler Coach über Kompetenzen in den Bereichen Zusammenarbeit und Kommunikation verfügen.

Du willst also ein agiler Coach werden

Du bist alle dabei. Sie möchten Ihr agiles Fachwissen erweitern, indem Sie dessen Prinzipien vermitteln oder agile Methoden außerhalb Ihres Teams vermitteln. Nun, wo fängst du an? Hier ist der Plan.

Lassen Sie uns das mit einem dreigleisigen Ansatz angehen:

1. Erlernen der agilen Frameworks
2. Engagieren Sie sich in einer agilen Community
3. Formelles agiles Training

Erlernen der agilen Frameworks

In der Regel benötigen Sie einige Erfahrung in der Arbeit mit agilen Frameworks, bevor Sie mit formellen Agile-Coaching-Zertifizierungen beginnen. Allerdings kann es schwierig sein, das zu beherrschen Vielzahl von Frameworks innerhalb der agilen Entwicklung, auch im Laufe einer langen Karriere. Zu weiß:

• Gedränge
• Kanban
• ScrumBan
• DevOps
• Digital Agile (DA)
• eXtreme Programming (XP)
• Praxis
• Skaliertes Agile-Framework (Sicher)
• Scrum im großen Maßstab (LeSS)

Aber warte... es gibt noch mehr! Uns geht die Tinte aus, wenn wir sie alle auflisten, also lass uns weitermachen. ✍️

Viele von uns verbringen den Großteil ihrer Zeit damit, mit einem oder zwei Frameworks oder einer Mischung davon zu arbeiten. Sie können beispielsweise lange in einer Scrum-Umgebung arbeiten, bevor Sie alle folgenden Aspekte beherrschen:

• Scrum-Rollen
• Scrum-Artefakte
• Scrum-Zeremonien

Und das ist ok! Wir schlagen vor, das, was Sie in Ihrer eigenen Arbeitsumgebung wie Scrum können, zu beherrschen und dann so viel wie möglich über ein oder zwei andere Dinge zu lernen, die Sie interessieren könnten und die Sie möglicherweise nicht direkt üben können. Lernen Sie zum Beispiel SAFe oder Weniger und wie sie agile Praktiken in großem Maßstab ermöglichen, wäre ein guter Anfang.

Ein wichtiger Tipp, den Sie beachten sollten: Es ist leicht, die Kernprinzipien von Agile aus den Augen zu verlieren, wenn Sie sich zu sehr damit beschäftigen, Frameworks täglich zu üben. Schließen Sie ab und zu Ihre Augen und gehen Sie zurück und lesen Sie das agiles Manifest (ok, du musst eigentlich deine Augen öffnen, aber du weißt, was wir vorschlagen):

• Individuen und Interaktionen statt Prozesse und Tools
• Funktionierende Software statt umfassender Dokumentation
• Zusammenarbeit mit dem Kunden statt Vertragsverhandlungen
• Auf Änderungen gemäß einem Plan reagieren

Du kannst jetzt deine Augen öffnen.

Wenn Sie bereits in einem Framework wie Scrum mit einem Entwicklungsteam als Scrum Master oder Product Owner arbeiten, haben Sie wahrscheinlich viele der Voraussetzungen, um mit Agile-Coach-Schulungen zu beginnen.

Engagieren Sie sich in einer agilen Community

Bevor Sie sich für eine Agile-Coaching-Zertifizierung bewerben, ist es eine gute Idee, Teil einer agilen Community zu sein. Dadurch werden drei Dinge erreicht:

1. Es hält Sie über aktuelle Ereignisse in der agilen Welt auf dem Laufenden.
2. Es macht Sie mit agilen Methoden und Ideen vertraut, die Kollegen außerhalb ihrer eigenen Organisation anwenden.
3. Es zeigt, dass du dich dafür einsetzt, Agile als Karriereziel zu praktizieren — was, wie wir bald sehen werden, wichtig für den Bewerbungsprozess für einen zertifizierten Agile-Coach ist.

Du kannst agile Communities finden örtlich oder entfernt.

Formelles agiles Training

Wenn du als Agile-Coach eingestellt werden möchtest, ist es eine gute Idee, einige agile Zertifizierungen anzustreben. Die bekanntesten Schulungen werden angeboten von Scrum-Allianz. Je nach Ihrem Interesse können Sie zwei Wege einschlagen, um ein zertifizierter Agile Coach zu werden — Zertifizierter Teamcoach (CTC) oder Zertifizierter Unternehmenscoach (CEC). Es gibt Unterschiede zwischen diesen beiden Tracks, die es zu verstehen gilt:

• Ein CTC arbeitet mit mehreren agilen Teams zusammen und coacht Scrum Master, Product Owner und Unternehmensmanager. Ein CTC bleibt im Allgemeinen dabei, einen Bereich einer Organisation zu betreuen, beispielsweise die Softwareentwicklung.
• Ein CEC coacht in der Regel auf der Führungsebene einer Organisation. Ein CEC ist ein Agile-Coach für Unternehmen, dessen Ziel es ist, eine Organisation dabei zu unterstützen, eine vollständige agile Transformation erfolgreich zu erreichen.

Sie fragen sich wahrscheinlich... wie hoch ist die Verpflichtung, eine Zertifizierung zu erhalten? Wir werden es nicht beschönigen — es ist bedeutsam. Dieses Engagement kann jedoch dazu führen, dass Sie Ihr ganzes Berufsleben lang in der Lage sind, spürbare Auswirkungen auf Teams und Organisationen zu haben. Kurz gesagt, Folgendes benötigen Sie, um ein CTC oder CEC zu werden:

• Sei ein Aktiver Zertifizierter Scrum Professional
• Reichen Sie eine erste Bewerbung ein, in der Ihre Agile-Erfahrung beschrieben wird, einschließlich Team- und Organisationscoachings, der Teilnahme an agilen Community-Aktivitäten und Ihrer Anwendung agiler Praktiken
• Reichen Sie eine zweite Bewerbung ein, die Ihr Wissen, Ihre Denkweise und Ihre Herangehensweise als Coach bewertet und Empfehlungen von Mentoren und Kunden erfordert
• Eine jährliche Zertifizierungsgebühr
• Weiterbildungsanforderungen zur Aufrechterhaltung Ihrer Zertifizierung

Gute Agile Coaches lernen weiter

Es kann lange dauern, die Erfahrung zu sammeln, um ein agiler Coach zu werden. Danach ist es wichtig, mit den zentralen agilen Konzepten und deren Beziehung zu aktuellen Trends in der Softwareentwicklung auf dem Laufenden zu bleiben, um genügend Wissen zu haben, um Ihre Qualifikationen aufrechtzuerhalten.

Wir glauben, dass unsere agilen Ressourcen für die Weiterbildung so gut sind, wie Sie es nur finden können. Hier sind einige Beiträge, die einige der wichtigsten Bereiche hervorheben, über die wir zuvor gesprochen haben:

• Was ist der Unterschied zwischen Kanban und Scrum?
• Lernen Sie zuerst Agile — dann lernen Sie, wie Sie es skalieren
• Warum große Unternehmen das Scaled Agile Framework (SAFe) benötigen, nicht Agile auf Teamebene

Aber warte... es gibt noch mehr! Gehen Sie rüber zu unserem Blog für unseren Schatz an Ressourcen — und wenn Sie es leid sind zu lesen, setzen Sie Ihre Kopfhörer auf und hören Sie unsere Podcast-Folge mit einem agilen Coach.

Dieser Leitfaden befasst sich mit den vier Zeremonien die eines der beliebtesten Frameworks von Agile bieten, Gedränge, zum Leben.

Erfahren Sie, wie jedes agile Ritual dazu beiträgt, Teams zu stärken und die Leistung zu steigern, und geben Sie einige Tipps heraus, mit denen Ihr Unternehmen das Beste aus Ihren Zeremonien herausholen kann.

Auf einen Blick:

• Die vier agilen Zeremonien sind Sprint-Planung, Tägliches Aufstehen, Sprint-Rückblick und Sprint-Rückblick
• Zeremonien in Agile ermöglichen Sichtbarkeit, Transparenz und Zusammenarbeit.
• Jede Zeremonie hat eine klare Struktur und ein klares Ziel.
• Klare Kommunikation, Flexibilität und kulturelle Ausrichtung sind die Schlüssel zu erfolgreichen Zeremonien.

Was sind die wichtigsten agilen Zeremonien?

Agile Zeremonien beziehen sich auf die vier Ereignisse, die während einer Scrum Sprint. Andere Formen der agilen Entwicklung, wie Kanban und Schlank, haben auch ähnliche Praktiken.

Das Liste agiler Zeremonien beinhaltet:

1. Sprint-Planung
2. Tägliches Aufstehen
3. Sprint-Rückblick
4. Sprint-Rückblick

Obwohl jede Zeremonie anders ist, dienen sie doch dem gleichen Gesamtzweck. Die Zeremonien bringen Teams mit einem gemeinsamen Ziel in einem regelmäßigen Rhythmus zusammen und helfen den Teams, Dinge zu erledigen.

„Unternehmen stehen heute unter erhöhtem Druck, schnell auf die Bedürfnisse ihrer Kunden und Stakeholder zu reagieren. Daher müssen sie neue Produkte schneller auf den Markt bringen und Verbesserungen vorhandener Lösungen und Dienstleistungen beschleunigen. „- Bericht zum Stand von Agile

Warum sind agile Zeremonien wichtig?

Agile Zeremonien helfen Organisationen, sich an Veränderungen anzupassen und erfolgreich zu sein. Da die Arbeit in kleineren Portionen und über kürzere Zeiträume geplant wird, helfen sie Teams dabei, schnell die Richtung zu ändern und bei Bedarf Kurskorrekturen vorzunehmen. Sie sind ein wichtiger Bestandteil des umfassenderen agilen Ansatzes, der heute in Unternehmen auf der ganzen Welt weit verbreitet ist.

Mit agilen Zeremonien können Teams in Ihrer Organisation von folgenden Vorteilen profitieren:

• Verbesserte Fähigkeit, sich ändernde Prioritäten zu verwalten
• Beschleunigung der Softwareentwicklung
• Steigerung der Teamproduktivität
• Bessere Abstimmung von Geschäft und IT

Es ist wichtig, sich daran zu erinnern, dass Zeremonien zwar ein wesentlicher Bestandteil von Scrum sind, aber nur eines von vielen Ritualen, die dazu beitragen, agile Teams und Arbeitsplätze zu schaffen. Um die wahren Vorteile von Agile zu nutzen, müssen Sie mehr tun, als eine oder mehrere der Zeremonien in Ihre Wasserfall-Projekt.

1. Sprint-Planung

Die Sprint-Planungszeremonie bereitet die Teams auf Erfolgskurs vor, indem sichergestellt wird, dass jeder die Sprintziele versteht und weiß, wie sie erreicht werden können.

• Struktur - Der Product Owner bringt das Produkt-Backlog mit, um es mit dem Entwicklungsteam zu besprechen. Der Scrum Master erleichtert. Zusammen nimmt das Scrum Team Schätzungen des Aufwands oder der Story Point vor. Das Produkt-Backlog muss alle Details enthalten, die für die Schätzung erforderlich sind. Der Product Owner sollte in der Lage sein, alle Zweifel bezüglich des Produkt-Backlogs zu klären.

• Teilnehmer - Das gesamte Scrum-Team (das Entwicklungsteam, der Scrum Master und der Product Owner).‍

• Zeitlicher Ablauf - Zu Beginn jedes Sprints.‍

• Dauer - Ein bis zwei Stunden Iteration pro Woche. Wenn Sie also einen zweiwöchigen Sprint planen, sollte Ihre Sprint-Planung zwei bis vier Stunden dauern. ‍

• Agiles Framework - Gedränge. Kanban-Teams planen zwar auch, aber weniger formell und pro Meilenstein, nicht iterativ.

Ergebnisse

Nach einigen Teamverhandlungen und Diskussionen sollten Sie bis zum Ende der Sprint-Planung eine klare Entscheidung darüber haben, welche Arbeit das Entwicklungsteam während des Sprints erledigen kann. Dies ist bekannt als Sprintziel.

Das Sprintziel ist eine Erhöhung der gesamten Arbeit, und jeder sollte sich der Verpflichtung sicher sein.

Das Produkt-Backlog definiert Prioritäten, die sich auf die Reihenfolge der Arbeiten auswirken. Dann wandelt der Scrum Master diese Entscheidung um in Sprint-Backlog.

Die besten Tipps

• Konzentrieren Sie sich auf Zusammenarbeit statt auf Wettbewerb.
• Teilen Sie Benutzerberichte in Aufgaben auf, um die Dinge für das Entwicklungsteam operationeller zu gestalten. Wenn Zeit zur Verfügung steht, weisen Sie diese Aufgaben während der Veranstaltung zu.
• Berücksichtigen Sie Feiertage und die Freizeit oder Ferien aller Teammitglieder.
• Behalten Sie das Tempo Ihres Teams im Auge — eine Erfolgsbilanz der Zeit, die für die Implementierung ähnlicher User Stories benötigt wurde, wäre hilfreich.
• Konzentrieren Sie sich auf das Produkt-Backlog und nichts anderes in Bezug auf die Arbeit für den Sprint.

2. Tägliches Aufstehen

Das tägliche Stand-up bringt das Team zusammen und bereitet alle auf den Tag vor. Das Team nutzt diese Zeit, um Blocker zu identifizieren und Pläne für den Tag auszutauschen.

• Struktur - Dies ist ein informelles, ständiges Treffen. Alle Mitglieder des Entwicklungsteams informieren alle darüber, was sie am Vortag getan haben und was sie heute tun. Die Mitglieder besprechen alle Blockaden, die sie haben, und bitten das Team bei Bedarf um Hilfe. Aus Zeitgründen sollten die Updates kurz sein.

• Teilnehmer - Entwicklungsteam, Scrum Master, Product Owner (optional).

• Zeitlicher Ablauf - Täglich, normalerweise morgens.

• Dauer - Kurz und scharf. Nicht länger als 15 Minuten.

• Agiles Framework - Scrum und Kanban.

Ergebnisse

Der Scrum Master sollte alle Blockaden beseitigen, die das Entwicklungsteam verlangsamen oder daran hindern, Ergebnisse zu liefern. Infolgedessen muss sich der Entwicklungsprozess möglicherweise ändern.

Dieser tägliche Pulscheck hält das Team auf dem Laufenden und hilft, Vertrauen aufzubauen. Gemeinsam findet die Gruppe Wege, sich gegenseitig zu unterstützen und zu helfen.

Die besten Tipps

• Verwenden Sie einen Timer, um dieses Meeting auf 15 Minuten zu beschränken.
• Halte deinen Stand jeden Tag zur gleichen Zeit.
• Besprechen Sie nur die Arbeit für den kommenden Tag.
• Wenn das Team verteilt ist, verwenden Sie Videokonferenzen mit eingeschalten Kameras.
• Nach der Veranstaltung sollten lange Diskussionen stattfinden.
• Da der Stand-up den Fortschritt fördert, sollte jeder ein Update bereitstellen und sich jeder sollte sich verantwortlich fühlen.

3. Bewertung im Sprint

Der Sprint Review ist die Zeit, um die abgeschlossenen Arbeiten des Teams zu präsentieren und Feedback von Stakeholdern einzuholen. Eine Vielzahl von Teilnehmern von außerhalb des Teams bietet wertvolle Einblicke aus unterschiedlichen Blickwinkeln. Diese Veranstaltung trägt auch dazu bei, Vertrauen sowohl bei externen als auch bei internen Interessengruppen aufzubauen.

• Struktur - Der Scrum Master übernimmt die Logistik der Eventvorbereitung. Der Product Owner sollte den Stakeholdern Fragen stellen, um so viel Feedback wie möglich zu erhalten. Sie sollten auch alle Fragen ihrer Stakeholder beantworten.

• Teilnehmer - Entwicklungsteam, Scrum Master, Product Owner. Wahlweise Management, Kunden, Entwickler und andere Interessengruppen.

• Zeitlicher Ablauf - Am Ende des Sprints.

• Dauer - In einem einwöchigen Sprint dauert der Sprint Review eine Stunde.

• Agiles Framework - Scrum und Kanban. Kanban-Teams führen diese Überprüfungen nach den Team-Meilensteinen durch, nicht nach Sprints.

Ergebnisse

Nach dieser Zeremonie muss der Product Owner möglicherweise das Produkt-Backlog anpassen oder ergänzen. Möglicherweise veröffentlichen sie auch Produktfunktionen, wenn diese bereits vollständig sind.

Die besten Tipps

• Planen Sie vor dem Meeting genügend Zeit für die Proben ein, damit Ihr Team selbstbewusst auftreten kann, insbesondere wenn externe Stakeholder anwesend sind.
• Präsentieren Sie keine unvollständigen Arbeiten. Überprüfe deine Sprint-Planung und die ursprünglichen Kriterien, wenn du dir nicht sicher bist, ob die Arbeit abgeschlossen ist.
• Konzentrieren Sie sich neben der Produktfunktionalität auf Benutzererfahrung, Wert für den Kunden, und die gelieferten geschäftlicher Wert.
• Überlegen Sie, wie Sie eine feierliche Atmosphäre schaffen können, um die Leistung des Teams anzuerkennen.

4. Sprint-Rückblick

In dieser letzten Scrum-Zeremonie in der Sequenz blickst du auf die Arbeit zurück, die du gerade geleistet hast, und findest heraus, wie du die Dinge beim nächsten Mal besser machen kannst. Die Sprint-Retrospektive ist ein Tool zur Risikominderung in zukünftigen Sprints.

• Struktur - Die Teams besprechen, was während des gesamten Sprints gut gelaufen ist und was schief gelaufen ist. Der Scrum Master sollte das Entwicklungsteam ermutigen, sich zu äußern und nicht nur Fakten, sondern auch seine Gefühle mitzuteilen. Ziel ist es, schnelles Feedback für eine kontinuierliche Verbesserung des Prozesses zu erhalten. Es ist auch eine Gelegenheit, bewährte Verfahren hervorzuheben, die das Team übernommen hat und wiederholen sollte.

• Teilnehmer - Entwicklungsteam, Scrum Master, Product Owner (optional).

• Zeitlicher Ablauf - Am Ende des Sprints.

• Dauer - 45 Minuten pro Sprintwoche.

• Agiles Framework - Scrum und Kanban (gelegentlich).

Ergebnisse

Nach dieser Sitzung sollte das Team die Probleme und Siege, die während der Iteration erzielt wurden, klar verstehen. Gemeinsam erarbeitet die Gruppe Lösungen und einen Aktionsplan, um Prozessprobleme im nächsten Sprint zu verhindern und zu identifizieren.

Die besten Tipps

• Konzentrieren Sie sich sowohl auf Fakten als auch auf Gefühle
• Sammeln Sie Informationen, die Ihnen helfen, sich auf kontinuierliche Verbesserungen zu konzentrieren — dazu können Tools und Beziehungen gehören
• Seien Sie ehrlich und fördern Sie Ideen, die prozessbezogene Probleme lösen
• Auch wenn alles gut gelaufen ist, sollten Sie dieses Meeting abhalten — Rückblicke geben fortlaufende Hinweise für den nächsten Sprint.

„Angesichts der Tatsache, dass sich die Geschwindigkeit des Wandels voraussichtlich fortsetzen wird, war der Bedarf an einem Betriebsmodell, das Schritt hält, noch nie so groß wie heute. „- McKinsey

Agile Lektionen, nach denen man leben kann

Als Team von erfahrenen agilen Praktikern haben wir einige wichtige Erkenntnisse darüber gewonnen, was es braucht, um das Beste aus Ihren agilen Zeremonien herauszuholen und die Grundlagen für eine wirklich agile Organisation zu schaffen.

Hier sind unsere Top-Tipps, um Ihre Zeremonien zum Erfolg zu führen:

• Sei bewusst präsent - Denken Sie daran, sich während der Zeremonien einen Moment Zeit zu nehmen, um innezuhalten und sich daran zu erinnern, warum Sie dort sind. Zeigen Sie anderen, dass Sie anwesend sind, indem Sie ihnen volle Aufmerksamkeit schenken und Ihre Körpersprache verwenden. Richten Sie Ihre Kamera aus der Ferne so aus, als ob Sie ihnen gegenüber sitzen würden, schauen Sie regelmäßig in das Objektiv und verwenden Sie einen ablenkungsfreien Hintergrund.
• Übe aktives Zuhören - Denke darüber nach, was die Person sagt, wer sie ist und was sie von dir braucht. Suchen sie nach einem Resonanzboden, brauchen sie deine Hilfe oder Meinung oder suchen sie nach einer emotionalen Verbindung?
• Motive verstehen - Verstehe die Beweggründe deiner Teamkollegen, bevor du sprichst. Überlege, warum sie sich für das, was du sagst, interessieren sollten, indem du deine Botschaft mit ihren eigenen Beweggründen verbindest. Bieten Sie nach Möglichkeit einen Kontext an, damit sie wissen, warum Ihre Botschaft wichtig ist.
• Sei flexibel - Es ist wichtig, sich daran zu erinnern, dass es für agile Arbeitsweisen kein Patentrezept gibt. Was für ein Team funktioniert, funktioniert möglicherweise nicht für ein anderes. Sie müssen also experimentieren, um herauszufinden, was funktioniert, und dann die Prozesse an die Bedürfnisse Ihres Teams anpassen.
• Kulturelle Ausrichtung schaffen - Die besten Prozesse der Welt werden nicht das liefern, was Sie brauchen, wenn Sie nicht über die Kultur verfügen, die sie unterstützt. Agile Zeremonien müssen von einer Kultur unterstützt werden, in der sich die Mitarbeiter aktiv engagieren, selbstbewusst sind, Probleme anzusprechen, und Wert auf kontinuierliche Verbesserung legen.

Agile Zeremonien führen zu besseren Ergebnissen

Es kann zwar einige Zeit dauern, bis sich Teams, die noch nicht mit Agile vertraut sind, an agile Zeremonien gewöhnt haben, aber sie sind die Mühe wert. Durch die Bereitstellung einer klaren Struktur und erreichbarer Ergebnisse tragen sie dazu bei, dass sich alle Beteiligten auf das Produkt, die Kommunikation und die Prioritäten konzentrieren.

Das Ergebnis? Agile Teams, die schneller qualitativ bessere Produkte liefern — und echte Geschäftsergebnisse liefern.

Wo auch immer sich Ihr Unternehmen auf Ihrem Weg zur Agilität befindet, es lohnt sich zu bedenken, dass jedes Team und jede Produktsuite anders sind. Es gibt also kein einheitliches Erfolgsrezept. Die gute Nachricht ist, dass auch Sie Ihre agilen Zeremonien im Laufe der Zeit wiederholen und verbessern können, indem Sie innerhalb der Denkweise der kontinuierlichen Verbesserung arbeiten, die das agile Framework fördert.

Bereit loszulegen?

Einfacher agiler Teamrhythmus unterstützt die agilen Praktiken deines Teams in Jira. TeamRhythm unterstützt dein Team von der Planung bis hin zur Retrospektive und hilft dir dabei, besser zusammenzuarbeiten, um deinen Kunden einen Mehrwert zu bieten.

Zu den Funktionen gehören:

• Agiles Tool zur Sprint- und Versionsplanung - Die Planung ist schnell und einfach, wenn Sie Probleme auf der Storymap erstellen und abschätzen. Sieh dir deine Arbeit unter Initiativen und Epen an und sieh dir die Swimlane-Statistiken auf einen Blick an. So stellst du sicher, dass die Teamkapazitäten voll, aber nicht überlastet sind
• Agiles Story-Mapping - Bilden Sie die Kundenreise anhand von Initiativen, Epen und Geschichten zusammen mit Ihren agile Jira-Boards. Fügen Sie der Story-Map schnell und einfach neue oder vorhandene Geschichten hinzu. Ziehen Sie per Drag-and-Drop, um Prioritäten nach dem Wert für den Kunden zu setzen.
• Verfeinerung des Produktbestands - Entfliehen Sie Ihrem flachen Backlog und sehen Sie sich Ihre Arbeit in der Storymap-Matrix an. Ziehen Sie Probleme per Drag-and-Drop, um sie zu priorisieren oder zu planen. Mithilfe der Inline-Bearbeitung können Sie Zusammenfassungen und Schätzungen zu Storypoints im Handumdrehen aktualisieren, um den Backlog zu verbessern.
• Team-Retrospektiven - Feiern Sie Erfolge, gewinnen Sie Erkenntnisse und teilen Sie Ihre Erkenntnisse mit Team-Retrospektiven für Scrum und Kanban. So fördern Sie Zusammenarbeit und Transparenz, sodass Sie und Ihr Team kontinuierlich besser werden.