Erleben Sie das Manifest, während Sie agil werden

In Fällen, in denen der Ausgangspunkt eine bestimmte Situation ist, wie z.B. "den Arbeitsrückstand in den Griff bekommen" oder "inkrementelle Softwareentwicklung" oder ähnliche Situationen, ist die Idee über die Existenz des Manifests und/oder der Werte, die es fördert, eher eine Sache der Entdeckung als wahrscheinlich ein Masterplan.

Da haben Sie es. Im Bereich der Softwareentwicklung gibt es immer einige Parameter, die Sie daran hindern, eine bestehende Software wiederzuverwenden und einen vorhersehbaren Plan für das Wiederverwendungsszenario zu erstellen. Von wenigen Ausnahmen abgesehen, müssen Sie in den meisten Fällen recherchieren, sich bis zu einem gewissen Grad anpassen und mit bestimmten Unbekannten umgehen. Die Erstellung eines umfassenden Plans in einer solchen Situation erfordert(etwas) Spielraum.

Lassen Sie mich zur Veranschaulichung zwei Fälle nennen, um den Punkt zu veranschaulichen.

Fall 1: Ein Softwareentwicklungsunternehmen, das mit einer Reihe von Komponenten, die ineinandergreifen, erfolgreich war, wollte diese zu einem integrierten System verweben. Die Idee war, den Geschäftswert auf nahtlose Weise zu steigern. Dieses ehrgeizige Ziel führte natürlich zu einer akribischen Planung und erschöpfte alle verfügbaren Kapazitäten, um diesen mehrjährigen Plan auszuführen und zu erfüllen. Abgesehen von den Verzögerungen und den Auswirkungen, die sich aus der Überarbeitung des Designs und der Neuplanung ergaben, stapelten sich die Arbeiten für die Unterstützung der produktiven Versionen der Komponenten und die enormen technischen Schulden. Ohne dass ein Ende in Sicht war, musste sich etwas ändern, um die Dinge wieder in den Griff zu bekommen.

Fall 2: Ein Softwareentwicklungsunternehmen machte sich daran, ein völlig neues Produkt als Ersatz für das bestehende Produkt zu entwickeln. Die Idee war, die neuesten und aufkommenden Technologien zu nutzen, um mit der Zeit zu gehen. Dieses neue Produkt sollte ein sehr flexibles und hochgradig konfigurierbares Produkt sein. Da es sich um ein so komplexes Produkt handelte, wuchs das Team im Laufe der Jahre von einigen wenigen Ingenieuren auf fast alle Mitarbeiter an (mit Ausnahme der wenigen, die mit der Wartung des bestehenden Produkts betraut waren). Am Ende dieser Zeit gab es nichts Greifbares, das man dem Kunden zeigen konnte. Es war ein anderer Ansatz erforderlich, um die Entwicklung dazu zu bringen, neben der Herstellung einer robusten Software auch einen Mehrwert für die Kunden zu schaffen.

Wie in den beiden oben genannten Fällen ersichtlich, teilten sich diese ehrgeizigen Vorhaben den Platz mit den anderen regulären Arbeiten, die mit der Pflege der bestehenden Produkte und Komponenten verbunden waren. Die Entwicklung dieser neuen Software in Silos und der Versuch, sie von Anfang bis Ende zu entwickeln, funktionierte offensichtlich nicht wie erwartet und führte wahrscheinlich zu Frustration in der gesamten Organisation.

Diese Situationen führen dazu, dass man nach einem anderen Ansatz sucht, mit dem man die halbgaren Teile zeitnah zusammensetzen kann. Das war "Reagieren auf Veränderungen statt Befolgen eines Plans" in Aktion.

Die Entscheidung fiel auf Scrum.

In einem ersten Schritt wurde ein schrittweiser Ansatz gewählt, um die halbgaren Teile schrittweise zu einer funktionierenden Software zu entwickeln, die dem Kunden einen Mehrwert bietet. Anstatt sich darauf zu konzentrieren, alle Schritte in einen Plan einzubauen oder die komplette Software-Architektur fertigzustellen, war es ein Pinsel mit funktionierender Software über der Detailarbeit. Der neue Ansatz versprach keine schnelle Lösung für alle Probleme. Er half dabei, die Probleme zu priorisieren und sie iterativ zu bearbeiten. Um sicherzustellen, dass wir auf Kurs bleiben, wurde beschlossen, mit den potenziellen Benutzern der Software zu arbeiten. Dies führte zu früherem Feedback und dazu, dass die Software für die geschäftliche Nutzung geeignet blieb, anstatt die Qualität der Software mit Hilfe von Vertragsklauseln verteidigen zu müssen. Customer Collaboration over Contract Negotiation" (Zusammenarbeit mit Kunden über Vertragsverhandlungen) und "Responding to change over following a plan" (Reagieren auf Veränderungen über das Befolgen eines Plans) wurden eingeleitet.

Ein von Anfang bis Ende ausgearbeiteter Plan und eine vollständig detaillierte Architektur sorgten für eine strenge Vorgehensweise. Alle internen Lernprozesse während der Entwicklung der Software konnten nicht die erforderliche Aufmerksamkeit erhalten, da der Plan zu starr war und nicht genügend Spielraum für Nachbesserungen und Verbesserungen bot. Mit der Umstellung auf Scrum gab es mehr Raum, um das interne Feedback ebenso zu verarbeiten wie den externen Input. Dies trug dazu bei, ein Umfeld der Zusammenarbeit innerhalb der Teams zu schaffen. Die Entwicklung der richtigen Software hatte ebenso viel Vorrang wie die Entwicklung der richtigen Software. Als die Software Gestalt annahm, wurden alle Beteiligten stärker einbezogen.

Schließlich wurden Individuen und Interaktion über Prozesse und Tools gestellt. Dies war ein Prozess der Entdeckung besserer Wege zur Entwicklung von Software. Es war eine mehrjährige Periode des Lernens der Feinheiten von Scrum und der Verbesserung der Art und Weise, wie Software besser entwickelt werden kann.