Agile Softwareentwicklung bezieht sich auf Softwareentwicklungsmethoden, die auf der Idee der iterativen Entwicklung basieren, bei der Anforderungen und Lösungen durch die Zusammenarbeit zwischen selbstorganisierenden, funktionsübergreifenden Teams entstehen. Der ultimative Wert der Agile-Entwicklung besteht darin, dass Teams schneller, mit höherer Qualität und Vorhersehbarkeit und mit größerer Fähigkeit, auf Veränderungen zu reagieren, Mehrwert liefern können. Scrum und Kanban sind zwei der am häufigsten verwendeten Agile-Methoden. Im Folgenden finden Sie die am häufigsten gestellten Fragen zu Agile und Scrum, beantwortet von unseren Experten.
Was ist Agile?
Agile Softwareentwicklung bezieht sich auf eine Gruppe von Softwareentwicklungsmethoden, die auf iterativer Entwicklung basieren, bei der Anforderungen und Lösungen durch die Zusammenarbeit zwischen selbstorganisierenden, funktionsübergreifenden Teams entstehen. Agile Methoden oder Agile Prozesse fördern im Allgemeinen einen disziplinierten Projektmanagementprozess, der häufige Überprüfung und Anpassung fördert, eine Führungsphilosophie, die Teamarbeit, Selbstorganisation und Verantwortlichkeit fördert, eine Reihe von bewährten technischen Verfahren, die eine schnelle Bereitstellung qualitativ hochwertiger Software ermöglichen sollen, und einen Geschäftsansatz, der die Entwicklung an den Kundenanforderungen und Unternehmenszielen ausrichtet. Agile Entwicklung bezieht sich auf jeden Entwicklungsprozess, der an den Konzepten des Agilen Manifests ausgerichtet ist. Das Manifest wurde von einer Gruppe von vierzehn führenden Persönlichkeiten der Softwarebranche entwickelt und spiegelt ihre Erfahrungen darüber wider, welche Ansätze für die Softwareentwicklung funktionieren und welche nicht. Lesen Sie mehr über das Agile Manifest. Wussten Sie, dass Agile auch auf Hardwareprojekte angewendet werden kann? Erfahren Sie mehr über Cprimes revolutionäres Agile for Hardware-Framework .
Holen Sie sich weitere Informationen und Mural-Vorlagen, um mit Agile zu beginnen
Was ist Scrum?
Scrum ist eine Untergruppe von Agile. Es ist ein leichtgewichtiges und am weitesten verbreitetes Prozessframework für die agile Entwicklung.
- Ein „Prozessrahmenwerk“ ist ein bestimmter Satz von Vorgehensweisen, die befolgt werden müssen, damit ein Prozess mit dem Rahmenwerk übereinstimmt. (Beispielsweise erfordert das Scrum-Prozessrahmenwerk die Verwendung von Entwicklungszyklen, die Sprints genannt werden, das XP-Rahmenwerk erfordert Paarprogrammierung usw.)
- „Leichtgewichtig“ bedeutet, dass der Mehraufwand des Prozesses so gering wie möglich gehalten wird, um die für die Erledigung nützlicher Arbeit zur Verfügung stehende produktive Zeit zu maximieren.
Ein Scrum-Prozess unterscheidet sich von anderen agilen Prozessen durch spezifische Konzepte und Praktiken, die in die drei Kategorien Rollen, Artefakte und Zeitfenster unterteilt sind. Diese und andere in Scrum verwendete Begriffe werden unten definiert. Scrum wird am häufigsten verwendet, um komplexe Software- und Produktentwicklungen zu verwalten, wobei iterative und inkrementelle Praktiken zum Einsatz kommen. Scrum erhöht die Produktivität erheblich und verkürzt die Zeit bis zum Erreichen der Vorteile im Vergleich zu klassischen „ Wasserfall “-Prozessen. Scrum-Prozesse ermöglichen es Organisationen, sich reibungslos an schnell ändernde Anforderungen anzupassen und ein Produkt zu erstellen, das sich entwickelnden Geschäftszielen entspricht. Ein agiler Scrum-Prozess kommt der Organisation zugute, indem er ihr hilft,
- Steigern Sie die Qualität der Ergebnisse
- Mit Veränderungen besser umgehen (und die Veränderungen erwarten)
- Erstellen Sie bessere Kostenvoranschläge und verbringen Sie gleichzeitig weniger Zeit mit deren Erstellung
- Mehr Kontrolle über den Projektzeitplan und -status
Was sind die Vorteile von Agile?
Entwicklungsanfragen reagiert. Hochwertige Funktionen werden in kurzen Zyklen schneller entwickelt und bereitgestellt als in den längeren Zyklen, die bei klassischen „Wasserfall“-Prozessen bevorzugt werden.
Vorteile für Anbieter
Anbieter reduzieren Verschwendung, indem sie den Entwicklungsaufwand auf hochwertige Funktionen konzentrieren, und verkürzen die Markteinführungszeit im Vergleich zu Wasserfallprozessen aufgrund geringerer Gemeinkosten und höherer Effizienz. Eine verbesserte Kundenzufriedenheit führt zu einer besseren Kundenbindung und positiveren Kundenreferenzen.
Vorteile für Entwicklungsteams
Teammitglieder haben Spaß an der Entwicklungsarbeit und möchten, dass ihre Arbeit genutzt und wertgeschätzt wird. Scrum kommt Teammitgliedern zugute, indem es unproduktive Arbeit (z. B. das Schreiben von Spezifikationen oder anderen Artefakten, die niemand verwendet) reduziert und ihnen mehr Zeit für die Arbeit gibt, die ihnen Spaß macht. Teammitglieder wissen auch, dass ihre Arbeit wertgeschätzt wird, da die Anforderungen so gewählt werden, dass sie den Wert für die Kunden maximieren.
Vorteile für Produktmanager
Produktmanager, die normalerweise die Rolle des Produktbesitzers innehaben, sind dafür verantwortlich, die Kunden zufriedenzustellen, indem sie sicherstellen, dass die Entwicklungsarbeit auf die Kundenbedürfnisse abgestimmt ist. Scrum erleichtert diese Abstimmung, indem es häufige Möglichkeiten bietet, die Arbeit neu zu priorisieren, um eine maximale Wertschöpfung sicherzustellen.
Vorteile für Projektmanager
Projektmanager (und andere), die die Rolle des ScrumMasters ausfüllen, stellen fest, dass Planung und Nachverfolgung im Vergleich zu Wasserfallprozessen einfacher und konkreter sind. Der Fokus auf die Nachverfolgung auf Aufgabenebene, die Verwendung von Burndown-Diagrammen zur Anzeige des täglichen Fortschritts und die täglichen Scrum-Meetings geben dem Projektmanager insgesamt jederzeit ein enormes Bewusstsein über den Status des Projekts. Dieses Bewusstsein ist der Schlüssel zur Überwachung des Projekts und zum schnellen Erkennen und Beheben von Problemen.
Vorteile für PMOs und C-Level-Führungskräfte
Scrum bietet täglich einen hohen Einblick in den Status eines Entwicklungsprojekts. Externe Stakeholder wie Führungskräfte auf C-Level und Mitarbeiter im Projektmanagementbüro können diese Transparenz nutzen, um effektiver zu planen und ihre Strategien auf der Grundlage von mehr konkreten Informationen und weniger Spekulationen anzupassen.
Was sind die Scrum-Anforderungen?
Scrum definiert nicht genau, welche Form Anforderungen haben sollen, sondern besagt lediglich, dass sie im Product Backlog gesammelt und allgemein als „Product Backlog Items“ oder kurz „PBIs“ bezeichnet werden. Angesichts der zeitlich begrenzten Natur eines Sprints können wir auch davon ausgehen, dass die Implementierung jedes Satzes deutlich weniger Zeit in Anspruch nehmen sollte als die Dauer des Sprints. Die meisten Scrum-Projekte übernehmen die „XP“-Praxis (Extreme Programming), bei der eine Funktionsanforderung als „User Story“ beschrieben wird, obwohl eine Minderheit das ältere Konzept eines „Use Case“ verwendet. Wir folgen hier der Mehrheitsmeinung und beschreiben drei einigermaßen standardmäßige Anforderungsartefakte, die in Product Backlogs zu finden sind.
Benutzer Geschichte
Eine User Story beschreibt eine gewünschte Funktion (funktionale Anforderung) in narrativer Form. User Stories werden normalerweise vom Product Owner geschrieben und liegen in dessen Verantwortung. Das Format ist nicht standardisiert, enthält aber normalerweise einen Namen, einen beschreibenden Text, Verweise auf externe Dokumente (z. B. Screenshots) und Informationen darüber, wie die Implementierung getestet wird. Eine Story könnte beispielsweise wie folgt aussehen:
Name: Planer trägt neuen Kontakt ins Adressbuch ein, so dass man die Person später per Post oder E-Mail kontaktieren kann |
Beschreibung: Der Planer gibt standardmäßige Kontaktinformationen (Vor- und Nachname, zwei Adresszeilen, Stadt, Bundesland, Postleitzahl, Land usw.) in den Kontakteingabebildschirm ein. Klicken Sie auf „Speichern“, um die Daten beizubehalten, und auf „Abbrechen“, um die Daten zu verwerfen und zum vorherigen Bildschirm zurückzukehren. |
So testen Sie: Der Tester gibt die Daten ein, speichert sie, sucht den Namen im Adressbuch und klickt darauf. Es erscheint eine schreibgeschützte Ansicht der Kontakteingabemaske mit allen zuvor eingegebenen Daten. |
Die Elemente dieser User Story sind:
- Name: Der Name ist eine beschreibende Phrase oder ein Satz. Das Beispiel verwendet eine grundlegende „Rolle-Aktion-Grund“-Organisation. Ein anderer gängiger Stil, der von Mike Cohn populär gemacht wurde, folgt der Vorlage „Als <Benutzertyp> möchte ich <ein Ziel>, damit <ein Grund>“. Die Wahl der Vorlage ist weniger wichtig als ein praktikabler Standard irgendeiner Art.
- Beschreibung: Dies ist eine allgemeine (wenig detaillierte) Beschreibung des zu erfüllenden Bedarfs. Für funktionale (benutzerorientierte) Anforderungen wird die Beschreibung in narrativer Form verfasst. Für nicht funktionale Anforderungen kann die Beschreibung in jeder leicht verständlichen Form formuliert werden. In beiden Fällen ist es wichtig, dass der Detaillierungsgrad gering ist, da die Feinheiten während der Implementierungsphase in Diskussionen zwischen Teammitgliedern, Produktbesitzern und allen anderen Beteiligten ausgearbeitet werden. (Dies ist eines der Kernkonzepte von Scrum: Anforderungen werden auf einer Ebene angegeben, die eine grobe Schätzung des für ihre Implementierung erforderlichen Arbeitsaufwands ermöglicht, nicht im Detail.)
- Bildschirme und externe Dokumente: Wenn die Story Änderungen an der Benutzeroberfläche erfordert (insbesondere nicht triviale), sollte die Story einen Prototyp der Änderungen enthalten oder auf einen solchen verweisen. Alle externen Dokumente, die zur Implementierung der Story erforderlich sind, sollten ebenfalls aufgelistet werden.
- So testen Sie: Die Implementierung einer Story gilt als abgeschlossen, wenn und nur wenn sie alle dafür entwickelten Abnahmetests besteht. Dieser Abschnitt enthält eine kurze Beschreibung, wie die Story getestet wird. Was das Feature selbst betrifft, ist die Beschreibung der Testmethoden kurz, da die Details während der Implementierung ausgearbeitet werden müssen. Wir benötigen jedoch zumindest eine Zusammenfassung, um den Schätzprozess zu leiten.
Es gibt zwei Gründe, Informationen zum Testen der Story einzuschließen. Der offensichtliche Grund besteht darin, die Entwicklung von Testfällen (Abnahmetests) für die Story zu steuern. Der weniger offensichtliche, aber wichtige Grund besteht darin, dass das Team diese Informationen benötigt, um abzuschätzen, wie viel Arbeit für die Implementierung der Story erforderlich ist (da Testdesign und -durchführung Teil der Gesamtarbeit sind).
Geschichte
Nicht alle Anforderungen für Neuentwicklungen stellen benutzerorientierte Funktionen dar, stellen aber erhebliche Arbeit dar, die erledigt werden muss. Diese Anforderungen stellen oft, aber nicht immer, Arbeit dar, die erledigt werden muss, um benutzerorientierte Funktionen zu unterstützen. Wir nennen diese nicht-funktionalen Anforderungen „Technische Geschichten“. Technische Geschichten haben dieselben Elemente wie Benutzergeschichten, müssen aber nicht in narrative Form gebracht werden, wenn dies keinen Nutzen bringt. Technische Geschichten werden normalerweise von Teammitgliedern geschrieben und dem Produkt-Backlog hinzugefügt. Der Produktbesitzer muss mit diesen Geschichten vertraut sein und die Abhängigkeiten zwischen diesen und den Benutzergeschichten verstehen, um alle Geschichten für die Implementierung zu bewerten (zu ordnen).
Defekt
Ein Defekt oder Fehlerbericht ist eine Beschreibung eines Fehlers des Produkts, der sich nicht wie erwartet verhält. Defekte werden in einem Fehlerverfolgungssystem gespeichert, das physisch dasselbe System sein kann, in dem das Produkt-Backlog gespeichert ist, aber nicht muss. Wenn dies nicht der Fall ist, muss jemand (normalerweise der Produktbesitzer) jeden Defekt in das Produkt-Backlog eintragen, um die Reihenfolge und Planung festzulegen.
Was sind die Scrum-Rollen?
Die drei in Scrum definierten Rollen sind der ScrumMaster, der Product Owner und das Team (das aus Teammitgliedern besteht). Die Personen, die diese Rollen ausfüllen, arbeiten täglich eng zusammen, um einen reibungslosen Informationsfluss und eine schnelle Lösung von Problemen sicherzustellen.
ScrumMaster
Der ScrumMaster (manchmal auch „Scrum Master“ geschrieben, obwohl der offizielle Begriff kein Leerzeichen nach „Scrum“ hat) ist der Hüter des Prozesses. Der ScrumMaster ist dafür verantwortlich, dass der Prozess reibungslos abläuft, Hindernisse, die die Produktivität beeinträchtigen, beseitigt und die kritischen Meetings organisiert und moderiert. Zu den Aufgaben des ScrumMasters gehören
- Bringen Sie dem Product Owner bei, wie er den Return on Investment (ROI) maximieren und seine Ziele durch Scrum erreichen kann.
- Verbessern Sie die Arbeit des Entwicklungsteams, indem Sie Kreativität und Eigenverantwortung fördern.
- Verbessern Sie die Produktivität des Entwicklungsteams auf jede mögliche Weise.
- Verbessern Sie die technischen Verfahren und Werkzeuge, sodass jede Funktionserweiterung potenziell lieferbar ist.
- Halten Sie Informationen über den Fortschritt des Teams auf dem neuesten Stand und für alle Parteien sichtbar.
In der Praxis muss der ScrumMaster Scrum gut genug verstehen, um die anderen Rollen zu schulen und zu betreuen sowie andere am Prozess beteiligte Stakeholder zu schulen und zu unterstützen. Der ScrumMaster muss den Status des Projekts (seinen bisherigen Fortschritt) im Verhältnis zum erwarteten Fortschritt ständig im Auge behalten, alle Hindernisse, die den Fortschritt behindern, untersuchen und deren Lösung erleichtern und im Allgemeinen flexibel genug sein, um auftretende Probleme auf jede erforderliche Weise zu erkennen und zu lösen. Der ScrumMaster muss das Team vor Störungen durch andere Personen schützen, indem er als Schnittstelle zwischen beiden fungiert. Der ScrumMaster weist Teammitgliedern keine Aufgaben zu, da die Aufgabenzuweisung in der Verantwortung des Teams liegt. Der allgemeine Ansatz des ScrumMasters gegenüber dem Team besteht darin, dessen Entscheidungs- und Problemlösungsfähigkeiten zu fördern und zu unterstützen, damit es mit zunehmender Effizienz und abnehmendem Überwachungsbedarf arbeiten kann. Das Ziel ist ein Team, das nicht nur befugt ist, wichtige Entscheidungen zu treffen, sondern dies auch gut und routinemäßig tut.
Laden Sie das Spickzettel zur Scrum-Master-Rolle herunter
Produktinhaber
Der Product Owner ist der Verwalter der Anforderungen. Er stellt für das Team die „einzige Quelle der Wahrheit“ in Bezug auf die Anforderungen und ihre geplante Reihenfolge der Umsetzung dar. In der Praxis ist der Product Owner die Schnittstelle zwischen dem Unternehmen, den Kunden und ihren produktbezogenen Anforderungen auf der einen Seite und dem Team auf der anderen Seite. Der Product Owner schützt das Team vor Funktions- und Fehlerbehebungsanfragen aus vielen Quellen und ist der einzige Ansprechpartner für alle Fragen zu den Produktanforderungen. Der Product Owner arbeitet eng mit dem Team zusammen, um die benutzerbezogenen und technischen Anforderungen zu definieren, die Anforderungen nach Bedarf zu dokumentieren und die Reihenfolge ihrer Umsetzung festzulegen. Der Product Owner pflegt das Product Backlog (das Repository für alle diese Informationen) und hält es auf dem neuesten Stand und in der vom Team geforderten Detailliertheit und Qualität. Der Product Owner legt auch den Zeitplan für die Veröffentlichung abgeschlossener Arbeiten an die Kunden fest und entscheidet abschließend, ob die Implementierungen die für die Veröffentlichung erforderlichen Funktionen und die erforderliche Qualität aufweisen.
Laden Sie das Cheatsheet zur Rolle des Product Owners herunter
Team
Das Team ist eine selbstorganisierende und funktionsübergreifende Gruppe von Personen, die die praktische Arbeit der Entwicklung und des Testens des Produkts leisten. Da das Team für die Herstellung des Produkts verantwortlich ist, muss es auch die Befugnis haben, Entscheidungen über die Art der Ausführung der Arbeit zu treffen. Das Team ist daher selbstorganisierend: Die Teammitglieder entscheiden während des gesamten Sprints, wie die Arbeit in Aufgaben aufgeteilt und wie Aufgaben einzelnen Personen zugewiesen werden. Die Teamgröße sollte möglichst im Bereich von fünf bis neun Personen liegen. (Eine größere Anzahl erschwert die Kommunikation, während eine kleinere Anzahl zu geringer Produktivität und Instabilität führt.) Hinweis: Ein sehr ähnlicher Begriff, „Scrum-Team“, bezieht sich auf das Team plus ScrumMaster und Product Owner.
Laden Sie das Scrum Team Cheatsheet herunter
Wie können Sie mit Agile Geld sparen?
Welche agilen Metriken kann ich zum Reporting verwenden?
Was in Agile gemessen werden soll, ist die bleibende Frage. Es sollten zwei primäre Filter vorhanden sein, die wir uns stellen sollten, bevor wir etwas messen: „ Wird diese Messung die Wertschöpfung beschleunigen? “ und „ Wird diese Messung das Vertrauen stärken? “.
Unten sehen Sie ein Beispiel für eine passende agile Messung. Normalerweise setzt sich eine Organisation das Ziel, die Story Point-Geschwindigkeit zu erhöhen, und das erscheint vernünftig, da wir immer danach streben, wo möglich mehr zu liefern. Diese Perspektive betrachtet das Problem aus dem falschen Blickwinkel, da wir Wertschöpfung und nicht höhere Leistung wollen. Das ist nicht dasselbe; das eine ist ergebnisorientiert und das andere produktionsorientiert. Agile betont das Ergebnis, also die Wertschöpfung, nicht die Leistung. Wenn man Geschwindigkeitssteigerungen mit Leistung gleichsetzt, setzt man einige Dinge voraus: Die Teams arbeiten nicht hart genug und die Leistung entspricht Wert. Wobei beide Annahmen normalerweise falsch sind.
Wir sollten die Geschwindigkeit nutzen, um unser Geschäft zu führen. Eine Story-Point-Geschwindigkeit kann verwendet werden, um den Produktrückstand aufzuteilen und grob zu planen, wann bestimmte Funktionen für unsere Kunden verfügbar sein werden. Was wir tun müssen, ist, Stabilität in der Geschwindigkeit zu fördern, nicht Geschwindigkeit, die sich ändert oder im Fluss ist. In einer Welt, in der es Anreize für eine Geschwindigkeitssteigerung gibt, werden die Teams dem nachkommen und eine höhere Story-Point-Geschwindigkeit bieten. Sie werden die Story Points aufblähen, um die gewünschte Steigerung zu erreichen, was wiederum unsere Fähigkeit verringert, das Geschäft zu führen, weil die Geschwindigkeit nicht mehr von Bedeutung ist.
Auf eine etwas andere Weise könnten wir das Sagen/Tun des Sprints messen. Wir bewerten die Schätzung eines Teams, wie viele Story Points es liefern wird, im Vergleich zu dem, was es in einem Sprint leistet. Der Anreiz sorgt sofort für Stabilität in der Story Point-Geschwindigkeit, was dem Unternehmen die Möglichkeit gibt, vorherzusagen, wann Features auf den Markt kommen.
Ersteres vermittelt den Teams, dass ihnen nicht vertraut wird, und untergräbt die Wertschöpfung, während Letzteres beides fördert. Es erwischt auch Teams, die gute Leistungen erbringen, wenn ihre Schätzungen beginnen, sich der Leistung anzunähern. Ein Anstieg auf einen Sagen/Tun-Wert von Null gibt dem Unternehmen die Möglichkeit, die Geschwindigkeit zu steigern und Vertrauen innerhalb der Organisation aufzubauen. Alle gewinnen: unsere Kunden, unsere Organisation und das Team.
Beispiele für Betriebsmetriken
- Vorlaufzeit
- Zykluszeit
- Burndown-Diagramme
Beispiele für Ausgabemetriken
- Durchsatz
- Modell zur Agilitätsbewertung
- Technische Qualität / Fehlermessungen / Codeabdeckung
- Anzahl der Funktionen usw.
Beispiel für Ergebnis-/Wertmetriken
- Teammoral
- Kundenzufriedenheit / NPS
- Geschäftswert
Weitere Informationen zu Agile Metrics finden Sie in diesen Artikeln:
Personalkennzahlen: Wie jährliche Leistungsbeurteilungen schlechtes Verhalten begünstigen
Agile mit Leistungsmetriken validieren
Verwenden Sie Metriken in Agile und Scrum falsch?
Kennzahlen im Projektmanagement
Wie gehe ich in Agile mit verteilten Teams um?
Diese Frage hat zwei Dimensionen. Entweder man hat Teams mit Remote-Mitarbeitern oder man hat alle lokalen Teams, die zwar intakt sind, sich aber an unterschiedlichen geografischen Standorten befinden. Ersteres sollte man um jeden Preis vermeiden.
Intakte Teams an verschiedenen geografischen Standorten
Wie bei allen Problemen ist der Kontext eine primäre Einschränkung bei der Lösung dieses Dilemmas. Unternehmen, die diese organisatorischen Eigenschaften berücksichtigen, erzielen die besten Ergebnisse: Vertrauen und die Entscheidungsfindung dort, wo die Informationen vorhanden sind. Die Leute, die die Arbeit machen, haben die Informationen; daher ist dies ein Umstand, den die Teams selbst lösen müssen. Die Organisation muss den Ideen der Teams hinsichtlich dieser Schwierigkeit vertrauen, sie finanzieren und unterstützen.
Die Organisation muss bei allen Problemlösungen Experimente unterstützen, denn dadurch wird das Scheitern aus dem Gespräch ausgeschlossen. Experimente erfordern einen bekannten Zustand, den gewünschten Zustand und Aktivitäten, die zum gewünschten Zustand führen. Erlauben Sie den Teams, zu experimentieren, zu bewerten und sich an die neuen Erkenntnisse anzupassen, die sich aus dieser Erfahrung ergeben. Seien Sie dann bereit, einen anderen Ansatz und ein weiteres Experiment zu unterstützen.
Teams mit weit entfernten Teammitgliedern haben
Weit entfernte Teammitglieder sind für alle ärgerlich. Die Kommunikationsstörungen sind wesentlich schlimmer, was zu mangelndem Bewusstsein in Bezug auf die Entwicklung von Produkten führt.
Der vernünftigste Weg, damit umzugehen, besteht darin, alle Teams mit lokalen Mitarbeitern zu bilden. Hinterfragen Sie Ihre Denkweise, Annahmen und Einschränkungen, wenn die Bildung von Teams am selben Standort nicht möglich ist. Als letztes Mittel sollte der oben beschriebene Weg das Beste aus einer schrecklichen Situation machen.
Was ist SAFe?
Agile Entwicklung auf Team- oder kleiner Organisationsebene hat sich in den letzten 20 Jahren als wirklich wirksame Methode zur Verbesserung von Leistung, Engagement und Qualität erwiesen. Die erfolgreiche und wiederholbare Skalierung von Agile auf mittlere und große Organisationen war jedoch ein Problem. Das Scaled Agile Framework (SAFe) hat sich als führende Lösung für dieses Problem herausgestellt. SAFe ist eine Sammlung von Prinzipien, Strukturen und Praktiken, die nachweislich Agile-Praktiken konsistent und erfolgreich skaliert und die Vorteile von Agile an Organisationen weitergibt, die zuvor mit Wasserfall- oder Ad-hoc-Methoden gearbeitet haben. Tauchen Sie tief in SAFe ein, indem Sie an unserem Leading SAFe-Schulungskurs teilnehmen .
Welche Verbindung besteht zwischen Agile und DevOps?
Obwohl Agile und DevOps als unabhängige methodische Bewegungen begannen, haben sie eine Reihe von Gemeinsamkeiten, die auf die Verbesserung der Effizienz und Geschwindigkeit von Teams abzielen. Da Unternehmen agiler werden und ihre Projektmanagementfähigkeiten verfeinern, sind sie zunehmend darauf angewiesen, dass technische Teams Schritt halten und eine gewisse Flexibilität beibehalten können.
Hier kommt DevOps als „Yang“ zum „Yin“ von Agile ins Spiel. Der DevOps-Ansatz hilft Entwicklungsgruppen, neue Tools, Automatisierung und verschiedene kulturelle Strategien zu nutzen, um nicht nur ihre eigene Arbeitsweise, sondern auch die Zusammenarbeit mit anderen zu ändern. Es entsteht eine symbiotische Beziehung, in der Produktteams Hand in Hand mit Entwicklern und Testern usw. arbeiten, um sicherzustellen, dass jeder ein besseres Kontextbewusstsein hat. Dies fördert eine höhere Gesamtqualität der Ergebnisse in kürzerer Zeit.
Sollte ich Scrum, Kanban oder eine andere Variante von Agile verwenden?
Scrum ist die heute vorherrschende teambasierte Variante von Agile. Es ist über zwanzig Jahre alt und hat sich bewährt. Kanban hat seinen Ursprung in der Fertigung und wurde 1953 von Toyota eingeführt, ein weiterer langlebiger Ansatz. Außerdem gibt es verschiedene Arten von Skalierungsrahmen, die Sie berücksichtigen sollten, wenn die Größe Ihrer Organisation einer Ihrer Kontexte ist.
Der Kontext ist für die Antwort von entscheidender Bedeutung. Welche kommerziellen Anforderungen stellen Ihr Unternehmen? Wie groß ist Ihre Organisation? Wie ist Ihr Unternehmen organisiert? Sind Ihre wichtigsten Produktteams über viele geografische Standorte verteilt? Daher sind die tatsächlichen kommerziellen Probleme, mit denen Ihr Unternehmen konfrontiert ist, und die Art und Weise, wie Sie auf Ihre Kunden reagieren, für die Antwort kontextbezogen.
Die Frage „Scrum, Kanban oder eine andere agile Variante“ zu stellen, ist der erste Schritt und ein ausgezeichneter Ausgangspunkt. Die Überlegung, zu einem agilen Ansatz zu wechseln, ist der erste Schritt in Richtung Nachhaltigkeit. Wie oben beschrieben, ist Agilität eine Voraussetzung für zukünftigen Erfolg, sie ist nichts Neues. Organisationen, die keine Form von Agilität übernehmen, können nicht auf Kunden- und Marktbedürfnisse reagieren und sind deutlich im Nachteil.
Wie skaliere ich die Agile-Einführung?
Die Skalierung agiler Methoden ist eine der schwierigsten Aufgaben, da es so viele verschiedene Organisationsstrukturen gibt und die kommerziellen Anforderungen unterschiedlich sind. Dieses Bewusstsein rückt den Begriff des Kontexts in den Mittelpunkt.
Aufgrund dieser großen Unterschiede sind viele Skalierungsframeworks entstanden, und die Vorstellung, dass eine Einheitslösung für alle passt, ist eine falsche Annahme. Scrum ist das vorherrschende Teamframework; daher haben die meisten Skalierungsframeworks Scrum als Kern. Die Verwendung von Scrum als Grundlage zur Lösung von Skalierungsproblemen ist sinnvoll, da die meisten von ihnen als Technik zur Erweiterung beitragen. Beispielsweise führen die SAFe-Skalierungsframeworks Kanban ein, um die Skalierungsherausforderungen zu erleichtern, während Scrum im Mittelpunkt bleibt.
Die kritischen Probleme, die bei der Skalierung über die Teamdynamik hinaus berücksichtigt werden müssen, sind Koordination, Kommunikation, gemeinsame oder abhängige Arbeit und die räumliche Distanz von Gruppen oder Teammitgliedern. Diese Einschränkungen sind die gleichen wie bei der Teamimplementierung von Scrum. Mit zunehmender Anzahl der Teams werden sie jedoch verstärkt und sind extrem schwieriger zu lösen. Wenn eine Organisation von einer Ein-Team- zu einer Mehr-Team-Struktur wechselt, werden umfassendere Probleme offensichtlich. Dabei handelt es sich in der Regel um den Fahrplan und die Investitionsverhältnisse zwischen konkurrierenden Initiativen zur Unterstützung der Vision und der Ziele des Unternehmens.
Auch die Größe der Organisation spielt bei der Umsetzung und Einführung der Skalierungsbemühungen sowie dem ausgewählten Skalierungsrahmen eine Rolle. Ein Unternehmen mit dreihundert Mitarbeitern und eine Organisation mit Zehntausenden Mitarbeitern erfordern unterschiedliche Ansätze. Auch hier gilt wieder die Devise „eine Größe passt allen“.
Sicherlich ist die organisatorische Skalierung von Scrum eine unternehmensweite Aktivität und nicht etwas, das auf das Produktmanagement und die Entwicklung beschränkt ist, wie dies bei Scrum-Implementierungen häufig vorkommt.
Was ist der beste ganzheitliche Ansatz zur Einführung agiler Methoden?
Wenn ein Unternehmen Agile einführt, liegt der Schwerpunkt häufig auf der Engineering-Services-Gruppe, während die Zusammenarbeit mit der Produktmanagementabteilung nur am Rande erfolgt. Dieses Muster ist weit verbreitet und erklärt in der Regel, warum Unternehmen das Gefühl haben, dass sie von der Einführung von Agile nicht die erwarteten Vorteile erhalten, was die Vermutung untermauert, dass Agile nicht funktioniert.
Kommerzielle Anforderungen, Unternehmensgröße, Organisationsstruktur und eine Vielzahl anderer Überlegungen schaffen den erforderlichen Kontext für die Gestaltung eines Ansatzes zur agilen Einführung. Das mit Abstand führende Erfolgssystem erfordert die Einbeziehung aller Aspekte des Geschäfts. Systemdenken, also das Verständnis, dass alle Bereiche des Unternehmens, die Wertschöpfung erzielen, aufeinander abgestimmt sind und zusammenarbeiten, ist von entscheidender Bedeutung. Daher ist es nicht das Ziel, die Entwicklungsabteilung mit etwas Unterstützung der Produktmanagementabteilung zu bitten, agil zu werden.
Leider wird das Unternehmen höchstwahrscheinlich Umstrukturierungen und eine Änderung des Managementstils in Betracht ziehen müssen, um eine organisatorische Ausrichtung zu erreichen. Die besten Ergebnisse werden erzielt, wenn das Führungsteam offen für die Möglichkeiten der Zusammenarbeit ist und alles daran setzt. Konzentrieren Sie sich bei der Zusammenarbeit auf die Wertschöpfung und arbeiten Sie auf unterstützende Weise zusammen. Dabei sollten Sie sich darüber im Klaren sein, dass sich alle zur Unterstützung dieser Möglichkeiten neu aufstellen werden.
Beispiele hierfür sind die Umstellung der Buchhaltungsabteilung von der Kostenrechnung auf Lean Accounting. Die Personalabteilung erwägt die Umstellung auf OKRs und die Abschaffung von MBOs und KPIs. Die Unternehmenskennzahlen konzentrieren sich auf Messungen, die mit der Wertschöpfung und nicht mit der Leistung korrelieren.
Der beste Ansatz bei der Einführung agiler Methoden bezieht sich auf den Kontext Ihrer Organisation, wie oben beschrieben. Beziehen Sie dann das Führungsteam und seine Schwerpunktbereiche mit ein, um eine beschleunigte Wertschöpfung über Output und Nutzung hinaus zu erreichen.
Wie verstärke ich die Wirkung von Agile?
Indem wir eine lernende Organisation mit einem klaren Ziel entwickeln und ein Umfeld schaffen, in dem die Menschen vertrauen.
Lernende Organisation
Was bedeutet es, eine lernende Organisation zu sein? Die grundlegenden Prinzipien von Scrum sind Prüfen, Anpassen und Transparenz. Diese sind in den Scrum-Prinzipien verankert und in jedem Event als Feedbackschleifen vorhanden. Sie zielen darauf ab, so viele Lernmöglichkeiten wie möglich zu bieten und so oft wie möglich Erfahrungen zu sammeln.
Wir müssen das gesamte Unternehmen in diese Prinzipien einbeziehen, denn die größeren Vorteile von Agile hängen vom Systemdenken ab. Systemdenken gepaart mit dem Fokus auf Wertschöpfung. Wir möchten, dass die Messungen, die die Engineering-Services beeinflussen, mit dem übereinstimmen, was das Geschäft antreibt.
Klarer Zweck
Die Organisation muss einen Zweck vorgeben, der über die einzelnen Personen in der Organisation hinausgeht, ein Ziel, das über die Organisation selbst hinausgeht. Es muss jeden emotional ansprechen und der inspirierende Grund sein, warum die Leute gerne zur Arbeit kommen.
Vertrauensvolle Umgebung
Das Ziel ist, dass jeder die Möglichkeit hat, zu experimentieren und zu lernen. Experimentieren ist etwas anderes als einfach nur an etwas zu scheitern. Wenn wir ein Experiment durchführen, müssen einige Dinge definiert werden. Ein aktueller Zustand, der gewünschte Zustand und das Experiment selbst, das sich dem gewünschten Zustand nähert.
Unter diesen Randbedingungen liefert das Experiment entweder ein bestätigtes Ergebnis oder eine Nullhypothese. Und beides sind wichtige Datenpunkte, die unser zukünftiges Verhalten beeinflussen sollten.
Zusammenfassend lässt sich sagen, dass Agile ein unternehmensweiter Sport ist und nicht nur eine Tätigkeit im Bereich Ingenieurdienstleistungen. Ohne alle drei Faktoren – lernende Organisation, klare Ziele und vertrauensvolles Umfeld – werden die Auswirkungen von Agile gemindert.
Mehr lesen: Wie kann ich feststellen, ob mein Samsung Original oder Refurbished ist?
Wie haben andere Organisationen Agile erfolgreich eingeführt?
Der Kontext ist entscheidend. Der Rahmen für eine so dramatische Veränderung wie die Änderung der Arbeitsweise eines Unternehmens erfordert, dass die Mitarbeiter durch den Prozess geführt werden, anstatt sie mitzuschleppen. Einige kritische Bereiche für den Erfolg sind die Erkenntnis, dass Veränderungen schwierig sind, und die Anerkennung, dass dieses Unterfangen eine menschliche Anstrengung ist.
Der Erfolg wird gefördert, wenn die Scrum-Werte Engagement, Mut, Konzentration, Offenheit und Respekt angenommen und auf eine Weise zum Ausdruck gebracht werden, die vom gesamten Unternehmen angenommen wird, sodass sie zu gemeinsamen Werten in der gesamten Organisation werden.
Ein dynamischer Ansatz zur Suche nach Freiwilligen wird Mitarbeiter ans Licht bringen, die sich positive Veränderungen wünschen, und diejenigen aussortieren, die sich gegen Veränderungen stellen. Diese Strategie wird die organisatorischen Blockierer aus dem Übergang entfernen, da sie nicht Teil des Fortschritts hin zur neuen Betriebsmethode sind. Mit der Zeit beginnt die Veränderung sichtbare Ergebnisse zu zeigen: zufriedenere Mitarbeiter, Innovation wird ausgeprägter und die Wertschöpfung wird beschleunigt. Plötzlich entsteht eine Dynamik, da Mitarbeiter, Teams, Abteilungen und Geschäftseinheiten in Richtung des neuen agilen Betriebsmodells gezogen werden.
Das Problem der Skalierung agiler Vorgehensweisen ist monolithisch, daher ist es erforderlich, beim Team oder bei einigen Teams anzufangen. Vorsicht ist geboten, wenn Skalierungsframeworks am ersten Tag nicht angewendet werden, da dies auf lange Sicht in der Regel weniger förderliche Ergebnisse bringt.