Innovation schön und gut…

Innovation schön und gut…

…aber bitte zu Ende denken!

Innovationsmethoden haben sich als Schlagworte und neuer Trend etabliert und die passende Beraterszene hat sich zu ihnen gerüstet. Buchen Sie einen solchen Experten, absolvieren Sie ein oder zwei Design Thinking Workshops und los geht die Fahrt in blühende Landschaften der digitalen und natürlich disruptiven Innovation. Das hört sich gut an, nicht wahr? Ganz so ist es in der Realität aber NICHT.

Der Unfug heutiger Innovationstrends: „Mal eben“

Zugegeben: Ich ertrage diese seichte Innovationbranche nicht mehr. Sie vermittelt den Eindruck, als könne man in ein paar wenigen Tagen mit Workshops die Welt revolutionieren. Klar, man kann sich mit neuen Workshop-Formaten frei von Konventionen machen, um frei zu denken. In der Realität ist die Welt aber komplexer. Auf die Schnelle lassen sich keine Machbarkeiten und Kosten berücksichtigen, vor allem aber müssen nach Entdecken der neuen Ideen dutzende Kompetenzen, Rollen und Menschen bereit sein, neu zu denken. Das erfordert in allen operativen Teams einen tief verankerten Glauben an das neue Produkt.

Im Ergebnis darf zwar eine neue, frei gedachte Produktvision nicht diskreditiert und sofort klein geredet werden. Sie sollte aber devot als Kompass verstanden werden und genug Raum für sinnvolle Kompromisse offenlassen. Außerdem braucht Innovation viel Fleißarbeit, um die Idee in echte Anforderungen zu gießen und intensive Kommunikation, um die umsetzenden Teams an Bord zu holen und zu behalten.

Um nicht falsch verstanden zu werden: Ich bin nicht gegen Neu-Denken! Ich liebe kreative, freie Ansätze, die den Kunden radikal ins Zentrum aller Produktmodellierungen stellen. Ich sehe nur tagtäglich, dass der Respekt vor der großen Arbeit, die dem kleinen Kreativ-Impuls folgen, fehlt. In Lichtgeschwindigkeit ist dann die Belegschaft abgehängt und das Projekt von Anfang an zum Scheitern verurteilt.

Werden die operativen Teams nicht abgeholt, droht fehlendes Commitment

Das Mindset von allen Beteiligten richtig ausrichten

Machen Sie sich deutlich: Es gab auch eine Welt vor der sagenhaften neuen Idee. In dieser Welt haben viele Menschen bereits lange und erfolgreich gearbeitet und auch schon für diese Ideen haben Menschen gebrannt. Es mag sein, dass diese Konzepte vormals nicht auf einen Kundennutzen konzentriert waren, sondern mangels etablierter Kundenorientierung eher aus persönlichen Bedürfnissen bestanden. So brannte ein Produktmanager beispielsweise für einen ihm nahestehenden Kunden, dessen Wünsche ihm heilig waren. Ein Entwickler wiederum identifizierte sich mit „dem einen besonderen Feature“, das unbedingt gebaut werden musste.

Das ist die Ausgangslage. Nun aber kommt eine kleine Gruppe an „Innovatoren“ aus einem Workshop mit einem teuren Berater und hat mit einer zukunftsweisenden Produktidee plötzlich die Welt neu erfunden. Der enge Kunde des Produktmanagers ist auf einmal nicht mehr Zielgruppe und das Lieblingsfeature des Entwicklers wird plötzlich nicht mehr benötigt. Was glauben Sie, wie diese beiden exemplarisch genannten Protagonisten das finden werden?

Damit sind wir bei der zentralen Herausforderung, wenn man Innovation betreiben will: Sie können nur so viel Innovation auf die Straße bekommen, wie sie Rückhalt in Ihrem Team gewinnen können.

Begegnen können Sie dieser Herausforderung nur mit zwei Mitteln:

Erstens: Seien Sie zum Start gerne so kreativ wie Sie wollen. Schließen Sie dann aber eine Pessimismus-Runde an, indem Sie ganz konkret die angedachte Lösung hinsichtlich Akzeptanz im Team bewerten und offen sind für Justierung.

Zweitens:  Kommunizieren Sie klug und taktvoll. Machen Sie einen Workshop mit allen Beteiligten, in dem Sie für die Ideen begeistern, sie aber lediglich als Impuls vorstellen und sich ehrlich und offen für Feedback zeigen. Respektieren Sie dabei, dass die Teams aus Ihren persönlichen Interessen mit Ihrer Idee kollidieren.

Beteiligen Sie Ihr Team an Umsetzungsstrategien

Wenn das Gesamt-Team einmal für die Idee begeistert wurde, geben Sie auch den operativen Teams ihren Raum innovativ zu denken. Lassen Sie konkrete Lösungsstrategien entwickeln, die der initialen Idee so nahe wie möglich kommen. Nehmen Sie die Ergebnisse – die sicherlich Abstriche beinhalten werden – ernst und verstehen Sie diese als neuen Kompass für ihr Projekt.

