Was ist agil? Eine Philosophie, die sich durch Praxis entwickelt

Ursprünglich für Softwareentwicklungsteams konzipiert, ist Agile heute der führende Projektmanagementansatz für Branchen und Unternehmen auf der ganzen Welt. Der Reiz liegt in seiner Einfachheit und Flexibilität: Agiles Fehlen von vorgeschriebenen Praktiken macht es sehr anpassungsfähig. Und doch habe ich bei der Leitung agiler Transformationen in mehreren Unternehmen festgestellt, dass diese Flexibilität auch zu Missverständnissen darüber führt, was es bedeutet, agil zu sein. Viele Unternehmen geben der Einhaltung von Agile-abgeleiteten Frameworks Vorrang vor dem Verständnis der Philosophie selbst.

Stattdessen sollten Projektmanager und Coaches, die agile Teams zusammenstellen und leiten, damit beginnen, sie darin zu schulen, eine agile Denkweise anzunehmen und im Wesentlichen die Grundwerte und Prinzipien der Philosophie zu verinnerlichen. Nur dann sollten sie Praktiken aus agilen Frameworks kombinieren, anpassen oder weglassen, je nachdem, was den Projektanforderungen am besten entspricht.

Indem er die historische Entwicklung von Agile nachzeichnet und seine Gründungsprinzipien mit den spezifischen Bedürfnissen von Unternehmen und Teams verknüpft, kann dieser Artikel Projektmanagern helfen, eine optimale Zukunft für agile Transformationen zu schaffen. Wie die folgenden Fälle zeigen, sollte Agile nicht ausschließlich als Projektmanagementansatz betrachtet werden, sondern als Produktentwicklungsphilosophie, die sich in der Praxis kontinuierlich weiterentwickelt.

Agile Vorgeschichte

Das erstmals 2001 zusammengestellte „Manifest für agile Softwareentwicklung“, eine prägnante Sammlung von vier Grundwerten und 12 Prinzipien, war eine radikale Antwort auf lineare, prozesslastige Ansätze, die mit Regeln und Unmengen von Dokumentation beladen sind. Aber die Geschichte von Agile begann Jahrzehnte zuvor mit einer Methode zur Rationalisierung der industriellen Fertigung.

Das Plan-Do-Study-Act-Modell, ein Vorläufer der Philosophie für ihren Fokus auf iterative Verbesserung, wurde in den 1930er Jahren vom Physiker und Statistiker Walter Shewhart von Bell Labs entwickelt. Nach dem Zweiten Weltkrieg wandte sein Schützling W. Edwards Deming es an, um Manager bei Toyota auszubilden. Die Methode war ein integraler Bestandteil der Entwicklung des Toyota-Produktionssystems, der Hauptquelle des Lean-Denkens mit seiner effizienten Bau-Mess-Lern-Schleife.

In den 1970er Jahren wurde das Konzept weiterentwickelt, als Barry Boehm die Breitband-Delphi-Technik vorschlug, bei der ein iterativer Prozess verwendet wurde, um den Arbeits- und Zeitaufwand für die Entwicklung von Software genau und objektiv abzuschätzen.

Mit der Verbreitung von PCs Mitte der 1980er Jahre wurde klar, dass Software als Produkt und Dienstleistung zum Eckpfeiler der Art und Weise werden würde, wie Menschen Geschäfte machen. Als Fachleute begannen, sich ernsthaft mit inkrementellen, iterativen Ansätzen im Software-Engineering zu beschäftigen, übertraf Agile Wasserfallprozesse als überlegenen Entwicklungs- und Managementansatz.

Forscher fanden heraus, dass Hersteller, die schneller innovativ waren als ihre Konkurrenten, eine multidisziplinäre, teamorientierte Methode einsetzten, um ein Produkt durch seinen Lebenszyklus zu führen. Dies wird weithin als Jeff Sutherlands Inspiration für die Erfindung des Scrum-Frameworks im Jahr 1993 angesehen, das es ihm ermöglichte, scheinbar unmögliche Projekte termingerecht und unter Budget mit minimalen Fehlern abzuschließen.

Agile Werte in der Theorie – die sich aus diesen Vorläufern ergeben – haben sich in meiner Anwendung von Agile in der Praxis bestätigt, wobei der Schwerpunkt auf iterativer Entwicklung, kollaborativer Teamarbeit und genauer Schätzung liegt.

