Nico Kotsapanajotou
22. Oktober 2022
7 min
In den letzten 19 Jahren habe ich eine große Vielfalt an Möglichkeiten kennengelernt, digitale Projekte umzusetzen. Von Wasserfall bis hyperagil habe ich in mehr als 30 ambitionierten Projekten schon alles gesehen. Heute möchte ich mit einigen Mythen über Agilität aufräumen, da es zu einem großen Buzzword geworden ist und dabei den besonderen Blick auf die Zusammenarbeit mit Digital-Agenturen richten.
Zunächst einmal halte ich es für wichtig zu verstehen, dass alle agilen Methoden zunächst sehr theoretisch sind und nie zu 100% auf ein Projekt passen. Dennoch enthalten sie einige sehr wichtige Prinzipien, die den Erfolg von Projekten sicherstellen. Der Schlüssel liegt also darin, sich die wichtigsten Prinzipien herauszupicken und eine eigene Art des agilen Arbeitens zu definieren, die zu deinem Projekt in Bezug auf Größe, Arbeitskräfte, Wissen und anderen Faktoren passt.
Im folgenden Artikel werden wir viele dieser Prinzipien und Methoden durchgehen, um einen klaren Blick auf die Mythen des agilen Arbeitens zu werfen. Beginnen wir mit der wohl wichtigsten Frage: Scrum oder Kanban?
Während in ihrer extremsten Ausprägung Scrum vor allem darauf abzielt, ein Projekt in überschaubare Teile (Versionen) zu zerlegen und diese in Sprints zu bearbeiten, während der Rest der Aufgaben (oder Stories) in einem Backlog verbleibt, geht es bei Kanban eher darum, einen Überblick über alle To-Dos in einem konsolidierten Board zu haben.
Die Vorteile von Scrum sind ein sehr klarer Blick auf die nächsten Schritte und das Wichtigste für das nächste Release sowie eine nahezu exakte Planung der Ressourcen pro Sprintzyklus. Die größten Nachteile sind der Mehraufwand, der durch die Besonderheit der Sprints entsteht und der Verlust des Überblicks in späten Projektphasen, wenn es auf die Deadline zugeht. Es gibt mehrere Meetings, die für die Einhaltung dieser Projektstruktur relevant sind: Refinement, Schätzungen, Sprintplanung, Review, Retrospektive.
Die Vorteile von Kanban sind ein besserer Überblick über die offenen Aufgaben und der Wegfall der zusätzlichen Meetings, während die Nachteile ein zusätzlicher Aufwand sind, um alle Beteiligten auf die nächsten Schritte einzustimmen, und aufgrund der fehlenden Schätzungen die fehlende Gesamtdauer der Aufgaben. Das Projekt könnte hinsichtlich der Time-to-Market entgleiten.
Die Frage nach Scrum oder Kanban lässt sich nicht pauschal beantworten. Nachdem wir uns nun einen Überblick über die Vor- und Nachteile verschafft haben, müssen wir einen Blick auf einige Schlüsselkriterien werfen:
a) Projektgröße: Während Scrum für ein 100.00,- EUR Projekt mit wenigen Leuten etwas zu ambitioniert erscheint, könnte der Kanban-Stil bei der Organisation eines 5 Mio. EUR Projekts mit vielen Mitarbeitern Probleme bekommen. Wir können also sagen, je größer das Projekt ist, desto wahrscheinlicher ist es, Scrum zu verwenden. Wir werden später in diesem Artikel darüber diskutieren, wo eine eventuelle Grenze zu ziehen ist.
b) Agentur oder Inhouse-IT: Agenturen verwenden normalerweise Scrum. Und warum? Sie müssen ihre Ressourcen effizient planen. Ein Entwickler braucht genau 40 Stunden Arbeit pro Woche. Um zu wissen, wie viel 40 Stunden an Aufgaben sind, sind Schätzungen für die meisten Agenturen obligatorisch. Wenn Sie stattdessen über eine eigene IT-Abteilung verfügen, könnten man sich den ganzen Aufwand sparen und sich auf die Entwicklung selbst konzentrieren.
c) Knowhow des Entwicklungsteams: Während ein sehr erfahrener Frontend-Entwickler, der z.B. mehr als 20 verschiedene PDPs (Produkt-Detail-Seiten) programmiert hat, genau weiß, was zu tun ist und daher weniger Aufwand in die Verfeinerung der Aufgaben steckt, wird ein Junior immer noch mehr Hilfe benötigen, um seine Aufgaben rechtzeitig zu erledigen. Wir können also sagen, dass es wahrscheinlicher ist, dass erfahrene Entwickler mit Kanban arbeiten können und eher in der Lage sind, sich teilweise selbst zu organisieren, als ein Nachwuchsentwickler, der genau wissen muss, was zu tun ist und was als nächstes kommt.
An dieser Stelle könnte man also sagen: Kleine Inhouse-Projekte mit erfahrenen Entwicklern sind Kanban und große Agenturprojekte mit durchschnittlichem Entwickler-Know-how sind Scrum? Irgendwie schon, aber das würde nur den Status Quo der Branche beschreiben und da gibt es meiner Meinung nach noch viel zu verbessern.
Der enorme Overhead, den Agenturen mit starren Scrum-Methoden erzeugen, ist ein extremer Kostentreiber in Projekten. Die meisten Agenturen verpassen die Chance, die Entwicklungszeit in Projekten zu erhöhen. In der Regel sind 30-35% der Projektzeit Nicht-Entwicklungszeit, manchmal sogar ein noch höherer inakzeptabler Anteil. Je höher der prozentuale Anteil der Nicht-Entwicklungszeit in Projekten ist, desto weniger effizient ist die Agentur.
Deshalb möchte ich jetzt die Frage stellen: Wenn man seine eigene interne IT hätte, sagen wir drei Entwickler und einen Product Owner, würden man dann streng nach Scrum arbeiten, mit Refinement, Schätzungen, Sprint-Planung, Review, Retrospektive, oder würde man lieber seinem PO vertrauen, dass er/sie alle beschäftigt und glücklich macht, sie in einem Raum unterbringt, so dass die Entwickler jederzeit Fragen stellen können und alle unnötigen Meetings überspringen? Ich denke, die Antwort ist klar. Und ist das nicht ein klarer Widerspruch zu dem, wofür agile Softwareentwicklung und insbesondere Scrum ursprünglich stehen?!
Aber warum arbeiten alle auf diese Weise mit den Agenturen zusammen? Weil die meisten Agenturen diese Struktur vorgeben und es kaum Alternativen gibt. Ich denke, dass dies eine große Chance für Agenturen ist, auf zwei wichtige Alleinstellungsmerkmale hinzuweisen, auf die jeder achten sollte, wenn er potenzielle Agenturpartner evaluiert: Die Effizienz und die Erfahrung des Entwicklungsteams. Agenturen, die in der Lage sind, dies zu beweisen oder sogar den Prozentsatz der Entwicklung in einem Vertrag festzulegen, werden sich langfristig von eher ineffizienten Akteuren abheben.
Nachdem wir also unser Ziel, nämlich mehr Effizienz, definiert haben, wie kommen wir dahin? Werfen wir einen Blick auf das Verbesserungspotenzial:
Discovery: Die Auslieferungsmethode und der Workflow müssen bereits während der Discovery-Phase berücksichtigt werden.
Die Auslieferungsmethode muss zur Projektgröße passen: Es macht keinen Sinn, in Sprints zu arbeiten, wenn man 20 Tickets auf dem Board hat.
Die Personalausstattung muss zur Projektgröße passen: Es macht keinen Sinn, ein Team mit Backend- und Frontend-Lead sowie drei Juniors zu besetzen, wenn es für den Kunden effizienter wäre, wenn die beiden Dev-Leads alles alleine machen würden.
User-Stories: Es ist schockierend, wie viel Zeit investiert wird, um z.B. eine PDP in eine unglaublich große Anzahl von aufgeblähten User Stories und Akzeptanzkriterien zu zerlegen. Manchmal habe ich das Gefühl, dass es effizienter wäre, einem Entwickler das Layout in einer Aufgabe zu geben und zu sagen: "Melde dich, wenn du fertig bist, und wir prüfen ob es Verbesserungspotenzial gibt". Sicherlich ist das übertrieben, aber nochmal: Je unerfahrener ein Entwickler ist, desto detaillierter muss jede kleine Komponente einer Aufgabe beschreiben werden.
Projektleiter: Sie sind die Schlüsselfiguren für den Projekterfolg. Fühlen sie sich in Scrum-Strukturen zu wohl und schieben gerne Verantwortung auf andere ab, anstatt das Projekt zu leben, verschenkt man eines der größten Verbesserungspotenziale. Ein guter Projektleiter weiß über alles Bescheid, behält den Überblick und hält das Projekt effizient. Dazu gehören auch unangenehme Aufgaben, wie z.B. dem Chef zu sagen, dass man einen Entwickler wegen seiner mangelnden Erfahrung nicht mit 100% abrechnen kann.
Overheads: Refinement-Meetings mit mehr als zehn Leuten und allen Backend- und Frontend-Entwicklern, bei denen man in einer Stunde drei Aufgaben bespricht, sind ineffektiv. Das technische Refinement von Aufgaben oder Stories sollte nur von einem Entwickler durchgeführt werden. Und das sollte der Entwicklungsleiter oder Lösungsarchitekt sein, der den technischen Überblick über das Projekt behält.
Testing: Dies ist auch ein Nachteil von Scrum. Da der Sprint regelmäßig abgeschlossen werden muss, kann man die kundenseitigen Tests nicht auf demselben Board durchführen. Es muss einen zusätzlichen Workflow oder ein Board für die Abnahme der Aufgaben oder Stories geben. Wir sollten auch über die Redundanz von internen Tests und kundenseitigen Tests (zusätzlich zum technischen Code-Review) nachdenken. Ich frage mich, ob es nicht ein guter Ansatz wäre, so früh wie möglich direkt mit dem Kunden zu testen, aber die Agenturen halten die Entwickler in der Regel von den Kunden fern, weil sie denken, dass dies nicht effizient ist oder aufgrund von Sprachbarrieren (vor allem bei Offshoring-Unternehmen). Daher fassen Agenturen ein Ticket lieber dreimal an, als 5 Minuten mit dem Kunden zu telefonieren.
Hybride Methoden: Warum arbeitet eigentlich niemand mit Kanban-Boards mit Backlogs? Normalerweise werden viele Tickets von Sprint 1 auf Sprint 2 und so weiter verschoben. Warum also nicht ein Kanban-Board als eine Art fortlaufender Sprint mit einem Backlog und einer dynamischen Organisation des Ganzen?
Deplyoment: In den meisten Sprint-Zyklen gibt es am Ende ein großes Deployment, bei dem der Entwicklungsleiter alle Features von mehreren Entwicklern in einem großen Deployment konsolidiert. Bei laufenden Projekten, die in Betrieb sind, ist das Schlagwort "Continouous Deployment" in aller Munde, bei dem man jedes Feature veröffentlicht, sobald es fertig ist. Warum arbeitet man nicht mit Kanban und liefert Feature für Feature aus statt immer bis zum Sprint-Ende zu warten?
Ticket-Pingpong: Person a) schreibt die Use Story, Person b) fügt die Akzeptanzkriterien hinzu, Gruppe c) macht ein Refinement-Meeting, Person d) entwickelt an dem Ticket, Person e) macht einen Code-Review, Person f) macht eine interne QA, Person f) gibt das Ticket zurück an d) zur Verbesserung, Person d) bringt es zurück zum Code-Review für e), e) leitet es an f) weiter, für eine erneute QA, f) segnet es ab zum Deployment, e) deployt und g) führt eine letzte Prüfung durch, bevor es an den Kunden geht, h) der Kunde prüft das Ticket und gibt es aufgrund eines Bugs wieder an einen Projektmanage zurück und das ganze geht wieder von vorne los - ist das effizient? Nein.
Transparenz in der Rechnungsstellung: Die Rechnungsstellung sollte so transparent wie möglich sein: Pro Person, Aufgabe und Datum. Potenzielle Unzulänglichkeiten, die durch Fehler der Agentur oder Overheads, die durch unerfahrene Mitarbeiter entstehen, sollten abgezogen und sichtbar gemacht werden. Wenn ein Projektleiter versucht, jede Minute in einem Projekt abzurechnen und dabei schlechte Qualität liefert, verliert der Kunde das Vertrauen und es entstehen viele unnötige Diskussionen. Die Agentur mag hier auf der rechtlichen Seite stehen, wenn die Abrechnung nach Aufwand erfolgt, aber sie verpasst die Chance, offensichtliche Ineffizienzen auszugleichen und damit Vertrauen aufzubauen.
Was sind also die Schlussfolgerungen zur Steigerung der Effizienz?
a) Theorie überspringen, Prozesse auf Effizienz herunterbrechen
b) eine Projektstruktur muss dem Projekterfolg dienen, nicht den internen Agenturpräferenzen
c) weniger Leute mit mehr Erfahrung
d) weniger Meetings, Overhead reduzieren
d) stattdessen: mehr Verantwortung pro Person
e) Continouous Deplyoment und kontinuierliche Tests können sehr wirkungsvoll sein
f) mehr Vertrauen durch Transparenz gewinnen
Es gibt für Digitalagenturen noch viel zu verbessern - wir werden die Entwicklung agiler Prozesse in der Softwareentwicklung im Auge behalten müssen.
