Ist Lean Startup für die klassische IT geeignet und wenn ja, wie? Foliennotizen beachten.

1. LEAN STARTUP IM
UNTERNEHMEN
Wird der IT-Leiter zum
Entrepreneur?
Stefan Roock
stefan.roock@it-agile.de
Twitter: @StefanRoock
Mittwoch, 6. November 13
Abstract: Lean-Startup ist eine akzeptierte Vorgehensweise in Startups und verbreitet sich schnell in alle Bereiche, in denen innovative Produkte entwickelt werden. Aber eignet sich der Ansatz auch
für die klassische Unternehmens-IT? Können klassische Unternehmen wie Banken und Versicherungen schneller und besser auf den Markt reagieren, wenn ihre interne IT Lean-Startup benutzt? Ist
gar die Verwendung von Lean-Startup über die IT hinaus sinnvoll?
Der Vortrag diskutiert nach einer kurzen Einführung in die Lean-Startup-Prinzipien die Chancen und Einsatzmöglichkeiten von Lean-Startup für die Unternehmens-IT und darüber hinaus. Dabei wird
neben der reinen „Mechanik“ auch der notwendige Kulturwandel adressiert.

2. Dieser Vortrag
• Lean-Startup
im Unternehmen für
interne IT-Projekte?
• Können größere Unternehmen wie
Banken und Versicherungen von
Lean-Startup für die Entwicklung
ihrer internen Software profitieren?
Mittwoch, 6. November 13

3. Die Kernaussage zuerst
• Lean-Startup
im Unternehmen
anzuwenden ist logisch und naheliegend,
• und gleichzeitig total bescheuert.
• Die Frage ist nicht, ob die Unternehmen
von Lean-Startup profitieren können,
sondern ob sie bereit sind, die
Voraussetzungen dafür zu schaffen.
• Aber vielleicht kann Lean-Startup eine
Perspektive für 2025 sein.
Mittwoch, 6. November 13

4. Aber der Reihe nach....
Mittwoch, 6. November 13

5. Manni der IT-Leiter
Mittwoch, 6. November 13
Manni ist IT-Leiter in einem größeren Unternehmen. Seine Abteilung entwickelt Software für die Fachabteilungen,
damit die ihre Arbeit besser erledigen können. Manni ist unglücklich. Die Fachabteilungen wollen mehr, als seine
Abteilung leisten kann.

6. Mehr Druck
Mittwoch, 6. November 13
Zunächst hat er versucht, mehr Druck auf seine Mitarbeiter auszuüben und sie damit zu mehr Leistung zu
bewegen. Das hat die Entwicklung leicht beschleunigt, aber leider die Qualität reduziert, so dass die Entwicklung
inkl. Fehlerbeseitigung am Ende sogar länger dauerte als vorher.

7. Scrum und Kanban
Mittwoch, 6. November 13
Dann hat Manni von Scrum und Kanban erfahren und Ansätze daraus in seine Abteilung gebracht. Der Stress bei
den Mitarbeitern reduzierte sich, es wurde stärker kooperiert und die Produktivität und Qualität stieg.
Außerdem konnte er jetzt die Leistungsfähigkeit seine Abteilung explizit benennen und dadurch professioneller
mit den Anforderungen der Fachabteilungen umgehen.

8. Manni, your software sucks!
Mittwoch, 6. November 13
Jetzt wurde sichtbar, dass die entwickelten Systeme häufig gar nicht so nützlich waren und auch die
Fachabteilungen mit den Systemen nicht richtig glücklich waren. Obwohl Mannis Mannen (und Frauen) ja
entwickelt hatten, was die Fachabteilungen sich gewünscht hatten.

9. Lean Startup
Mittwoch, 6. November 13
Irgendwann stieß Manni zufällig auf Lean-Startup und las das Buch „The Lean Startup“ von Eric Ries. Manni war
fasziniert. Konnte Lean-Startup ihm helfen, Software zu entwickeln, die für die Fachabteilungen wirklich nützlich
wären?

