Die Agile Projektmanagement knacken

Obwohl Agile die Menschen von der Angst befreit, zu viel in eine dumme Entscheidung zu investieren, kann es ziemlich verwirrend sein, es anzuwenden.

In diesem Artikel werden Sie lernen:

• Unterschiede zwischen Scrum und Kanban-Board

• Schritt-für-Schritt-Anleitung zur Einrichtung von Agile in Ihrem Team

• Tipps, um Fallstricke in jedem Schritt zu vermeiden.

Agile Projektmanagement unterscheidet sich von traditionellen Methoden durch die Betonung der kurzen Rückmeldeschleifen und adaptiven Zyklen. Durch kontinuierliche Bereitstellung von Inkrementen glauben die Befürworter, dass der Agile-Prozess anpassungsfähiger an den Kundenwert und die Bedürfnisse ist.

Es wurde in den 1990er Jahren eingeführt, um die schwerfälligen Wasserfallmethoden zu ersetzen. Es fördert kontinuierliche Verbesserungen. Die frühen 2000er Jahre waren ein Meilenstein für Agile-Methoden. 10 angesehene Praktiker, darunter Jeff Sutherland, haben gemeinsam das berühmte Manifest für Agile Softwareentwicklung präsentiert.

Seitdem haben sich viele Abweichungen entwickelt. Scrum, Extreme Programming (XP), Feature-Driven-Development (FDD) und Test-Drive-Development (TDD) sind nur einige davon. Unabhängig von den Namen bleiben die grundlegenden Prinzipien jedoch gleich –> das Geschäft durch iterative Entwicklung, verkürzte Rückmeldeschleifen und adaptive Planung zu "entrisikieren".

Unter all diesen Rahmenwerken ist Scrum das beliebteste. Ein vollständiger Zyklus umfasst fünf Phasen: Visionierung, Sprint-Planungsmeeting, täglicher Sprint, Lieferung und Retrospektive. Dieser Artikel wird sich auf das Scrum-Rahmenwerk konzentrieren.

Aber zuerst…

Was sind die Unterschiede zwischen Scrum und Kanban

Bevor wir mit der Anleitung beginnen, lassen Sie uns zwei häufig verwendete Begriffe klären:

Scrum ist ein Rahmenwerk, ein Prozess

Ein Agile-Rahmenwerk, das für kleine Teams entworfen wurde, um ihre Arbeit in Aktionen zu unterteilen, die innerhalb von zeitlich festgelegten Iterationen, den sogenannten Sprints, abgeschlossen werden können, die normalerweise zwei Wochen dauern. Das Team verfolgt den Fortschritt und plant in 15-minütigen Steh-auf-Besprechungen, die tägliche Scrums genannt werden, neu.

Kanban ist eine Visualisierungsmethode für Aufgaben

Eine schlanke Methode zur Verwaltung und Verbesserung von Arbeiten, indem Arbeitsgegenstände visualisiert werden, um den Teilnehmern einen Überblick über die Anforderungen und die verfügbare Kapazität zu geben. Die Sammlungen visuell dargestellter Elemente werden Kanban-Board genannt. Das Board wird auch in Scrum verwendet.

Kanban und Scrum sind zwei Methoden. Aber aufgrund der Verbreitung und Effektivität des Kanban-Boards übernehmen die Scrum-Rahmenwerke manchmal dieses Tool ebenfalls. Neben den oben genannten Begriffen können Sie auch mehr Agile-Glossar auf AgileAlliance überprüfen.

Wie man die Agile-Praxis einrichtet

Schritt 1: Vorbereitung - Bauen Sie Ihr Team auf

Typischerweise besteht ein Agile-Team aus drei Rollen: dem Scrum Master (SM), dem Product Owner (PO) und den Entwicklern. Die Teamgröße beträgt etwa 7(+/-2): 1 Scrum Master, 1 Product Owner und 3-5 Entwickler.