Im Ergebnis bekommen Sie Commitment, weil es nichts gibt, was sich Entwicklungsteams mehr wünschen und es genießen, als technisch auf grüner Wiese Neues auszuprobieren. Außerdem haben die operativen Teams nun das Gefühl Teil der neuen Vision zu sein.

Fleißarbeit: Nachhaltige Ausrichtung am Kundennutzen

Wenn Sie nun eine gemeinsame realistische Idee für das neue Produkt haben, fängt der anstrengende Teil an. Je nach Größe des Kontextes mag die eigentliche Entwicklung viele Monate oder sogar Jahre dauern. Das ist übrigens die Realität, die gerne in schnellen Design Thinking-Zyklen ausgeklammert wird. Wenn Sie nur eine kleine App entwickeln, dann seien Sie froh und überspringen dieses Kapitel. Wenn Sie aber eine große Unternehmensanwendung neu auflegen, dann sollten sie dringend weiterlesen. Jetzt kommt der Casus Knacksus.

Sobald nämlich die operative, natürlich agile, Arbeit startet, ist ohne weitere Maßnahme gesichert, dass die ursprüngliche Vision Stück für Stück verwässert wird und im Zweifel sogar untergeht. Skeptiker (die es immer gibt) finden dann doch wieder zurück zu alten Lösungsansätzen, Technik stellt sich doch als komplexer dar, als angedacht, und das Produktmanagement mag dem Druck der lauten einzelnen Bestandskunden doch nicht mehr Stand halten wollen. Es gilt also vor Start der Implementierung, verbindliche Leitplanken aufzustellen, die Subjektivität so weit wie möglich einzugrenzen und das Mindset nachhaltig aufrechtzuerhalten.

Der konkrete Kundennutzen im praktischen Anwendungsszenario gehört in den Fokus

Dieser Kompass kann nur der einmal aufgestellte Kundennutzen sein. Hier reicht aber keine Powerpoint-Präsentation mit hochtrabenden Slogans, sondern handfestes Anforderungsmanagement. Das müssen sie operativ und für alle greifbar als Prozesse aufstellen – und zwar so lange Sie noch das initiale Commitment haben.

Den Kundennutzen konkret machen

Konkret ist der Kundennutzen eine Hierarchie von Anforderungsstellern:

  1. Märkte, die adressiert werden sollen
  2. In den Märkten finden sich Szenarien, in denen Personas in bestimmten Kontext Wertschöpfung generieren
  3. Je Szenario sind konkrete Anwendungsfälle zu fixieren, die zur Wertschöpfung führen
Die harte Fleißarbeit des kundenorientierten Anforderungsmanagements

Szenarien sind wertschöpfende Arbeitssituationen mit einem konkreten Ziel, durchgeführt von Personas in einem Kontext. Personas bringen abzusehende Domain- und Digital-Kompetenz mit. Die eine mag branchenspezifische Abkürzungen aus dem FF beherrschen, die andere mag nicht mal im Umgang mit Computern gewöhnt sein. Hier spielt auch die Erwartungshaltung aus bisherigen Arbeitsabläufen eine Rolle. Der Kontext offenbart Vorgaben aus dem Umfeld und zu Visualisierungs- und Interaktionsmöglichkeiten. In einem Fall mag die Bedienung mit Handschuhen notwendig sein, im anderen mag die Wertschöpfung unter extrem zeitkritischen Bedingungen erfolgen.

Achtung: Szenarien sind nicht nur reine Nutzungsmomente! Hier mag auch Marketing zu berücksichtigen sein, zum Beispiel könnte eine Anzeigenkampagne visuell verständliche Screens erfordern. Oder Vertrieb muss als eigene Persona in der Lage sein, eine allgemein verständliche Demo abzuliefern. Und vielleicht gibt es auch Kriterien, die schlicht einen Show-Stopper für den Verkauf darstellen mögen. Denkbar wäre hier die Persona „Behördlicher Kaufentscheider“ mit speziellen Anforderungen an besondere Zertifizierung in Ausschreibungen. Ob solche wenig innovativen Anforderungen jetzt in die große initiale Vision passt oder nicht: Vielleicht kommen Sie gar nicht bis zum Benutzer, wenn Sie sich als Entwerfer einer neuen Idee vorab disqualifizieren.

