Wochen von Entwicklung ersetzen Stunden von Papier-Prototyping

Eine der wichtigsten Prüfungen ob ein Unternehmen agil verstanden hat, ist, in einem Team jemanden Beliebiges zu fragen was sie gerade für ein Problem lösen. Häufig erhalte ich als Antwort eine sehr technische Beschreibung eines aktuellen Lösungsansatzes. Aber manchmal, wenn ich Glück habe, weiß die Gefragte direkt, worum es wirklich geht: ein konkretes Problem des Kunden zu lösen.

Warum es häufig nicht um diese Kundenziele geht, rätseln viele Organisationen. Wie man endlich den Kunden in den Mittelpunkt stellt fragt man sich. Und dann isoliert man die Teams von den tatsächlichen Endnutzern, zwängt sie in ein enges Korsett aus sinnlosen Metriken und verteilt Verantwortung in winzigen Dosen. Auch die Organisation muss verstanden haben was Agile bedeutet.

Alles hat seinen Anfang im Chartering, der Aufstellung, ob der Organisation, des Produktes oder einzelner Projekte. Hier setze ich die Tonart, in der die gesamte Arbeit gespielt wird.

Und so hoch ich das Thema Vision in so einer Situation hänge, es geht noch viel einfacher. Mit dem Papier-Prototyp.

Mit einem Papier-Prototyp löse ich das Kundenproblem, ohne einen Rechner auch nur anzufassen. Keine Zeile Code, keine spezialisierten Werkzeuge, keine standardisierten Prozesse. Ein Kunde muss her, und hier erkenne ich relativ schnell wie direkt die hochgepriesene Kundennähe tatsächlich ist. Hat der Kunde dem Team das Problem beschrieben machen sie sich direkt an die Lösung – und nutzen dafür, was sie schon zur Verfügung haben. Ein klares Ziel für den Sprint, alle Kompetenz im Team und direkter Zugriff auf den Kunden, mehr braucht es häufig nicht.

Ein Beispiel für den Sinn eines Papier-Prototypen lieferte vor einigen Jahren ein Investor auf Twitter. Ein Team war auf ihn zugekommen um 50000$ einzuwerben. Ihr Ziel: Drohnen und eine Software zu entwickeln, die mittels modernster Kameratechnik Acker analysieren, Nährstoffe und Defizite aufstellen und daraus einen Bericht für den Landwirt generieren können. Der Investor fragte zurück, ob sie den selben Bericht bereits auf konventionelle Weise verkauft hätten. Das Team verneinte, der Investor lehnte ab. Das Team hatte vor lauter Lösungen das Problem aus den Augen verloren.

Ein anderes Beispiel habe ich diese Woche selbst experimentell geliefert. Eine Userin auf Twitter wünschte sich einen Bot (die Drohne der 2020er) der automatisch erkennt, welche Unternehmen in der BILD inserieren, um sie meiden zu können. Mein erster Impuls war, dass dies sicher eine tolle Fingerübung für ein kleines Python Projekt wäre. Aber bevor ich mich prospektive Wochen mit der Entwicklung beschäftige wollte ich einen Papier-Prototyp erstellen.

Da ich die Zeitung nicht über Gebühr unterstützen wollte, nahm ich mir 2 Stunden, in denen ich auf der Website und diversen Artikeln notierte, wo und welche Unternehmen vertreten waren. Diese Recherche hätte ich für die Entwicklung ohnehin machen müssen, denn wenig überraschend tun Bild ihr Möglichstes, Anzeigen und Inhalte miteinander zu vermischen. Dennoch hatte ich nach einer Weile rund 70 Unternehmen zusammen, die Werbung auf der Seite veröffentlichen.

Über die entstandene Tabelle hätte man den Bot sicherlich gut anlernen können, aber anstelle in die Entwicklungsumgebung ging ich zu Twitter rüber, wo die ursprüngliche Anfrage herkam. In rund 20 Posts stellte ich dort meine Ergebnisse vor, und das Feedback war eindeutig: ich hatte das eigentliche Problem vieler User erkannt und gelöst. Ja, der Bot kann eine Veränderung der Zusammensetzung einfacher erkennen als wenn ich meine Infos händisch sammle. Aber auch dieser muss upgedatet werden; ein Aufwand, der in keinem Verhältnis zu dem bereits geschaffenen Nutzen steht.

Jede Lösung ist ein Experiment. Je größer die Komplexität des Problems, desto größer die Wahrscheinlichkeit, dass ich etwas Großes bewegen kann, Mehrwert schaffe den vor mir niemand geschaffen hat. Aber mit steigender Komplexität steigt auch das Risiko zu scheitern, in die falsche Richtung zu laufen, an die Grenzen der Machbarkeit zu gelangen oder am Ende nicht genug Kunden zu finden um die Entwicklung zu rechtfertigen. Je früher ich diese Umstände erkenne, desto besser. Lieber im ersten Sprint erkennen, dass ich keinen Markt habe, als nach einem halben Jahr. Im Best Case baue ich natürlich auf den Erkenntnissen des Papier-Prototyp auf und habe ein Team, das intim mit dem Kunden und seinem Problem vertraut ist. Oder habe das Problem bereits gelöst und kann zum nächsten Projekt übergehen.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.