10. „A startup is a human
institution designed to
create a new product or
service under
conditions of extreme
uncertainty.“
Eric Ries
Mittwoch, 6. November 13
Mannis IT-Abteilung ist sicherlich kein klassisches Startup. Aber Eric Ries hat eine deutlich breitere Definition
eines Startups.
Manni dachte daran, wie häufig die entwickelte Software wenig oder keinen Mehrwert schaffte. Seine Abteilung
entwickelte also auch unter Bedingungen großer Unsicherheit. Folglich müsste Lean-Startup auch für ihn
anwendbar sein.

11. Entrepreneur
Mittwoch, 6. November 13
Wenn seine Abteilung ein Startup ist, dann wäre er wohl ein Entrepreneur. Manni ließ diesen Gedanken ein wenig
auf sich wirken und betrachtete ihn aus verschiedenen Richtungen. Manni der Entrepreneur. Das fühlte sich gut
an.

12. Können wir die Software
entwickeln?
Sollten wir die Software
entwickeln?
Mittwoch, 6. November 13
Klassisch sah man das Hauptrisiko bei der Software-Entwicklung bei der Umsetzung. Konnte man die Software
überhaupt bauen und wenn ja in welcher Zeit zu welchen Kosten? Laut Lean-Startup sollte heute die
vorherrschende Frage sein, ob man die Software überhaupt bauen sollte. Adressiert die Software echte
Kundenbedürfnisse, so dass sich daraus ein Business entwickeln kann. Das mit den Kundenbedürfnissen leuchtete
Manni sofort ein. Sie hatten so oft an den eigentlichen Bedürfnissen der Fachabteilungen vorbei entwickelt.

13. Manni, your software sucks!
Check assumptions!
Mittwoch, 6. November 13
Lean-Startup sagt, dass wir ständig Annahmen darüber treffen, was die Systembenutzer wirklich brauchen und
wie diese Bedürfnisse am Besten adressiert werden können. Wir sollten auf Basis dieser Annahmen keine großen
Systeme entwickeln. Stattdessen sollten wir unsere Annahmen explizit machen und dann prüfen.

14. Check assumptions!
Build
Learn
Measure
Mittwoch, 6. November 13
Lean-Startup nutzt die wissenschaftliche Methode, um Annahmen zu überprüfen. Man beginnt mit der Annahme also dem, worüber man etwas lernen möchte. Jetzt überlegt man sich, wie man feststellen/messen kann, ob die
Annahmen stimmt oder nicht. Und jetzt überlegt man sich, was man minimal bauen muss, um die Annahme zu
überprüfen.

15. Check assumptions!
Ideas
Build
Learn
Data
Code
Measure
Mittwoch, 6. November 13
Und dann wird der Build-Measure-Learn-Zyklus vorwärts durchlaufen, um das Experiment auszuführen und zu
lernen.

16. Check assumptions!
Build-Measure-Learn
Ideas
Build
Learn
Data
Code
Measure
Mittwoch, 6. November 13
Also erzählte Manni den Fachabteilungen von Lean-Startup. Er sagte Ihnen, dass sie ihre Annahmen überprüfen
müssten und dass er ihnen dabei helfen würde.

17. Check assumptions!
Build-Measure-Learn
Ideas
Build
Learn
Data
Code
Measure
Mittwoch, 6. November 13
Aber die Fachabteilungen fragten sich nicht, welche Annahmen, sie überprüfen sollten. Sie fragten sich, was der
IT-Leiter geraucht hätte. Schließlich würden sie ihre eigene Arbeit verstehen und wüssten sehr genau, was ihre
Probleme wären. Warum sollten sie vorher nochmal mit wissenschaftlichen Experimenten prüfen, ob ihre Probleme
real wären.

18. Henry Ford: „Wenn ich die Menschen gefragt hätte, was
sie wollen, hätten sie gesagt: ,schnellere Pferde‘.“
Mittwoch, 6. November 13
Manni war ratlos. Dann stieß er auf ein interessantes Zitat von Henry Ford. Das bedeutet doch, dass die Kunden
selbst nicht unbedingt mit innovativen Ideen ankommen.

19. Kano-Modell
Mittwoch, 6. November 13
Manni erinnerte sich an das Kano-Modell der Kundenzufriedenheit. In diesem Modell werden drei Arten von
Anforderungen/Features unterschieden. Die Leistungsfeatures („performance“) sind die, die die
Kundenzufriedenheit linear steigern. Je mehr, desto besser. Für diese Features können die Kunden direkt
Anforderungen formulieren. Dann gibt es noch die Basisanforderungen. Diese werden im System erwartet, häufig
aber gar nicht explizit formuliert. Wenn sie fehlen, ist der Schaden aber sehr groß. Und dann gibt es noch die
Begeisterungs-Features (delight). Diese werden von den Kunden nicht erwartet und können daher von ihnen auch
nicht angefordert werden. Fords Zitat bezog sich auf Begeisterungsfeatures.

