SlideShare ist ein Scribd-Unternehmen logo
Einfangen
eines
technisch
kaputten
Projektes
Johann: Hallo!

Erfolg kann jeder, und wenn man Konferenzen trauen darf, dann besteht unser Leben praktisch nur aus welchen. Aber man lernt mehr aus Katastrophen.
Wer war schon
einmal in einem
Katastrophen-
Projekt?
Johann:

Frage an das Publikum: Wer von Euch war schon einmal in einem Katastrophenprojekt? Projekte, in denen Dinge langsam werden, Interessen unklar sind und man sich
gerne und viel streitet? Die Zielstellungen unklar sind?
Wir auch.
Uns geht das nicht besser. Wir, das sind :

Andreas Goschler - Chief Product Manager bei myDriver und verantwortlich für die Produktentwicklung unserer Chauffeurservice-Vermittlungsplattform

Johann-Peter Hartmann - CTO, Chief Tailwind Officer bei Mayflower und gerne da mit dabei wo es brennt.
Wie man mit lauter
richtigen Schritten
zur einer
kaputten Plattform
kommt.
Andreas: Katastrophen passieren nie mit Absicht und nur selten aus Dummheit. Und auch in unserem Fall war jeder einzelne Schritt sinnvoll, auch wenn die Summe aller
Schritte zu einer schwer wartbaren Software geführt hat.
Andreas: myDriver ist der jüngste Mobilitätsdienst aus dem Hause Sixt.
2012.
Andreas: Wie haben wir begonnen? Mit einem klassischen Businesscase ca. 10 Wochen vor Jahresende wollten wir uns mal anschauen, ob man in dem gerade neu
entstehenden Markt der Taxivermittlung etwas machen kann.
0
12500
25000
37500
50000
Fahrzeuge
Taxi Chauffeurservices
?
Andreas: Während es bei den Taxis bereits eine ganze Reihe von Startups gab die erfolgreich in der Vermittlung tätig waren, gab es bei den Chauffeurservices in
Deutschland noch gar nichts - obwohl diese zahlenmäßig mit 2/3 der Anzahl Taxis nur unwesentlich weniger stark vertreten waren
Andreas: Der Businesscase war währenddessen im Ausland quasi validiert - der Erfolg von Uber in den USA und Addison Lee in London hat uns bestärkt auch in diesen
Markt zu einzusteigen.
7 Wochen.
Andreas: Innerhalb von 7 Wochen wurde die Applikation mobil und als Website entwickelt und im Januar 2013 in Deutschland gelauncht.
Johann: Wie kann man so eine Software schnell liefern? 

Die Frage können die Vorredner von Rocket und Project A am besten beantworten - indem ich einen fertigen Baukasten verwende - in diesem Fall den von Sixt, bei dem
die meisten Funktionalitäten von Payment über Billing und Reservierung schon existieren.
Januar April Juli Oktober Januar
Fahrten
Andreas: Sofort nach Launch ging es mithilfe von Marketingmassnahmen steil bergauf. Unser Service stieß sowohl auf Kunden wie auch auf Fahrerseite auf reges
Interesse und die Anfangseuphorie war bei allen riesig.
Januar April Juli Oktober Januar
Fahrten
Panik!
Andreas: Die ersten Monate waren wir natürlich vollkommen damit beschäftigt unser Serviceversprechen einzulösen. Allerdings war schnell klar, dass die Kunden - die
wir über Marketing akquirierten - die kamen nicht wieder von sich aus zurück und dass das finanziell nicht so lange Sinn macht - erschließt sich von selbst.

Genau das ist der Moment, in dem die eigene Roadmap nicht mehr von einem selbst kommt, sondern vom Kunden bzw. Allen die meinen zu wissen was man braucht.
Es ist zwar klar, dass es zu wenig Wiederkehrer gibt, aber warum sie nicht wiederkommen ist unklar.
Januar April Juli Oktober Januar
Fahrten
Feature A?
Feature B?
Feature C?
Andreas: Was macht man in dem Moment? Man bewirft die Software mit Features. Features von denen man meint, dass der Kunde sie unbedingt braucht. Faktisch weiß
man noch nicht, welche funktionieren werden.
Mitte-Ende 2013:


Development
wird langsam
Andreas: nachdem man die Software eine Weile mit Features beworfen hat kommen die Features immer langsamer, und es passieren immer mehr Bugs.
„Die Developer
müssen
schneller
liefern!
Andreas: Was passiert also? Die Developer werden aufgefordert mehr zu liefern, jetzt kommt es nämlich darauf an.
Abhängigkeiten
+ 

Technische Schulden =

Kein Fortschritt.
Sorry …<3
Die Entwickler können das aber nicht - sie sind nicht wirklich flexibel in Ihrer Bewegung, und sie können nur im Rahmen dessen navigieren was die Legobausteine der
alten Systeme erlauben. 

