Warum sind Scrum-Projekte erfolgreicher?

Scrum macht Sinn

Software zu entwickeln ist komplex. Es gibt viele Abhängigkeiten, Dinge gehen kaputt und der Projekt-Scope verändert sich oft während des Projekts durch unvorhersehbare Ereignisse. Es ist ein bisschen vergleichbar mit dem Bau von deutschen Opernhäusern oder Flughäfen ;-). Wenn Sie noch nie das Vergnügen hatten, sind Sie versucht, das Projekt in einem klassischen Wasserfall-Modell herunter zu brechen. Das bedeutet:

1. Sie planen alles.
2. Sie designen alles.
3. Sie implementieren alles.
4. Sie gehen live.

Unsere Kollegen bei PriceWaterhouseCooper und der Harvard Business Review haben ein paar Zahlen zu klassischen IT- Projekten zusammengestellt:

1. Nur 2,5% klassischer IT-Projekte werden erfolgreich abgeschlossen.

2. Jedes IT-Projekt überschreitet sein Budget im Durchschnitt um 27%.

3. Jedes sechste IT-Projekt überschreitet seine Kosten um 200%.

PriceWaterhouseCooper und Harvard Business Review

Sie denken nun vielleicht: Wie schwer kann es sein? Sie wollen doch nur eine App entwickeln lassen. Davon gibt es Millionen auf der Welt. Was kann denn dabei schon schief gehen? Nun, Sie wären überrascht.

