Die Folgerung, mit der man Softwareentwickler und klassische Requirement Engineers zum Kopfschütteln bringt, ist nun: Eine Schnittstelle ist kein Feature. Eine Schnittstelle hat keinen Businesswert. Gemeint ist eine Schnittstelle, z. B. zwischen zwei Systemen, dem ERP und dem Shop, dem CRM und dem PIM, dem Blog und dem CMS... (Ausnahme ist natürlich, wenn die Schnittstelle das Produkt ist. Wenn wir es packagen und verkaufen können, haben wir Wirkung damit.) Denn nur mit der Schnittstelle, kann niemand eine Wirkung erzielen. Wenn wir Bestellungen aus dem Shop ins ERP übertragen, um sie zu fakturieren, auszuliefern etc., dann erzielen wir Wirkung. Das Feature ist also “Bestellung von Shop an ERP übermitteln.” Die Schnittstelle ist nur ein Mittel zum Zweck. Wenn wir Kundenstammdaten aus der Eingabemaske ins CRM schreiben können, dann erzielen wir Wirkung. Wiederum ist die Schnittstelle nur ein Mittel zum Zweck.

Bauen wir eine Zugstrecke von Rosenheim nach München. Die Strecke geht über Großkarolinenfeld via Grafing via Baldham via Vaterstetten zum Münchener Hauptbahnhof. Was ist hier ein Feature? Womit erzielt man Wirkung? Möglichkeit A: Mit dem Kiesbett auf der Gesamtstrecke (die “Schnittstelle” zwischen Boden und Gleisen)? Oder B: Mit dem ersten Streckenabschnitt von Rosenheim nach Großkarolinenfeld.

Ich bin für Option B. Ich kann Tickets von Rosenheim nach Großkarolinenfeld verkaufen, weil Leute den ersten Abschnitt der Strecke bereits nutzen. Nach Grafing oder Baldham gibt es noch nicht einmal ein Kiesbett. Na und? Kann irgendjemand mit einem “Kiesbett only” eine Wirkung erzielen? Nein. Man nennt das inkrementelles Vorgehen, ein alter Hut. Man muss nur darauf achten, dass die Inkremente für sich genommen einen Wert haben.

Wenn man das Portfolio Board betrachtet im Bild, ein Whiteboard mit einem Sticky pro Projekt, sieht man, dass sich mit dieser Visualisierung schnell und einfach erfassen lässt, wie welches Projekt dasteht. Projekte, die geringen Fertigstellungsgrad haben, jedoch schon viel Budget ausgegeben haben, stellen ein Risiko dar. Bei Projekten, die vergleichsweise wenig Budget verbraten haben, aber schon recht weit sind in der Fertigstellung, ist es umgekehrt, solche Projekte mögen wir.

Würde sich der gesamte Wert eines Projekts erst ganz am Schluss realisieren, erst, wenn alles plötzlich magisch ineinandergreift und der gordische Projektknoten sich plötzlich löst, dann würde ich persönlich “Fortschritt” als eine nicht sinnvolle Skala empfinden. Was nutzt uns Fortschritt, wenn wir keinen Wert generieren? Das Risiko bleibt bis zum Schluss bei nahe 100%. Ja, die Schnittstelle kann sämtliche vorgesehenen API-Calls von System 1 an System 2 verarbeiten, es gibt aber kein User Interface und keine Persistenzschicht (etwa eine Datenbank), also haben wir keinerlei Wert, niemand kann etwas wirkungsvoll mit der Schnittstelle machen. Deshalb finde ich die Betrachtung sinnvoll, dass das Projekt bislang bei 0% Wert steht.

Betrachtet man ein Produkt, bzw. jedwedes gewünschte Outcome eines Projekts, als eine Schichtung verschiedener Technologien, Komponenten oder generell Wertschöpfungsaspekte, dann sind Features vertikale Durchstiche. Sie haben Wert, weil jemand etwas damit bewirken kann. Von Rosenheim nach Grafing fahren oder einen Adressdatensatz in die Applikation eingeben und speichern. Das sind Minimal Marketable Releases. Man kann jetzt zwei Stationen fahren. Man kann die Adressen manuell erfassen. Auch wenn sonst noch nichts geht.

Inkremente werden in der agilen Planung deshalb erstens als Durchstiche, zweitens als in sich abgeschlossen werthaltig und drittens möglichst klein konzipiert. Wenn man semantisch streng ist, stellt sich übrigens erst hinterher heraus, ob ein Inkrement ein Requirement war. Die 80% Features einer Applikation, die wenig oder fast nicht benutzt werden, sind nicht wirklich Requirements, wie der Name schon sagt: Man braucht sie nicht (vgl. Info “Die richtigen 20%). Die 20% Killler-Features, das sind die Requirements. Wenn man nur vorher schon wüsste, welche welche sind...

Weil man das nicht weiß, sind die Inkremente in der agilen Planung zunächst auch möglichst einfache Iterationen (sprich Varianten). Nur so können wir testen, ob wir überhaupt auf dem richtigen Weg sind. Stellt sich das Inkrement als Erfolg heraus (viele Leute nehmen den Zug von Rosenheim nach Grafing), können wir es in einer nächsten Iteration aufmöbeln, können wir eine bessere, aufwendigere Iteration angehen. In unserem Fall einen Zug mit Bar, Wellness-Wagon und unlimited WLAN einsetzen... das hab ich mir auf meinen Zugfahrten zumindest immer gewünscht.

Die richtigen 20%

Eine Studie der Standish Group, die auf einer Konferenz 2002 vorgestellt wurde, machte Furore, denn sie zeigte (angeblich), dass nur wenige Features einer Applikation von vielen Nutzern genutzt werden. Das heißt, den größeren Teil der Features baut man evtl. Umsonst... In seinem Blog berichtet Software-Guru Martin Fowler darüber: “Build only the features you need”.

Zur Ausgabe