Dazu kommen technische Schulden - immer wenn es eilig wird geht die Qualität verloren. Technical Debt macht die ganze Entwicklung nicht nur langsamer, sondern
erzeugt auch mehr Bugs in der Arbeit - die dann wiederum selbst noch für eine Verlangsamung sorgen.
Druck!
Andreas: Das Entwicklung bringt also nicht die Performance die es braucht - erster Lösungsansatz ist mehr Druck. Das funktioniert auch kurzzeitig, versagt aber auf der
mittleren Strecke. Und zwar meist schon nach sehr kurzer Zeit.
Resultat:
Die Performance sinkt
nach einem initialen
Anstieg weiter.
Johann: Druck auf Softwaredeveloper hilft nur begrenzt weiter - am Anfang steigt die Lieferfähigkeit, und auch Überstunden resultieren in mehr Features. Das geht etwa 4
Wochen gut, dann flaut die Mehrleistung nicht nur ab, sondern man landet sogar unterhalb dem Torniveau - denn die technische Qualität ist einmal mehr deutlich
gesunken.
Mehr Leute!Andreas: Die zweite Strategie ist in der IT auch nicht eben unüblich - wenn ich mehr Features über Zeit will, erhöhe ich die Zahl der beteiligten Leute.
Brooks Law:
„Adding manpower
to a late software project
makes it later"
(Un)bekannt seit 1975.
Johann: Eigentlich ist Brooks Law schon von 1975, doch seltsamerweise hat es sich noch lange nicht in deutsche Managementetagen herumgesprochen. Ich kann den
Featurefluss nicht schnell erhöhen indem ich neue Leute in das Projekt nehme. Ganz im Gegenteil - es wird langsamer, und diese Verlangsamung kann durch für ein
halbes Jahr gelten, bevor das Projekt durch die neuen Kollegen an Fahrt gewinnt, manchmal geschieht dies auch nie.
Resultat:
Die Performance sinkt
weiter, jetzt aber teurer.
Johann: Fazit daraus - die Performance sinkt immer noch, die Kosten sind allerdings gestiegen.
Featuredruck
Lieferfähigkeit
Viel Aktion, wenig Resultat.
Johann: Und am Ende befindet man sich in einer Situation, in der der Featuredruck immer mehr steigt, die Lieferfähigkeit immer kleiner wird. 

Die übliche Antwort darauf: Aktionismus - es werden mehr Dinge probiert, andere Leute, andere Techniken. Solche Projekte werden auch Deathmarch, also
Todesmarschprojekte genannt - da gibt es sogar ein Buch mit genau diesem Titel zu.
Chaos
Johann: Als Management denkt man: Liebes Development, jetzt wird es gerade wirklich wichtig, und Ihr performed überhaupt nicht. Was soll ich denn bitte noch tun?
Chance
Johann: Und wenn Du lange genug im Chaos steckst und nichts nachhaltig den gewünschten Erfolg bringt - dann tut sich faktisch eine Chance auf.
Featuredruck
Lieferfähigkeit
Johann: Wenn ich einen Schritt zurücktrete ist die Lösung doch eigentlich ganz offensichtlich: Ich muss die Lieferfähigkeit nach oben bringen und den Bedarf reduzieren.
Das sagt sich jetzt leicht. Wie erreiche ich das?
Hosen runter & 

Shareholdersupport
Andreas: In unserem Fall haben wir den gesamten, angehäuften Bedarf schonungslos auf den Tisch gelegt und damit ein Bewusstsein geschaffen dass wir hier auf ganz
viele lose Enden blicken. Konkret waren da Features für B2C Kunden, Features für B2B Kunden, ellenlange Wunschlisten der angeschlossenen Fahrer, aus dem BI, dem
Marketing, dem Accounting, der Operations etc. etc.

Ab diesem Moment wussten wir unseren Shareholder hinter uns - und das gibt einem erst den Freiraum, um wieder aus dem Sumpf herauszukommen.
Störungen reduzieren
Andreas: Wie haben wir es gemacht? 

Natürliche Verknappung auf der Maintenance-Seite, und die klügsten Leute mit Domainwissen so freigeschaufelt. Wir haben Business und Technik räumlich getrennt -
das soll man eigentlich nicht machen, war in dieser Situation aber notwendig.
Fokus
20 %
80 %
Kano-Modell
Andreas: Und während man den Featuredruck nicht reduzieren kann, kann man ihn wenigstens fokussieren. Es gilt die Pareto-Regel: mit 20% des Aufwands kann man
80% des Nutzens erreichen. Wir haben das im konkreten Fall mit dem Kano-Modell gemacht, und den Rewrite über die Internationalisierung als Lean Startup gemacht -
also ein MVP, ein kleinstmögliches Produkt in einem anderen Land aufgebaut und dann nach und nach die übrigen Features ergänzt.
Sequentiell > Parallel
Time to Market:

3 Monate im Mittel
Fokus: unklar
Time to Market:

2 Monate im Mittel
Fokus: klar
Johann: In Deathmarchprojekten sind oft sehr viele Dinge parallel in Arbeit - man hofft die Time to Market zu verbessern, indem man früh beginnt. 

Faktisch ist es aber offensichtlich, dass die Time to Market bei sequentieller Bearbeitung deutlich besser ist, denn abgeschlossene Tätigkeiten werden früher geliefert.
Und nicht nur das - durch den besseren Fokus liefert die Entwicklung schneller.
Immer QA statt QA-Phasen
Deploy in 5 Minuten
Cloud statt Server
Infrastructure as Code
DEV

SPEED
Johann: Nächster Schritt war Development auf Speed bringen. Da gehört nicht nur Fokus dazu, auch das Environment muss stimmen. Dafür haben wir DevOps-
Methoden benutzt - gleich in die Cloud, automatisiertes Deployment, automatisierte Tests. Es gibt keine QA-Phasen, weil kontinuierlich - automatisch und manuell -
getestet wird. Die komplette Plattform kann in 45 Minuten neu aufgebaut werden, wenn es einen Ausfall gäbe. Die gibt es jetzt natürlich nicht mehr.
Kontrollverlust
Andreas: Das Management muss zulassen, dass die Entwicklung sich neu sortiert und darauf vertrauen, dass sie in absehbarer Zeit wieder lieferfähig wird.

Wenn ich da in einen Modus des Micromanagement und der Planung übergehe - was in so einer Situation ein nachvollziehbarer Reflex ist - dann ersticke ich jedes noch
so kleine Quäntchen auf Erfolg. Statt dessen ist meine Aufgabe das Alignment von Development und Businessanforderungen. Jeder muss verstehen, worum es wirklich
geht. In unserem Fall war ich derjenige der zwar das Domainwissen besaß aber die Lösung genauso wenig kann wie alle anderen. Ich kann nur empfehlen sich mitten in
diesen Prozess hinein zu begeben, darauf zu vertrauen dass die Entwicklung die Lieferfähigkeit sehr bald wieder herstellen wird und die eigene Energie dafür einsetzen
den Weg von jeglichen Blockaden zu befreien.
Fragen!
Andreas: Wir haben erst vor wenigen Wochen erfolgreich unsere neue Platform gelauncht, bereits 4 weitere europäische Ländern eröffnet und keine Sekunde Downtime
gehabt ;-)

