Lean Collaboration – eine Einführungsmethode für Mutige?

Über Einführungsmethoden haben wir hier schon den einen oder anderen Artikel veröffentlicht und das Thema ist mit Blick auf unsere Kundenprojekte mittlerweile mindestens genauso heiß diskutiert wie die Auswahl der passenden Technologie.

Inspiriert von dem Buch "Lean Startup" von Eric Ries habe ich zusammen mit meinem Kollegen Frank Wolf im Rahmen unseres Digital Life Camps die Frage gestellt, was wir und unsere Kunden von erfolgreichen Webstartups lernen können. Was Social Collaboration überhaupt mit Startups gemein haben, was die Lean Startup Methode im Kern besagt und welche Rückschlüsse man daraus ziehen kann, soll heute mein Thema hier sein.

Gemeinsamkeiten von Social Collaboration und StartUps

Die Mehrzahl aller Startups wollen ein neues, mindestens jedoch ein neuartiges Geschäftsmodell etablieren. Bei Social Collaboration entspräche das einem neuem Arbeitsmodell, wie Mitarbeiter künftig zusammenarbeiten sollen. Neugründungen im Web erfordern von Gründern, Geldgebern und Kunden enormen Mut. Darüber hinaus erzeugen sie Ängste, gerade bei denen, für die der neue Service ein Umdenken erfordern müsste. (Fragen Sie mal die Taxiindustrie nach uber oder die Hotelerie nach AirBnB, Angst ist da noch untertrieben.) Eine gewisse Form von Angst treffen wir auch bei unseren Kunden an: Betriebsräte haben Angst, dass persönliche Daten zur Bewertung der Arbeitskraft von Mitarbeitern automatisch und in Echtzeit ermittelt und missbraucht genutzt werden, Manager haben Angst davor, die ihre Position sichernde Kontrolle zu verlieren und dem einen oder anderen Wissensträgern läuft es bei dem Gedanken, alles mit jedem zu teilen, kalt den Rücken runter. Und dann ist da noch die Sache mit dem Scheitern: Gefühlt verschwinden 99 von 100 Startups so schnell wie sie gekommen sind wieder von der Bildfläche. Auch wenn wir den Erfolgswert von 1% bei der Einführung von Social Collaboration in der Höhe (!) nicht bestätigen können, ist die Anzahl an gescheiterten Initiativen höher als jedem Beteiligten recht sein dürfte. In gewissen Kreisen hat sich schon das Motto etabliert: Das erste Release geht immer schief. Alles ganz schön düstere Aussichten, da hilftam Ende nur noch eins: Eine Strategie muss her. Unbestritten hilft ein planvolles Vorgehen ungemein bei der Einführung von Social Software, kann die Ableitung von Unternehmenszielen und die Identifikation eines positiven ROI hilfreich bei der Nutzenargumentation sein und gibt ein klarer Zeitplan Projektteam, Management und Sponsor Sicherheit bei ihrer Entscheidung. Aber was passiert, wenn alles durchdacht und geplant ist und die Kunden bzw. die Mitarbeiter nicht mitspielen?

Als gebranntes Kind, das selber mal versucht hat ein zwar nicht disruptives, aber schon in der Form sehr neuartiges Modell zu etablieren (Link: http://www.wunsch-los-gluecklich.de/blog/2009/03/15/a-vision-ends/) und mit Pauken und Trompeten untergegangen ist, habe ich eine Idee davon, wie es sich anfühlt die eigene Vision nicht zum Fliegen zu bekommen. Neben vielen Gründen ist einer hervorzuheben: Es war von A bis Z zu Ende geplant. Ich war mir sicher, an alles gedacht zu haben und dass ich die Welt verändern würde. Ein befreundeter Berater sagte mir damals: Das ist ja alles generalstabsmäßig geplant. Ich fühlte mich geehrt und bestätigt, heute weiß ich, das war das Todesurteil.

Die Lean-Startup-Methode in Kürze

In seinem Buch "Lean Startup" beschreibt Eric Ries eine mittlerweile etablierte Methode, Startups schnell und erfolgreich zu gründen. Es ist eine echte Leseempfehlung, daher hier nur in Kürze ein Blick auf die wesentlichen Elemente:

 

Minimum viable product

Ries propagiert so schnell wie möglich mit einem Produkt zu starten, was so gerade funktioniert. Stellenweise hat er sogar Ansätze beschrieben, wo wichtige Funktionalitäten in der ersten Phase durch "manpower" zunächst kompensiert worden sind.

Continuous deployment

Sobald neue Funktionalitäten bereit zur Freigabe sind, sollten diese so schnell wie möglich veröffentlicht werden. Je früher sie getestet werden können, desto schneller gibt es Feedback.

Split testing

A/B Test helfen gerade bei der Identifizierung der Zielgruppen und ihren individuellen Wünschen und sollten ebenfalls kontinuierlich gemacht werden.

Actionable metrics

Zahlen, Daten, Fakten: Es ist zwar alles messbar, wichtig ist jedoch, was gemessen wird. Die Gefahr, sich von falschen hohen Zahlen blenden zu lassen, ist sehr hoch.

Pivot

Startups stellen Hypothesen auf, die kontinuierlich überprüft werden müssen. In letzter Konsequenz fordert die Lean Startup Methode den kompletten Neuanfang oder sogar den Abbruch aller Bemühungen.

Innovation Accounting

Startups sollten nicht an klassischen Unternehmenskennzahlen wie Umsatz oder Marge gemessen werden, sondern mittels einer Innovationsbilanz an der Umsetzung und Akzeptanz aller Innovationen.

Build-Measure-Learn

Ziel eines Lean Startups ist es, soviel wie möglich Iterationen in einer bestimmten Zeit zu schaffen. Eine Iteration besteht immer aus der Entwicklungsphase, der Messung und dem Lernen.

 

Problem und Lösung: unbekannt

In unserer gut besuchten Diskussion ist den Beteiligten und uns eines besonders klar geworden: Im Vergleich verschiedener Projektmanagementmethoden bildet der Zusammenhang zwischen Problem und Lösung den wesentlichen Unterschied:

Im klassischen Wasserfallmodell ist das Problem klar und auch die Lösung detailliert beschrieben und bekannt (Wir ignorieren jetzt bitte die Wahrheit, dass Kunden nur glauben, ihr Problem und die passende Lösung zu kennen).

Das agile Manifest, welches in der SCRUM-Methode Anwendung findet, propagiert, das Problem zwar zu kennen, die finale Lösung aber nicht und sich dieser über Iterationen (Sprints) zu nähern.

Bei der Lean-Startup-Methode sind beide Parameter unbekannt: Man startet zwar mit einer Hypothese (Wertversprechen), aber sowohl die finale technische Umsetzung als auch der Beweis der Hypothese bleiben völlig ergebnisoffen.

Wir haben sogar noch ein viertes Szenario identifiziert: Problem ist zwar noch unbekannt, aber die Lösung ist schon fertig. Überrascht? Horchen Sie mal bei der nächsten Produktpräsentation eines Technologieanbieters ihres Vertrauens genauer hin. Und ja, auch der eine oder andere IT-Dienstleister hat für alles eine Lösung, selbst wenn das Problem noch relativ unbekannt ist. Aus bekannten Gründen wollen wir darauf jetzt aber nicht tiefer eingehen ;-)