20. Kano-Modell
Lean
Startup
häufige
Produktdemos,
z.B. Scrum
Mittwoch, 6. November 13
Und Manni erkannte: Für Leistungsfeatures ist es in der Tat nicht besonders nützlich. Man würde seine Annahmen
vermutlich zum überwiegenden Teil bestätigt finden. Und bisher hat man mit den Fachabteilungen in erster Linie
auf der Ebene von Leistungsanforderungen interagiert. Häufige Produktdemos können helfen, sicherzustellen,
dass die Leistungsanforderungen in geeigneter Form umgesetzt wurden.

21. Kano-Modell
Lean
Startup
häufige
Produktdemos,
z.B. Scrum
Lean
Startup
häufige
Produktdemos
Mittwoch, 6. November 13
Bei den Basisanforderungen ist ebenfalls nicht das Hauptproblem, dass Annahmen nicht zutreffen würden. Das
Problem ist, dass sie nur unterbewusst vorhanden sind und daher nicht genannt werden. Wenn sie erstmal explizit
gemacht wurden, ist i.d.R. sofort klar, ob und in welcher Form sie benötigt werden. Fehlende Basisanforderungen
können gut durch frühe und häufige Produkt-Demos (ggf. mit Prototypen) entdeckt werden, z.B. indem man
Scrum verwendet.

22. Kano-Modell
Lean
Startup
Lean
Startup
häufige
Produktdemos,
z.B. Scrum
Lean
Startup
häufige
Produktdemos
Mittwoch, 6. November 13
Die Ideen für Begeisterungsanforderungen müssten aber woanders oder auf andere Art entstehen als heute. Und
dann könnte man Lean-Startup vermutlich sehr gut einsetzen, um zu prüfen, ob die generierten Ideen etwas
taugen.

23. Lean-Startup != Innovation
Mittwoch, 6. November 13
Allerdings ist Lean-Startup kein Ansatz, um innovative Ideen zu generieren. Lean-Startup hat lediglich den
Anspruch, schlechte Ideen, schnell als solche zu entlarven.
Zunächst müsste man also herausfinden, wie man zu diesen innovativen Ideen/Begeisterungsfeatures kommt.
Also vertiefte sich Manni wieder in Bücher und das Internet.

24. Design Thinking, Innovation Games, Participatory Design
„Group Genius“
Mittwoch, 6. November 13
Und er fand neue Ansätze wie Design-Thinking und Innovation Games sowie deutlich ältere Ansätze wie
Participatory Design.
Was allen diesen Ansätzen gemein ist, ist die enge Kooperation zwischen verschiedenen Disziplinen wie
Fachabteilungen und Entwicklern. Und er las das Buch „Group Genius“, das mit vielen Studien erklärte, warum die
Kooperation für Innovation so wichtig ist.

25. Innovation
Mittwoch, 6. November 13
Also erklärte Manni den Fachabteilungen und den Entwicklern kooperative Innovationstechniken und brachte
Fachabteilungen und Entwickler zusammen, in der Hoffnung, dass sie dann Ideen für Begeisterungsfeatures
entwickeln würden. Tatsächlich entwickelten sich viele neue Ideen, viel mehr als man jemals umsetzen könnte.
Also beschloss Manni, Lean-Startup-Techniken zu verwenden, um die schlechten Ideen auszusieben.

26. MVP: Minimum Viable Product
VP
M
„The MVP is that version of the product that enables a full turn of the
Build-Measure-Learn loop with a minimum amount of effort and the
least amount of development time.“
Eric Ries
Mittwoch, 6. November 13
Um Ideen zu testen, bietet Lean-Startup das Konzept des Minimum Viable Product (MVP).