Weitere ähnliche Inhalte

Was ist angesagt?

NewWork in der Praxis
NewWork in der PraxisNewWork in der Praxis
NewWork in der Praxis
Johann-Peter Hartmann
 
Lügen, schlimme Lügen und IT-Verträge
Lügen, schlimme Lügen und IT-VerträgeLügen, schlimme Lügen und IT-Verträge
Lügen, schlimme Lügen und IT-Verträge
Johann-Peter Hartmann
 
Agility Brainfucks - Von Menschen, Bildern und Steampunk-Management mit Notizen
Agility Brainfucks - Von Menschen, Bildern und Steampunk-Management mit NotizenAgility Brainfucks - Von Menschen, Bildern und Steampunk-Management mit Notizen
Agility Brainfucks - Von Menschen, Bildern und Steampunk-Management mit Notizen
Gerrit Beine
 
Legacy php - Sanieren oder Ablösen?
Legacy php  - Sanieren oder Ablösen?Legacy php  - Sanieren oder Ablösen?
Legacy php - Sanieren oder Ablösen?
Johann-Peter Hartmann
 
Leadership in der IT
Leadership in der ITLeadership in der IT
Leadership in der IT
Johann-Peter Hartmann
 
Warum die it nicht um new work herumkommt
Warum die it nicht um new work herumkommtWarum die it nicht um new work herumkommt
Warum die it nicht um new work herumkommt
Johann-Peter Hartmann
 
DevOps jenseits der Tools
DevOps jenseits der ToolsDevOps jenseits der Tools
DevOps jenseits der Tools
Johann-Peter Hartmann
 
Anforderungen haben immer Schuld
Anforderungen haben immer SchuldAnforderungen haben immer Schuld
Anforderungen haben immer Schuld
Frank Düsterbeck
 
Agiles Schätzen im Team - Joachim Seibert, OBJEKTspektrum 5/2012
Agiles Schätzen im Team - Joachim Seibert, OBJEKTspektrum 5/2012Agiles Schätzen im Team - Joachim Seibert, OBJEKTspektrum 5/2012
Agiles Schätzen im Team - Joachim Seibert, OBJEKTspektrum 5/2012
Martin Seibert
 
Planlos mit Plan
Planlos mit PlanPlanlos mit Plan
Planlos mit Plan
Frank Düsterbeck
 
Surviving Complexity
Surviving ComplexitySurviving Complexity
Surviving Complexity
Johann-Peter Hartmann
 
Vom Entwickler zur Führungskraft
Vom Entwickler zur FührungskraftVom Entwickler zur Führungskraft
Vom Entwickler zur Führungskraft
Johann-Peter Hartmann
 
Produktive teams
Produktive teamsProduktive teams
Produktive teams
Mayflower GmbH
 
Portfolio Kanban
Portfolio KanbanPortfolio Kanban
Portfolio Kanban
Stefan ROOCK
 
Wetware Bugs and Refactoring
Wetware Bugs and RefactoringWetware Bugs and Refactoring
Wetware Bugs and Refactoring
Johann-Peter Hartmann
 
Meine! Deine! Keine! Verantwortung in agilen Teams
Meine! Deine! Keine! Verantwortung in agilen TeamsMeine! Deine! Keine! Verantwortung in agilen Teams
Meine! Deine! Keine! Verantwortung in agilen Teams
Frank Düsterbeck
 
Alles Wichtige zu Scrum in 4 Minuten
Alles Wichtige zu Scrum in 4 MinutenAlles Wichtige zu Scrum in 4 Minuten
Alles Wichtige zu Scrum in 4 Minuten
TechDivision GmbH
 
Arbeitswelt2020PechaKucha
Arbeitswelt2020PechaKuchaArbeitswelt2020PechaKucha
Arbeitswelt2020PechaKuchaElsy Zollikofer
 

Was ist angesagt? (19)

NewWork in der Praxis
NewWork in der PraxisNewWork in der Praxis
NewWork in der Praxis
 
Lügen, schlimme Lügen und IT-Verträge
Lügen, schlimme Lügen und IT-VerträgeLügen, schlimme Lügen und IT-Verträge
Lügen, schlimme Lügen und IT-Verträge
 
Agility Brainfucks - Von Menschen, Bildern und Steampunk-Management mit Notizen
Agility Brainfucks - Von Menschen, Bildern und Steampunk-Management mit NotizenAgility Brainfucks - Von Menschen, Bildern und Steampunk-Management mit Notizen
Agility Brainfucks - Von Menschen, Bildern und Steampunk-Management mit Notizen
 
Legacy php - Sanieren oder Ablösen?
Legacy php  - Sanieren oder Ablösen?Legacy php  - Sanieren oder Ablösen?
Legacy php - Sanieren oder Ablösen?
 
Leadership in der IT
Leadership in der ITLeadership in der IT
Leadership in der IT
 
Warum die it nicht um new work herumkommt
Warum die it nicht um new work herumkommtWarum die it nicht um new work herumkommt
Warum die it nicht um new work herumkommt
 
DevOps jenseits der Tools
DevOps jenseits der ToolsDevOps jenseits der Tools
DevOps jenseits der Tools
 
Anforderungen haben immer Schuld
Anforderungen haben immer SchuldAnforderungen haben immer Schuld
Anforderungen haben immer Schuld
 
Agiles Schätzen im Team - Joachim Seibert, OBJEKTspektrum 5/2012
Agiles Schätzen im Team - Joachim Seibert, OBJEKTspektrum 5/2012Agiles Schätzen im Team - Joachim Seibert, OBJEKTspektrum 5/2012
Agiles Schätzen im Team - Joachim Seibert, OBJEKTspektrum 5/2012
 
Planlos mit Plan
Planlos mit PlanPlanlos mit Plan
Planlos mit Plan
 