Der Scrum Master steht auf der Entwicklerseite, um sicherzustellen, dass das Projekt reibungslos und hoffentlich schneller verläuft. Er/Sie sollte ein Mediator oder Facilitator als eigenständige Rolle sein. Je nach den Interessen des Teams kann der technische Leiter oder QA jedoch auch als Teilzeit-Scrum Master gut funktionieren.

Der Product Owner steht auf der Projekt- und Benutzersseite. Der Product Owner sind die Geschäftsleute und Kundenvertreter. Folglich sind Product Owner häufig Produktmanager oder Marketingexperten.

Beste Praxis: Vermeiden Sie ernste Konflikte

Kooperieren, aber nicht konkurrieren.

Der Scrum Master und der Product Owner haben einen unterschiedlichen Fokus und können in ernste Konflikte geraten. Aber denken Sie daran, dass Teamarbeit das Ziel sein sollte, Dinge gemeinsam zu erreichen. Der Zweck der drei Rollen ist es, das Team voll funktionsfähig zu machen. Deshalb plant jeder im Team zusammen.

Schritt 2: Visionierung - Bereiten Sie das Produkt-Backlog vor

Der Product Owner ist der Hauptbeitragende in dieser Phase. Er/Sie spricht mit Stakeholdern und synthetisiert ein Produkt-Feature-Backlog. Stakeholder sind in der Regel die Führungskräfte, das Vertriebs- und Supportteam, das Marketingteam sowie Benutzer oder Kunden.

Der PO muss das Backlog pflegen und die Features priorisieren. Und aus diesem riesigen Backlog formuliert er/sie Visionen und nachfolgende Ziele.

Beste Praxis: Vermeiden Sie das mühselige

Automatisieren Sie den mühsamen Prozess.

Das Füllen des Produkt-Backlogs ist manchmal eine mühsame Aufgabe. Das Sammeln und Verfolgen von Verfahren kann sehr repetitiv sein. Für Bugfixes kann der PO das Backlog mit einem Bug-Tracking-System verbinden. Kommentierungs-Tracking-Tools und eine Social-Media-Management-Plattform sind ebenfalls hilfreich.

Schritt 3: Meeting - Halten Sie das Sprint-Planungsmeeting ab

Das Meeting bringt klare Sprintziele und Sprint-Backlogs hervor. Es dauert normalerweise weniger als eine Stunde und findet früh in der Sprintwoche(n) statt. Basierend auf den Produktzielen und Produkt-Backlogs arbeitet das Team zusammen daran, Backlogs in versandfähige Inkremente zu unterteilen.

Die Entwickler entscheiden über die geeignete Anzahl von Storypoints, wie das Ziel in Aufgaben unterteilt werden kann, und damit über das Sprint-Backlog. Am Ende des Meetings sollte das Team Vertrauen in den Umfang und die gewünschten Ergebnisse dieses Sprints haben.

Beste Praxis: Vermeiden Sie vage Ziele

Geben Sie klare Erwartungen für die Sprint-Lieferungen an.

Das Sprintziel besteht NICHT nur aus ein oder zwei zufälligen Sätzen, sondern gibt den Stakeholdern die Erwartungshaltung in Bezug auf die Lieferungen. Es funktioniert als schneller Bericht für die Stakeholder darüber, was das Team tut. Ein klares Sprintziel ebnet den Weg für die Messung der Leistung der Lieferung.

Schritt 4: Tägliches Scrum - Überprüfen Sie den Fortschritt

Das tägliche Scrum (tägliches Stand-up) Meeting dient zur Aktualisierung des Projektstatus. Es ist am besten, das Meeting zur gleichen Zeit und am gleichen Ort jeden Tag während der Iteration abzuhalten. Das tägliche Stand-up zeigt Agiles Augenmerk auf persönliche Kommunikation.

Der Scrum Master sollte die Hindernisse ansprechen, um den Entwicklungsprozess zu erleichtern. Wenn es etwas gibt, das das Sprintziel erheblich beeinträchtigt, hat der PO das Recht, dies sofort zu erfahren. Im Gegenzug sollte der PO der Versuchung widerstehen, das Sprint-Backlog zu ändern.