27. hoch
MVP-Typen
Das Produkt
Concierge MVP
Produkttreue
Software Prototyp
Beta
Video
Papier-Prototyp
Papier-Skizze
niedrig
Feature Fake
Interview
AdWords-Anzeige
wenige
Reichweite
viele
Stefan Roock
Mittwoch, 6. November 13
Manni fand heraus, dass es viele verschiedene MVP-Typen gibt. Einige sind sehr schnell und einfach herzustellen
und haben daher vielleicht kaum Ähnlichkeit mit dem späteren Produkt (z.B. Papier-Prototyp). Mit anderen kann
man sehr viele potenzielle Kunden erreichen (z.B. AdWords). Dafür wird der Feedback-Kanal dünner. Mit MVPs, die
eine sehr große Reichweite haben, kann man nur herausfinden, ob Kunden auf den MVP ansprechen oder nicht.
Wenn sie nicht ansprechen, kann man aber nur schlecht herausfinden, warum nicht.
Insbesondere die MVPs mit hoher Reichweite bei geringer Produkttreue schienen Manni für sein Vorhaben wenig
geeignet. Er hat eine prinzipiell überschaubare Menge von Kunden/Anwendern. Diese können in die hunderte
gehen, aber selten in die zig-tausende. Und er hat die E-Mail-Adressen und Telefonnummern der potenziellen
Kunden/Anwender.

28. Manni, your software still sucks!
Mittwoch, 6. November 13
Mannis Entwickler arbeiteten mit Interviews und Papier-Prototypen, um ihre Ideen/Begeisterungsfeatures zu
validieren. Die Fachabteilungen sprachen darauf an und die Entwicklung begann. Erstaunlicherweise waren die
Anwender mit dem dann gelieferten System immer noch nicht richtig zufrieden.

29. ?
Mittwoch, 6. November 13
Manni war verwirrt. Nun hatten sie alle ihre Annahmen mit MVPs validiert und trotzdem war die Software kein
Erfolg. Was hatte er übersehen?
Da erinnerte sich Manni an eine Problem-Klassifikation von Lehman aus seinen Studienzeiten.

30. Lehman: S-Probleme (S = Specification)
Problem
z.B.
QuadratzahlBerechnung
Specification
formaler
Korrektheitsbeweis
möglich
Program
formaler
Korrektheitsbeweis
möglich
Mittwoch, 6. November 13
S-Probleme (sogenannte Spezifikationsprobleme) sind welche, zu denen man eine vollständige Spezifikation
erstellen kann. Die Spezifikation kann man dann in ein Programm überführen. Man kann formal beweisen, dass
die Spezifikation korrekt ist und dass das Programm der Spezifikation entspricht.
Mathematische Berechnungen wie die Quadratzahl-Berechnung sind S-Probleme.

31. Lehman: P-Probleme (P = real world Problems)
Heuristik
notwendig
Problem
Specification
Program
z.B.
Schach
formaler
Korrektheitsbeweis
unmöglich
formaler
Korrektheitsbeweis
möglich
Validierung unter
Laborbedingungen
Mittwoch, 6. November 13
P-Probleme (sogenannte Real-World-Problems) unterscheiden sich von S-Problemen dadurch, dass der
Problembereich zu umfangreich ist, um ihn komplett in einer Spezifikation auszudrücken. Daher muss man beim
Erstellen der Spezifikation Heuristiken anwenden. Ein Beispiel ist ein Schach-Programm. Theoretisch könnte man
eine vollständige Spezifikation erstellen, die alle möglichen Zug-Kombinationen durchrechnet. Das würde für die
Praxis aber zu lange dauern und daher nimmt man bestimmte Abkürzungen vor und rechnet nur die
erfolgsversprechendsten Züge durch.
Für die Überführung der Spezifikation in das Programm kann man einen formalen Korrektheitsbeweis
durchführen. Der ist aber nur von begrenztem Wert, weil man nicht theoretisch prüfen kann, ob die Spezifikation
ein angemessenes Modell des Problems darstellt. Das gelingt nur dadurch, dass man das Programm ausführt und
darüber validiert, dass Spezifikation und Program angemessen sind. Diese Validierung kann unter
Laborbedingungen stattfinden (z.B. indem man gegen das Schachprogramm spielt).