Surviving Complexity
Surviving ComplexitySurviving Complexity
Surviving Complexity
 
Vom Entwickler zur Führungskraft
Vom Entwickler zur FührungskraftVom Entwickler zur Führungskraft
Vom Entwickler zur Führungskraft
 
Produktive teams
Produktive teamsProduktive teams
Produktive teams
 
Portfolio Kanban
Portfolio KanbanPortfolio Kanban
Portfolio Kanban
 
Wetware Bugs and Refactoring
Wetware Bugs and RefactoringWetware Bugs and Refactoring
Wetware Bugs and Refactoring
 
Meine! Deine! Keine! Verantwortung in agilen Teams
Meine! Deine! Keine! Verantwortung in agilen TeamsMeine! Deine! Keine! Verantwortung in agilen Teams
Meine! Deine! Keine! Verantwortung in agilen Teams
 
Arbeitswelt2020 pecha kucha
Arbeitswelt2020 pecha kuchaArbeitswelt2020 pecha kucha
Arbeitswelt2020 pecha kucha
 
Alles Wichtige zu Scrum in 4 Minuten
Alles Wichtige zu Scrum in 4 MinutenAlles Wichtige zu Scrum in 4 Minuten
Alles Wichtige zu Scrum in 4 Minuten
 
Arbeitswelt2020PechaKucha
Arbeitswelt2020PechaKuchaArbeitswelt2020PechaKucha
Arbeitswelt2020PechaKucha
 

Andere mochten auch

JavaScriptDays: vom 10 Tage Hack zur ersten Universalsprache?
JavaScriptDays: vom 10 Tage Hack zur ersten Universalsprache?JavaScriptDays: vom 10 Tage Hack zur ersten Universalsprache?
JavaScriptDays: vom 10 Tage Hack zur ersten Universalsprache?
Johann-Peter Hartmann
 
Javascript Security
Javascript SecurityJavascript Security
Javascript Security
jgrahamc
 
DevOps beyond the Tools
DevOps beyond the ToolsDevOps beyond the Tools
DevOps beyond the Tools
Johann-Peter Hartmann
 
Reparier Deine Unternehmenskultur!
Reparier Deine Unternehmenskultur!Reparier Deine Unternehmenskultur!
Reparier Deine Unternehmenskultur!
Johann-Peter Hartmann
 
Java script security for java developers
Java script security for java developersJava script security for java developers
Java script security for java developers
Johann-Peter Hartmann
 
Rewrites überleben
Rewrites überlebenRewrites überleben
Rewrites überleben
Johann-Peter Hartmann
 
JavaScript Security
JavaScript SecurityJavaScript Security
JavaScript Security
Johann-Peter Hartmann
 
How not to screw the operating system of your startup
How not to screw the operating system of your startupHow not to screw the operating system of your startup
How not to screw the operating system of your startup
Johann-Peter Hartmann
 
Von Kutschern, Managern und Systemadministratoren
Von Kutschern, Managern und SystemadministratorenVon Kutschern, Managern und Systemadministratoren
Von Kutschern, Managern und Systemadministratoren
Johann-Peter Hartmann
 

Andere mochten auch (9)

JavaScriptDays: vom 10 Tage Hack zur ersten Universalsprache?
JavaScriptDays: vom 10 Tage Hack zur ersten Universalsprache?JavaScriptDays: vom 10 Tage Hack zur ersten Universalsprache?
JavaScriptDays: vom 10 Tage Hack zur ersten Universalsprache?
 
Javascript Security
Javascript SecurityJavascript Security
Javascript Security
 
DevOps beyond the Tools
DevOps beyond the ToolsDevOps beyond the Tools
DevOps beyond the Tools
 
Reparier Deine Unternehmenskultur!
Reparier Deine Unternehmenskultur!Reparier Deine Unternehmenskultur!
Reparier Deine Unternehmenskultur!
 
Java script security for java developers
Java script security for java developersJava script security for java developers
Java script security for java developers
 
Rewrites überleben
Rewrites überlebenRewrites überleben
Rewrites überleben
 
JavaScript Security
JavaScript SecurityJavaScript Security
JavaScript Security
 
How not to screw the operating system of your startup
How not to screw the operating system of your startupHow not to screw the operating system of your startup
How not to screw the operating system of your startup
 
Von Kutschern, Managern und Systemadministratoren
Von Kutschern, Managern und SystemadministratorenVon Kutschern, Managern und Systemadministratoren
Von Kutschern, Managern und Systemadministratoren
 

Ähnlich wie Einfangen eines technisch kaputten projektes

Bessere Software schneller liefern
Bessere Software schneller liefernBessere Software schneller liefern
Bessere Software schneller liefern
Mayflower GmbH
 
Mobile Apps für Unternehmen: White Paper mit Praxistipps
Mobile Apps für Unternehmen: White Paper mit PraxistippsMobile Apps für Unternehmen: White Paper mit Praxistipps
Mobile Apps für Unternehmen: White Paper mit Praxistipps
SterzerPR
 
Datenanalysen in der Softwareentwicklung mit Software Analytics
Datenanalysen in der Softwareentwicklung mit Software AnalyticsDatenanalysen in der Softwareentwicklung mit Software Analytics
Datenanalysen in der Softwareentwicklung mit Software Analytics
Markus Harrer
 
Wie Sie Mit Design Sprints Echten Digitalen Wandel Schaffen
Wie Sie Mit Design Sprints Echten Digitalen Wandel SchaffenWie Sie Mit Design Sprints Echten Digitalen Wandel Schaffen
Wie Sie Mit Design Sprints Echten Digitalen Wandel Schaffen
iTiZZiMO
 
E-Commerce Organisationsstrukturen
E-Commerce OrganisationsstrukturenE-Commerce Organisationsstrukturen
E-Commerce Organisationsstrukturen
Björn Schotte
 