Was ist Agilität in der Theorie?

Wenn Unternehmen weiterhin agile Arbeitsweisen übernehmen, riskieren sie, sie präskriptiver zu machen, als es die Verfasser der Philosophie jemals beabsichtigt hatten. Meiner Erfahrung nach konzentrieren sich Führungskräfte, die Agile einführen möchten, zu sehr auf die Rahmenbedingungen – oder Sätze spezifischer Praktiken und der damit verbundenen Nomenklatur – und nicht genug auf die Werte und Prinzipien.

Wie Praktiker, die fortgeschritten in der Vermittlung agiler Prinzipien sind, wissen, muss jede Organisation, die eine agile Transformation anstrebt, geeignete Ansätze finden und anpassen. Ich fördere diesen Lernprozess, indem ich Teams zeige, wie sie die Werte und Prinzipien des Manifests befolgen können, und mich dann von den Frameworks wie Scrum, Kanban und Extreme Programming (XP) inspirieren lasse, um sie in der Praxis umzusetzen.

Die Grundsätze des Manifests sind agilen Projektmanagern mittlerweile in Fleisch und Blut übergegangen:

1. Individuen und Interaktionen über Prozesse und Tools
2. Funktionierende Produkte über umfassende Dokumentation
3. Kundenzusammenarbeit über Vertragsverhandlungen
4. Auf Veränderungen reagieren, anstatt einem Plan zu folgen

Der Vorbehalt, der diesen Grundsätzen im Manifest folgt, wird jedoch oft übersehen: „Das heißt, während die Elemente auf der rechten Seite einen Wert haben, schätzen wir die Elemente auf der linken Seite mehr.“ Viele agile Praktiker ignorieren schließlich die Werte auf der rechten Seite und konzentrieren sich nur auf das, was auf der linken Seite steht. Das Ergebnis? Das Gegenteil zum blinden Folgen prozesslastiger Frameworks: überhaupt kein Prozess, was ebenso problematisch ist.

Das richtige Gleichgewicht zwischen den Elementen auf der rechten und linken Seite zu finden, ist zum Schlüssel dafür geworden, wie ich agile Transformationen leite. Dies wird auch durch die Managementansätze bei Apple, Google, Amazon, Facebook und Netflix veranschaulicht, von denen sich keiner einem einzigen Agile-Framework verschrieben hat. Sie haben in erster Linie die Prinzipien des Manifests verkörpert, während sie Teile verschiedener Frameworks befolgten oder veränderten, je nachdem, was für sie am besten funktionierte; Dadurch haben sie sich an Marktveränderungen angepasst und sind in der Lage, neue Produkte schnell zu liefern.

Was ist Agilität in der Praxis?

In der folgenden Übersicht habe ich die ursprüngliche Formulierung der Werte des Manifests modifiziert. Änderungen an der Semantik helfen zu verdeutlichen, wie ich agile Werte in der Praxis anwende.

Beim ersten Wert ersetze ich den Begriff „Individuen“ durch „Menschen“, denn Agilität bedeutet Teamorientierung. Was das zweite betrifft, ist es offensichtlich, dass Software „funktionieren“ muss, sodass der Fokus jetzt auf einer erfolgreichen und rechtzeitigen „Lieferung“ liegt. Der dritte Wert ist einfach „Zusammenarbeit“, da er gleichermaßen für die Zusammenarbeit von Kollegen und Teams gilt, die mit Kunden arbeiten. Schließlich ersetzt „Frameworks“ „einem Plan folgen“, weil dies dem Missverständnis vorbeugt, dass Planung ganz aufgegeben werden sollte.

Menschen über Prozesse

Agile Transformationen sind schwierig, vor allem, weil die meisten Unternehmen daran gewöhnt sind, Prozesse strikt zu befolgen. Das Abschließen einer bestimmten Anzahl von Schritten mit einem bestimmten Satz von Werkzeugen, anstatt ein innovatives Produkt zu entwickeln, wird zum Endziel.

