Unsere Scrum-Methodik

Agile App-Entwicklung nach Scrum

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 😉


3 Gründe, warum App-Projekte scheitern

1 Änderungen im Projektverlauf

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
Eine Funktion, unterschiedliche Erwartungen
Individuelle Filter +2 Tage; Ungelesen-Icon +1 Tag; Synchronisierung des Ungelesen-Icons +10 TageLinks-Swipe zum Archivieren +2 TageRechts-Swipe zum Löschen +2 TageLong-Press, um Optionen anzuzeigen +2 Tage
Aufwandsschätzung einer Funktion in unterschiedlichen Ausbaustufen
Screenshot 2019-10-25 at 12.06.00
Eine Funktion mit unterschiedlichen Komplexitätsstufen
Status markieren +1 TagPull-Down und regelmäßige Aktualisierung +1 TagEinfache Suche +10 TageKomplexe Suche +50 Tage
Aufwandsschätzung einer Funktion in unterschiedlichen Ausbaustufen

Der Unterschied zwischen diesen 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

So läuft der 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.


Rolle und Verantwortung als Kunde

Sie und alle Personen, die am Projekt beteiligt sein werden, treten dem Projekt-Team bei und sind von da an vollständige Mitglieder des Teams. So verhindern wir In-Group vs. Out-Group Denken und schaffen es, dass alle Beteiligten gemeinsam an einem Strang ziehen. Sie als Kunde werden der sogenannte Project Owner.

Ihre Aufgaben als Kunde

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.

Keine Sorge: 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.

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.

2 Die Akzeptanz-Kriterien

Wann gilt ein Feature für Sie als erfolgreich umgesetzt?

Beispiel für 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.


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 Scherz!

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 gibt es vier wesentliche Eckpunkte:
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 (siehe Einführung oben). An welchen Eckpunkten können Sie schrauben?

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 😉

Features ändern, Budget einhalten

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.


3 Dinge, die Scrum-Projekte erfolgreich machen

Screenshot 2019-10-25 at 11.59.50

Unsere Scrum-Methodik mag Ihnen anfangs vielleicht etwas seltsam vorkommen. Insbesondere, wenn Sie noch nie das Vergnügen hatten, an einem komplexen Software-Projekt mitzuarbeiten. Aber vertrauen Sie uns bitte.

In 11 Jahren App- und Web-Entwicklung haben wir einige Erfahrungen gesammelt, was erfolgreiche Softwareprojekte ausmacht. Unsere wichtigsten Erkenntnisse teilen wir hier mit Ihnen. Diese drei Faktoren sind keinesfalls “nice to have”, sondern essenziell, damit Ihr Projekt erfolgreich wird.

1 Tiefes Vertrauen

Wenn Sie uns als einen Dienstleister sehen, an den Sie Ihr Projekt auslagern, werden wir scheitern. Wenn wir Sie als Kunden sehen, der keine Ahnung von Softwareentwicklung hat und den wir über den Tisch ziehen 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 Sie gründlich und kompetent beraten, ehrlich und offen mit Ihnen umgehen und alles daran setzen, dass unser gemeinsames Projekt erfolgreich wird. 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. Ach, und bitte bezahlen Sie auch Ihre Rechnungen rechtzeitig – auch wir haben Fixkosten ;-).

Wir sind EIN Team in unserem Projekt 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 Aufträgen annehmen. Das Team und Projekt des Kunden müssen uns überzeugen, damit wir gemeinsam etwas Großartiges entwickeln können. Das meinen wir ernst.

2 Deep Work

Sie würden nicht glauben, wie viel Zeit Entwickler damit verbringen, nicht zu programmieren. Die durchschnittliche Entwicklungszeit pro Tag in einem klassischen Software-Unternehmen beträgt zwischen 2-4 Stunden. Und selbst die wird mehrfach unterbrochen durch Textnachrichten, E-Mails, Anrufe oder vom Chef persönlich.

Softwareentwicklung ist ein komplexes Unterfangen, das mehrstündige Arbeitsblöcke mit voller Konzentration und ohne Ablenkung benötigt. Unsere Entwickler arbeiten deshalb remote im Homeoffice oder aus Co-Working-Spaces zusammen, anstatt in einem gemeinsamen Office zu sitzen.

So können wir die schlausten Köpfe (und nettesten Entwickler 😉 aus ganz Europa einstellen. Und zusätzlich geben wir Ihnen das, was sie sich am meisten auf der Welt wünschen: Ungestörte Zeit zu programmieren!

Und das tun sie, und zwar hochkonzentriert und unterbrechungsfrei, über Stunden hinweg. So entsteht exzellente Software.

3 Kontinuierliche Verbesserung

Die Entwicklung von Software ist wie das Fischen in unerforschten Gewässern. Anfangs haben Sie eine vage Vorstellung von Ihrem Projekt und davon, was Sie damit erreichen wollen. Das ist die Spitze des Eisbergs oder konkret: 1% der Erkenntnis, die wir gemeinsam im Laufe des Projekts erarbeiten müssen.

Softwareentwicklung bedeutet, eine vage Vision in konkreten Code zu übersetzen. Deshalb ist alles, was wir im Projekt machen, eine gemeinsame Lernerfahrung.

Wir alle sind Menschen mit unterschiedlichen Erfahrungen, Vorurteilen und Schwächen. Deshalb werden wir uns manchmal 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.