Wir haben die wichtigsten Gründe, warum Projekte oft furchtbar schief gehen, für Sie nach Impact zusammengefasst. Die Daten sind Erkenntnisse aus über 100 App- und Web-Projekten (unser CEO ist Spreadsheet-Fan 😉


Die häufigsten Gründe, warum Projekte scheitern

1 Änderungen im Laufe des Projekts

Sie bekommen einen neuen Chef oder einen neuen Kollegen, die andere Vorstellungen von der App haben oder (noch besser) Sie erhalten Feedback Ihrer Kunden, dass sie eigentlich ganz andere Features in Ihrer App erwarten. Nun könnten Sie denken: “Aber der Scope hat sich doch nur marginal verändert.“ Das kann durchaus sein.

Moderne Software ist jedoch in einer architektonischen Strukturen aufgebaut, ähnlich wie ein Wolkenkratzer. Wenn Sie nach der Hälfte der Bauzeit nun einen Keller hinzufügen möchten, müssen Sie das bisherige Bauwerk abreißen und neu aufbauen. Ein weiteres großes Risiko sind Designänderungen. Sie bekommen einen neuen Chef, Marketingleiter etc., der seine Marke setzen möchte und ein komplettes Redesign anordnet. Das passiert in einem von fünf Projekten! Hier wieder: Alles auf Anfang. 

2 Abhängigkeiten

Manchmal bitten uns Kunden, mit ihren eigenen Designern zu arbeiten oder eine Schnittstelle (API) zu verwenden, die sie selbst oder ein Drittanbieter entwickelt haben (oder entwickeln wollen). Unsere Erfahrung aus allen bisherigen Projekten zeigt: Das klappt nie so, wie man es erwartet. 

Auch wenn Sie alles bis ins kleinste Detail spezifizieren: Je mehr Schnittstellen (menschlich und technisch), desto mehr Missverständnisse treten auf und können Ihr Projekt explodieren lassen in Bezug auf Zeit, Aufwand und Budget. 

Ein kleines Missverständnis darüber, wie ein Datumsfeld aussehen soll –  „2019-01-01“ vs. „2019-01-01 00:00“ – kann dazu führen, dass ein Frontend-Entwickler stundenlang nach einem Fehler sucht, nachdem der externe Backend-Entwickler möglicherweise gerade an einem anderen Projekt arbeitet und deshalb für eine Woche nicht erreichbar ist. Die Deadline rückt näher und der Frontend-Entwickler beschließt, einen Workaround zu bauen.

Wenn der Backend-Entwickler nun endlich seinen Part korrigiert, muss der Frontend-Entwickler seinen Workaround ebenfalls nochmal anpassen. Wir haben Projekte erlebt, die aufgrund von Co-Design oder Co-Entwicklung um den Faktor 5 (!) explodiert sind.

3 Fehlkommunikation

Erwartungen an Software sind unglaublich schwer zu formulieren. Zeigen Sie Ihr Screen-Design drei verschiedenen Personen und Sie erhalten 5 verschiedene Interpretationen. Die Anforderungen an Software sind wie Eisberge: 95% liegen unter der Oberfläche – oder in unserem Fall – in den Köpfen unserer Stakeholder verborgen. Nehmen wir diese einfache Listenansicht in einer E-Mail-App.

Screenshot 2019-10-25 at 11.58.15
Erwartungen klar formulieren, um Fehlinterpretationen zu vermeiden

Wir sehen vielleicht eine Email-Listenansicht, die vom Server abgerufen werden und die den Absender, Betreff, die ersten beiden Textzeilen und der Tag des Versands anzeigt. Unsere Aufwandsschätzung: 2 Arbeitstage. Sie erwarten – bewusst oder unbewusst – eine der folgenden Funktionen. Der Unterschied zwischen unseren beiden Erwartungen beträgt 2 Tage und 100 Tage. 

Screenshot 2019-10-25 at 11.58.58
Individuelle Filter +2 TageLinks-Swipe zum Archivieren +2 TageRechts-Swipe zum Löschen +2 TageLong-Press, um Optionen anzuzeigen +2 Tage
Ungelesen-Icon +1 Tag
Synchronisierung des Ungelesen-Icons +10 Tage
Screenshot 2019-10-25 at 12.06.00
Status markieren +1 TagPull-Down und regelmäßige Aktualisierung +1 TagEinfache Suche +10 TageKomplexe Suche +50 Tage

Der Unterschied zwischen unseren beiden Erwartungen beträgt 2 Tage und 100 Tage. 

Nun könnte man sagen: „Ok, lasst uns ein 6-monatiges Vorprojekt durchführen, um alle Anforderungen aller Beteiligten zu erfassen, neu zu priorisieren, zu designen und zu dokumentieren.“ Das können Sie sicherlich so machen. So entstanden die Elbphilharmonie in Hamburg und der Berlin Airport. 😉 

Aber selbst in diesen 6 Monaten werden Dinge passieren, die Sie rückwirkend mit einplanen müssen. Sie werden neue Informationen von Ihrem Kunden erhalten, neue Vorgesetzte, ein neuer Projektleiter, neue Versionen von Betriebssystemen, das neue iPhone, eine neue App-Version Ihres Mitbewerbers, neue Wettbewerber werden auftauchen. Und Sie werden noch mehr Veränderungen bekämpfen müssen in Ihrem durch-deklinierten Wasserfall-Projekt. Lassen Sie uns Ihre App doch lieber agil entwickeln, so wie es die großen Digitalunternehmen wie Apple, Google und co tun.

WasserfallScrum
Lange Planungsphase bis zum ProjektstartKurze Planungsphase vor Projektstart, anschließend kurze wöchentliche Planungs-Sessions
Alles auf einmal bauenIterieren – Die kleinstmögliche Version eines Features bauen, User-Feedback einholen und anschließend verbessern
200 „Must Have“ Features, von denen 90% nicht genutzt werdenprodukt ist fertig, wenn Nutzer finden, es ist gut genug. Das kann bereits nach 10 Features der Fall sein, nicht erst nach den 200 geplanten
Kann nicht vor Projektende gestoppt werdenKann jederzeit angehalten werden und live gehen
Änderungen sind schwierig und teuerÄnderungen sind einfach und kostenlos
Aus Fehlern lernt man erst nach ProjektendeRegelmäßige Retros, um schon während des Projekts dazu zu lernen und besser zu werden
Regelmäßige, lange Statusreports in Word oder PPTTäglicher 10-minütiger Status-Call
Wasserfall- und Scrum-Projekte im Vergleich

2-Wochen-Zyklus mit Scrum

Wir arbeiten in unseren Projekten in 2-wöchigen Zyklen, auch Sprints genannt.

Zweiwöchentliches Planungsmeeting

Wir starten jeden Sprint mit einem gemeinsamen Planungsmeeting, an dem Sie und unser gesamtes Team teilnehmen. Wir gehen die Liste der offenen Features (Backlog) von oben bis unten nach Wichtigkeit durch. Sie erklären, worum es bei jedem Feature geht, wir stellen Fragen dazu und schätzen anschließend dessen Komplexität. Sobald das Team sagt: „Das ist alles, was wir im kommenden Sprint umsetzen können“, endet das Meeting und das Team macht sich an die Arbeit.

Tägliches Status-Meeting

Jeder Tag beginnt mit einem kurzen 15-minütigen Meeting mit Ihnen und dem gesamten Team, bei dem jeder drei Fragen beantwortet:

1. Was habe ich gestern fertiggestellt?
2. Was werde ich heute in Angriff nehmen?
3. Was blockiert mich gerade?

So wissen Sie immer, wie Ihr Projekt gerade läuft und kommen völlig ohne zeitraubende E-Mails, Check-Ins oder Statusberichte aus. Wir können Blocker frühzeitig identifizieren und diese schnell und unbürokratisch mit Ihnen klären – weniger E-Mailverkehr für Sie und produktivere Programmierzeiten für uns. Ein absolutes Win-Win!

Demo

Sobald ein Feature fertig ist, zeigen wir es Ihnen in einer Videokonferenz, damit wir sicherstellen, dass wir alles richtig verstanden haben. Am letzten Tag eines jeden Sprints führen wir Sie durch alle implementierten Features. Je mehr Stakeholder von Ihnen dabei sind, desto besser. Denn so bekommen alle Beteiligten ein gutes Gefühl des Fortschritts und Look and Feel des Projekts. Sie erhalten von uns dazu alle zwei Wochen eine funktionierende Version der App, die Sie mit Ihren Stakeholdern oder sogar Nutzern teilen können, um Feedback einzusammeln. So können Sie frühzeitig die Richtung korrigieren, wenn nötig.

Retro

In der Regel werden wir im Laufe eines Projekts um den Faktor 5 bis 10 besser. Der Quell unserer geheimen Super Power sind die regelmäßigen Retrospektiven, die wir gemeinsam durchführen. Am Ende eines jeden Sprints kommen wir zusammen und diskutieren, was toll gelaufen ist und was wir vergeigt haben. Wir sind brutal ehrlich und offen bei diesen Treffen und wünschen uns, dass auch Sie uns offen und ehrlich – aber freundlich – sagen, was Sie gerade empfinden und denken.



Ihre Rolle und Verantwortung als Kunde

So werden wir es machen: Sie und alle, die am Projekt beteiligt sein werden, werden dem Team beitreten. Sie werden der sogenannte Project Owner und wir werden das Projekt nach Scrum-Methodik umsetzen.

Das brauchen wir von Ihnen

1. Sie beschreiben die Features aus Nutzersicht in sogenannten User Stories und definieren für uns, wann Sie dieses Feature für erfolgreich umgesetzt ansehen.
2. Sie sortieren und priorisieren alle Features. In dieser Reihenfolge werden wir die Features für Sie bauen.
3. Sie nehmen aktiv an allen unseren Meetings teil: unsere täglichen Status-Meetings (15min/Tag), Planungs-Meetings (1h/Woche), Demos (30min/Woche) und Retros (30min/Woche). Das ist ein Aufwand von 3 Stunden pro Woche für Sie.
4. Sie halten dagegen in der Demo, wenn wir ein Feature nicht wie spezifiziert umgesetzt haben.

Übrigens: Wir zwingen Sie nur, das absolute Minimum zu schreiben und verlassen uns vielmehr auf ein gemeinsames Verständnis.

Ein erfahrener Consultant von uns hilft Ihnen dabei, Ihr Projekt in einzelne Features bzw. User Stories zu zerteilen. Damit wir verstehen, was wir für Sie entwickeln sollen und was das Ziel dieser Features ist, brauchen wir zwei Dinge von Ihnen:

1. Die User Story, in der Sie erklären, welcher Nutzer welche Handlung in Ihrer App durchführen möchte und warum. Das „Warum“ ist wichtig, denn es gibt uns das nötige Hintergrundwissen, damit wir smarte Entscheidungen in der Umsetzung treffen können, z.B.Abkürzungen oder alternative Wege zu Ihrem Ziel finden.
2. Die Akzeptanzkriterien: Wann gilt ein Feature für Sie als erfolgreich umgesetzt?

Beispiel einer User Story
„Als Nutzer möchte ich alle meine E-Mails in einer Listenansicht sehen, damit ich sie überfliegen und sehen kann, welche wichtiger ist.

Akzeptanzkriterien
1. E-Mails werden vom Server geladen.
2. E-Mails werden vom Server alle 15 Minuten aktualisiert oder bei Pull Down.
3. E-Mails werden in einer nach Datum absteigenden Liste mit Absender, Betreffzeile und einer 2-zeiligen Vorschau des Textes angezeigt.
4. Durch Tippen auf die E-Mail öffnet sich eine Detailansicht dieser E-Mail.


4 Change Requests

Wenn Sie jemals ein Softwareprojekt durchgeführt haben oder unsere Einleitung aufmerksam gelesen haben wissen Sie, warum Sie Angst vor Change Requests haben sollten. Change Requests sind das Schlimmste, das Ihrem Projekt passieren kann. Abhängig davon, wie freundlich Sie zu Ihrer Agentur sind, wird entweder Ihr Budget um das fünffache explodieren oder Sie treiben Ihre Agentur mit Ihrer “harten Hand” in den Konkurs. Wir handeln Change Requests folgendermaßen:

Änderungswünsche sind kostenlos und wir garantieren, dass wir Ihr Budget einhalten! Kein Witz!

Also, wo ist der Haken?

Sie haben wahrscheinlich schon vom magischen Projektdreieck gehört. Wir haben es liebevoll umbenannt in das „Projektquadrat des Todes“. 😉

In jedem Softwareprojekt müssen Sie vier Eckpunkte einhalten:
1. Kosten
2. Features
3. Deadlines
4. Qualität

Sie können nie alle vier Eckpunkte halten. Unvorhersehbare Dinge werden während des Projekts passieren. Lesen Sie unsere Einführung zu diesem Thema. Sie können drei von vier Eckpunkte haben. Eigentlich ist es aber nur einer. Warum?

Die Kosten sind durch Ihr Budget festgelegt, die Qualität ist – außer bei einem Minimum Viable Product (MVP) – nicht verhandelbar. Bei einem MVP drehen wir also beispielsweise an der Anzahl der Features, damit wir die Deadline und hohe Qualität einhalten können. Bei einer App, die bereits in Betrieb ist, können wir an den Stellschrauben “Anzahl der Features” und “Deadline” drehen. Ihre Entscheidung werden wir in großen roten Lettern in den Vertrag aufnehmen 😉

Wann immer Sie nun im Projektverlauf eine Funktion hinzufügen möchten oder Ihre Meinung ändern, werden wir die Komplexität der Änderung bewerten und Ihnen eine Schätzung des Zeitaufwands geben. Da wir die Einhaltung Ihres Budgets garantiert haben, suchen Sie sich nun einfach Funktionen aus dem unteren (wenig relevanten) Teil des Backlogs, die vergleichbar komplex sind, die sie zugunsten des neuen Features streichen wollen. Da Sie den Backlog selbst nach Wichtigkeit der Features von oben nach unten sortiert haben, ist es nicht weiter schlimm, wenn ein paar unwichtige Features wegfallen. Positiver Nebeneffekt: Sie werden sich bei jedem Feature fragen: Ist das neue Feature wirklich wichtiger als das andere?

Kennen Sie das Parkinson’sche Gesetz (nicht der Krankheit)? Dann wissen Sie, warum diese Art von „Timeboxing“ großartige Produkte genau in Time und in Budget liefert.


5 Vorteile von Scrum

Screenshot 2019-10-25 at 11.59.50

Unsere Scrum-Methodik mag ein wenig seltsam für Sie klingen. Vor allem, wenn Sie noch nie in einem komplexen Software-Projekt gearbeitet haben. Vertrauen Sie uns. Nach 11 Jahren in diesem Business haben wir so manche Dinge gelernt, wie man erfolgreich Software entwickelt.

Die wichtigsten zwei Erkenntnisse teilen wir hier mit Ihnen. Das sind keine “Nice to Haves”, sondern essentiell, damit Ihr Projekt erfolgreich wird. Fehlt eine der beiden Komponenten, werden Sie Ihr Projekt nicht erfolgreich abliefern können.


1 Tiefes Vertrauen

Wenn Sie uns als einen Dienstleister sehen, an den Sie Ihr Projekt auslagern können, werden wir scheitern. Wenn wir Sie als Kunden sehen, der keine Ahnung von Softwareentwicklung hat und den wir deshalb abziehen können, werden wir scheitern.

Softwareentwicklung ist eine Gemeinschaftsleistung, die wir nur in enger, vertrauensvoller Zusammenarbeit erreichen können. Das bedeutet: Sie vertrauen darauf, dass wir uns den Arsch für Sie aufreißen, Sie gründlich und kompetent beraten und vor allem ehrlich und offen mit Ihnen sind. Im Gegenzug vertrauen wir darauf, dass Sie für uns ansprechbar sind, wenn wir Sie brauchen, dass Sie offen für unsere Ideen und Fragen sind und uns sagen, was auf Ihrer Seite gerade passiert. (Und bitte bezahlen Sie auch Ihre Rechnungen rechtzeitig 😉

Wir sind EIN Team in unseren Projekten und unterscheiden nicht zwischen Kunden und Entwicklern. Wir wollen großartige Software abliefern, die Impact hat und auf die wir stolz sein können. Das ist ein Grund dafür, warum wir nur 2 von 10 Kundenprojekten annehmen. Sowohl das Team als auch das Projekt des Kunden müssen uns überzeugen, damit wir gemeinsam etwas Großartiges entwickeln können. Das klingt nach Klischee, hat in unserer Branche aber echten Seltenheitswert.

Achtung: WIR. MEINEN.DAS. ERNST.


2 Deep Work

Sie würden nicht glauben, wie viel Zeit ein Entwickler damit verbringt, nicht zu programmieren. In anderen Unternehmen sehen Sie zwischen 2-4 Stunden Programmierzeit. Und selbst die wird alle 5 Minuten unterbrochen durch eine Textnachricht, E-Mail, einen Anruf oder dem Chef persönlich.

Aber Softwareentwicklung ist ein komplexes Unterfangen. Deshalb ist es wenig überraschend, dass wir dafür nur die schlausten Leute einstellen, die wir aus ganz Europa finden können. Und das in einer Branche, in der bereits die klügsten Köpfe arbeiten. Anschließend schicken wir diese Top-Programmierer nach Hause und geben Ihnen das, was sie sich am meisten wünschen: ungestörte Zeit zu programmieren! Und das tun sie, und zwar hochkonzentriert und unterbrechungsfrei, über Stunden hinweg. So entsteht am Ende exzellente Software.


3 Kontinuierliche Verbesserung

Die Entwicklung von Software ist wie das Fischen in unerforschten Gewässern. Zu Beginn haben Sie eine vage Vorstellung davon, was Sie mit Ihrem Projekt erreichen wollen. Das ist 1% der Erkenntnis, die wir gemeinsam im Laufe des Projekts erarbeiten müssen.

Kurzum: Softwareentwicklung bedeutet, eine vage Vision in konkreten Code zu übersetzen. Also ist alles, was wir im Projekt tun, eine gemeinsame Lernerfahrung. Da wir alle unsere persönlichen Vorurteile und Schwächen mit uns herumtragen, werden wir uns oft missverstehen. Aber das ist in Ordnung und völlig normal.

Wichtig ist, dass wir offen und ehrlich darüber sprechen, was im Projekt gut läuft und was wir besser machen müssen. Sie werden überrascht sein, wie anders sich dieses Projekt anfühlt im Gegensatz zu allen, die Sie bisher erlebt haben. Mit dieser Vorgehensweise werden wir von Woche zu Woche besser – und zwar alle zusammen.