32. Lehman: E-Probleme (E = Embedded problems)
Problem
z.B.
Software zur
Optimierung
interner
Sachbearbeitung
Specification
Program
ung im
li dier
Va
etrieb
Echtb
Mittwoch, 6. November 13
E-Probleme (sogenannte Embedded Problems) teilen mit den P-Problemen die Unsicherheit bei der Erstellung der
Spezifikation. Im Gegensatz zu P-Problemen, reicht eine Validierung unter Laborbedingungen aber nicht mehr
aus. Das Program wird in der Problemdomäne eingesetzt und verändert sie. Die dadurch entstehenden Effekte
kann man nicht sicher vorhersehen. Daher kann die endgültige Validierung immer erst im Echtbetrieb erfolgen.

33. System einsetzen früh und häufig
Mittwoch, 6. November 13
Jetzt fiel es Manni wie Schuppen von den Augen. MVPs sind gut und schön. Bei E-Problemen (und damit hat Manni
es fast ausschließlich zu tun) müssen zusätzlich möglichst früh echte Systemversionen in den Echtbetrieb
gebracht werden - und sei es nur für einen Teil der Anwender. Nur so kann man abschätzen, welche Effekte
auftreten werden und welche Modifikationen an der Software noch notwendig sind. Lean-Startup ergibt also nur
mit einer kurzzyklischen Entwicklungsmethode wie Scrum Sinn und auch nur dann, wenn Produktinkremente
häufig eingesetzt werden.
Jetzt hatte Manni ein rundes Bild. Er war zufrieden.

34. hoch
einige MVPs können
Feedback aus dem
Produktivbetrieb liefern
Das Produkt
Concierge MVP
Produkttreue
Software Prototyp
Beta
Video
Papier-Prototyp
Papier-Skizze
niedrig
Feature Fake
Interview
AdWords-Anzeige
wenige
Reichweite
viele
Stefan Roock
Mittwoch, 6. November 13
Neben dem echten Produkt sind insbesondere Concierge MVP und Beta-Versionen sind geeignet, um Feedback
aus dem Produktivbetrieb zu erhalten.

35. Der Traum ist aus...
...die Vision treibt an!
Mittwoch, 6. November 13
Und dann wachte Manni aus seinen Tagträumen auf. Jetzt hatte er eine Vision: Fachabteilungen und Entwickler
würden kooperieren, um Software zu entwickeln, die echte Bedürfnisse adressierte und für das Unternehmen
einen merklichen Unterschied ausmachen würden. Die Fachabteilungen würden sich über neue Software freuen
und die Entwickler Stolz auf ihre Arbeitsergebnisse sein. Und der Vorstand würde die IT nicht mehr als
Kostenfaktor sehen, sondern als wichtigen Faktor der Wertschöpfung.
Und neben dieser Vision hatte Manni und einen sehr, sehr langen Weg vor sich. Und je mehr er über die Vision
nachdachte, desto länger erschien ihm der Weg.

36. Wir müssten uns
ernsthaft für den
Kunden interessieren.
Vertrieb
Dev
Abteilungszweck (KPI)
Marketing
Wert für Kunden
Mittwoch, 6. November 13
Test
...

37. Ein langer Weg...
• Kulturwandel
• Kulturwandel
• Kulturwandel
• Strukturen
anpassen
• Prozesse
anpassen
Mittwoch, 6. November 13
Fachabteilungen und Entwickler würden nicht einfach so miteinander kooperieren. Dafür wäre ein Kulturwandel
notwendig.
Fachabteilungen und Entwickler würden ihre eigenen Ideen nicht einfach so in Frage stellen und mit Experimenten
überprüfen. Dafür wäre ein Kulturwandel notwendig.
Die Wertschöpfung für das Unternehmen müsste einen größeren Stellenwert haben als lokale Optimierung von
Abteilungen und politische Spielchen. Dafür wäre ein Kulturwandel notwendig und vermutlich müsste man auch
Strukturen anpassen.
Fachabteilungen und Entwickler müssten zunächst kooperativ miteinander arbeiten, um zu innovativen Ideen zu
kommen - bevor es Fachkonzepte oder Lastenhefte gibt. Das müsste möglich sein, ohne den heute üblichen
schwerfälligen Budget-Bewilligungsprozess zu durchlaufen. Dafür wären Änderungen an den internen
Unternehmensprozessen notwendig.