Beste Praxis: Vermeiden Sie lange Meetings

Halten Sie jedes Stand-up-Meeting unter 15 Minuten. Beachten Sie, dass das Meeting wie eine Informationssynchronisierung innerhalb des Teams ist und nicht zur Problemlösung dient. Es ist besser, die Problemlösung in anderen Prozessen zu belassen.

Schritt 5: Versand - Veröffentlichung und Retrospektive

Die Veröffentlichung des Teams wird am Ende der Iteration demonstriert. Stakeholder, innerhalb oder außerhalb der Organisation, sind im Überprüfungsmeeting. Indem die Gesamtziele des Sprints mit den Ergebnissen verglichen werden, kann der Product Owner messen, wie erfolgreich der Sprint ist.

Nach dem Überprüfungsmeeting hält das Agile-Team ein Retrospektive-Meeting ab, um darüber nachzudenken, was verbessert werden sollte und was fortgesetzt werden sollte. Für neuere Entwickler ist es auch eine perfekte Gelegenheit, die Erwartungen an Geschwindigkeit und Kapazität zu überarbeiten.

Beste Praxis: Überspringen Sie niemals die Retrospektive

Selbst wenn nichts schiefgeht, sollte das Team niemals die Retrospektive auslassen. Zu bestätigen, was richtig ist, ist hilfreich für zukünftige Sprints. Wenn der SM möchte, kann er/sie sogar eine Abstimmung über Verbesserungsvorschläge einleiten.

Was sind die Einschränkungen von Agile

Befürworter behaupten, dass Agile-Praktiken ein Gleichgewicht zwischen Mikromanagement und Nicht-Management sind. Kritiker entstehen jedoch aus Erfahrungen bei der Einführung. Einige empirische Studien haben keine wissenschaftlichen Beweise für die Agilität des Teams gefunden.

Da Agile Flexibilität betont, hat es einen Preis in Bezug auf kontinuierliche Qualitätskontrolle. Die verkürzte Projektdauer erfordert schnelles und schlankes Handeln. Das kommt oft mit einem Mangel an ordnungsgemäßer Dokumentation und Ressourcen. Projekte neigen dazu, an Kontinuität und Integrität zu mangeln, was das Prinzip des Fokus auf Qualität fast obsolet macht.

Agile ist für stark risikoscheue Organisationen oder Branchen, sagen wir, Pharmaunternehmen, nicht geeignet. Diese langjährig etablierten Branchen haben ihre schwerfälligen, aber dennoch wichtigen Konventionen zu befolgen. Änderungen von Verfahren gegen das traditionelle Management sind extrem riskant, wenn nicht sogar gefährlich.

Das gesagt, unzählige erfolgreiche Beispiele sind der Beweis, dass Agile funktioniert. Obwohl es Fallstricke gibt, bieten die sich ständig weiterentwickelnden Agile-Rahmenwerke Werkzeuge und Techniken, wie kontinuierliche Integration (CI/CD), automatisierte Unit-Tests und Code-Refactoring, um zumindest die Probleme zu mildern.

Wichtigste Erkenntnis

Der Agile-Prozess befürwortet schnelle Iterationen, kontinuierliche Verbesserung und schnelle Reaktionen auf Veränderungen. Er besteht hauptsächlich aus fünf Schritten: Visionierung, Sprint-Planung, täglichem Scrum, Versand und Retrospektive.

Diese Methode zielt darauf ab, ein Gleichgewicht zwischen traditionellen Methoden und losem Management zu schaffen. Obwohl es an starken Beweisen mangelt und Fallstricke hat, hat der Agile-Prozess seine Punkte, um erfolgreich zu sein.

Was halten Sie davon? Tweeten Sie mir, um Ihre Erfahrungen und Tricks bei der Anwendung von Agile-Methoden zu teilen :).