CMS im Dornröschenschlaf – Wann es sich lohnt, Ihr CMS wach zu küssen
CMS im Dornröschenschlaf – Wann es sich lohnt, Ihr CMS wach zu küssenCMS im Dornröschenschlaf – Wann es sich lohnt, Ihr CMS wach zu küssen
CMS im Dornröschenschlaf – Wann es sich lohnt, Ihr CMS wach zu küssen
TANNER AG
 
The Power of the Crowd
The Power of the CrowdThe Power of the Crowd
The Power of the Crowd
Anne Märtens
 
Auf zu neuen Ufern! Mit „Lean Startup“ den Kundengeschmack treffen. Elmar Bor...
Auf zu neuen Ufern! Mit „Lean Startup“ den Kundengeschmack treffen. Elmar Bor...Auf zu neuen Ufern! Mit „Lean Startup“ den Kundengeschmack treffen. Elmar Bor...
Auf zu neuen Ufern! Mit „Lean Startup“ den Kundengeschmack treffen. Elmar Bor...
SYNGENIO AG
 
Innovation durch Scrum und Continuous Delivery
Innovation durch Scrum und Continuous DeliveryInnovation durch Scrum und Continuous Delivery
Innovation durch Scrum und Continuous Delivery
Peter Gfader
 
Individuelle Software Entwicklung
Individuelle Software EntwicklungIndividuelle Software Entwicklung
Individuelle Software Entwicklung
Dorie Fehlmann
 
PPI-Blog: Digitalisierung bei Versicherungsunternehmen
PPI-Blog: Digitalisierung bei VersicherungsunternehmenPPI-Blog: Digitalisierung bei Versicherungsunternehmen
PPI-Blog: Digitalisierung bei Versicherungsunternehmen
PPI AG
 
10 Tipps für ein erfolgreiches CRM-Projekt
10 Tipps für ein erfolgreiches CRM-Projekt 10 Tipps für ein erfolgreiches CRM-Projekt
10 Tipps für ein erfolgreiches CRM-Projekt
Uwe Laufer
 
Geschwindigkeit zählt: Beschleunigen Sie die Transformation Ihrer Domino-Apps
Geschwindigkeit zählt: Beschleunigen Sie die Transformation Ihrer Domino-AppsGeschwindigkeit zählt: Beschleunigen Sie die Transformation Ihrer Domino-Apps
Geschwindigkeit zählt: Beschleunigen Sie die Transformation Ihrer Domino-Apps
panagenda
 
Case Study Softwareentwickler aus Indien für Agentur aus München
Case Study Softwareentwickler aus Indien für Agentur aus MünchenCase Study Softwareentwickler aus Indien für Agentur aus München
Case Study Softwareentwickler aus Indien für Agentur aus München
YUHIRO
 
Process partner slides
Process partner slidesProcess partner slides
Process partner slides
socialmediapp
 
Stoeckel 7 Mistakes Requirements Engineering
Stoeckel 7 Mistakes Requirements EngineeringStoeckel 7 Mistakes Requirements Engineering
Stoeckel 7 Mistakes Requirements Engineering
Visure Solutions
 
Projektmanagement und IBM Lotus Quickr - Olav Behrens (PAVONE AG)
Projektmanagement und IBM Lotus Quickr  - Olav Behrens (PAVONE AG)Projektmanagement und IBM Lotus Quickr  - Olav Behrens (PAVONE AG)
Projektmanagement und IBM Lotus Quickr - Olav Behrens (PAVONE AG)Udo Sill
 
Tools Berlin Power Workshop: Wie visuelle Kommunikation Kundenservice & Bug T...
Tools Berlin Power Workshop: Wie visuelle Kommunikation Kundenservice & Bug T...Tools Berlin Power Workshop: Wie visuelle Kommunikation Kundenservice & Bug T...
Tools Berlin Power Workshop: Wie visuelle Kommunikation Kundenservice & Bug T...
Usersnap
 
Effizienz auf Knopfdruck
Effizienz auf KnopfdruckEffizienz auf Knopfdruck
Effizienz auf Knopfdruck
d.velop AG
 

Ähnlich wie Einfangen eines technisch kaputten projektes (20)

Bessere Software schneller liefern
Bessere Software schneller liefernBessere Software schneller liefern
Bessere Software schneller liefern
 
Mobile Apps für Unternehmen: White Paper mit Praxistipps
Mobile Apps für Unternehmen: White Paper mit PraxistippsMobile Apps für Unternehmen: White Paper mit Praxistipps
Mobile Apps für Unternehmen: White Paper mit Praxistipps
 
Datenanalysen in der Softwareentwicklung mit Software Analytics
Datenanalysen in der Softwareentwicklung mit Software AnalyticsDatenanalysen in der Softwareentwicklung mit Software Analytics
Datenanalysen in der Softwareentwicklung mit Software Analytics
 
Wie Sie Mit Design Sprints Echten Digitalen Wandel Schaffen
Wie Sie Mit Design Sprints Echten Digitalen Wandel SchaffenWie Sie Mit Design Sprints Echten Digitalen Wandel Schaffen
Wie Sie Mit Design Sprints Echten Digitalen Wandel Schaffen
 
E-Commerce Organisationsstrukturen
E-Commerce OrganisationsstrukturenE-Commerce Organisationsstrukturen
E-Commerce Organisationsstrukturen
 
CMS im Dornröschenschlaf – Wann es sich lohnt, Ihr CMS wach zu küssen
CMS im Dornröschenschlaf – Wann es sich lohnt, Ihr CMS wach zu küssenCMS im Dornröschenschlaf – Wann es sich lohnt, Ihr CMS wach zu küssen
CMS im Dornröschenschlaf – Wann es sich lohnt, Ihr CMS wach zu küssen
 
The Power of the Crowd
The Power of the CrowdThe Power of the Crowd
The Power of the Crowd
 
Agile Business Software mit der Enterprise Cloud
Agile Business Software mit der Enterprise CloudAgile Business Software mit der Enterprise Cloud
Agile Business Software mit der Enterprise Cloud
 
