In agilen Projekten ist „Waste“ (dt. Abfall) ein unerwünschtes Nebenprodukt. Die Produktvision ändert sich, Kunden sind unzufrieden mit einem Feature oder das Business hat plötzlich andere Erwartungen an das Produkt: All dies führt manchmal dazu, dass bestehende Komponenten überflüssig werden. Doch wie verhindert man Waste? Kann man ihn sinnvoll recyclen, falls er trotzdem anfällt?
„Waste“ ist ein unerwünschtes Nebenprodukt der agilen Entwicklung, mit dem Sie sich beschäftigen sollten. Durch agile Entwicklung sind Sie zwar schneller in der Lage, ein brauchbares und nützliches Produkt zu veröffentlichen, jedoch sind die kürzeren Entwicklungszyklen bis hin zum brauchbaren Produkt auch stärker beeinflusst von kurzfristigen (und daher oft fehlgeleiteten) Entscheidungen.
Die agile Entwicklung verleitet die Verantwortlichen während der Entwicklung eines Produktes dazu, aktuelle Pain Points aus dem Kundenfeedback oder aus dem Business zu priorisieren. Im nächsten Sprint einen Button einfügen, der die fehlende Funktion ergänzt, die sich die Kunden wünschen? Für das Content-Team ein neues Element einbauen, damit sie kurzfristig ihre Werbekampagne fahren können? Die Datenbank um eine neue Tabelle erweitern, damit Daten fürs interne BI-Tool angereichert werden können? Vermutlich kennen Sie solche Fälle. Die Lösung wird gebaut und die Stakeholder und Kunden sind glücklich. Der Nachteil an solchen Entscheiden ist, dass damit der Fokus auf kurzfristigen und vor allem kurzsichtigen Erfolgen beruht und in vielen Fällen damit die Vision auf das langfristige Ziel vernachlässigt wird, da der Griff zur „low hanging fruit“ erfolgssicherer ist.
5 mögliche Ursachen für Waste in agilen Projekten:
1. Das auftraggebende Unternehmen plant ohne klare / ohne kommunizierte / ohne realistische Produktvision
2. Prioritäten des Marktes ändern sich durch geändertes Kundenverhalten / geänderte Regulatorien / geänderte Marktbedingungen
3. Technologien erringen den Durchbruch / werden ersetzt / werden nicht weiter unterstützt
4. Entwicklern fehlt die Erfahrungen im Produkt / in der Programmiersprache / in der eingesetzten Technologie
5. Prozesse oder Anforderungen sind nicht klar / sind abhängig voneinander / werden überflüssig
Was ist die Konsequenz dieser Ursachen? Bestimmt kennen Sie dieses bekannte Bild des crisp.se Blog-Autors Henrik Kniberg, mit dem er den agilen Entwicklungszyklus veranschaulicht. Durch den im Bild illustrierten MVP-Ansatz („Minimum Viable Product“, dt. minimal brauchbares Produkt) wird ein Produkt in verschiedenen Stufen entwickelt. In seinem Beispiel handelt es sich beim entwickelten Auto zwar um ein physisches Produkt, jedoch kann dieses Beispiel auch für die Softwareentwicklung verwendet werden.
Auf den ersten Blick scheinen seine vorgeschlagenen Entwicklungsschritte schlüssig zu sein. Der Kunde hat nach 5 Entwicklungszyklen und 5 Inkrementen ein ausgereiftes Produkt erhalten, welches seine Bedürfnisse komplett befriedigt. Wenn man die Inkremente genauer analysiert, erkannt man, wie viel Waste zwischen den einzelnen Ausbaustufen anfällt. Es wurde Zeit in Komponenten investiert welche im fertigen Produkt nicht mehr gebraucht wurden. Ergo: Es wurde ein grosser Haufen Waste produziert. Ich habe dies im folgenden Bild veranschaulicht:
Waste entsteht dann, wenn für einen Entwicklungsschritt Komponenten entwickelt werden, welche keinen längerfristigen Verwendungszweck haben. Zugegebenermassen ist diese Illustration etwas fern von der Realität und realer Komponenten (bspw. hat das Auto keine Scheinwerfer), doch im Kern erkennen Sie sicherlich an, dass man die Entwicklungsschritte hätte optimieren können.
3 Optionen, um Waste zu verringern, bevor er anfällt
1. Revision
Die Produktverantwortliche Person (oder das Team) muss eine klare Vision vom Produktumfang haben. Darin ist festgehalten, was das Produkt können soll und auch was es nicht können soll. Halten Sie ein Produktversprechen fest, was das Produkt den Kunden bringt. Setzen Sie die Entwickler über die Vision und das Versprechen in Kenntnis und nennen Sie den Entwicklern die erwarteten Kennzahlen (Anzahl Nutzer, Transaktionen, Aufrufe, etc.) welche für Ihre Produktvision relevant sind. Definieren Sie Standards für Inhalte und Design zusammen mit den Stakeholdern, damit das Produkt trotz inkrementeller Entwicklung einen roten Faden zeigt. Hierbei helfen unter anderem Design Patterns (bspw. Atomic Design), ein Textglossar und weitere standardisierte Bausteine.
2. Restructure
Skizzieren Sie, wie die Produktstruktur im Kern aufgebaut sein muss, damit sie erweiterbar bleibt. Dabei sind die nach innen gerichteten Themen wie die Architektur und eingesetzte Technologie ebenso entscheidend wie die nach aussen gerichteten Themen: Legen Sie fest, wie die Bedien- oder Menüstruktur aufgebaut sein muss, damit sich der Kunde auch bei fortlaufender Erweiterung noch zurechtfindet und den Kontext der Inhalte versteht. Menschen haben grosse Mühe damit, wenn sich die gewohnten Strukturen laufend ändern. Es ist hilfreich, sich an bestehenden und etablierten Modellen zu orientieren, statt diese neu zu erfinden. Entwickeln Sie ein Datenstrukturmodell und reduzieren Sie es auf das nötigste, um unnötige Daten zu vermeiden oder später aufwändig migrieren oder transformieren zu müssen.
3. Reprioritize
Holen Sie Kundenfeedbacks ein und versuchen Sie das zugrunde liegende Bedürfnis Ihrer Kunden zu erkennen. Oft enthalten die Feedbacks Hintergrundinformationen, welche sich nur mithilfe des grösseren Kontext verstehen lassen. Stellen Sie Rückfragen, wenn nötig, und dokumentieren Sie die Erkenntnisse. Dies hilft, Ihre Ressourcen nicht in Komponenten zu stecken, welche im nächsten Iterationsschritt wieder überflüssig werden. Priorisieren Sie diejenigen Komponenten, welche Sie langfristig einsetzen können, ggf. mithilfe eines Priorisierungsschemas mit „Ausbaustufen“ im Projekt. Das Produktmanagement bei der Pistor AG nutzt hierfür beispielsweise die „SUPI“-Regel.
3 Optionen, um angefallenen Waste zu reyclen
1. Revive
Die Verwendung von Code in anderen Applikationen ist ein Weg, um Komponenten, welche im aktuellen Produkt keine Verwendung mehr finden, trotzdem etwas Nützlichem zuzuführen. Identifizieren Sie die verwertbaren Komponenten und prüfen Sie deren Verwendung in anderen Applikationen. Entwickelt sich ein interner Unternehmenszweig, welcher davon profitieren könnte? Gibt es Start-Ups, denen Sie mit Ihrer Komponente unter die Arme greifen könnten? Könnte daraus sogar ein eigenständiges Produkt entwickelt werden, welches als OpenSource veröffentlicht oder sogar verkauft werden könnte (siehe Punkt 3. Resell)? Falls sich keine solche Möglichkeit abzeichnet, entfernen Sie die Komponente aus dem Produkt um keine ungewollten Seiteneffekte zu provozieren oder sogar potenzielle Sicherheitslücken zu öffnen.
2. Refactor
Die Komponente stösst an ihre Grenzen oder kann die erwarteten Möglichkeiten technisch nicht liefern, ist aber essenziell für das Produkt. Identifizieren Sie das Kundenbedürfnis und versuchen Sie, die problematischen Komponenten auszutauschen, um dem Produkt wieder Mehrwert zu verschaffen. Ersetzen Sie die eingesetzte Technologie wenn nötig und setzen Sie auf etwas Neues nach einer ausführlichen Analyse. Investieren Sie direkt in ein Upgrade, wenn es sich anbietet. Prüfen Sie, ob die bisherigen Komponenten anderweitig eingesetzt werden können (siehe Punkt 1. Revive).
3. Resell
Prüfen Sie, ob man Teile davon oder ein eigenständiges Produkt lancieren und verkaufen kann, wenn die Komponente oder sogar das Produkt nicht mehr gebraucht wird und kein interner Einsatzzweck dafür gefunden werden kann. Falls es keine Bedenken oder Risiken gibt, können Sie die Komponenten oder das Produkt auch unentgeltlich veröffentlichen. Neben der Anerkennung und Dankbarkeit, die der Entwickler oder die Firma für die Veröffentlichung ernten kann, ist es auch ein Zeichen der Wertschätzung an die OpenSource-Community. Viele der heute weltweit eingesetzten Komponenten stammen von frei verfügbaren Quellen ab. Ihre Komponenten können so unter Umständen Teil von etwas viel Grösserem werden.
