Projektmanagement im Vergleich: Agile vs. Scrum vs. Wasserfall vs. Kanban – was ist der Unterschied?

By Kate Eby | 15. Februar 2017

Im Laufe eines Projekts werden Hunderte Entscheidungen getroffen. Eine der ersten Entscheidungen ist die Auswahl der anzuwendenden Projektmanagementmethode.

Agile vs. Wasserfall, Scrum oder Kanban – es gibt zahlreiche Unterschiede bei Projektmanagement-Frameworks. Einige, wie Scrum oder Wasserfall, folgen einer starreren, strukturierteren Methode. Andere, wie Kanban oder Agile, lassen sich bei bestehenden Prozessen leichter einführen und implementieren. Sie alle haben Vor- und Nachteile. Wie entscheiden Sie also, welche sie auswählen sollen?

Dieser Artikel behandelt die Unterschiede von Agile vs. Wasserfall vs. Scrum vs. Kanban. Wir sprechen über die Vorteile, Nachteile, Phasen und wann die einzelnen Methoden verwendet werden sollten.

Agile-Methode

Was ist Agile?

Die Basis agiler Softwareentwicklung ist ein inkrementeller, iterativer Ansatz. Statt einer detaillierten Planung zu Beginn des Projekts sind agile Methoden sich im Laufe der Zeit ändernden Anforderungen gegenüber offen und fördern ständiges Feedback von Endbenutzern. Funktionsübergreifende Teams arbeiten über einen bestimmten Zeitraum an Iterationen eines Produkts. Diese Arbeit wird in einem Backlog organisiert, das nach Geschäfts- oder Kundenwert priorisiert wird. Das Ziel jeder Iteration ist es, ein funktionierendes Produkt zu produzieren.

Bei agilen Methoden fördert die Unternehmensführung Teamarbeit, Verantwortung und persönliche Kommunikation. Business-Stakeholder und Entwickler müssen zusammenarbeiten, um das Produkt an die Kundenbedürfnisse und Unternehmensziele anzupassen. 

Agile bezieht sich auf jeden Prozess, der den Konzepten des Agile-Manifests entspricht. Im Februar 2001 trafen sich 17 Softwareentwickler in Utah, um über schlanke Entwicklungsmethoden zu diskutieren. Sie veröffentlichten das Manifest für Agile Softwareentwicklung , in dem es darum ging, wie sie „bessere Wege zur Entwicklung von Software finden, indem man es tut und anderen hilft, es zu tun“ und vier Werte sowie 12 Prinzipien enthielt. Das Agile-Manifest ist ein dramatischer Kontrast zum traditionellen Text A Guide to the Project Management Body of Knowledge (PMBOK® Guide) und anderen Standards.

Project Management Guide

Your one-stop shop for everything project management

the 101 guide to project management

Ready to get more out of your project management efforts? Visit our comprehensive project management guide for tips, best practices, and free resources to manage your work more effectively.

View the guide

12 Prinzipien der Agile-Methode

Das Agile-Manifest zählt 12 Prinzipien auf, die Teams bei der Umsetzung mit agilen Methoden Hilfestellung geben. Dies sind die Prinzipien:

  1. Die oberste Priorität ist, den Kunden durch frühzeitige und kontinuierliche Lieferung wertvoller Software zufriedenzustellen.
  2. Begrüßen Sie sich ändernde Anforderungen auch in späten Phasen der Entwicklung. Agile Prozesse nutzen Änderungen als Wettbewerbsvorteil für den Kunden.
  3. Liefern Sie funktionierende Software alle paar Wochen bis alle paar Monate, bevorzugt alle paar Wochen.
  4. Geschäftsleute und Entwickler müssen das gesamte Projekt über täglich zusammenarbeiten.
  5. Richten Sie Projekte an motivierten Einzelpersonen aus. Geben Sie ihnen die nötige Umgebung und Unterstützung und vertrauen Sie darauf, dass sie die Arbeit erledigen werden.
  6. Die effizienteste und effektivste Methode zur Vermittlung von Informationen an und innerhalb eines Entwicklungsteams ist ein persönliches Gespräch.
  7. Funktionierende Software ist der Hauptmaßstab für Fortschritt.
  8. Agile Prozesse fördern nachhaltige Entwicklung. Die Sponsoren, Entwickler und Benutzer sollten in der Lage sein, stets ein konstantes Tempo beizubehalten.
  9. Ein kontinuierliches Augenmerk auf technische Exzellenz und gutes Design erhöht die Agilität.
  10. Einfachheit – die Kunst, nicht zu erledigende Arbeit zu maximieren – ist unerlässlich.
  11. Selbstorganisierte Teams produzieren die besten Architekturen, Anforderungen und Designs.
  12. Das Team überlegt regelmäßig, wie es effektiver werden kann und passt sein Verhalten entsprechend an. 

Vorteile von Agile

Agile entstand in den 1990er-Jahren aus verschiedenen schlanken Softwareansätzen und ist eine Reaktion auf die Abneigung einiger Projektmanager gegenüber der starren, linearen Wasserfall-Methode. Es legt den Fokus auf Flexibilität, kontinuierliche Verbesserung und Geschwindigkeit. 

Hier sind einige der größten Vorteile von Agile vs. andere Methoden wie z. B. Wasserfall:

  • Veränderung wird angenommen: Dank der kürzeren Planungszyklen ist es leicht, Änderungen während des Projekts zu akzeptieren und sich an sie anzupassen. Es gibt immer die Möglichkeit, das Backlog zu verfeinern und Prioritäten zu ändern, sodass Teams innerhalb von wenigen Wochen Änderungen am Projekt vornehmen können.
     
  • Endziel kann unbekannt sein: Agile ist sehr vorteilhaft für Projekte, bei denen das Endziel nicht klar definiert ist. Die Ziele treten im Laufe des Projekts zutage und die Entwicklung kann leicht an diese sich entwickelnden Anforderungen angepasst werden.
     
  • Schnellere, qualitativ hochwertige Lieferung: Die Aufschlüsselung des Projekts in Iterationen (überschaubare Einheiten) ermöglicht es dem Team, sich auf qualitativ hochwertige Entwicklung, Tests und Zusammenarbeit zu konzentrieren. Die Durchführung von Tests während jeder Iteration sorgt dafür, dass Fehler schneller identifiziert und behoben werden. Außerdem kann die hochwertige Software dann mit konsistenten, aufeinanderfolgenden Iterationen schneller geliefert werden.
     
  • Gute Teaminteraktion: Agile hebt die Bedeutung häufiger Kommunikation und persönlicher Interaktionen hervor. Teams arbeiten zusammen und Personen können Verantwortung und Teile der Projekte übernehmen.
     
  • Kunden werden gehört: Kunden haben viele Möglichkeiten, die gelieferte Arbeit zu sehen, ihren Input zu geben und einen echten Einfluss auf das Endprodukt zu haben. Sie können durch die enge Zusammenarbeit mit dem Projektteam ein Gefühl der Inhaberschaft spüren.
     
  • Kontinuierliche Verbesserung: Agile Projekte fördern Feedback von Benutzern und Teammitgliedern während des gesamten Projekts, sodass gewonnene Erkenntnisse der Verbesserung künftiger Iterationen dienen können.

Tipps und Best Practices für Ihr nächstes Projekt mit der Agile-Methode.

Agile PM Ebook

 

Erfahren Sie alles über agiles Projektmanagement und Tipps, die Ihnen helfen, bewährte Vorgehensweisen für agiles Projektmanagement zu implementieren

 

Kostenloses E-Book zur Implementierung der Best Practices für Agile sichern

Nachteile von Agile

Die Flexibilität ist im Vergleich von beispielsweise Agile vs. Wasserfall oder Scrum zwar in der Regel positiv, geht aber auch mit einigen Kompromissen einher. Es kann schwierig sein, einen festen Liefertermin festzulegen, die Dokumentation kann vernachlässigt werden oder das Endprodukt kann sich stark von der ursprünglichen Idee unterscheiden. 

Dies sind einige Nachteile von Agile:

  • Planung kann weniger konkret sein: Manchmal kann es schwierig sein, ein festes Lieferdatum festzulegen. Da Agile auf Lieferung in engen Zeitfenstern basiert und Projektmanager Aufgaben oft neu priorisieren, ist es möglich, dass einige Elemente zur ursprünglich geplanten Lieferung nicht rechtzeitig abgeschlossen sind. Außerdem können dem Projekt jederzeit zusätzliche Sprints hinzugefügt werden, was den Gesamtzeitplan vergrößert.
     
  • Team muss sachkundig sein: Agile-Teams sind in der Regel klein, Teammitglieder müssen also in einer Vielzahl von Bereichen qualifiziert sein- Zusätzlich müssen Sie die gewählte Agile-Methode verstehen und mit ihr vertraut sein. 
     
  • Vollständige Widmung der Entwickler: Agile ist am erfolgreichsten, wenn sich das Entwicklungsteam nur auf ein Projekt konzentriert. Der Agile-Prozess erfordert von Anfang bis Ende aktive Beteiligung und Zusammenarbeit, was ihn zeitaufwendiger als einen herkömmlichen Ansatz macht. Das bedeutet auch, dass sich Entwickler für die Dauer des Projekts binden müssen.
     
  • Dokumentation kann vernachlässigt werden: Das Agile-Manifest stellt funktionierende Software über umfassende Dokumentation, einige Teammitglieder könnten also der Ansicht sein, dass die Dokumentation nicht so wichtig ist. Eine umfassende Dokumentation allein führt zwar nicht zum Projekterfolg, aber Agile-Teams sollten dennoch das richtige Gleichgewicht zwischen Dokumentation und Diskussion finden.
     
  • Endprodukt kann anders sein: Am Anfang des Agile-Projekts gibt es möglicherweise keinen endgültigen Plan, sodass sich das Endprodukt stark vom ursprünglich beabsichtigten Produkt unterscheidet. Da Agile so flexibel ist, können auf Grundlage sich ändernden Kundenfeedbacks neue Iterationen hinzugefügt werden, was zu einer ganz anderen endgültigen Leistung führen kann. 

Der Agile-Entwicklungszyklus

 


Dies sind die Phasen des Agile-Entwicklungszyklus. Beachten Sie, dass diese Phasen nicht nacheinander ausgeführt werden sollten. Sie sind flexibel und entwickeln sich ständig weiter. Viele dieser Phasen verlaufen parallel.  

  • Planung: Sobald eine Idee als brauchbar und machbar angesehen wird, kommt das Projektteam zusammen und identifiziert Funktionen. Das Ziel dieser Phase ist, die Idee in kleinere Arbeitsteile (die Funktionen) aufzuschlüsseln und dann jeder Funktion eine Priorität zu geben und sie einer Iteration zuzuweisen. 
     
  • Anforderungsanalyse: In dieser Phase finden viele Meetings mit Managern, Stakeholdern und Benutzern statt, um Geschäftsanforderungen zu identifizieren. Das Team muss Informationen sammeln, wie zum Beispiel wer das Produkt verwendet und wie es verwendet wird. Diese Anforderungen müssen quantifizierbar, relevant und detailliert sein.
     
  • Design: Das System- und Softwaredesign basiert auf den Anforderungen, die in der vorherigen Phase identifiziert wurden. Das Team muss sich vorstellen, wie das Produkt oder die Lösung aussehen wird. Das Testteam entwickelt auch eine Teststrategie oder einen Plan zur weiteren Vorgehensweise.
     
  • Implementierung, Codierung oder Entwicklung: In dieser Phase geht es um das Erstellen und Testen von Funktionen und die Planung der Bereitstellung von Iterationen (gemäß dem iterativen und inkrementellen Entwicklungsansatz [IID]). Die Entwicklungsphase beginnt mit Iteration 0, da noch keine Funktionen bereitgestellt wurden. Diese Iteration bildet mit Aufgaben wie dem Abschluss von Verträgen, der Vorbereitung der Umgebungen und der Finanzierung die Grundlage für die Entwicklung.
     
  • Tests: Sobald der Code programmiert wurde, wird er anhand der Anforderungen getestet, um sicherzustellen, dass das Produkt tatsächlich die Kundenbedürfnisse erfüllt und mit User Storys übereinstimmt. In dieser Phase werden Komponententests, Integrationstests, Systemtests und Abnahmetests durchgeführt.
     
  • Bereitstellung: Nach den Tests wird das Produkt zur Verwendung an die Kunden geliefert. Die Bereitstellung ist jedoch nicht das Ende des Projekts. Sobald Kunden das Produkt verwenden, können neue Probleme auftreten, die das Projektteam lösen muss.