Ich war bestürzt zu sehen, dass diese Mentalität zu einer profitablen „agilen Industrie“ geführt hat. Wie die Agile-Gründer Ward Cunningham und Jon Kern erklären, verkaufen viele Unternehmen Software, von der sie behaupten, dass sie Unternehmen dabei hilft, „agil zu werden“. Aber agil zu werden bedeutet, eine Philosophie zu übernehmen, keine Software zu verwenden und dem Programm zu folgen, das sie vorschreibt.

Um das richtige Gleichgewicht zu erreichen, geht es nicht darum, Verfahren zu eliminieren, sondern diejenigen zu finden, die die Entwicklungsziele jedes Teams am besten unterstützen. Für einen meiner Kunden, ein großes Technologieunternehmen, habe ich Disciplined Agile implementiert, einen bei IBM entwickelten Ansatz. Es kombiniert viele Praktiken aus mehreren Frameworks, einschließlich Scrum und Kanban. Es nutzt iterative Entwicklung, ist aber etwas prozesslastiger als traditionelles Agile, insbesondere in der Anfangsphase, da es dazu gedacht ist, Lücken zu schließen, die Scrum hinterlassen hat. Disciplined Agile arbeitete für diesen Kunden, weil die Organisation sehr prozessorientiert war. Es ermöglichte mir, die Teams auf halbem Weg zu treffen, ihre Zustimmung zu erhalten und sie davon zu überzeugen, einen Scrum-Workflow einzuführen.

Ich habe Backlog-Refinement-Meetings, Review-Meetings und tägliche Scrums eingebaut, um die Zusammenarbeit innerhalb und zwischen den Teams zu erleichtern. Backlog Refinement ist Teil des Scrum Guides, aber Refinement Meetings nicht. Ich habe diese hinzugefügt, um ein gesundes Gespräch darüber zu ermöglichen, warum wir geplant haben, bestimmte Funktionen in kommenden Sprints zu implementieren, was für Agile-Neulinge hilfreich ist. Ich habe auch die Nomenklatur „Meilensteine“ gewählt – ein Begriff, der im Wasserfall-Projektmanagement verwendet wird – weil er dem Kunden vertrauter war. Reviews und tägliche Scrum-Interaktionen sind herkömmliche Elemente aus dem Scrum Guide, aber ich habe sie in Bezug auf Zeitplan, Dauer und Ablauf strukturierter gestaltet.

Während bei einer strikten Einhaltung von Scrum jede Person vollständig einer der im Scrum-Leitfaden aufgeführten Rollen zugeordnet wäre, gab es außerdem Personen in den Teams meiner Kunden, deren Fähigkeiten nicht genau in eine Rolle passten. Die Anwendung der Disciplined Agile-Methode ermöglichte es mir, die Verantwortlichkeiten dieser Positionen auf mehrere Teammitglieder aufzuteilen und einen Prozess zu schaffen, der die Stärken der beteiligten Personen berücksichtigt.

Softwarelieferung über Dokumentation

Ein weiterer Grund, warum ich angepasste Scrum- oder Kanban-Workflows der strikten Einhaltung eines bestimmten Frameworks vorziehe, ist, dass sie mir die Möglichkeit geben, das Minimum Viable Product (MVP) als Ziel in den Plan aufzunehmen. Die von Lean abgeleitete Praxis, ein MVP zu erstellen, steht im Einklang mit der iterativen Entwicklung und ist zu einer beliebten Technik unter agilen Praktikern geworden. Es ermöglicht einem Team, qualitativ hochwertige Software und andere Waren effizient an Benutzer zu liefern und sie dann basierend auf Feedback zu verfeinern. Die Anwendung als Teil eines hybriden Ansatzes, der weitgehend auf Scrum oder Kanban basiert, hat die Fähigkeiten meiner Teams verbessert, Produkte zu entwickeln, die die Anforderungen der Kunden erfüllen.

Ich arbeite derzeit mit einem in den USA ansässigen Startup zusammen und wende diese Methode beim Aufbau eines Kryptowährungsmarktplatzes für NFTs an. Wir konzentrieren uns auf die Erstellung des MVP, also schreiben wir nur die minimal benötigte Dokumentation. Während dieser Ansatz für eine breite Palette von Produkten effektiv ist, ist er besonders nützlich für Kryptowährungen und NFTs, die zu einer neuen, experimentellen Kategorie gehören, die sich schnell ändert. Anstatt vollständige Spezifikationen und Funktionen zu entwerfen und sie vor der Veröffentlichung wiederholt ändern zu müssen, können wir diese Zeit darauf verwenden, Benutzerfeedback einzubeziehen, um unsere Marktplatzentwicklung zu verbessern.