In den Szenarien laufen nun konkrete Anwendungsfälle aka User Storys ab. Hier ist der allseits bekannte Faux-Pas, sie technisch und nicht am Kundenutzen zu formulieren. Erkennbar ist eine falsche Ausrichtung daran, dass das Ziel nicht direkt auf die im Szenario definierte Wertschöpfung einzahlt. Nein: Kein Benutzer möchte sich an einem System anmelden. Sein Ziel ist wohlmöglich eine Route in einer Logistikanwendung zu planen und die Anmeldung am System mag eine Notwendigkeit dazu sein. Allen Beteiligten aber muss klar sein, dass solche Notwendigkeiten den Benutzer in Wirklichkeit in der Wertschöpfungen hindern! Mit dieser Perspektive sollten Diskussionen und Priorisierungen betrachtet werden.

Um den Kundennutzen zu konkretisieren, ist es unabdingbar, die innovative Idee in genau diese Struktur von Szenarien, Personas, Kontexten und Anwendungsfällen und entlang des gesamten Lebenszyklusses des Produkts zu gießen. Darauf muss nun das gesamte Team Zugriff haben.

Steuern Sie die Kommunikation entlang des Kundennutzens

Ist die Liste der Szenarien und der Details fixiert und allen in SharePoint, Confluence oder ähnlichem verfügbar, braucht es eine permanente Referenz darauf.

Der Produkt Manager liefert ab jetzt nicht mehr nur den Wunsch nach einer Funktion, sondern auch eine Herleitung, welche Persona in welchem Kontext und Anwendungsfall welches Ziel erreichen möchte und warum dafür diese oder jene Funktion unabdingbar ist. Der Product Owner definiert Sprint Goals mit Referenz auf den Kundennutzen. User Stories werden im Refinement oder Planning entsprechend eingeordnet und die Teams für den Kundennutzen begeistert. Die umsetzenden Teams haben absolute Transparenz darüber, warum sie einen Task umsetzen sollen, idealerweise sind sogar diese Hintergründe direkt aus den Taskmanagement-Systemen verlinkt. Empfehlenswert ist auch das subtile Aushängen der Personas und Abbildungen der Szenarien auf Plakaten in den Büros.

Es darf im Ergebnis keine Anforderung geben, die nicht auf einen Anwendungsfall eines Szenarios und die damit verbundene Persona einzahlt!

Der erste Einwand, der an dieser Stelle üblicherweise geäußert wird, sind technische Basisarbeiten, die keinen konkreten Bezug zum Kunden haben. Zugegeben, zum Start eines Projekts fallen solche Arbeiten an. Aber: „Basisarbeiten“ sind das größte Einfallstor für ausufernde architektonische Diskussionen. Und zwar genau, weil der Kompass des Kundennutzens fehlt. Eine Lösung, die erfahrungsgemäß gut funktioniert, sind klar limitierte Basisarbeits-Sprints zu Beginn des Projekts. Anschließend werden „Basisarbeiten“ immer nur dann angegangen, wenn sie für ein Sprint-Goal (was sich an Szenarien und Anwendungsfällen orientiert) erforderlich sind. Ergänzen lassen sich technische Sondierungen in so genannten „Spike-Storys“. Darin können Team-Mitglieder im Sprint vor der eigentlichen User-Story in klar abgesteckten Rahmen Umsetzungsstrategien erarbeiten. Das führt im Übrigen auch zu erheblich präziserer Schätzung im Planning!

Die beiden größten Herausforderungen meistern

Der erste schwierige Teil ist die aktive Kommunikation und Entscheidungsfindung entlang des Kundennutzens. Denn hier darf eine persönliche Meinung kaum noch eine Rolle spielen. Zum Beispiel bei Diskussionen im Refinement zu abhängigen Aufgaben zur Erfüllung eines Sprint-Goals. Hier gilt es, aktiv Bezug auf die Anwendungsfälle und Personas zu nehmen. Braucht Persona ABC wirklich diese diskutierte Funktion zur Erreichung seines Ziels im Anwendungsfall XYZ? Hier sind die gut gebrieften Scrum Master gefragt. Und natürlich sehr viel Geduld mit den Teams, die sich an die neue Kommunikationskultur gewöhnen müssen.

Der zweite schwierige Teil ist die Eskalation von Abweichungen. Was, wenn ein Produkt Manager auf einer nicht legitimierten Anforderung besteht? Hier hilft nur, in Ruhe zu hinterfragen. Häufig versteckt sich hinter kurzem kritischem Kundenfeedback eine bislang unberücksichtigte Persona oder neue berechtigte Anforderungen, die sich aus dem Kontext ergeben. Dann ergänzen Sie einfach die Herleitungsdokumentation und alles ist gut. Eine gute Frage an dieser Stelle ist allerdings, wer genau in Ruhe diese Diskussion führt…Es könnte der engagierte PO sein. Oder ein Externer, der mit Erfahrung zur Seite steht. Ich kenne da jemanden 😉.

1 Comment

  • Michael Plähn

    29. November 2019 at 08:27

    Hallo,

    ein sehr interessanter Artikel, der viel der Probleme bei der Umsetzung von Veränderungen beschreibt!

    Gruß
    Michael Plähn

Post a Comment

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