Methoden zur Implementierung von Agile

Agile ist ein Framework und innerhalb der Agile-Bewegung gibt es eine Reihe spezifischer Methoden. Sie können sich diese als verschiedene Sorten von Agile vorstellen:

  • Extreme Programming (XP): Extreme Programming, auch XP genannt, ist eine Art der Softwareentwicklung, deren Ziel die Verbesserung der Qualität und Reaktionsfähigkeit auf sich entwickelnde Kundenanforderungen ist. Zu den Prinzipien von XP gehören Feedback, die Annahme von Einfachheit und das Aufgreifen von Änderungen.
     
  • Feature-Driven Development (FDD): Dieser iterative und inkrementelle Softwareentwicklungsprozess kombiniert Best Practices der Branche zu einem Ansatz. In FDD gibt es fünf grundlegende Aktivitäten: Gesamtmodell entwickeln, Funktionsliste erstellen, nach Funktion planen, nach Funktion entwerfen und nach Funktion entwickeln.
     
  • Adaptive System Development (ASD): Das Adaptive System Development vertritt die Idee, dass Projekte immer in einem Zustand der kontinuierlichen Anpassung sein sollten. ASD besteht aus einem Zyklus drei sich wiederholender Aktivitäten: spekulieren, zusammenarbeiten und lernen.
     
  • Dynamic Systems Development Method (DSDM): Dieses Agile-Framework für die Bereitstellung von Projekten wird für die Entwicklung von Software und Nicht-IT-Lösungen verwendet. Es adressiert die gängigen Defizite von IT-Projekten wie Budgetüberschreitungen, verpasste Fristen und mangelnde Benutzerbeteiligung. Die acht Prinzipien von DSDM sind: Konzentrieren Sie sich auf die Geschäftsbedürfnisse, liefern Sie pünktlich, arbeiten Sie zusammen, gehen Sie niemals Kompromisse bei der Qualität ein, entwickeln Sie von einer festen Grundlage aus schrittweise, entwickeln Sie iterativ, kommunizieren Sie kontinuierlich und klar und bleiben Sie in Kontrolle. 
     
  • Lean Software Development (LSD): Lean Software Development bedient sich der Prinzipien der Lean-Fertigung und Lean-IT und wendet sie auf die Softwareentwicklung an. Es wird durch sieben Prinzipien charakterisiert: Eliminieren Sie Verschwendung, legen Sie den Fokus auf das Lernen, treffen Sie Entscheidungen so spät wie möglich, liefern Sie so schnell wie möglich, befähigen Sie das Team, setzen Sie auf Integrität und sehen Sie das große Ganze.
     
  • Kanban: Kanban, japanisch für „visuelles Zeichen“ oder „Karte“, ist ein visuelles Framework zur Implementierung von Agile. Es propagiert kleine, kontinuierliche Änderungen an Ihrem aktuellen System. Die Prinzipien umfassen: Visualisieren Sie den Workflow, setzen Sie eine Grenze für laufende Arbeiten, verwalten und verbessern Sie den Ablauf, legen Sie Richtlinien explizit fest und verbessern Sie sich kontinuierlich.
     
  • Crystal Clear: Crystal Clear ist Teil der Familie der Crystal-Methoden. Die Methode kann von Teams mit sechs bis acht Entwicklern verwendet werden und legt den Fokus auf die Personen anstatt der Prozesse oder Artefakte. Crystal Clear dreht sich um die häufige Bereitstellung von nutzbarem Code an Benutzer, reflexive Verbesserung und osmotische Kommunikation, vorzugsweise durch die Arbeit an einem Standort.
     
  • Scrum: Scrum ist einer der gängigsten Wege, Agile zu implementieren. Dabei handelt es sich um ein iteratives Softwaremodell, das eine Reihe dauerhafter Rollen, Verantwortlichkeiten und Meetings umfasst. Sprints, die in der Regel ein bis zwei Wochen dauern, ermöglichen dem Team, regelmäßig Software bereitzustellen.

Andere Verfahren in Agile

Es gibt viele andere Praktiken und Frameworks, die mit Agile zusammenhängen. Dazu gehören:

  • Agile Modeling (AM): Agile Modeling wird verwendet, um Softwaresysteme zu modellieren und zu dokumentieren und ist eine Ergänzung zu anderen Agile-Methoden wie Scrum, Extreme Programming (XP) und Rational Unified Process (RUP). AM ist kein eigenständiger Softwareprozess und kann helfen, Modelle mithilfe von Code zu verbessern, aber es umfasst keine Programmieraktivitäten. 
     
  • Rational Unified Process (RUP): RUP wurde von der Rational Software Corporation, einer Abteilung der IBM, entwickelt und ist ein iteratives, adaptives Framework für die Softwareentwicklung. Laut Rational ist RUP wie ein Online-Mentor, der Richtlinien, Vorlagen und Beispiele für die Programmentwicklung bereitstellt. Zu den wichtigsten Aspekten von RUP gehören ein risikoorientierter Prozess, eine auf Anwendungsfälle fokussierte Entwicklung und ein architekturorientiertes Design.
     
  • Lean vs. Agile: Die Lean-Entwicklung konzentriert sich auf das Eliminieren und Reduzieren von Verschwendung (Aktivitäten, die keinen Mehrwert bieten). Lean Software Development bedient sich der Prinzipien der Lean-Fertigung und wendet sie auf die Softwareentwicklung an. Diese Prinzipien ähneln Agile sehr, aber Lean geht noch einen Schritt weiter. In der Entwicklungsphase wird nur eine Funktion ausgewählt, geplant, entwickelt, getestet und bereitgestellt, bevor der Prozess für die nächste Funktion wiederholt wird.
     
  • Test-Driven Development (TDD): TDD beruht auf repetitiven, kurzen Entwicklungszyklen. Zunächst programmiert ein Entwickler einen (anfangs misslingenden) automatisierten Testfall für eine neue Funktion und fügt schnell einen Test mit der minimalen Menge an Code zum Bestehen des Testfalls hinzu. Dann arbeitet er den neuen Code akzeptablen Standards gemäß um. 
     
  • Scaled Agile Framework (SAFe-Markenlogo): Das Scaled Agile Framework ist eine sehr strukturierte Methode, die großen Unternehmen den Einstieg in Agile erleichtert. SAFe basiert auf Lean- und Agile-Prinzipien und befasst sich mit schwierigen Problemen in großen Organisationen, wie Architektur, Integration, Finanzierung und Rollen in großem Maßstab. SAFe hat drei Ebenen: Team, Programm und Portfolio. 
     
  • Rapid Application Development (RAD): Bei RAD wird in der Softwareentwicklung mehr Wert auf die Entwicklung als auf die Planung von Aufgaben gelegt. Es läuft nach einem inkrementellen Modell ab, bei dem jede Komponente parallel entwickelt wird. Die Phasen von RAD sind: Geschäftsmodellierung, Datenmodellierung, Prozessmodellierung, Anwendungsgenerierung sowie Tests und Einsatz.
     
  • Empirische Steuerungsmethode: Bei der agilen Softwareentwicklung können Sie eine empirische Steuerungsmethode verwenden, was bedeutet, dass Sie Entscheidungen basierend auf der im Projekt ersichtlichen Realität treffen. Das empirische Modell der Prozesssteuerung besteht aus drei Teilen: Einblicke, Inspektion und Anpassung. 

Wie Sie Budgets für Agile schätzen

Ohne detaillierte Planung im Voraus sind sich viele Projektmanager nicht sicher, wie sie die Kosten und das Budget eines Agile-Projekts berechnen sollen. 

Die Kosten vor Projektbeginn abzuschätzen kann immer eine Herausforderung sein, egal welche Projektmethode Sie verwenden. Bei einem Agile-Projekt können Sie jedoch die Zeit, die das Projekt in Anspruch nehmen wird, mit den Gesamtkosten abgleichen. 

Erstellen Sie zunächst ein Burndown-Diagramm und verwenden Sie die Burndown-Rate, um die Anzahl der Sprints sowie das Ende des Projekts abzuschätzen. Berechnen Sie dann auf Grundlage der Stundensätze, wie hoch die Kosten für das Team sind. Multiplizieren Sie den Stundensatz der einzelnen Personen mit deren Anzahl an Arbeitsstunden pro Woche und multiplizieren Sie diesen Wert dann mit der Anzahl der Wochen in einem Sprint. Sobald Sie das anfängliche Budget für Ihr Team geschätzt haben, können Sie andere Kosten wie Technologie, Reisen oder Ausrüstung dazurechnen. 

Sie können auch jede User Story in Aufgaben aufschlüsseln. Sobald Sie eine Vorstellung davon haben, wie viele Stunden die einzelnen Aufgaben in Anspruch nehmen werden, können Sie das Projektbudget abschätzen. 

Zu guter Letzt können Sie Planning Poker verwenden, um den für Entwicklungsziele erforderlichen Aufwand abzuschätzen. Planning Poker ist eine konsensbasierte, spielerische Technik zur Schätzung des Aufwands für Entwicklungsziele. Jedes Teammitglied gibt Schätzungen ab, indem es nummerierte Karten verdeckt auf den Tisch legt, anstatt den Wert zu sagen. Die Karten werden dann aufgedeckt und die Schätzungen mit dem gesamten Team besprochen.

Agile und Paar-Programmierung

Paar-Programmierung (auch bekannt als „Pairing“) ist Teil der Extreme Programming (XP)-Verfahren. Dabei teilen sich zwei Programmierer einen Arbeitsplatz, einschließlich des Bildschirms, der Tastatur und der Maus. Der Zweck dieser Technik besteht darin, eine bessere Kommunikation, die Verdeutlichung des Problems und das Verständnis der Lösung zu fördern. Die Paar-Programmierung wird oft in Agile-Projekten verwendet, um schnell qualitativ hochwertige Produkte zu liefern, aber ist sie immer erforderlich? 

Die Antwort hängt von Ihren Programmierern, Ihrem Unternehmen und Ihren Zielen ab. Bei einigen Projekten und Programmierern kann die Paar-Programmierung die Produktivität steigern. Sie ist jedoch nicht zwangsläufig für jedes Projekt geeignet. Am besten experimentieren Sie und schauen, ob es für Sie funktioniert.

Wie Agile auf Softwareanforderungen reagiert

Agile hilft Entwicklungsteams, sich so schnell wie möglich auf die wichtigsten Kundenanforderungen zu konzentrieren. Mit kontinuierlichem Feedback und häufigen persönlichen Interaktionen können das Projektteam und die Stakeholder die richtigen Anforderungen ausmachen und priorisieren.

Agile-Teams verwenden Backlogs mit User Storys, um Anforderungen und Dokumente zu verwalten. Bevor eine Iteration beginnt, vereinbart das Team, welche Anforderungen mit der nächsten Lieferung erfüllt werden sollen. Dieser kollaborative Ansatz stellt sicher, dass die wichtigsten Funktionen priorisiert werden. Außerdem werden Anforderungen im Laufe des gesamten Projekts ständig aktualisiert, wenn neue Informationen aufkommen.

Kann man Agile für Projekte außerhalb von Software nutzen?

Obwohl Agile ursprünglich für die Softwareentwicklung geschaffen wurde, kann es auch in vielen anderen Projekten und Branchen Anwendung finden. 