Auf zu neuen Ufern! Mit „Lean Startup“ den Kundengeschmack treffen. Elmar Bor...
Auf zu neuen Ufern! Mit „Lean Startup“ den Kundengeschmack treffen. Elmar Bor...Auf zu neuen Ufern! Mit „Lean Startup“ den Kundengeschmack treffen. Elmar Bor...
Auf zu neuen Ufern! Mit „Lean Startup“ den Kundengeschmack treffen. Elmar Bor...
 
Innovation durch Scrum und Continuous Delivery
Innovation durch Scrum und Continuous DeliveryInnovation durch Scrum und Continuous Delivery
Innovation durch Scrum und Continuous Delivery
 
Individuelle Software Entwicklung
Individuelle Software EntwicklungIndividuelle Software Entwicklung
Individuelle Software Entwicklung
 
PPI-Blog: Digitalisierung bei Versicherungsunternehmen
PPI-Blog: Digitalisierung bei VersicherungsunternehmenPPI-Blog: Digitalisierung bei Versicherungsunternehmen
PPI-Blog: Digitalisierung bei Versicherungsunternehmen
 
10 Tipps für ein erfolgreiches CRM-Projekt
10 Tipps für ein erfolgreiches CRM-Projekt 10 Tipps für ein erfolgreiches CRM-Projekt
10 Tipps für ein erfolgreiches CRM-Projekt
 
Geschwindigkeit zählt: Beschleunigen Sie die Transformation Ihrer Domino-Apps
Geschwindigkeit zählt: Beschleunigen Sie die Transformation Ihrer Domino-AppsGeschwindigkeit zählt: Beschleunigen Sie die Transformation Ihrer Domino-Apps
Geschwindigkeit zählt: Beschleunigen Sie die Transformation Ihrer Domino-Apps
 
Case Study Softwareentwickler aus Indien für Agentur aus München
Case Study Softwareentwickler aus Indien für Agentur aus MünchenCase Study Softwareentwickler aus Indien für Agentur aus München
Case Study Softwareentwickler aus Indien für Agentur aus München
 
Process partner slides
Process partner slidesProcess partner slides
Process partner slides
 
Stoeckel 7 Mistakes Requirements Engineering
Stoeckel 7 Mistakes Requirements EngineeringStoeckel 7 Mistakes Requirements Engineering
Stoeckel 7 Mistakes Requirements Engineering
 
Projektmanagement und IBM Lotus Quickr - Olav Behrens (PAVONE AG)
Projektmanagement und IBM Lotus Quickr  - Olav Behrens (PAVONE AG)Projektmanagement und IBM Lotus Quickr  - Olav Behrens (PAVONE AG)
Projektmanagement und IBM Lotus Quickr - Olav Behrens (PAVONE AG)
 
Tools Berlin Power Workshop: Wie visuelle Kommunikation Kundenservice & Bug T...
Tools Berlin Power Workshop: Wie visuelle Kommunikation Kundenservice & Bug T...Tools Berlin Power Workshop: Wie visuelle Kommunikation Kundenservice & Bug T...
Tools Berlin Power Workshop: Wie visuelle Kommunikation Kundenservice & Bug T...
 
Effizienz auf Knopfdruck
Effizienz auf KnopfdruckEffizienz auf Knopfdruck
Effizienz auf Knopfdruck
 

Mehr von Johann-Peter Hartmann

The End of my Career
The End of my CareerThe End of my Career
The End of my Career
Johann-Peter Hartmann
 
E-Commerce vs Architektur CodeTalks.Commerce_2018
E-Commerce vs Architektur CodeTalks.Commerce_2018E-Commerce vs Architektur CodeTalks.Commerce_2018
E-Commerce vs Architektur CodeTalks.Commerce_2018
Johann-Peter Hartmann
 
Serverside Cryptoparty
Serverside CryptopartyServerside Cryptoparty
Serverside Cryptoparty
Johann-Peter Hartmann
 
JavaScript und Security - JavaScript Days 2013 Berlin
JavaScript und Security - JavaScript Days 2013 BerlinJavaScript und Security - JavaScript Days 2013 Berlin
JavaScript und Security - JavaScript Days 2013 Berlin
Johann-Peter Hartmann
 
Profiling for Grown-Ups
Profiling for Grown-UpsProfiling for Grown-Ups
Profiling for Grown-Ups
Johann-Peter Hartmann
 
Paradigmenwechsel bei webapplikationen
Paradigmenwechsel bei webapplikationenParadigmenwechsel bei webapplikationen
Paradigmenwechsel bei webapplikationenJohann-Peter Hartmann
 

Mehr von Johann-Peter Hartmann (6)

The End of my Career
The End of my CareerThe End of my Career
The End of my Career
 
E-Commerce vs Architektur CodeTalks.Commerce_2018
E-Commerce vs Architektur CodeTalks.Commerce_2018E-Commerce vs Architektur CodeTalks.Commerce_2018
E-Commerce vs Architektur CodeTalks.Commerce_2018
 
Serverside Cryptoparty
Serverside CryptopartyServerside Cryptoparty
Serverside Cryptoparty
 
JavaScript und Security - JavaScript Days 2013 Berlin
JavaScript und Security - JavaScript Days 2013 BerlinJavaScript und Security - JavaScript Days 2013 Berlin
JavaScript und Security - JavaScript Days 2013 Berlin
 
Profiling for Grown-Ups
Profiling for Grown-UpsProfiling for Grown-Ups
Profiling for Grown-Ups
 
Paradigmenwechsel bei webapplikationen
Paradigmenwechsel bei webapplikationenParadigmenwechsel bei webapplikationen
Paradigmenwechsel bei webapplikationen
 