Zusammenarbeit über Verträge

Die oben erwähnte große Enterprise-Tech-Organisation stützte sich bei vielen Fixkostenprojekten stark auf Verträge. Die Verträge umrissen die Methoden, die sie zur Fertigstellung der Arbeit verwenden würden, sowie die spezifischen Personen, die für jede Aufgabe verantwortlich sein würden. Einmal unterschriebene Verträge ließen sich nicht ohne langwierigen Antragsprozess ändern.

Ein Teil der Transformation, die ich leitete, priorisierte die Zusammenarbeit gegenüber diesen starren Vereinbarungen. Der von uns umgesetzte Plan ersetzte die Verträge durch einseitige Dokumente. Alle erklärten, dass wir uns bereit erklärt hätten, Agile für die Zusammenarbeit – mit unseren Kunden sowie unseren Teamkollegen und Kollegen aus verschiedenen Teams – zwischen festgelegten Start- und Enddaten zu verwenden. Was auch immer aus der Zusammenarbeit herauskam, würde das Ergebnis sein. Ich habe keine Angaben darüber gemacht, was die fertigen Produkte sein könnten. Da wir Kundenfeedback erbeten und es in unsere Produktentwicklung einbezogen haben, hat uns das Entfernen von Spezifikationen aus unserem Plandokument empfänglicher für ihre Antworten gemacht und sie dazu angeregt, aktiver mit uns zusammenzuarbeiten.

Um das Management an Bord zu holen, bat ich sie, mich einen Proof of Concept mit einem kleinen Team leiten zu lassen, das mit einem kleinen Kunden zusammenarbeitet, der Bedenken geäußert hatte, dass die Entwicklungszeiten zu lang seien, noch bevor erforderliche Änderungen das Problem verschlimmerten. Indem wir diesen Kunden direkt mit unserem Product Owner zusammenarbeiten ließen, konnten wir während der Entwicklung Änderungen vornehmen und die Lieferzeiten erheblich verkürzen.

Diese Ergebnisse überzeugten das Management, mich den Plan in mehr Teams einführen zu lassen. Insgesamt verkürzten der optimierte Vertrag und unser agiler Workflow die Zeit, die für die Entwicklung und Markteinführung von Produktfunktionen erforderlich war.

Anpassungsfähigkeit über Frameworks

Ein anderer Kunde von mir, ein Health-Tech-Unternehmen, hat es ebenfalls versäumt, ein Gleichgewicht zwischen der Anerkennung der Bedeutung beider Seiten eines agilen Werts zu finden, nämlich der Reaktion auf Veränderungen gegenüber der Befolgung eines Plans. In diesem Fall hatte es jedoch das Gegenteil von dem Fehler gemacht, den mein Enterprise-Tech-Kunde gemacht hatte: Anstatt einem Prozess zu starr zu folgen, hatte es die Flexibilität überindexiert und den Prozess weitgehend vernachlässigt. Die Ingenieure wussten selten, woran sie arbeiten sollten, da es keine Priorisierung oder einen Zeitplan gab. Sie verloren Zeit und Produktivität, wenn sie jeden Tag versuchten, das herauszufinden, und erledigten weniger wichtige Aufgaben vor wichtigeren.

Ich schlug dem CEO und dem CTO die Implementierung von Scrum vor und erklärte, dass Sprints die Ingenieure dazu zwingen würden, diszipliniert zu sein und in Zwei-Wochen-Schritten zu planen, anstatt zu entscheiden, woran sie jeden Tag arbeiten. Außerdem riet ich ihnen, einen Product Owner einzustellen, der die mangelnde Produktverantwortung des Teams beheben würde. Ich bat die Führungskräfte, mir drei oder vier Monate Zeit zu geben, um mit ihren Teams zu arbeiten, bevor sie mit Ergebnissen rechnen konnten.