Man sollte nicht vergessen, dass die agile Softwareentwicklung auf den Prinzipien der Lean-Fertigung und des organisatorischen Lernens beruht. Diese Ideen hatten nie mit Software zu tun. Außerdem sind viele Verfahren in Agile, wie z. B. Stand-up-Meetings und visuelles Management, sehr weit verbreitet und können in jeder Branche zum Einsatz kommen. 

Dennoch gibt es nur wenige Fallstudien von Teams, die Agile außerhalb der Softwareentwicklung verwenden. Zum Beispiel hat Kate Sullivan, Firmenanwältin in der Rechtsabteilung von The Lonely Planet, die Bereitstellung von Rechtsdienstleistungen mit Agile transformiert. Das Team nutzt Whiteboards und Karten, Stand-up-Meetings am Morgen, Priorisierung, wöchentliche Iterationen und regelmäßige Retrospektiven. 

Agile kann definitiv bei Projekten außerhalb der Softwareentwicklung angewendet werden, Sie müssen nur die richtige Methode und den richtigen Ansatz für Ihre Bedürfnisse finden. Sie können mit Boards und Karten, einem Arbeits-Backlog, Stand-up-Meetings oder Iterationen (wöchentlichen Planungsmeetings) anfangen, um zu sehen, wie Ihr Team reagiert. 

Erste Schritte mit Agile

Eine einfache Möglichkeit, die ersten Schritte mit Agile zu machen, ist, tägliche Stand-up-Meetings in Ihr Projekt zu integrieren. Tägliche Stand-up-Meetings lassen sich leicht in jede andere Projektmethodik integrieren, die Sie möglicherweise bereits verwenden (sogar Wasserfall) und erfordern weder Schulungen noch Wissenstransfer. Treffen Sie sich jeden Tag für etwa zehn Minuten am selben Ort und lassen Sie jeden darüber sprechen, woran sie am vorigen Tag gearbeitet haben, woran sie heute arbeiten werden und ob es Hindernisse gibt.

Wenn umgehend vollständig auf Agile umgestellt werden soll, sollten Sie zunächst verstehen, warum das Team und die Organisation diese Änderung vornehmen möchten. Was funktioniert und was nicht? Was soll verbessert werden? Dann können Sie eine Agile-Bewertung durchführen, um einen vollständigen Überblick über die eingesetzten Personen, Fähigkeiten und Technologien zu erhalten. 

Ganz gleich, für welchen Weg Sie sich entscheiden, denken Sie daran, dass Agile von Natur aus flexibel ist. Es gibt keinen falschen oder richtigen Weg für die Anwendung von Agile. Tun Sie, was für Sie und Ihr Team funktioniert.

Mit der neuen Kartenansicht in Smartsheet können Agile-Teams visueller arbeiten, kommunizieren und zusammenarbeiten. In der Kartenansicht können Sie mit umfangreichen Karten wichtige Dinge hervorheben, mit flexiblen Ansichten verschiedene Perspektiven beleuchten und Arbeit visueller priorisieren und anpassen. Sie können Informationen auf Karten darstellen, darunter anpassbare Felder, Bilder und farbliche Kennzeichnungen, um die Aufmerksamkeit Ihres Teams auf wichtige Dinge zu richten. Die Karten lassen sich in Bahnen anordnen, um Arbeit visueller zu organisieren. 

Weitere Informationen zu Smartsheet für die Softwareentwicklung

Scrum-Methode

Vorteile von Scrum

Scrum ist ein sehr verbindliches Framework mit bestimmten Rollen und Zeremonien. Sie müssen gegebenenfalls eine Menge lernen, aber diese Regeln haben viele Vorteile. Scrum bietet folgende Vorteile:

  • Mehr Transparenz und Projekteinblicke: Dank täglicher Stand-up-Meetings weiß das gesamte Team, wer was tut, wodurch viele Missverständnisse und Unklarheiten beseitigt werden. Probleme werden im Voraus identifiziert, sodass das Team sie lösen kann, bevor sie aus dem Ruder laufen.
     
  • Erhöhte Verantwortung des Teams: Es gibt keinen Projektmanager, der dem Scrum-Team sagt, was wann zu tun ist. Stattdessen entscheidet das Team gemeinsam, welche Arbeit in den einzelnen Sprints erledigt werden kann. Alle arbeiten zusammen und helfen sich gegenseitig, was die Zusammenarbeit verbessert und jedes Teammitglied befähigt, unabhängig zu sein. 
     
  • Änderungen werden einfacher angenommen: Durch kurze Sprints und ständiges Feedback ist es einfacher, Änderungen zu bewältigen und zu berücksichtigen. Wenn das Team beispielsweise während eines Sprints eine neue User Story entdeckt, kann es diese Funktion während des Meetings zur Verbesserung des Backlogs problemlos in den nächsten Sprint aufnehmen.
     
  • Erhöhte Kosteneinsparungen: Die ständige Kommunikation stellt sicher, dass sich das Team aller Probleme und Änderungen bewusst ist, sobald sie auftreten. Dadurch können die Ausgaben gesenkt und die Qualität erhöht werden. Die Programmierung und das Testen von Funktionen in kleineren Mengen liefert kontinuierliches Feedback und Fehler können frühzeitig korrigiert werden, bevor ihre Behebung zu kostspielig wird.

Nachteile von Scrum

Scrum bietet zwar einige konkrete Vorteile, hat aber auch einige Nachteile. Scrum erfordert ein hohes Maß an Erfahrung und Engagement des Teams und Projekte sind dem Risiko schleichenden Funktionszuwachses (Scope-Creep) ausgesetzt. 

Dies sind die Nachteile von Scrum:

  • Risiko schleichenden Funktionszuwachses (Scope-Creep): Bei einigen Scrum-Projekten kann es aufgrund eines fehlenden konkreten Enddatums zu Scope-Creep kommen. Ohne Abschlussdatum können Stakeholder in Versuchung kommen, immer wieder weitere Funktionen anzufordern. 
     
  • Team braucht Erfahrung und Engagement: Aufgrund der definierten Rollen und Verantwortlichkeiten muss das Team mit Scrum-Prinzipien vertraut sein, um erfolgreich zu sein. Da es im Scrum-Team keine definierten Rollen gibt (jeder macht alles), sind Teammitglieder mit technischer Erfahrung notwendig. Das Team muss auch an den täglichen Scrum-Meetings festhalten und für die Dauer des Projekts im Team bleiben.
     
  • Der falsche Scrum-Master kann alles ruinieren: Ein Scrum-Master unterscheidet sich sehr von einem Projektmanager. Der Scrum-Master hat keine Kontrolle über das Team. Er oder sie muss dem Team vertrauen und sollte ihm nie sagen, was zu tun ist. Wenn der Scrum-Master versucht, Kontrolle über das Team auszuüben, wird das Projekt scheitern.
     
  • Schlecht definierte Aufgaben können zu Ungenauigkeiten führen: Projektkosten und Zeitpläne können nicht genau sein, wenn die Aufgaben nicht klar definiert sind. Wenn die ursprünglichen Ziele unklar sind, wird die Planung erschwert und Sprints können mehr Zeit in Anspruch nehmen als ursprünglich angenommen.

Rollen in Scrum

 

Roles in scrum

Es gibt drei spezifische Rollen in Scrum. Diese sind:

  • Produktinhaber: Der Scrum-Produktinhaber (Product Owner) hat eine Vision davon, was er oder sie entwickeln möchte, und vermittelt diese Vision dem Team. Der Produktinhaber konzentriert sich auf die Geschäfts- und Marktanforderungen und legt die Priorität der zu erledigenden Arbeiten fest. Er oder sie erstellt und verwaltet das Backlog, empfiehlt, welche Funktionen als Nächstes geliefert werden sollen, und interagiert mit dem Team und anderen Stakeholdern, um sicherzustellen, dass jeder die Elemente im Produkt-Backlog nachvollziehen kann. Produktinhaber sind keine Projektmanager. Anstatt den Status und Fortschritt zu verwalten, besteht seine/ihre Aufgabe darin, das Team mit einem Ziel und einer Vision zu motivieren. 
     
  • Scrum-Master: Der Scrum-Master wird oft als Coach des Teams betrachtet und hilft dem Team, die bestmögliche Arbeit zu leisten. Das bedeutet, Meetings zu organisieren, sich mit Hindernissen und Herausforderungen auseinanderzusetzen und mit dem Produktinhaber zusammenzuarbeiten, um sicherzustellen, dass das Produkt-Backlog für den nächsten Sprint bereit ist. Der Scrum-Master achtet auch darauf, dass das Team den Scrum-Prozess befolgt. Er oder sie hat keine Autorität über Teammitglieder, aber er oder sie hat Autorität über den Prozess. Beispielsweise kann der Scrum-Master einem Teammitglied nicht sagen, was zu tun ist, könnte aber einen neuen Sprint-Rhythmus vorschlagen. 
     
  • Scrum-Team: Das Scrum-Team besteht aus fünf bis sieben Mitgliedern. Alle Projektbeteiligten arbeiten zusammen, helfen sich gegenseitig und sind durch ein Gefühl der Kameradschaft verbunden. Im Gegensatz zu traditionellen Entwicklungsteams gibt es keine festen Rollen wie Programmierer, Designer oder Tester. Alle erledigen die Arbeit gemeinsam. Das Scrum-Team ist Inhaber der Sprintplanung. Es antizipiert, wie viel Arbeit pro Iteration erledigt werden kann. 

Schritte im Scrum-Prozess

 

Scrum cycle


Es gibt eine bestimmte, feste Reihe von Schritten im Scrum-Prozess. Dazu gehören:

  • Produkt-Backlog: Der Produktinhaber und das Scrum-Team treffen sich, um die Priorität der Elemente im Produkt-Backlog zu bestimmen (die Arbeit im Produkt-Backlog wird aus User Storys und Anforderungen abgeleitet). Das Produkt-Backlog ist keine Liste zu erledigender Arbeit; vielmehr handelt es sich um eine Liste mit allen gewünschten Funktionen für das Produkt. Das Entwicklungsteam entnimmt dann die während jedes Sprints abzuschließende Arbeit aus dem Produkt-Backlog.
     
  • Sprintplanung: Vor jedem Sprint stellt der Produktinhaber dem Team in einem Sprintplanungsmeeting die wichtigsten Elemente im Backlog vor. Das Team wählt dann aus, welche Arbeit es während des Sprints erledigen kann und verschiebt sie vom Produkt-Backlog zum Sprint-Backlog (eine Liste der Aufgaben, die im Sprint erledigt werden sollen).
     
  • Backlog-Verbesserung/-Pflege: Am Ende eines Sprints treffen sich das Team und der Produktinhaber, um sicherzustellen, dass das Backlog für den nächsten Sprint bereit ist. Das Team kann nicht relevante User Storys entfernen, neue Storys erstellen, Prioritäten von Storys neu bewerten oder User Storys in kleinere Aufgaben aufteilen. Dieses „Pflegemeeting“ soll sicherstellen, dass das Backlog nur relevante und detaillierte Elemente enthält, die den Zielen des Projekts entsprechen.
     
  • Tägliche Scrum-Meetings: Das Daily Scrum ist ein 15-minütiges Stand-up-Meeting, bei dem jedes Teammitglied über seine Ziele und gegebenenfalls aufgetretene Probleme spricht. Das Daily Scrum findet an jedem Tag während des Sprints statt und hilft, das Team auf Kurs zu halten.
     
  • Sprint-Überprüfungsmeeting: Am Ende jedes Sprints präsentiert das Team die geleistete Arbeit in einem Sprint-Überprüfungsmeeting. Die Präsentation sollte in Form einer Live-Demonstration anstelle eines Berichts oder einer PowerPoint-Präsentation abgehalten werden. 
     
  • Retrospektives Sprint-Meeting: Zusätzlich bespricht das Team am Ende jedes Sprints, wie gut Scrum funktioniert, und spricht über eventuelle Änderungen, die im nächsten Sprint vorgenommen werden müssen. Das Team kann darüber sprechen, was während des Sprints gut gelaufen ist, was schiefgelaufen ist und was es anders machen könnte.

