Agile Projekte zur Web-Entwicklung

Agile Projekte werden gern propagiert, stellen jedoch im Agenturalltag eine Herausforderung dar. Wie wir dieser in unserem CHRIST-Projekt begegneten, verrät Part 3 unserer CHRIST-Story.

von Johanna

|

16. December 2021

16.12.2021

|

Lesedauer: ca. 5 Minuten

In Teil eins und Teil zwei unserer CHRIST-Story haben uns Constantin und Michael geschildert, wie es zum gemeinsamen Projekt kam und was digitale Zusammenarbeit auf Augenhöhe bedeutet.  

Dieser dritte Teil beschreibt den agilen Ansatz und die Zusammenarbeit im Projekt. Die Learnings werden geschildert von Constantin Klause, CHRIST, und Michael  Friedrich, brandpfeil. Die Fragen stellte Johanna von Estorff. 

Die agile Projektdurchführung

Johanna: Michael, mich würde interessieren, wie sich der weitere Projektverlauf gestaltet hat. 

Michael:  Auf unseren gemeinsamen Workshop folgte eine geplante Zäsur, denn wir hatten für Constantin eine Angebotsunterlage geschrieben, die er auch mit anderen Firmen besprach. Wir waren aber glücklich, dass sich CHRIST für die weitere Zusammenarbeit mit uns entschieden hat. 

Durch diese Verfahrensweise änderte sich allerdings die Konstellation: Wir initiierten ein agiles Projektteam und arbeiteten nach einer an Scrum angelehnten Vorgehensweise in fünf Sprints. 

Johanna: Welche Mitglieder hatte das Team? 

Michael: Wir hatten mit Paul und Jonas zwei Full-Stack-Entwickler im Projektteam. Ich selbst durfte die Rolle des Product Owners übernehmen, während Constantin, Arne und weitere CHRIST-Mitarbeiter als Stakeholder agiert haben. 

Johanna: Wie wurden Informationen zwischen CHRIST und dem Team ausgetauscht und woher wusstet ihr, welche Schritte wichtig sind?

Michael: Gerade zu Beginn war es wichtig darauf zu achten, dass die Verantwortung für die Ausgestaltung des Produkts einzig beim Scrum-Team liegt. Für die Beteiligten von CHRIST hieß das, Anforderungen ins Team zu geben und darauf zu vertrauen, dass dieses das Produkt, also den Reparaturannahme- und Diagnoseservice, richtig entwickeln wird.

Von Sprint zu Sprint hat sich aber mehr gezeigt, dass das wie gewünscht funktioniert und wir haben einen sehr guten Arbeitsmodus gefunden. Arne und ich haben mindestens einmal wöchentlich über die Anforderungen an das Endprodukt gesprochen. Unser Projektboard enthielt sämtliche Informationen und Stände und bot damit eine transparente Basis für diesen Austausch. 

Die Sprints planten wir gemeinsam und schlossen sie auch gemeinsam per Review mit Arne und Constantin ab. 

Agile Entwicklung

Johanna: Constantin magst du mir vielleicht einmal erklären, warum ihr euch ausgerechnet für eine agile Methode entschieden habt und was in den einzelnen Sprints dann passiert ist?

Constantin: Ich finde eine agile Vorgehensweise immer dann angebracht, wenn man zwar ein großes Ziel vor Augen hat, aber noch nicht genau weiß, wie der Weg dorthin aussehen soll. 

Da das inhaltliche Thema für uns alle neu war, konnten wir nicht sagen: „Hier brandpfeil, das ist unser Diagnose- und Reparaturannahme-Tool, geht mal bitte vier Wochen ins stille Kämmerlein und macht eine Version 2.0 daraus.“ 

Stattdessen hatten wir alle zusammen in dem Workshop eine Vision festgelegt, wie es sich am Ende anfühlen soll. Dabei war es dann wichtig immer wieder zu verstehen, was die Herausforderungen sind. Und da macht eine agile Vorgehensweise glaube ich durchaus immer Sinn. 

Wir hatten eine Vision, wie sich unser Produkt am Ende anfühlen soll. - Constantin Klause

Johanna: Gab es auch Herausforderungen aufgrund der Agilität?

Constantin: Schwierig war die Priorisierung, hier haben Michael und ich teilweise auch recht kritisch diskutiert: Am Ende des Tages schließen sich eine agile Vorgehensweise und ein festgesetztes Projektbudget natürlich ein bisschen aus. Bei agil kann theoretisch beides passieren: Entweder ist man früher fertig und Michael fragt sich, was er mit den ganzen Tagen, die er CHRIST in Rechnung stellen wollte, machen kann oder aber CHRIST sagt zu brandpfeil, dass das Tool noch nicht das macht, was sich CHRIST gewünscht hat und es anders ist als vereinbart. Daraufhin würde Michael dann sagen, dass die Tage aber schon aufgebraucht sind, die CHRIST gebucht hat. Das war für alle ein bisschen herausfordernd, aber nicht unlösbar. Auch das war spannend. 