Lean Collaboration – eine mögliche Erfolgsgeschichte?

Im folgenden direkten Vergleich versuche ich, eine erste grobe Vorgehensweise à la lean collaboration abgeleitet aus den elementaren Thesen der Methode abzubilden. Dafür liegen folgende Parameter zu Grunde:

• Es gibt weder eine gesetzte Technologie noch eine Präferenz.

• Es gibt keine Vorprojekte/Piloten oder interne Studien zu Social Collaboration.

• Die Unternehmenskultur ist geprägt von einer ausgewiesenen Fehlerkultur.

• Der Unternehmenserfolg baut auf einer lernenden Organisation auf.

 

LEAN STARTUP METHODE	LEAN COLLABORATION ANSATZ
Minimum viable product	Ein MVP zur Einführung von Social Collaboration könnte eine rudimentäre Installation einer Basissoftware sein. Weniger ist hier mehr, bei komplexen Systemen sollten eher Funktionen abgeschaltet werden und die Nutzbarkeit auf wesentliche Elemente reduziert werden. Interessant könnte hier auch die Verwendung von Open Source Enterprise Social Networks sein. Ein einfaches optisches Branding unterstreicht den Produktcharakter und sollte Bestandteil sein. Im Grunde kennen wir solche MVP im Umfeld Social Collaboration als Piloten, auch wenn diese nach anfänglicher Zurückhaltung doch schon sehr oft sehr komplett daherkommen.
Continuous deployment	Sobald erste User das MVP erobern, muss die Entwicklungsmannschaft bereit sein, Feedback aufzunehmen, zu bewerten und nach Priorisierung schnell umzusetzen. Standardsoftwareentwicklungsprozesse sollten hier auf ein Minimum reduziert werden. Es geht jetzt mal nicht vorrangig um Qualität sondern um Schnelligkeit. Neben der Softwareentwicklung empfehle ich hier zusätzlich ein Continuous Support Team, welches den Pilotnutzern zur Verfügung steht und aktiv die Einführung begleitet.
Split testing	Unterschiedliche Pilotgruppen bieten sich sehr gut an, mit verschiedenen Varianten der Social Collaboration Plattform ausgestattet zu werden, um durch A/B-Tests wichtige Erkenntnisse zu gewinnen. Denkbar wäre auch ein Unterschied je nach Zugang (mobile vs. Desktop). Spannend fände ich unterschiedliche Varianten für Wissensarbeiter auf der einen und Prozessarbeiter auf der anderen, gern auch mit mehreren Wechseln.
Actionable metrics	Wenn die Personalvertretung mitspielt (sie muss überzeugt werden!), sind Messungen keine Grenzen gesetzt. Wichtig sind hier die Identifikation und die Auswahl der richtigen KPI. Das Set muss auch kontinuierlich (weiter-)entwickelt werden.
Pivot	Full-Stop! Der wesentlichste Unterschied zu bekannten Methoden ist die absolute Bereitschaft, die Social Collaboration Piloten vollständig zu beenden und mit dem Team (Entwicklung, Support & Nutzer) in eine völlig andere Richtung zu denken und von vorne zu beginnen.
Innovation Accounting	Viele Pilotprojekte müssen heute bereits nach viel zu kurzer Zeit den Beweis erbringen, übliche Unternehmensziele bereits zu erfüllen (schneller-besser-billiger). Im Lean Collaboration Ansatz spielen diese noch keine Rolle, gezählt wird die Akzeptanz ausgerollter Innovationen.
Build-Measure-Learn	Ihr Team hat sechs Monate Zeit? Dann versuchen Sie so viele Iterationen wie möglich in diesem Zeitraum umzusetzen, je mehr, desto besser. Die ersten Zyklen dauern meist länger, zum Ende hin wird sich diese Zeit enorm verkürzen.

 

Wir sind gespannt, ob sich die Lean-Collaboration-Methode etablieren kann und werden an dieser Stelle weiter darüber berichten. Was denken Sie darüber? Bedarf es Mut oder ist es eher eine wesentlich sicherere Variante für Ängstliche? Wir sind gespannt auf Ihre Kommentare.