Tools, Artefakte und Methoden in Scrum

 

Burndown chart


Neben Rollen und Zeremonien umfassen Scrum-Projekte auch bestimmte Tools und Artefakte. Zum Beispiel verwendet das Team ein Scrum-Board, um das Backlog oder ein Burndown-Diagramm so zu visualisieren, dass ausstehende Arbeit angezeigt wird. Die gängigsten Artefakte und Methoden sind:

  • Scrum-Board: Sie können Ihr Sprint-Backlog mit einem Scrum-Task-Board visualisieren. Das Board kann verschiedene Formen haben; traditionell enthält es Karteikarten, Post-It-Notizen oder ein Whiteboard. Das Scrum-Board ist in der Regel in drei Kategorien unterteilt: Zu erledigen, In Bearbeitung und Erledigt. Das Scrum-Team muss das Board im Laufe des gesamten Sprints aktualisieren. Wenn jemand beispielsweise eine Idee für eine neue Aufgabe hat, füllt diese Person eine neue Karte aus und fügt sie der entsprechenden Spalte hinzu. 
     
  • User Storys: Eine User Story beschreibt eine Softwarefunktion aus der Sicht des Kunden. Sie umfasst den Benutzertypen, was er möchte und warum. Diese kurzen Storys haben alle eine ähnliche Struktur: Als möchte ich damit ich . Das Entwicklungsteam verwendet diese Storys, um Code zu programmieren, der den Anforderungen der Storys entspricht.
  • Burndown-Diagramm: Ein Burndown-Diagramm stellt alle ausstehenden Arbeiten dar. Das Backlog repräsentiert in der Regel die vertikale Achse und die Zeit die horizontale Achse. Die verbleibende Arbeit kann durch Story-Punkte, ideale Tage, Teamtage oder andere Messzahlen dargestellt werden. Ein Burndown-Diagramm kann dem Team eine Warnung geben, wenn die Dinge nicht nach Plan laufen, und hilft, die Auswirkungen von Entscheidungen aufzuzeigen. 
     
  • Large-Scale Scrum (LeSS): Wenn Sie Elemente in Scrum auf Hunderte von Entwicklern ausweiten möchten, hilft das Framework Large-Scale Scrum (LeSS), die Regeln und Richtlinien zu erweitern, ohne die Essenz von Scrum zu verlieren. Die Prinzipien werden direkt von Scrum übernommen, der Fokus liegt jedoch auf der Skalierung ohne zusätzlichen Aufwand (wie das Hinzufügen von mehr Rollen, Artefakten oder Prozessen).
     
  • Timeboxing: Eine Timebox ist ein festgelegter Zeitraum, in dem ein Team am Erreichen eines Ziels arbeitet. Anstatt ein Team bis zum Erreichen des Ziels arbeiten zu lassen, wird beim Timebox-Ansatz die Arbeit eingestellt, wenn das Zeitlimit erreicht ist. Timebox-Iterationen werden oft im Rahmen von Scrum und Extreme Programming verwendet.
     
  • Icebox: Alle User Storys, die erfasst, aber nicht zur Entwicklung weitergeleitet werden, werden in die Icebox verschoben.
    Der Begriff „Icebox“ wurde von Pivotal Tracker, einem Tool für das Agile-Projektmanagement, geprägt. 
     
  • Scrum vs. RUP: Sowohl Scrum als auch Rational Unified Process (RUP) orientieren sich am Agile-Framework, jedoch umfasst RUP eine formellere Definition des Umfangs, wichtiger Meilensteine und bestimmter Daten (in Scrum kommt anstatt von Umfang ein Projekt-Backlog zum Einsatz). Darüber hinaus besteht RUP aus vier wichtigen Phasen des Projektlebenszyklus (Vorbereitung, Strukturierung, Erstellung und Übergabe), während in Scrum vorgegeben wird, dass der gesamte „traditionelle Lebenszyklus“ in eine Iteration passen muss. 
     
  • Lean vs. Scrum: Scrum ist ein Framework für die Softwareentwicklung, während Lean dazu beiträgt, den Prozess zu optimieren. Das Hauptaugenmerk von Scrum liegt auf den Personen, während sich Lean auf den Prozess konzentriert. Beide gelten als Agile-Techniken, jedoch führt Lean zwei wichtige Konzepte ein: die Beseitigung von Verschwendung und die Verbesserung des Ablaufs.

Erste Schritte mit Scrum

Mit Scrum zu arbeiten bedeutet oft, die Gewohnheiten des Teams zu ändern. Sie müssen mehr Verantwortung übernehmen und die Qualität des Codes sowie die Liefergeschwindigkeit erhöhen. Dieses Maß an Engagement dient als der Treiber für Wandel; wenn sich Teams auf Sprintziele festlegen, steigt ihre Motivation, besser und schneller zu werden und so ein qua0litativ hochwertiges Produkt zu liefern.

Ein guter Ausgangspunkt für Scrum ist ein Gespräch über die Rollen. Jedes Projekt benötigt einen Scrum-Master, Produktinhaber und ein Scrum-Team. Sie sollten darüber sprechen, wer Scrum-Master und wer Produktinhaber sein sollte. Wenn diese Rollen bereits zugewiesen sind, sollten Sie ihre Rollen und Verantwortlichkeiten klarstellen. 

Je nachdem, wie gut Ihr Team mit Scrum vertraut ist, sollten Sie auch Schulungen erwägen. Zertifizierte Scrum-Coaches und -Trainer sowie von der Scrum Alliance anerkannte Schulungsanbieter können Ihrem Team helfen, Scrum zu lernen und anzunehmen.

Mit der neuen Kartenansicht in Smartsheet können Agile-Teams visueller arbeiten, kommunizieren und zusammenarbeiten. In der Kartenansicht können Sie mit umfangreichen Karten wichtige Dinge hervorheben, mit flexiblen Ansichten verschiedene Perspektiven beleuchten und Arbeit visueller priorisieren und anpassen. Sie können Informationen auf Karten darstellen, darunter anpassbare Felder, Bilder und farbliche Kennzeichnungen, um die Aufmerksamkeit Ihres Teams auf wichtige Dinge zu richten. Die Karten lassen sich in Bahnen anordnen, um Arbeit visueller zu organisieren. 

Verwenden Sie während Ihres nächsten Scrum-Meetings die Kartenansicht in Smartsheet.

Weitere Informationen zu Smartsheet für die Softwareentwicklung

Wasserfall-Methode

Was ist die Wasserfall-Methode?

Die Wasserfall-Methode ist ein sequenzieller, linearer Prozess und ist die gängigste Version des Systementwicklungslebenszyklus (Systems Development Life Cycle/SDLC) für Softwareentwicklungs- und IT-Projekte. Manchmal wird sie mit einem Gantt-Diagramm geplant, einer Art Balkendiagramm, das die Start- und Enddaten jeder Aufgabe anzeigt. Sobald eine der acht Phasen abgeschlossen ist, geht das Entwicklungsteam zum nächsten Schritt über. Das Team kann nicht zu einer vorherigen Phase zurückkehren, ohne den gesamten Prozess von Neuem zu beginnen. Bevor das Team in die nächste Phase übergehen kann, müssen die Anforderungen gegebenenfalls vom Kunden geprüft und genehmigt werden.

Das Wasserfall-Modell hat seinen Ursprung in der Fertigungs- und der Bauindustrie, zwei höchst strukturierten Umgebungen, in denen Änderungen zu kostspielig oder gar unmöglich sein können. Die erste formale Beschreibung der Wasserfall-Methode wird Winston W. Royce in einem Artikel aus dem Jahr 1970 zugeschrieben, in dem er ein fehlerhaftes Softwaremodell beschrieb. 

Vorteile der Wasserfall-Methode

Die Wasserfall-Methode ist am besten für einfache, gleichbleibende Projekte geeignet. Ihre lineare, starre Vorgehensweise ermöglicht einen einfachen Einsatz und eine detaillierte Dokumentation.  

Zu den Vorteilen der Wasserfall-Methode gehören:

  • Einfach anzuwenden und zu verwalten: Da das Wasserfall-Modell bei jedem Projekt das gleiche sequenzielle Muster hat, ist es einfach anzuwenden und zu verstehen. Das Team benötigt keine Vorkenntnisse oder Schulung, um an einem Wasserfall-Projekt zu arbeiten. Darüber hinaus ist Wasserfall ein starres Modell. Jede Phase hat bestimmte Leistungen und Überprüfungen, was die Methode leicht zu verwalten und zu steuern macht.
     
  • Sorgt für Disziplin: Jede Phase des Wasserfall-Modells hat einen Start- und einen Endpunkt, und es ist leicht, Stakeholdern und Kunden Fortschritt mitzuteilen. Wenn es den Fokus vor dem Programmieren von Code auf die Anforderungen und das Design legt, kann das Team das Risiko senken, eine Frist zu verpassen.
     
  • Erfordert einen Ansatz mit guter Dokumentation: Bei der Wasserfall-Methode muss jede Phase dokumentiert werden. Dadurch kann die Logik hinter dem Code und den Tests leichter nachvollzogen werden. Man verfügt auch über Referenzen für künftige Projekte oder wenn Stakeholder mehr Details zu einer bestimmten Phase benötigen. 

Nachteile der Wasserfall-Methode

Der größte Nachteil der Wasserfall-Methode ist der Umgang mit Änderungen. Da Wasserfall ein lineares, sequenzielles Modell ist, können Sie nicht zwischen Phasen hin und her wechseln (wie beispielsweise bei Wasserfall vs. Agile), auch wenn unerwartete Änderungen auftreten. Sobald Sie eine Phase abgeschlossen haben, ist sie abgeschlossen. 

Hier weitere Informationen zu den Nachteilen der Wasserfall-Methode:

  • Die Anpassung an Änderungen ist nicht leicht: Sobald das Team eine Phase abgeschlossen hat, kann es nicht mehr zu ihr zurückkehren. Wenn sie die Testphase erreichen und feststellen, dass eine Funktion aus der Anforderungsphase fehlt, ist es sehr schwierig und kostspielig, dies zu beheben. 
     
  • Software wird erst spät geliefert: Das Projekt muss zwei bis vier Phasen durchlaufen, bevor die Programmierung beginnt. Folglich sehen Stakeholder funktionierende Software erst sehr spät im Lebenszyklus.
     
  • Die Erfassung genauer Anforderungen kann eine Herausforderung sein: Eine der ersten Phasen eines Wasserfall-Projekts ist, mit Kunden und Stakeholdern zu sprechen und ihre Anforderungen zu identifizieren. Es kann jedoch schwierig sein, zu Beginn des Projekts genau zu bestimmen, was sie möchten. Anfangs wissen Kunden oft nicht, was sie möchten, und identifizieren Anforderungen stattdessen im Laufe des Projekts.

Phasen der Wasserfall-Methode

 

Grafische Darstellung der Entwicklungsphasen in der Wasserfall-Projektmanagement-Methode.


Bei der Wasserfall-Methode gibt es acht Phasen, die alle nacheinander abgeschlossen werden müssen. Beispielsweise kann das Entwicklungsteam nicht zur Analysephase zurückkehren, wenn es sich in der Testphase befindet.

  1. Konzept: Diese Phase beginnt mit einer Idee. Die Konzeptphase umfasst eine grobe Bewertung des Projekts, warum es vorteilhaft ist und befasst sich mit anfänglichen Kostenschätzungen. 
  2. Initiierung: Sobald die Idee steht, müssen Sie das Projektteam aufstellen und Ziele, Umfang, Zweck und Leistungen definieren.
  3. Anforderungserfassung und -analyse: Die Anforderungen werden erfasst und analysiert, um herauszufinden, ob das Projekt machbar ist. Alle diese Informationen werden in einem Dokument zur Anforderungsspezifikation dokumentiert. 
  4. Design: Die in dieser Phase entworfenen Designspezifikationen werden in der Programmierungsphase verwendet, um den Code zu programmieren. Die Anforderungen werden untersucht und evaluiert und das Systemdesign wird vorbereitet. Das Ziel des Teams ist nachzuvollziehen, welche Maßnahmen ergriffen werden müssen und wie sie aussehen sollen.
  5. Implementierung/Programmierung: Die eigentliche Programmierung der Software beginnt. Alle in der Designphase erstellten Flussdiagramme oder Algorithmen werden in eine Programmiersprache übersetzt.
  6. Tests: Sobald der Code programmiert wurde, muss die Software auf Fehler getestet werden. Wenn die Tests abgeschlossen sind, wird die Software an den Kunden geliefert. Einige Teams entscheiden sich auch dafür, Abnahmetests durchzuführen, bei denen Benutzer die Software testen, bevor sie veröffentlicht wird.
  7. Wartung: Sobald Kunden die Software verwenden, können neue Probleme aufkommen. Das Entwicklungsteam muss die Probleme lösen und die Software gegebenenfalls ändern, damit sie effektiv bleibt.

Iterative Wasserfall-Entwicklung

Im traditionellen Wasserfall-Modell durchläuft das Team jede Phase für das gesamte Projekt. Sie führen beispielsweise die Analyse für das gesamte Projekt durch, entwerfen dann das Design für das gesamte Projekt usw. 

In einem iterativen Wasserfall-Modell ist hingegen eine Menge Planung im Voraus erforderlich. Sobald der Plan steht, geht das Team nach demselben Muster wie bei einem traditionellen Wasserfall-Projekt vor, tut dies aber für jede Story. Sie analysieren eine Story, entwerfen dann das gesamte Design für eine Story und programmieren und testen dann eine Story. Dann wiederholen sie den Prozess für eine andere Story. Die Arbeit wird in Teile aufgegliedert, von denen das Entwicklungsteam profitiert. 

Wie bei der Wasserfall-Methode mit Softwareanforderungen verfahren wird

Wasserfall-Projekte definieren alle Softwareanforderungen im Voraus. Das Projekt kann nur fortgesetzt werden, wenn diese Anforderungen identifiziert und dokumentiert wurden.

Bei einigen Wasserfall-Projekten gibt es auch ein dediziertes Team für die Erfassung dieser Anforderungen. Dabei greifen sie auf Fragebögen, persönliche oder telefonische Gespräche, Whiteboards und Software-Tools zurück, um die Anforderungen von Stakeholdern und Kunden zu erfassen.

Sobald die anfänglichen Anforderungen definiert sind, sollte das Team ein Dokument für die Anforderungsspezifikation erstellen (manchmal auch mehr als eins). Dieses Dokument definiert, was geliefert werden muss, damit jeder den Umfang des Projekts nachvollziehen kann. 

Kanban

Was ist Kanban?

Kanban ist japanisch für „visuelles Zeichen“ oder „Karte“. Dabei handelt es sich um ein visuelles Framework zur Implementierung von Agile, das zeigt, was wann und in welcher Menge produziert werden soll. Es regt kleine, inkrementelle Änderungen an Ihrem aktuellen System an und erfordert weder eine besondere Einrichtung noch spezielle Verfahren (Sie könnten Kanban also mit anderen bestehenden Workflows kombinieren).

Kanban wurde vom Produktionssystem von Toyota und der Lean-Fertigung inspiriert. In den 1940er-Jahren verbesserte Toyota seinen technischen Prozess, indem es ihn Regalen in Supermärkten nachempfand. Ingenieur Taiichi Ohno bemerkte, dass Supermärkte gerade genug Produkte vorrätig haben, um der Nachfrage nachzukommen und dadurch den Ablauf zwischen Supermarkt und Kunde zu optimieren. Der Lagerbestand wurde nur dann wieder aufgefüllt, wenn Regale leere Stellen aufwiesen (ein visueller Hinweis). Da der Bestand den Verbrauch deckte, verbesserte der Supermarkt die Effizienz des Bestandsmanagements.

Toyota übernahm diese Prinzipien für seine Werkshallen. Verschiedene Teams erstellten eine Karte (oder Kanban), um mitzuteilen, dass sie über Kapazitäten verfügen und bereit waren, mehr Materialien entgegenzunehmen. Da alle Anfragen für Teile aus dem Auftrag entnommen (eng. pull) wurden, wird Kanban manchmal auch als „Pull-System“ bezeichnet.

Dieselben Ideen kommen heute bei Softwareteams und IT-Projekten zum Einsatz. In diesem Kontext tritt laufende Entwicklungsarbeit (Work-in-Progress, WIP) an die Stelle des Bestands und neue Arbeit kann erst angefangen werden, wenn das visuelle Kanban-Board des Teams eine „Lücke“ hat. Kanban stimmt die Menge an laufender Arbeit auf die Kapazität des Teams ab, was Flexibilität, Transparenz und Leistung verbessert.

Laut dem Kanban-Blog ist Kanban „eine Technik zur hocheffizienten Verwaltung eines Softwareentwicklungsprozesses. Kanban untermauert das Just-in-Time-Produktsystem (JIT) von Toyota. Obwohl die Entwicklung von Software eine kreative Aktivität ist und sich daher von der Massenproduktion von Autos unterscheidet, kann der zugrunde liegende Mechanismus für die Verwaltung der Produktionslinie dennoch für beides angewendet werden.“

Beim Vergleich von Kanban und Agile muss beachtet werden, dass Kanban eine Variante von Agile ist. Es ist eines von vielen Frameworks, die zur Implementierung von agiler Softwareentwicklung verwendet werden.

Über das Kanban-Board

 

Unterteilung des Aufgabenstatus in „ausstehend“, „in Arbeit“ und „erledigt“ mithilfe von Post-it-Notizen bei der Kanban-Projektmanagement-Methode.

Ein Kanban-Board ist ein Tool zur Implementierung der Kanban-Methode in Projekten. Herkömmlicherweise ist dieses Tool ein physisches Board mit Magneten, Plastikchips oder Haftnotizen auf einem Whiteboard, die Arbeitselemente darstellen. In den letzten Jahren werden jedoch immer häufiger mit Software-Tools für das Projektmanagement Online-Kanban-Boards erstellt.

Ein Kanban-Board, ob physisch oder online, besteht aus verschiedenen Swimlanes oder Spalten. Die einfachsten Boards haben drei Spalten: Zu erledigen, In Bearbeitung und Erledigt. Ein Softwareentwicklungsprojekt kann die Spalten „Backlog“, „Bereit“, „Programmierung“, „Tests“, „Genehmigung“ und „Erledigt“ umfassen.

Kanban-Karten repräsentieren (genau wie Haftnotizen) die Arbeit und jede Karte wird auf der Bahn des Boards platziert, die dem Status dieser Arbeit entspricht. Diese Karten kommunizieren den Status auf einen Blick. Sie können auch Karten mit unterschiedlichen Farben verwenden, um unterschiedliche Details darzustellen. Beispielsweise könnten grüne Karten eine Funktion und orangefarbene Karten eine Aufgabe darstellen.

Vorteile von Kanban

Das visuelle Wesen von Kanban bietet einen besonderen Vorteil bei der Implementierung von Agile. Das Kanban-Board ist leicht zu erlernen und zu verstehen, es verbessert den Arbeitsablauf und minimiert die Zykluszeit. 

Zu den Vorteilen von Kanban gehören:

  • Erhöht die Flexibilität: Kanban ist ein sich weiterentwickelndes, fließendes Modell. Es gibt keine festgelegten Phasendauern und Prioritäten werden bei Erhalt neuer Informationen neu bewertet. 
     
  • Reduziert Verschwendung: Der Fokus von Kanban liegt auf der Reduzierung von Verschwendung, damit Teams keine Zeit in unnötige Arbeit investieren oder die falsche Arbeit machen. 
     
  • Leicht zu verstehen: Das visuelle Wesen von Kanban macht es unglaublich intuitiv und einfach zu erlernen. Das Team muss keine völlig neue Methode erlernen und Kanban kann leicht parallel zu anderen Systemen implementiert werden.
     
  • Verbessert den Lieferfluss: Kanban-Teams optimieren den Arbeitsfluss für Kunden. Wie bei der kontinuierlichen Lieferung (Continuous Delivery, CD) liegt der Fokus von Kanban auf der pünktlichen Erbringung von Wert und der regelmäßigen Lieferung von Arbeit an Kunden.
     
  • Minimiert die Zykluszeit: Die Zykluszeit ist die Zeit, die Arbeit für das Durchlaufen des Workflows des Teams benötigt. Bei Kanban-Projekten trägt das gesamte Team dazu bei, die Arbeit schnell und erfolgreich durch den Prozess laufen zu lassen.

Nachteile von Kanban

Viele der Nachteile von Kanban sind mit der falschen Anwendung oder falschen Handhabung des Kanban-Boards verbunden. Ein veraltetes oder zu kompliziertes Board kann zu Unklarheiten, Ungenauigkeiten oder Fehlkommunikation führen. 

Hier finden Sie weitere Informationen über die Nachteile von Kanban:

  • Veraltetes Board kann zu Problemen führen: Das Team muss das Kanban-Board stets auf dem neuesten Stand halten, da sich die Arbeit sonst auf ungenaue Informationen stützt. Sobald Arbeiten durchgeführt werden, die auf veralteten Informationen beruhen, kann es schwierig sein, die Dinge wieder auf den richtigen Weg zu bringen.
     
  • Teams können das Board zu kompliziert gestalten: Das Kanban-Board sollte übersichtlich und leicht zu lesen bleiben, aber manche Teammitglieder könnten neu gelernte “Tricks“ auf das Board anwenden wollen. Allerdings lenken diese Art von Extras im Kanban-Board nur von den wichtigen Informationen ab.
     
  • Mangelndes Timing: Ein häufiger Kritikpunkt von Kanban ist, dass man nicht weiß, wann Dinge erledigt sein sollen. Die Spalten auf dem Kanban-Board sind nur durch die Phase gekennzeichnet (Zu erledigen, In Bearbeitung, Abgeschlossen). Die Phasen haben keinen Zeitrahmen, sodass man nicht wirklich weiß, wie lange beispielsweise die Phase „Zu erledigen“ dauern könnte.

Grundverfahren und -prinzipien von Kanban

Jedes Kanban-Projekt sollte sich an diesen Grundprinzipien orientieren:

  • Den Arbeitsablauf visualisieren: Eine visuelle Darstellung Ihrer Arbeit ermöglicht es Ihnen, das große Ganze nachzuvollziehen und zu sehen, wie die Arbeit voranschreitet. Durch die Sichtbarkeit der Arbeit, einschließlich der Hindernisse und Warteschlangen, können Sie Probleme frühzeitig erkennen und die Zusammenarbeit verbessern.
     
  • Die laufende Arbeit begrenzen: Grenzen für laufende Arbeiten bestimmen die Mindest- und Höchstmenge an Arbeit für jede Spalte des Boards oder für jeden Workflow. Durch die Begrenzung laufender Arbeiten können Sie die Geschwindigkeit und Flexibilität erhöhen sowie die Notwendigkeit der Priorisierung von Aufgaben reduzieren.
     
  • Den Arbeitsablauf verwalten und verbessern: : Der Arbeitsfluss (die Bewegung der Arbeit) auf dem gesamten Kanban-Board sollte überwacht und verbessert werden. Bemühen Sie sich um einen schnellen, reibungslosen Ablauf, der veranschaulicht, dass das Team schnell Wert schöpft. Das Team sollte Probleme im Ablauf analysieren und dann Änderungen implementieren.
     
  • Explizite Prozessrichtlinien formulieren: Damit kollaborative Änderungen im Kanban-System vorgenommen werden können, müssen die Prozesse explizit sein. Jeder muss verstehen, wie die Dinge funktionieren oder was „erledigt“ wirklich bedeutet. Sie können das Board anpassen, um diese Prozesse klarer zu gestalten. Sie könnten es beispielsweise so umgestalten, dass der Ablauf der Arbeit beschrieben wird.
     
  • Kontinuierlich verbessern: Die Kanban-Methode regt kleine, kontinuierliche Änderungen an. Sobald das Kanban-System eingerichtet ist, kann das Team Probleme identifizieren und verstehen sowie Verbesserungen vorschlagen. Teams messen ihre Effektivität, indem sie den Arbeitsablauf nachverfolgen, die Zykluszeit messen und die Qualität der Arbeit erhöhen.

Häufige Fragen zu Kanban

 

F: Wie organisiert man Meetings und bleibt ohne einen Scrum-Master fokussiert?

Ein Mitglied des Teams muss das Meeting im Kalender festsetzen und sicherstellen, dass die Diskussion beim Thema bleibt. Selbst ohne Scrum-Master ist dies normalerweise kein allzu großes Problem. 

Das Kanban-Board hilft, während des Meetings den Fokus aufrechtzuerhalten. Während des Meetings können Sie das Board von links nach rechts durchgehen und nach Storys suchen, deren Position seit dem letzten Meeting unverändert ist. Anstatt über Errungenschaften zu sprechen, können Sie sich einfach die Karten auf dem Board ansehen. Die eine Frage, die Sie während eines Meetings stellen müssen, ist die Frage nach den Hindernissen oder Herausforderungen bei der Abarbeitung von Elementen. 

Sie können auch ein Kaizen-Meeting ausprobieren, zu dem Sie nur Personen einladen, die an der anstehenden Aufgabe beteiligt sind. Jede Person diskutiert Probleme und Herausforderungen und wie seine oder ihre Arbeit effizienter erledigt werden könnte. Dann spricht die gesamte Gruppe über Lösungen für diese Probleme.

Bei Kaizen kann es auch einen Kaizen-Moderator geben, der das Team anregt, kritische Probleme offen zu besprechen.


F: Wie kann Kanban den Wunsch des Managements nach vorhersehbarer Lieferung erfüllen?

Bis zu einem gewissen Grad tauscht Kanban Vorhersehbarkeit gegen Effizienz ein. Es gibt keine Timebox-Einschränkungen oder Zeitplanung, aber sobald ein Team den Arbeitsablauf optimiert hat und ein Gefühl dafür bekommt, wie lange bestimmte Aufgaben dauern, entsteht ein gewisses Maß an Vorhersehbarkeit.

Wenn das Management noch definiertere Vorhersehbarkeit benötigt (was nicht dem Kanban-Ansatz entspricht), müssen Sie versuchen, die Erwartungen zu verwalten. In einem herkömmlichen Modell gibt es ein vorhersehbares Lieferdatum, aber in Wirklichkeit wird ein Produkt nicht bis zu diesem Datum geliefert, wenn es nicht abgeschlossen ist. Das Management wird immer darauf warten, bis das Produkt fertig ist, unabhängig vom ursprünglich festgelegten Datum. Im Kanban-Modell müssen die Erwartungen darauf angepasst werden, das Produkt zu liefern, wenn es bereit und abgeschlossen ist.


F: Wie verwendet man Kanban, wenn man eine Frist einhalten muss?

Das Kanban-Modell bietet verschiedene Möglichkeiten, mit Fristen umzugehen. Sie können die Fristen einfach auf die Kanban-Karten schreiben und diese Fristen so eher als Richtlinien anstatt als feste Fälligkeitstermine betrachten (in Kanban sollten Sie die Qualität nicht zugunsten zeitlicher Bedenken vernachlässigen).

Sie können auch Ihre und die Herangehensweise Ihres Teams an Fristen ändern. In der reinsten Form benötigt Kanban diese nicht. Das System von Kanban stellt sicher, dass alle Aufgaben so schnell wie möglich erledigt werden, sodass eine Frist nicht mehr notwendig ist. 


F: Kann Kanban neben der Softwareentwicklung auch für andere Projekte verwendet werden?

Ja, Kanban kann Prozessergebnisse verbessern, Produktionszeiten verkürzen und in fast jeder Branche dabei helfen, den Workflow zu verwalten. In der Spieleentwicklungsbranche hilft Kanban beispielsweise, die Dauer des Videoprozesses zu verkürzen und Verschwendung zu reduzieren. Im Immobilienwesen sorgt es für mehr Effizienz, indem Verträge, potenzielle Kunden und Anzeigen auf verschiedenen Boards nachverfolgt werden können. Im Finanzbereich kann man mit Kanban Engpässe schnell erkennen und die Markteinführung beschleunigen. 


F: Ist laufende Arbeit von der Verfügbarkeit von Ressourcen abhängig?

Ja. Wenn Sie Grenzen für laufende Arbeit festlegen, müssen Sie berücksichtigen, wie viele Personen in Ihrem Team sind und wie viele Aufgaben sie gleichzeitig bearbeiten sollen.


F: Woher weiß man, ob die Grenze für laufende Arbeit passt?

Es gibt keine Formel für die Festlegung der richtigen Grenzen für laufende Arbeit. Häufig passen Grenzen anfangs nicht, aber Sie müssen sie nur im Laufe des Projekts anpassen. Ein guter Anfang ist 1,5 für eine verfügbare Ressource, aber Sie sollten diese Zahl ständig neu bewerten und bei Bedarf Änderungen vornehmen.

Agile vs. Scrum

Unterschiede und Gemeinsamkeiten bei Agile vs. Scrum

 

Scrum vs agile


Agile und Scrum folgen zwar dem gleichen System, aber beim Vergleich von Scrum vs. Agile gibt es dennoch einige Unterschiede. Agile stellt eine Reihe von Prinzipien im Agile-Manifest für die Programmierung von Software durch iterative Entwicklung dar. Auf der anderen Seite ist Scrum ein bestimmter Satz an Regeln, die bei der agilen Softwareentwicklung zu befolgen sind. Wenn man also das Verhältnis von Agile vs. Scrum genauer beschreiben möchte, könnte man sagen, Agile ist die Philosophie und Scrum die Methode zur Umsetzung der Agile-Philosophie. 

Da Scrum eine Möglichkeit zur Umsetzung von Agile ist, weisen beide viele Gemeinsamkeiten auf. Bei beiden liegt der Fokus darauf, Software frühzeitig und häufig zu liefern, beides sind iterative Prozesse und beide passen sich an Änderungen an. Zusätzlich fördern sie Transparenz und kontinuierliche Verbesserung.  

Scrum vs. Agile – wie passt das zusammen?

Scrum ist eines von vielen Frameworks, die zur Umsetzung eines Agile-Prozesses verwendet werden. Agile ist ein Überbegriff, der andere Prozesse wie Extreme Programming, Kanban, Crystal und Scrum zusammenfasst. Scrum ist Agile, aber Agile ist nicht Scrum. 

Wann Scrum verwendet werden sollte

Wir empfehlen die Verwendung von Scrum, wenn:

  • die Projektanforderungen sich ändern und weiterentwickeln,
  • kontinuierliches Feedback erforderlich ist,
  • Sie herausfinden müssen, wie Sie den Großteil der Arbeit erledigen, da Sie sie noch nie gemacht haben,
  • Sie sich nicht auf ein festes Veröffentlichungsdatum festlegen müssen,
  • das Projektteam eigenständig arbeiten möchte,
  • Sie regelmäßig Software liefern müssen.

Scrum ist gut für Projekte geeignet, bei denen es viele Unbekannte gibt oder die sich im Laufe der Zeit verändern. Scrum geht sehr effektiv mit diesen Änderungen um, sodass Sie sich während des gesamten Prozesses problemlos an neue Informationen oder Funktionen anpassen können.

Wann Agile verwendet werden sollte

Die Grenze zwischen Agile vs. Scrum ist kaum erkennbar. Scrum ist ein Framework des Agile-Prozesses, sodass die beiden viel gemeinsam haben. Sie sollten zuerst überlegen, ob Agile allgemein in Ihrem Fall überhaupt geeignet ist. Wenn Sie zu dem Schluss kommen, dass eine Agile-Methode der richtige Ansatz ist, können Sie anschließend wählen, welches Agile-Framework angewendet werden soll (Scrum ist eines davon).

Wir empfehlen die Verwendung von Agile, wenn:

  • das Endprodukt nicht klar definiert ist,
  • die Kunden/Stakeholder in der Lage sein müssen, den Umfang zu ändern,
  • im Laufe des Prozesses Änderungen implementiert werden müssen,
  • die Entwickler anpassungsfähig sind und unabhängig denken können,
  • Sie für eine schnelle Bereitstellung Optimierungen vornehmen müssen.

Hybrider Ansatz

Wenn ein reiner Scrum-Ansatz nicht für Ihr Projekt geeignet ist, können Sie auch ein hybrides Modell ausprobieren. Es gibt einige Methoden, welche die Prinzipien von Agile oder Scrum kombinieren und das Framework für eine effektivere Skalierung anpassen.

Zum Beispiel baut Disciplined Agile Delivery (DAD) auf den Verfahren von Agile, Scrum und Lean auf, um eine solide Grundlage für die Skalierung zu schaffen. DAD wurde entwickelt, um einen geschlosseneren Ansatz für Agile zu bieten, der Strategien von Scrum, Kanban, Extreme Programming und anderen Frameworks übernimmt. Anstatt Zeit darin zu investieren, eines dieser bestehenden Frameworks zu erlernen oder sie bei Bedarf zusammenzuschustern, kombiniert DAD bereits alle relevanten Techniken.

Andere hybride Methoden sind Large-Scale Scrum (LeSS), das Scrum um Skalierungsregeln und -richtlinien erweitert, und Scaled Agile Framework (SAFe), das auf den zugrunde liegenden Prinzipien von Lean und Agile basiert. 

Kanban vs. Scrum

Kanban vs. Scrum: Unterschiede und Gemeinsamkeiten

 

Scrum vs kanban


Ob Scrum oder Kanban – beide sind Varianten von Agile, aber sie weisen einige deutliche Unterschiede auf.

  • Scrum erfordert bestimmte Rollen, während Kanban ohne diese auskommt.
  • Scrum basiert auf Timebox-Iterationen, die Planung, Prozessverbesserung und Release kombinieren. Bei Kanban können Sie diese Aktivitäten in regelmäßigen Abständen oder wann immer notwendig ausführen.
  • Scrum begrenzt laufende Arbeit in den einzelnen Iterationen, während Kanban diese in den einzelnen Workflows begrenzt.
  • Scrum sträubt sich gegen Änderungen, Kanban nimmt und passt sich an Änderungen an. Bei Scrum kann das Team, sobald es Storys für einen Sprint festgelegt hat, keine weiteren Storys mehr hinzufügen. Bei Kanban können Sie Storys nach Belieben hinzufügen oder ändern, vorausgesetzt, dies liegt innerhalb der Grenzen für laufende Arbeit.
  • Unterschied Scrum- vs. Kanban-Board: Ein Scrum-Board wird nach jedem Sprint zurückgesetzt. Ein Kanban-Board wird kontinuierlich verwendet.
  • Ein Scrum-Team ist funktionsübergreifend und ein Team ist Inhaber des Scrum-Boards. Bei Kanban müssen Teams nicht funktionsübergreifend sein und jeder kann Inhaber des Kanban-Boards sein.
  • Scrum-Teams müssen Schätzungen durchführen, Kanban-Teams nicht.


Es gibt auch einige Gemeinsamkeiten bei Vergleich von Kanban vs. Scrum:

  • Sie sind empirisch. Sie müssen mit dem Prozess experimentieren, um zu sehen, ob Scrum oder Kanban besser für Sie funktioniert.
  • Beide ermöglichen es Teammitgliedern, an mehreren Produkten gleichzeitig zu arbeiten.
  • Sie orientieren sich an Lean und Agile.
  • Beide legen Grenzen für laufende Arbeit fest (die Art und Weise, wie sie Grenzen festlegen, unterscheidet sich aber).
  • Sie verwenden Pull-Planung.
  • Beide konzentrieren sich darauf, Software frühzeitig und häufig zu liefern.
  • Beide nutzen Transparenz, um den Prozess zu verbessern.

Kanban vs. Scrum: Wie verhalten sie sich zueinander?

Bei Scrum oder Kanban handelt es sich in beiden Fällen um Frameworks der Agile-Softwareentwicklung. Beide nehmen große, komplexe Aufgaben und gliedern sie in kleinere Teile auf. Kanban und Scrum arbeiten auch auf eine kontinuierliche Verbesserung und Optimierung des Prozesses hin und sorgen dafür, dass man Einblicke in die Arbeit erhält. 

Sowohl Kanban als auch Scrum sind sehr anpassungsfähig, aber Scrum ist starrer als Kanban. Scrum hat mehr Einschränkungen, Kanban ist hingegen flexibler.

Scrum- vs. Kanban-Board

Ein Scrum- und ein Kanban-Board können visuell ähnlich aussehen, aber sie basieren auf sehr unterschiedlichen Prinzipien. 

Um ein Scrum-Board zu erstellen, muss das Scrum-Team zunächst Sprints erstellen, User Storys Punkte zuweisen und planen, welche Storys in welchen Sprint einfließen. Dann visualisiert das Scrum-Board den Sprint und zeigt an, welche Storys in der Planungs- und welche in der Arbeitsphase sind. Das Scrum-Board wird zwischen jedem Sprint zurückgesetzt und liegt in der Verantwortung eines bestimmten Teams. Erstellen Sie Ihr Scrum-Board digital oder physisch, je nachdem, was für Ihr Team am besten funktioniert.

Ein Kanban-Board hat das gleiche auf Spalten aufbauende Layout wie ein Scrum-Board, erfordert jedoch keine Planung im Voraus. Sie können mit der Arbeit anfangen und das Kanban-Board abarbeiten, ohne einen strukturierten Plan zu benötigen. Das Kanban-Board kann von mehreren Personen genutzt werden und ist dauerhaft, Sie müssen das Board also nicht zurücksetzen. Außerdem schränkt das Kanban-Board im Gegensatz zum Scrum-Board die Anzahl an Storys pro Spalte und Zeitpunkt ein. Dieser Ablauf gilt für die Dauer des Projekts, wobei neue Storys hinzugefügt und abgeschlossene Storys bei Bedarf neu bewertet werden.

Wann Kanban verwendet werden sollte

Wir empfehlen die Verwendung von Kanban, wenn:

  • Sie spontan Storys hinzufügen oder Sprints ändern müssen,
  • keine Iterationen erforderlich sind,
  • keine Schätzung notwendig ist,
  • Sie die Freiheit haben möchten, Produkte jederzeit zu veröffentlichen,
  • bereits Wert auf die kontinuierliche Verbesserung gelegt wird,
  • Ihr Team nicht gut auf große Veränderungen reagiert,
  • Sie den Lieferungsfluss verbessern möchten,
  • das System einfach zu verstehen sein muss.

Scrum kann weniger flexibel sein als Kanban. Die Zeit wird in Sprints unterteilt, wobei jeder Sprint zwei bis vier Wochen dauert. Bei jedem Sprint hat das Team bestimmte Rollen und orientiert sich an bestimmten Zeremonien. 

Kanban vs. Scrum – Was ist Scrumban?

Scrumban kombiniert die Prinzipien von Scrum und Kanban zu einem Pull-basierten System. Das Team plant die Arbeit ein, die während der Initialisierung beschlossen wurde, und pflegt kontinuierlich das Backlog. Scrum-Meetings sollten weiterhin stattfinden, aber die Häufigkeit kann je nach Kontext und Bedarf anders sein. Der wichtigste Teil von Scrumban ist sicherzustellen, dass die Grenzen für laufende Arbeit eingehalten werden.

Scrumban ist eine Mischung aus Scrum und Kanban. Beispielsweise sind die definierten Rollen, das Daily Scrum und andere Meetings von Scrum entliehen. Von Kanban werden das Kanban-Board, der kontinuierliche Ablauf und die Möglichkeit, je nach Bedarf Änderungen am Board vorzunehmen, übernommen. 

Scrumban ähnelt auf technischer Ebene eher Scrum, auf kultureller Ebene aber eher Kanban. Anstatt große Änderungen auf einmal vorzunehmen, regt Scrumban zu inkrementellen Änderungen an. Wenn Ihr Team von Scrum auf Kanban umstellen möchte, kann Scrumban einen sanften Übergang ermöglichen.

Was ist am besten – Scrum oder Kanban? Kanban vs. Scrum

Beim Vergleich Kanban vs. Scrum gibt es keinen eindeutigen Gewinner. Ob Sie lieber Scrum oder Kanban verwenden, hängt von Ihrem Projekt, Team und Ihren Zielen ab. Da es sich sowohl bei Kanban als auch bei Scrum um flexible Agile-Methoden handelt, können Sie problemlos Prinzipien der beiden Methoden übernehmen und sie nach Belieben anwenden.

Vergessen Sie nicht, dass echtes Scrum eine viel größere Umstellung ist als Kanban. Das Team muss die Zeremonien, die spezifischen Rollen und Iterationen kennenlernen. Auf der anderen Seite regt Kanban inkrementelle Verbesserungen an. Sie können Kanban-Prinzipien auf jeden bereits eingerichteten Prozess anwenden, selbst Scrum. Die Einrichtung von Kanban erfordert keine wesentlichen Änderungen. 

Als allgemeine Faustregel gilt: Wenn Ihr Team oder Ihre Organisation nicht von der Stelle kommt und eine starke Änderung notwendig ist, kann Scrum besser geeignet sein. Wenn Sie mit Ihrem bereits vorhandenen Prozess zufrieden sind, aber ein paar kleine Änderungen vornehmen möchten, kann Kanban die bessere Wahl sein.

Agile vs. Wasserfall

Unterschiede und Gemeinsamkeiten: Wasserfall vs. Agile

 

Waterfall vs agile


Die Unterschiede zwischen der Projektmanagement-Methode Wasserfall vs. Agile lassen sich mit zwei Worten zusammenfassen: starr vs. flexibel. Wasserfall ist ein viel strengerer und starrer Prozess, während Agile flexibel ist und sich ständig weiterentwickelt. Hier erfahren Sie mehr über den Unterschied von Agile vs. Wasserfall:

  • Wasserfall ist ein strukturierter Prozess, bei dem Sie eine neue Phase erst starten können, wenn die vorherige abgeschlossen ist. Auf der anderen Seite ist Agile ein flexibler Prozess, mit dem Sie in der gewünschten Reihenfolge am Projekt arbeiten können.
  • Wasserfall ist sequenziell und Agile erzwingt keinen linearen Prozess.
  • Wasserfall-Projekte haben in der Regel im Voraus definierte Anforderungen, während bei Agile-Projekten davon ausgegangen wird, dass sich Anforderungen ändern und weiterentwickeln.
  • Bei Wasserfall-Projekten können Sie nicht ändern, was in früheren Phasen getan wurde, während sich Agile gut an Änderungen anpassen kann.

Beim Vergleich Agile vs. Wasserfall gibt es nicht viele Gemeinsamkeiten. Agile wurde speziell als Gegensatz zu Wasserfall entwickelt. Man kann jedoch sagen, dass Agile und Wasserfall das gleiche Ziel haben. Bei beiden sollen qualitativ hochwertige Produkte auf effiziente Weise geliefert werden. Wenn Ihnen noch weitere Gemeinsamkeiten von Agile und Wasserfall einfallen, hinterlassen Sie uns bitte einen Kommentar! 

Projektmanagement mit Wasserfall vs. Agile – wann sie was einsetzen sollten

Wir empfehlen die Verwendung von Wasserfall, wenn:

  • Sie keine Änderungen am Umfang erwarten und mit Festpreisverträgen arbeiten,
  • das Projekt sehr einfach ist oder Sie bereits Erfahrung mit Projekten dieser Art haben,
  • die Anforderungen bekannt und festgelegt sind,
  • Kunden schon im Voraus genau wissen, was sie wollen,
  • Sie an geordneten und vorhersehbaren Projekten arbeiten.


Agile sollten Sie verwenden, wenn:

  • das Endprodukt nicht klar definiert ist,
  • die Kunden/Stakeholder in der Lage sein müssen, den Umfang zu ändern,
  • Sie erwarten, dass im Laufe des Projekts Änderungen auftreten,
  • das Ziel eine schnelle Bereitstellung ist.

Bei der Entscheidung Agile vs. Wasserfall kann es auf Folgendes hinauslaufen: Wenn Sie erwarten, dass im Laufe des Projekts Änderungen auftreten, entscheiden Sie sich für Agile. Wenn Sie wissen, dass das Projekt feststeht sowie unveränderlich und vorhersehbar ist, ist Wasserfall die bessere Wahl.

Welche Methode ist besser? Agile vs. Wasserfall

Agile und Wasserfall sind so gegensätzlich, dass es schwer zu sagen ist, welche der beiden Methoden die bessere ist. Letztendlich hängt es vom Projekt, der Klarheit bezüglich der Anforderungen und Ihrer Flexibilität ab.

Wenn Sie eine klare Vorstellung vom Endprodukt und feste Anforderungen haben, die sich nicht ändern werden, und an einem relativ einfachen Projekt arbeiten, ist nach der Meinung einiger Fachleute Wasserfall die bessere Wahl als Agile. Wenn Sie keine Änderungen erwarten, ist Wasserfall ein einfacher, effizienter Prozess. Probleme mit Wasserfall entstehen, wenn Sie Änderungen berücksichtigen müssen.

Wenn Sie keine klare Vorstellung vom Endprodukt haben, mit Änderungen rechnen und an einem komplexen Projekt arbeiten, ist Agile besser geeignet. Agile wurde entwickelt, um sich während des gesamten Projekts an neue, sich ändernde Anforderungen anzupassen, während Wasserfall keine Möglichkeit bietet, zu einer abgeschlossenen Phase zurückzukehren und Änderungen vorzunehmen.

Hybrid: Agifall oder Wagile

Wenn Sie sich immer noch über Wasserfall vs. Agile Gedanken machen, besteht immer die Möglichkeit, Prinzipien der beiden zu kombinieren und ein hybrides Modell zu verwenden.

Agifall erhöht beispielsweise die Geschwindigkeit und Qualität, indem der Wasserfall-Prozess um Agile-Methoden ergänzt wird. Bei einem Agifall-Projekt werden die Forschungs-, die Strategie- und die Planungsphase in Aufgaben aufgegliedert, die wiederum in Sprints erledigt werden. Die Entwicklungsphase gleicht der eines üblichen Agile-Projekts, wobei mehr Informationen im Voraus feststehen. Sie müssen auch nicht das Ende einer Phase abwarten, um die folgende Phase zu starten, wie bei reinem Wasserfall üblich. Bei Agifall sollte das Projekt gestartet werden, sobald es kann.

Wagile hat eine negativere Konnotation als Agifall. Die Definition von Wagile auf Wikipedia lautet in etwa „eine Gruppe von Softwareentwicklungsmethoden, die sich aus dem Rückschritt von Agile zurück zu Wasserfall ergeben. Dabei werden viele kleine Wasserfalls so ausgeführt, als würde es sich um einen Agile-Prozess handeln. Das Wasserfall-Modell wird als agile Softwareentwicklung ausgegeben.“

Wagile übernimmt Agile-Verfahren wie z. B. kurze Iterationen, tägliche Stand-ups oder kontinuierliche Integration zusätzlich zum Wasserfall-Modell, ohne das traditionelle Wasserfall-Modell wirklich zu ändern.

Kanban vs. Agile