Einfangen eines technisch kaputten projektes

  • 1. Einfangen eines technisch kaputten Projektes Johann: Hallo! Erfolg kann jeder, und wenn man Konferenzen trauen darf, dann besteht unser Leben praktisch nur aus welchen. Aber man lernt mehr aus Katastrophen.
  • 2. Wer war schon einmal in einem Katastrophen- Projekt? Johann: Frage an das Publikum: Wer von Euch war schon einmal in einem Katastrophenprojekt? Projekte, in denen Dinge langsam werden, Interessen unklar sind und man sich gerne und viel streitet? Die Zielstellungen unklar sind?
  • 3. Wir auch. Uns geht das nicht besser. Wir, das sind : Andreas Goschler - Chief Product Manager bei myDriver und verantwortlich für die Produktentwicklung unserer Chauffeurservice-Vermittlungsplattform Johann-Peter Hartmann - CTO, Chief Tailwind Officer bei Mayflower und gerne da mit dabei wo es brennt.
  • 4. Wie man mit lauter richtigen Schritten zur einer kaputten Plattform kommt. Andreas: Katastrophen passieren nie mit Absicht und nur selten aus Dummheit. Und auch in unserem Fall war jeder einzelne Schritt sinnvoll, auch wenn die Summe aller Schritte zu einer schwer wartbaren Software geführt hat.
  • 5. Andreas: myDriver ist der jüngste Mobilitätsdienst aus dem Hause Sixt.
  • 6. 2012. Andreas: Wie haben wir begonnen? Mit einem klassischen Businesscase ca. 10 Wochen vor Jahresende wollten wir uns mal anschauen, ob man in dem gerade neu entstehenden Markt der Taxivermittlung etwas machen kann.
  • 7. 0 12500 25000 37500 50000 Fahrzeuge Taxi Chauffeurservices ? Andreas: Während es bei den Taxis bereits eine ganze Reihe von Startups gab die erfolgreich in der Vermittlung tätig waren, gab es bei den Chauffeurservices in Deutschland noch gar nichts - obwohl diese zahlenmäßig mit 2/3 der Anzahl Taxis nur unwesentlich weniger stark vertreten waren
  • 8. Andreas: Der Businesscase war währenddessen im Ausland quasi validiert - der Erfolg von Uber in den USA und Addison Lee in London hat uns bestärkt auch in diesen Markt zu einzusteigen.
  • 9. 7 Wochen. Andreas: Innerhalb von 7 Wochen wurde die Applikation mobil und als Website entwickelt und im Januar 2013 in Deutschland gelauncht.
  • 10. Johann: Wie kann man so eine Software schnell liefern? Die Frage können die Vorredner von Rocket und Project A am besten beantworten - indem ich einen fertigen Baukasten verwende - in diesem Fall den von Sixt, bei dem die meisten Funktionalitäten von Payment über Billing und Reservierung schon existieren.
  • 11. Januar April Juli Oktober Januar Fahrten Andreas: Sofort nach Launch ging es mithilfe von Marketingmassnahmen steil bergauf. Unser Service stieß sowohl auf Kunden wie auch auf Fahrerseite auf reges Interesse und die Anfangseuphorie war bei allen riesig.
  • 12. Januar April Juli Oktober Januar Fahrten Panik! Andreas: Die ersten Monate waren wir natürlich vollkommen damit beschäftigt unser Serviceversprechen einzulösen. Allerdings war schnell klar, dass die Kunden - die wir über Marketing akquirierten - die kamen nicht wieder von sich aus zurück und dass das finanziell nicht so lange Sinn macht - erschließt sich von selbst. Genau das ist der Moment, in dem die eigene Roadmap nicht mehr von einem selbst kommt, sondern vom Kunden bzw. Allen die meinen zu wissen was man braucht. Es ist zwar klar, dass es zu wenig Wiederkehrer gibt, aber warum sie nicht wiederkommen ist unklar.
  • 13. Januar April Juli Oktober Januar Fahrten Feature A? Feature B? Feature C? Andreas: Was macht man in dem Moment? Man bewirft die Software mit Features. Features von denen man meint, dass der Kunde sie unbedingt braucht. Faktisch weiß man noch nicht, welche funktionieren werden.
  • 14. Mitte-Ende 2013: 
 Development wird langsam Andreas: nachdem man die Software eine Weile mit Features beworfen hat kommen die Features immer langsamer, und es passieren immer mehr Bugs.
  • 15. „Die Developer müssen schneller liefern! Andreas: Was passiert also? Die Developer werden aufgefordert mehr zu liefern, jetzt kommt es nämlich darauf an.
  • 16. Abhängigkeiten + 
 Technische Schulden =
 Kein Fortschritt. Sorry …<3 Die Entwickler können das aber nicht - sie sind nicht wirklich flexibel in Ihrer Bewegung, und sie können nur im Rahmen dessen navigieren was die Legobausteine der alten Systeme erlauben. Dazu kommen technische Schulden - immer wenn es eilig wird geht die Qualität verloren. Technical Debt macht die ganze Entwicklung nicht nur langsamer, sondern erzeugt auch mehr Bugs in der Arbeit - die dann wiederum selbst noch für eine Verlangsamung sorgen.
  • 17. Druck! Andreas: Das Entwicklung bringt also nicht die Performance die es braucht - erster Lösungsansatz ist mehr Druck. Das funktioniert auch kurzzeitig, versagt aber auf der mittleren Strecke. Und zwar meist schon nach sehr kurzer Zeit.
  • 18. Resultat: Die Performance sinkt nach einem initialen Anstieg weiter. Johann: Druck auf Softwaredeveloper hilft nur begrenzt weiter - am Anfang steigt die Lieferfähigkeit, und auch Überstunden resultieren in mehr Features. Das geht etwa 4 Wochen gut, dann flaut die Mehrleistung nicht nur ab, sondern man landet sogar unterhalb dem Torniveau - denn die technische Qualität ist einmal mehr deutlich gesunken.
  • 19. Mehr Leute!Andreas: Die zweite Strategie ist in der IT auch nicht eben unüblich - wenn ich mehr Features über Zeit will, erhöhe ich die Zahl der beteiligten Leute.
  • 20. Brooks Law: „Adding manpower to a late software project makes it later" (Un)bekannt seit 1975. Johann: Eigentlich ist Brooks Law schon von 1975, doch seltsamerweise hat es sich noch lange nicht in deutsche Managementetagen herumgesprochen. Ich kann den Featurefluss nicht schnell erhöhen indem ich neue Leute in das Projekt nehme. Ganz im Gegenteil - es wird langsamer, und diese Verlangsamung kann durch für ein halbes Jahr gelten, bevor das Projekt durch die neuen Kollegen an Fahrt gewinnt, manchmal geschieht dies auch nie.
  • 21. Resultat: Die Performance sinkt weiter, jetzt aber teurer. Johann: Fazit daraus - die Performance sinkt immer noch, die Kosten sind allerdings gestiegen.
  • 22. Featuredruck Lieferfähigkeit Viel Aktion, wenig Resultat. Johann: Und am Ende befindet man sich in einer Situation, in der der Featuredruck immer mehr steigt, die Lieferfähigkeit immer kleiner wird. Die übliche Antwort darauf: Aktionismus - es werden mehr Dinge probiert, andere Leute, andere Techniken. Solche Projekte werden auch Deathmarch, also Todesmarschprojekte genannt - da gibt es sogar ein Buch mit genau diesem Titel zu.
  • 23. Chaos Johann: Als Management denkt man: Liebes Development, jetzt wird es gerade wirklich wichtig, und Ihr performed überhaupt nicht. Was soll ich denn bitte noch tun?
  • 24. Chance Johann: Und wenn Du lange genug im Chaos steckst und nichts nachhaltig den gewünschten Erfolg bringt - dann tut sich faktisch eine Chance auf.
  • 25. Featuredruck Lieferfähigkeit Johann: Wenn ich einen Schritt zurücktrete ist die Lösung doch eigentlich ganz offensichtlich: Ich muss die Lieferfähigkeit nach oben bringen und den Bedarf reduzieren. Das sagt sich jetzt leicht. Wie erreiche ich das?
  • 26. Hosen runter & 
 Shareholdersupport Andreas: In unserem Fall haben wir den gesamten, angehäuften Bedarf schonungslos auf den Tisch gelegt und damit ein Bewusstsein geschaffen dass wir hier auf ganz viele lose Enden blicken. Konkret waren da Features für B2C Kunden, Features für B2B Kunden, ellenlange Wunschlisten der angeschlossenen Fahrer, aus dem BI, dem Marketing, dem Accounting, der Operations etc. etc. Ab diesem Moment wussten wir unseren Shareholder hinter uns - und das gibt einem erst den Freiraum, um wieder aus dem Sumpf herauszukommen.
  • 27. Störungen reduzieren Andreas: Wie haben wir es gemacht? Natürliche Verknappung auf der Maintenance-Seite, und die klügsten Leute mit Domainwissen so freigeschaufelt. Wir haben Business und Technik räumlich getrennt - das soll man eigentlich nicht machen, war in dieser Situation aber notwendig.
  • 28. Fokus 20 % 80 % Kano-Modell Andreas: Und während man den Featuredruck nicht reduzieren kann, kann man ihn wenigstens fokussieren. Es gilt die Pareto-Regel: mit 20% des Aufwands kann man 80% des Nutzens erreichen. Wir haben das im konkreten Fall mit dem Kano-Modell gemacht, und den Rewrite über die Internationalisierung als Lean Startup gemacht - also ein MVP, ein kleinstmögliches Produkt in einem anderen Land aufgebaut und dann nach und nach die übrigen Features ergänzt.
  • 29. Sequentiell > Parallel Time to Market:
 3 Monate im Mittel Fokus: unklar Time to Market:
 2 Monate im Mittel Fokus: klar Johann: In Deathmarchprojekten sind oft sehr viele Dinge parallel in Arbeit - man hofft die Time to Market zu verbessern, indem man früh beginnt. Faktisch ist es aber offensichtlich, dass die Time to Market bei sequentieller Bearbeitung deutlich besser ist, denn abgeschlossene Tätigkeiten werden früher geliefert. Und nicht nur das - durch den besseren Fokus liefert die Entwicklung schneller.
  • 30. Immer QA statt QA-Phasen Deploy in 5 Minuten Cloud statt Server Infrastructure as Code DEV
 SPEED Johann: Nächster Schritt war Development auf Speed bringen. Da gehört nicht nur Fokus dazu, auch das Environment muss stimmen. Dafür haben wir DevOps- Methoden benutzt - gleich in die Cloud, automatisiertes Deployment, automatisierte Tests. Es gibt keine QA-Phasen, weil kontinuierlich - automatisch und manuell - getestet wird. Die komplette Plattform kann in 45 Minuten neu aufgebaut werden, wenn es einen Ausfall gäbe. Die gibt es jetzt natürlich nicht mehr.
  • 31. Kontrollverlust Andreas: Das Management muss zulassen, dass die Entwicklung sich neu sortiert und darauf vertrauen, dass sie in absehbarer Zeit wieder lieferfähig wird. Wenn ich da in einen Modus des Micromanagement und der Planung übergehe - was in so einer Situation ein nachvollziehbarer Reflex ist - dann ersticke ich jedes noch so kleine Quäntchen auf Erfolg. Statt dessen ist meine Aufgabe das Alignment von Development und Businessanforderungen. Jeder muss verstehen, worum es wirklich geht. In unserem Fall war ich derjenige der zwar das Domainwissen besaß aber die Lösung genauso wenig kann wie alle anderen. Ich kann nur empfehlen sich mitten in diesen Prozess hinein zu begeben, darauf zu vertrauen dass die Entwicklung die Lieferfähigkeit sehr bald wieder herstellen wird und die eigene Energie dafür einsetzen den Weg von jeglichen Blockaden zu befreien.
  • 32. Fragen! Andreas: Wir haben erst vor wenigen Wochen erfolgreich unsere neue Platform gelauncht, bereits 4 weitere europäische Ländern eröffnet und keine Sekunde Downtime gehabt ;-)