38. Ein langer Weg...
• Kulturwandel
• Kulturwandel
• Kulturwandel
• Strukturen
anpassen
• Prozesse
anpassen
„Um das Mögliche
zu erreichen,
müssen wir das
Unmögliche
versuchen.“
Hermann Hesse
Mittwoch, 6. November 13
Diese ganzen Änderungen... Das schlug Manni gewaltig auf die Stimmung. Aber dann erinnerte er sich an ein
Hermann-Hesse-Zitat: „Um das Mögliche zu erreichen, müssen wir das Unmögliche versuchen.“ Das gab ihm
wieder Mut und er entschloss, sich der Aufgabe zu stellen.

39. Entrepreneur
Change Agent
Mittwoch, 6. November 13
Manni wurde klar: Er würde absehbar kein Entrepreneur im Unternehmen werden. Zunächst müsste er ein Change
Agent werden, um die Änderungen im Unternehmen zu bewirken, die notwendig sind, um Lean-Startup überhaupt
einsetzen zu können.

40. „Veränderungen? Kann ich schon!“
Mittwoch, 6. November 13
Glücklicherweise war das keine ganz neue Aufgabe für Manni. Mit der Einführung von Scrum und Kanban für die
Entwicklung hatte er bereits Veränderungen der Strukturen und Kultur in seiner Abteilung eingeleitet.
Prinzipien von Scrum und Kanban auf der nächsthöheren Ebene sollten beispielsweise geeignet sein, um die
Kooperation zwischen Fachabteilungen und Entwicklern noch weiter zu stärken - auch schon vor der eigentlichen
„Auftragserteilung“ durch die Fachabteilung.
Und wenn Manni mit einen Portfolio-Kanban-Board für Transparenz auf Ebene ganzer Projekte oder Initiativen
sorgen würde, könnte damit weiteres Vertrauen zu den anderen Managern im Unternehmen aufgebaut werden.
Und auf Basis dieses Vertrauens könnten Änderungen am Budget-Prozess doch möglich werden. Aber das ist eine
andere Geschichte...

41. Die Erlaubnis zum Andersein
Mittwoch, 6. November 13
Ein Weg, den Unternehmen erfolgreich gehen, läuft über Inkubatoren: Es wird eine Kapsel im Unternehmen
etabliert, die die Erlaubnis hat, anders zu sein als der Rest des Unternehmens. In unserem Fall würde man also ein
Startup im Unternehmen gründen. Das damit verbundene Risiko kann man über Sandboxing begrenzen: es
werden Randbedingungen gesetzt (z.B. in Form von Budget, Team, verfügbarer Zeit und Ziel) und die Akteure in
der Sandbox könnten in diesem Rahmen vollkommen frei entscheiden. Das kann man auch dauerhaft installieren,
z.B. in Form eine Agile Software Studios.

42. Fazit
•
•
•
Man muss die Software produktiv nutzen, um die Auswirkungen seriös
bewerten zu können (E-Probleme).
• Das sollte man bei der Wahl der konkreten MVPs beachten.
Lean-Startup ist keine Innovationstechnik, sondern eine effiziente
Ideen-Vernichtungsmaschine.
Die ergibt nur Sinn, wenn man auch innovative Ideen hat
(Begeisterungsanforderungen).
Lean-Startup muss mit geeigneten Innovationstechniken kombiniert
werden (z.B. Design-Thinking).
Die Innovationstechniken funktionieren nur kooperativ.
Letztlich führt wohl kein Weg an Organisationsentwicklung vorbei.
•
Kooperation stärken.
•
•
•
Mittwoch, 6. November 13

43. Lean Startup im Unternehmen
charmant
einleuchtend
Mittwoch, 6. November 13
totaler
Unsinn
vielleicht
in 10 Jahren?

44. Vielen D
ank für
die Aufm
erksamk
eit
Stefan Rooc
k
stefan.roock
@it-agile.d
e
Tel. 0172/4
29 76 17
@StefanRo
oc k
Mittwoch, 6. November 13
Wir beraten Sie gerne in den angesprochenen Techniken: Scrum, Kanban, Portfolio-Kanban,
Unternehmensentwicklung, Kulturwandel, Lean-Startup, Design-Thinking, Innovation Games, etc.
Sprechen Sie uns an: stefan.roock@it-agile.de, Tel. 0172/429 76 17, http://www.it-agile.de, http://
www.stefanroock.de