Unterschiede und Gemeinsamkeiten: Agile vs. Kanban

 

Kanban vs agile


Obwohl Kanban eine visuelle Möglichkeit der Umsetzung von Agile darstellt, gibt es zwischen den beiden viele Unterschiede:

  • Kanban plädiert für einen kontinuierlichen Ablauf, während Agile mit Iterationen arbeitet.
  • Kanban kann für jede Art von Arbeit gleichermaßen geeignet sein, Agile ist jedoch für einige Projekte besser geeignet als für andere.
  • Kanban kann ohne besondere Kenntnisse angewendet werden, einige Agile-Methoden erfordern hingegen Kenntnisse oder Schulung.
  • Kanban erfordert eine visuelle Darstellung des Workflows, Agile nicht.
  • Einige Agile-Projekte erfordern funktionsübergreifende Teams, Kanban nicht.
  • Agile ist eine Philosophie, Kanban eine Methode.


Agile und Kanban haben aber auch Gemeinsamkeiten:

  • Beide gliedern Projekte in kleinere Teile auf.
  • Sie betonen kontinuierliche Verbesserung.
  • Sie legen großen Wert auf Transparenz.
  • Keines von beiden erfordert viel Planung im Voraus.
  • Sie bemühen sich um eine schnellere Lieferung.

Kanban vs. Agile – wann Sie was einsetzen sollten

Wir empfehlen die Verwendung von Kanban, wenn:

  • Ihr Projekt keine Iterationen erfordert,
  • Sie die Freiheit haben möchten, Produkte jederzeit zu veröffentlichen,
  • Ihr Team inkrementelle Änderungen bevorzugt,
  • Ihr Team gut mit visuellen Materialien arbeitet,
  • Sie den Lieferungsablauf verbessern möchten,
  • Sie nach einem leicht verständlichen System suchen.


Die Verwendung von Agile empfehlen wir, wenn:

  • das Endprodukt nicht klar definiert ist,
  • im Laufe des Prozesses Änderungen implementiert werden müssen,
  • die Entwickler anpassungsfähig sind und unabhängig denken können,
  • Sie eine wesentliche Änderung vornehmen möchten.

Welche Methode ist besser? Agile vs. Kanban

Wie bei jeder Projektmanagementmethode gibt es nicht das eine Framework, das immer besser ist. Bei manchen Projekten sollten Sie sich für Kanban entscheiden, bei anderen für Agile.

Überlegen Sie, welche Dimension die Änderung haben soll. Wenn Sie einem bestehenden Framework mittels kleiner, inkrementeller Änderungen etwas hinzufügen möchten, ist Kanban die bessere Wahl. Wenn Sie eine größere Änderung an einem Prozess vornehmen möchten, wäre die Implementierung von Agile (wie Scrum) besser. 

Wenn Sie möchten, dass Ihr Projektteam umgehend eine neue Methode anwendet, ist Kanban leichter zu verstehen. Die Methode erfordert keine Schulung und kann neben einem beliebigen bestehenden Prozess angewendet werden. Auf der anderen Seite erfordern einige Agile-Methoden mehr Kenntnisse im Team. Beispielsweise müssen die Teammitglieder bestimmte Rollen, Zeremonien und Terminologie erlernen. 

Ressourcen und ähnliche Beiträge

 

Laden Sie eine kostenlose Excel-Vorlage für ein Wasserfall-Diagramm herunter oder erfahren Sie, wie Sie ein Wasserfall-Diagramm von Grund auf neu erstellen. Wir erklären Ihnen auch, wann Sie ein Wasserfall-Diagramm verwenden sollten und welche Funktionen ein Wasserfall-Diagramm in Excel hat.

 

Entdecken Sie acht Vorlagen für agiles Projektmanagement in Excel, von einer Vorlage für das Agile-Produkt-Backlog bis hin zu einer Vorlage für eine Agile-Projektcharta. Sie erfahren auch, wie Sie Vorlagen für Agile in Smartsheet verwenden.

Kurse:

  • PMI Agile Certified Practitioner (PMI ACP): Diese Zertifizierung wird vom Project Management Institute (PMI) angeboten und deckt die vielen verschiedenen Agile-Ansätze, wie z. B. Scrum, Kanban, Lean, Extreme Programming (XP) und die testgetriebene Entwicklung (Test-Driven Development/TDD) ab. Die Voraussetzungen sind 2.000 Stunden allgemeine Projekterfahrung in einem Team, 1.500 Stunden Arbeit in Agile-Projektteams und 21 Kontaktstunden-Schulung in Agile-Verfahren.
  • Certified Scrum Master (CSM): Diese Zertifizierung der Scrum Alliance hilft Teams, Scrum richtig zu verwenden, die Werte nachzuvollziehen und Ablenkungen für das Team zu vermeiden. Als CSM können Sie sowohl die Rolle des Scrum-Masters als auch des Scrum-Teammitglieds besetzen. Um Ihr CSM-Zertifikat zu erlangen, müssen Sie einen CSM-Kurs eines von der Scrum Alliance autorisierten Trainers belegen und Ihren Fortschritt mit einem Online-Test nachweisen.
  • Certified Scrum Product Owner (CSPO): Ein Certified Scrum Product Owner erlernt Terminologie, Verfahren und Prinzipien von Scrum, um in einem Scrum-Team die Rolle des Produktinhabers zu besetzen. Er oder sie ist der geschäftlichen Seite des Projekts am nächsten, pflegt das Produkt-Backlog und stellt sicher, dass jeder die Prioritäten kennt. Um diese Zertifizierung von der Scrum Alliance zu erhalten, müssen Sie an einem zweitägigen CSPO-Präsenzkurs mit einem zertifizierten Scrum-Trainer teilnehmen.
  •  
  • Certified Scrum Professional (CSP): Certified Scrum Professionals motivieren ihre Scrum-Teams, die Umsetzung von Scrum bei Projekten zu verbessern. Um als CSP zertifiziert zu werden, müssen Sie eine CSM-, CSPO- oder CSD-Zertifizierung haben, mindestens 36 Monate Erfahrung mit Agile/Scrum haben und 70 Scrum-Bildungseinheiten aus den letzten drei Jahren einreichen.
  • Accredited Kanban Practitioner (AKP): Accredited Kanban Practitioner sind Fachleute mit nachgewiesenem Wissen und Fachkenntnissen bei der Umsetzung von Kanban in der Softwareentwicklung. Die Zertifizierung wird vom Agile Certification Institute, Inc. angeboten und erfordert eine vorherige Schulung in Agile-Verfahren und das Bestehen einer AKP-Zertifizierungsprüfung.

Projekte mit Smartsheet auf Ihre Weise verwalten

Empower your people to go above and beyond with a flexible platform designed to match the needs of your team — and adapt as those needs change. 

The Smartsheet platform makes it easy to plan, capture, manage, and report on work from anywhere, helping your team be more effective and get more done. Report on key metrics and get real-time visibility into work as it happens with roll-up reports, dashboards, and automated workflows built to keep your team connected and informed. 

When teams have clarity into the work getting done, there’s no telling how much more they can accomplish in the same amount of time. Try Smartsheet for free, today.

 

 

Ressourcen und ähnliche Beiträge

So erstellen Sie ein Wasserfall-Diagramm in Excel

Laden Sie eine kostenlose Excel-Vorlage für ein Wasserfall-Diagramm herunter oder erfahren Sie, wie Sie ein Wasserfall-Diagramm von Grund auf neu erstellen. Wir erklären Ihnen auch, wann Sie ein Wasserfall-Diagramm verwenden sollten und welche Funktionen ein Wasserfall-Diagramm in Excel hat.

Die besten Excel-Vorlagen für agiles Projektmanagement

Entdecken Sie acht Vorlagen für agiles Projektmanagement in Excel, von einer Vorlage für das Agile-Produkt-Backlog bis hin zu einer Vorlage für eine Agile-Projektcharta. Sie erfahren auch, wie Sie Vorlagen für Agile in Smartsheet verwenden

Agile Planung: Best Practices für Projektmanager

Die umfassende Ressource für agiles Projektmanagement

Kurse:

  • PMI Agile Certified Practitioner (PMI ACP): Diese Zertifizierung wird vom Project Management Institute (PMI) angeboten und deckt die vielen verschiedenen Agile-Ansätze, wie z. B. Scrum, Kanban, Lean, Extreme Programming (XP) und die testgetriebene Entwicklung (Test-Driven Development/TDD) ab. Die Voraussetzungen sind 2.000 Stunden allgemeine Projekterfahrung in einem Team, 1.500 Stunden Arbeit in Agile-Projektteams und 21 Kontaktstunden-Schulung in Agile-Verfahren.
  • Certified Scrum Master (CSM): Diese Zertifizierung der Scrum Alliance hilft Teams, Scrum richtig zu verwenden, die Werte nachzuvollziehen und Ablenkungen für das Team zu vermeiden. Als CSM können Sie sowohl die Rolle des Scrum-Masters als auch des Scrum-Teammitglieds besetzen. Um Ihr CSM-Zertifikat zu erlangen, müssen Sie einen CSM-Kurs eines von der Scrum Alliance autorisierten Trainers belegen und Ihren Fortschritt mit einem Online-Test nachweisen.
  • Certified Scrum Product Owner (CSPO): Ein Certified Scrum Product Owner erlernt Terminologie, Verfahren und Prinzipien von Scrum, um in einem Scrum-Team die Rolle des Produktinhabers zu besetzen. Er oder sie ist der geschäftlichen Seite des Projekts am nächsten, pflegt das Produkt-Backlog und stellt sicher, dass jeder die Prioritäten kennt. Um diese Zertifizierung von der Scrum Alliance zu erhalten, müssen Sie an einem zweitägigen CSPO-Präsenzkurs mit einem zertifizierten Scrum-Trainer teilnehmen.
  • Certified Scrum Developer (CSD): Certified Scrum Developer erlernen spezielle Agile-Entwicklungstechniken und weisen ihr Wissen mittels formeller Schulungen und einer technischen Kompetenzbewertung nach. Der CSD-Kurs richtet sich an Softwareentwickler, die in einer Scrum-Umgebung arbeiten. Um von der Scrum Alliance als CSD anerkannt zu werden, sind fünf Tage formelle Schulung durch einen von der Scrum Alliance anerkannten Schulungsanbieter und einen von der Scrum Alliance autorisierten Ausbilder vorausgesetzt. 
  • Certified Scrum Professional (CSP): Certified Scrum Professionals motivieren ihre Scrum-Teams, die Umsetzung von Scrum bei Projekten zu verbessern. Um als CSP zertifiziert zu werden, müssen Sie eine CSM-, CSPO- oder CSD-Zertifizierung haben, mindestens 36 Monate Erfahrung mit Agile/Scrum haben und 70 Scrum-Bildungseinheiten aus den letzten drei Jahren einreichen.
  • Accredited Kanban Practitioner (AKP): Accredited Kanban Practitioner sind Fachleute mit nachgewiesenem Wissen und Fachkenntnissen bei der Umsetzung von Kanban in der Softwareentwicklung. Die Zertifizierung wird vom Agile Certification Institute, Inc. angeboten und erfordert eine vorherige Schulung in Agile-Verfahren und das Bestehen einer AKP-Zertifizierungsprüfung.

Projekte mit Smartsheet auf Ihre Weise verwalten

Empower your people to go above and beyond with a flexible platform designed to match the needs of your team — and adapt as those needs change. 

The Smartsheet platform makes it easy to plan, capture, manage, and report on work from anywhere, helping your team be more effective and get more done. Report on key metrics and get real-time visibility into work as it happens with roll-up reports, dashboards, and automated workflows built to keep your team connected and informed. 

When teams have clarity into the work getting done, there’s no telling how much more they can accomplish in the same amount of time. Try Smartsheet for free, today.

 

 

Discover why over 90% of Fortune 100 companies trust Smartsheet to get work done.

Smartsheet kostenlos testen Get a Free Smartsheet Demo