Nachdem ich ihre Zustimmung erhalten hatte, stellte ich zunächst agile Werte und Prinzipien vor und schulte das Team dann in Bezug auf das Produkt-Backlog und die verschiedenen Techniken, um es zu arrangieren, einschließlich der Erstellung von Epics und User Stories und der Erstellung von Unteraufgaben. Die Techniken und Meetings, die wir in unseren Workflow aufgenommen haben, sind Abweichungen vom traditionellen Scrum, da sie nicht im Scrum Guide erscheinen. Ich habe sie in den Plan integriert, weil die Epics, Stories und Subtasks während des Trainings bei den Teams Anklang fanden und die Meetings produktive Diskussionen förderten.

Ich habe auch das Konzept der Geschwindigkeit aufgenommen, eine späte Ergänzung zu XP, die die Schätzungen des Gesamtaufwands für alle User Stories in jeder Produktiteration misst. Ich habe jedoch den Begriff „Kapazität“ verwendet, den ich bevorzuge, da er eher betont, wie viel Arbeit Teammitglieder aufnehmen können, als wie schnell sie Aufgaben erledigen können.

Zur Schätzung begann ich mit der T-Shirt-Größenbestimmung, einer Technik, die Projekte und Aufgaben als klein, mittel und groß misst; Als das Team Fortschritte machte, wechselte ich zu Story Points, einer traditionelleren Schätztechnik. Story Points werden oft von Teams missbraucht, die in Agile nicht eingeweiht sind, die versuchen, sie in Arbeitsstunden oder -tage umzuwandeln, sich übermäßig auf Zeitrahmen konzentrieren und Menschen nach ihrer Fähigkeit beurteilen, Fristen einzuhalten.

Die Größenbestimmung von T-Shirts ist abstrakter, was es für Teams einfacher macht, diese Fallstricke zu vermeiden. Allerdings ist es auch ungenauer. Sobald das Team verstanden hatte, wie man relativ schätzt, stellte ich es auf die anspruchsvollere Technik um.

Als das Team zwei Sprints abgeschlossen hatte, konnte die Geschäftsleitung feststellen, dass ihre Mitarbeiter produktiver arbeiteten und effektiver kommunizierten. Die Entwickler arbeiteten zum ersten Mal mit Stakeholdern und der Geschäftsleitung zusammen. Sie hatten das Kundensupport-Team getroffen und verstanden, wie die von ihnen implementierten Funktionen das Leben der Benutzer verbesserten.

Dieser Ansatz führte bald zu einer Steigerung der Qualität der Software des Unternehmens und einer Verkürzung der Lieferzeit für neue Funktionen von Monaten auf Wochen.

Was ist die Zukunft von Agile?

Die COVID-19-Pandemie hat eine neue Realität geschaffen, in der Teams nicht mehr am gleichen Ort untergebracht werden konnten, was die bevorzugte Art war, innerhalb von Agile zu arbeiten, als es konzipiert wurde. Dass dies so bleiben muss, ist jedoch ein Mythos: Da Remote-Arbeit alltäglich geworden ist, ist klar geworden, dass eine enge Kommunikation mit Videokonferenz-Software durchaus möglich ist. Die Teams, mit denen ich jetzt arbeite, sind vollständig verteilt, und ich führe Schulungen aus der Ferne durch. Einige Teams entscheiden sich sogar dafür, asynchron zu arbeiten, indem sie Tools wie Notion und Loom sowie Slack-Plugins wie Standuply verwenden.

Das verteilte Modell der Zusammenarbeit ist die neue Arbeitswelt, in deren Zentrum Agilität steht. Die Work-Life-Balance, die Remote-Teams geboten wird, wirkt sich positiv auf die Moral und das geistige Wohlbefinden aus, was die Produktivität und Qualität steigert; Es stellt Menschen über Prozesse und ist flexibel und anpassungsfähig, was es durch und durch agil macht.

Agile Coaches, Scrum-Master und Projektmanager sollten zu den Wurzeln der Philosophie zurückkehren und sie so präsentieren, wie es die Verfasser des Manifests getan haben: ein flexibles und dynamisches Set von Entwicklungs- und Bereitstellungsrichtlinien. Sie sollten Führungskräften und Teamleitern beibringen, dass sie sich zwar vom Projektmanagement inspirieren lassen, aber in Agile nicht wirklich etwas verwalten – sie führen Teams und geben ihnen die Möglichkeit, ihr Bestes zu geben.