Noch ein Beispiel, warum die agile Vorgehensweise sinnvoll war: Wir haben erst im Prozess gemerkt, dass die größte Herausforderung gar nicht ist, wie es sich am Ende für den Kunden anfühlen muss, sondern eher wie man eigentlich etwas leicht handzuhabendes baut für den Mitarbeiter bei CHRIST, für den Handwerker, der kein IT-ler ist. Wir wollten ein Produkt, bei dem man nicht für jede kleine Anpassung der Oberfläche oder für jede neuen Textbaustein immer wieder auf einen Programmierer zugehen muss und sagen muss „Bitte lieber Programmierer, ändere mal folgende Farbe, folgenden Text, folgenden Button“, sondern dass das auch durch einen IT-Amateur getan werden kann. 

 

Johanna: Welchen Anteil nahm denn die Entwicklung dieses „Backends“ ein? 

Constantin: Ganz zu Anfang des Projektes hätten wir gedacht, dass wir lediglich eine Oberfläche bauen. Am Ende stellte sich dann aber heraus, dass wir 70-80 % der Zeit in die Konzeption und Entwicklung des Backends investiert haben. Ich glaube das geht auch nur agil, sonst hätten wir jetzt ein Produkt, was schick aussieht aber den Zweck nicht erfüllt. 

Johanna: Für unsere technikinteressierten Leser wäre es spannend zu erfahren, inwiefern der Techstack eine Rolle gespielt hat, also die Technologien, mit denen der CHRIST Reparaturservice erstellt wurde. 

Constantin: Wir haben brandpfeil gegenüber von Anfang an ganz offen und transparent kommuniziert, dass wir ein Produkt möchten, was wir im späteren Verlauf eigenständig mit unseren IT-Ressourcen weiterbearbeiten können. brandpfeil sollte also als externer Katalysator für dieses Thema fungieren, weil unsere IT-Ressourcen zu sehr in andere Projekte involviert sind, als dass vier Leute vier Wochen lang nur auf diesem Thema denken könnten. Langfristig jedoch haben wir die Ressourcen, interne Anpassungen zu programmieren. 

Daher war es so wichtig, dass brandpfeil einen Tech Stack verwendet hat, den wir bei CHRIST auch einsetzen können. Damit waren wir in der Lage, das Produkt eins-zu-eins zu übernehmen und weiterzuentwickeln. 

Das waren die Eigenheiten des Projektes. Anderenfalls hätte man auch sagen können „Macht ihr einfach mal“, Michael hätte uns ein fertiges Produkt gegeben, uns erklärt wie es funktioniert und für jede Änderung hätten wir wieder einige Stunden bei brandpfeil buchen müssen. Das wäre auch gegangen, hätte uns aber nicht wirklich weitergeholfen. 

0 – 1 – 2 – 3 – 4: Die Sprints

Johanna: Michael, kannst du einmal aufzeigen, was ihr in den einzelnen Sprints gemacht habt?

Michael: Ja, gern. Das Projekt war ja recht sportlich angelegt, in fünf Sprints inklusive technischer Architektur, Konzeption, Design und Umsetzung von Backend und Frontend. Ein klassisches MVP also. 

In „Sprint 0“ haben wir die technische Architektur definiert und in Betracht gezogen, welche externen Komponenten mit in das Projekt reinspielen. Dazu kam die Abstimmung mit der CHRIST IT zum Teck Stack, welche Technologien später von denen weiter supporten werden können. 

Im Sprint 1 haben wir den Check-Out-Prozess gebaut, sodass der Kunde, wenn die Reparaturleistung feststeht, in der Lage ist, seine Daten anzugeben und abzuschicken und so dass er informiert wird, wie es weiter geht. Dort haben wir auch die Möglichkeit eingebaut, direkt Fotos mit dem Smartphone zu machen und zu senden. 

Das komplette Frontend haben wir mobile-first entwickelt, sind also nicht von einem Desktop-Design ausgegangen. Danach, mit den Sprints zwei, drei und vier ging es dann richtig ans Eingemachte.

Im Sprint 2 haben wir kleinere Anpassungen am Frontend vorgenommen, uns ansonsten aber auf das Backend, die dort notwendige Logik und die Verbindung zwischen Backend und Frontend konzentriert. Eine Frage war, wie wir den Diagnoseprozess, also den so genannten Diagnosebaum eigentlich abspeichern. 

In Sprint 3 haben wir den Diagnosebaum bearbeitbar gemacht: Wie legt man neue Fragen an, wie werden diese mit den bestehenden Fragen verbunden und welche Logiken brauchen wir eigentlich noch?

Sprint 4 haben wir gebraucht, um alles noch einmal glattzuschleifen und unser Produkt marktfähig zu bekommen. 

Johanna: Und mit dem Ergebnis waren ja offensichtlich alle zufrieden? 

Michael: Ja. Wir haben zwar nicht jedes kleine Feature einbauen können, weil wir uns auf die wesentlichen Dinge beschränken mussten. „Das ist nicht MVP“ war ein Satz, der häufiger fiel. Trotzdem waren wir alle sehr glücklich, auf welchen Stand wir das Projekt gebracht haben.

Constantin: Ja, das sehe ich auch so.

 

Bis hierhin der dritte Teil unseres Interviews. Kommende Woche veröffentlichen wir den vierten und letzten Teil „Das Endprodukt und unsere Learnings“. Stay tuned!


Teilen via: