Über agile Softwareentwicklung wurde bereits viel geredet und geschrieben. Trotzdem stellen wir in unserer täglichen Praxis bei Mondata regelmäßig fest, dass häufig sehr unterschiedliche Vorstellungen existieren, was agil eigentlich heißt. In der Diskussion werden dann häufig agile Vorgehensmodelle wie Scrum, Kanban oder Extreme Programming mit dem Begriff “Agil” gleichgesetzt. Das hat mich zu diesem Artikel motiviert.

Ich werde damit beginnen, kurz zu rekapitulieren, dass es sich beim Begriff “agil” um ein Wertemodell und nicht um ein Vorgehensmodell handelt. Darauf aufbauend, zeige ich, wie wir bei Mondata aus diesen Werten passende Vorgehensmodelle für unsere Projekte entwickeln. Dabei orientieren wir uns selbstverständlich an bewährten Modellen wie Scrum, Kanban oder Extreme Programming, passen diese jedoch immer an die projektspezifischen Rahmenbedingungen an. Zuletzt stelle ich ganz konkret ein Vorgehensmodell vor, das wir bei Mondata für die Entwicklung von GDPR Studio anwenden.

Was ist agil?

Das vorrangige Ziel agiler Softwareentwicklung sollte es meiner Meinung nach sein, möglichst effizient, d.h. mit wenig Zeit- und Kostenaufwand zum qualitativ gewünschten Ergebnis zu kommen. Um dieses Ziel zu erreichen, definiert das agile Manifest vier Grundwerte, jeweils mit meiner Interpretation:

Individuals and interactions over processes and tools

Anstatt starr an globalen Prozessen und Tools festzuhalten, ist in einem Projekt alles erlaubt, was eine effiziente Kommunikation zwischen den Projektbeteiligten ermöglicht. Das heißt nicht, dass man keine Prozesse und Tools einsetzen sollte, sondern nur, dass diese spezifisch für das Projekt in Hinblick auf das Ziel eines möglichst effizienten Informationsflusses bewertet werden müssen.

Working software over comprehensive documentation

Umfangreiche Dokumentation hilft nichts, wenn sie nicht zur realen Software passt – entweder weil diese nie gebaut wurde, oder, weil die Software durch Weiterentwicklung nicht mehr zur Dokumentation passt. Das heißt nicht, dass agile Projekte keine Dokumentation pflegen sollten, es müssen jedoch Wege gefunden werden, dass diese sich an real existierender Software orientiert und nicht für sich steht.

Customer collaboration over contract negotiation

Ein Kontakt zu Stakeholdern geschieht nicht nur zu Projektbeginn in einer vorgelagerten Planungsphase. Stattdessen werden Stakeholder aktiv in den Entwicklungsprozess eingebunden, z.B. in regelmäßigen Reviews und der Weiterentwicklung der Anforderungen. Dies führt zu schnelleren (Teil-)Ergebnissen, erzeugt aber auch neue, z.T. ungewohnte Herausforderungen gerade für externe Kunden. Umgekehrt heißt das aber nicht, dass agile Vorgehensmodelle auf eine detaillierte Anforderungsanalyse durch Stakeholder und Entwicklungsteams verzichten – diese wird nur flexibler gestaltet.

Responding to change over following a plan

Ziele, Anforderungen, Rahmenbedingungen usw. von Projekten ändern sich. Je komplexer ein Projekt ist und je länger es dauert, desto stärker wird es davon betroffen sein. Agile Vorgehensmodelle sind derart gestaltet, dass Entscheidungen schnell und unkompliziert revidiert werden können. Das heißt nicht, dass es keinen Plan gibt, sondern nur, dass existierende Pläne unkompliziert angepasst werden können.

Scrum, Kanban, Extreme Programming, … – Welches Vorgehen ist das beste?

Basierend auf den agilen Grundwerten sind zahllose Vorgehensmodelle entstanden, wobei Scrum, Kanban und Extreme Programming wohl zu den bekanntesten zählen. Umgekehrt ist aber auch jedes andere Vorgehen agil, wenn es sich an diesen Werten orientiert.

Wir bei Mondata sind überzeugt davon, dass es keinen One-Size-Fits-It-All-Approach gibt, das für alle (Software-)Projekte passt. Denn ein unangepasstes Vorgehensmodell führt meist zu einem der folgenden zwei Probleme:

1. Unnötiger Overhead: Wenn das Vorgehensmodell zu komplexe Prozesse für ein Projekt vorgibt, sinkt schnell die Effizienz (Ergebnis pro Zeit). Z.B. eignet sich klassisches Scrum unserer Erfahrung nach erst bei Projekten, die eine gewisse Teamgröße erreicht haben und einen kontinuierlichen Workload aufweisen. Andernfalls führen die starren Entwicklungszyklen und umfangreiche Kommunikationsstrukturen (Sprint Planning, Dailies, Sprint Review, Sprint Retrospektive) zu unnötigem Overhead.

2. Kontrollverlust: Wenn ein Vorgehensmodell wenig Struktur aufweist, aber die Abstimmung von vielen Parteien von Nöten ist, dann wird es zunehmend schwerer, ein Projekt planbar und effizient zu gestalten. Dies passiert häufig, wenn kleine Projekte wachsen: Während sich zu Beginn vielleicht ein bis zwei Projektbeteiligte noch problemlos vorwiegend mündlich auf eine gemeinsame Vision und Milestones verständigen konnten, wird dies ohne Prozesse zunehmend schwieriger, wenn mehr und mehr Stakeholder und Entwickler zum Projekt hinzustoßen – jeder mit seinen eigenen Ansichten, Vorwissen und Arbeitsweisen. Schnell ist unklar, was überhaupt entwickelt werden soll und der Projektfortschritt bleibt im Dunkeln.

Ein sinnvolles Projektmanagement beginnt daher unserer Meinung nach bereits bei einer wohlüberlegten und sachlichen Auswahl des Vorgehensmodells. Während ich selbst überzeugter Verfechter von agilen Methoden bin, sollte diese Entscheidung nicht emotional getroffen werden. So können, abhängig von den Rahmenbedingungen, durchaus auch Vorgehensmodelle optimal sein, die nicht in allen Punkten mit den agilen Grundwerten übereinstimmen. Häufig ist es in der Realität z.B. schwierig, einen externen Kunden hinreichend eng in den Entwicklungsfluss einzubinden, sodass hierfür andere Lösungen gefunden werden müssen.

Bei Mondata passen wir daher unsere Arbeitsweise immer an die Anforderungen des jeweiligen Projekts an. Wenn wir ein Projekt beginnen, analysieren wir detailliert die Rahmenbedingungen, um ein für das jeweilige Projekt geeignetes Vorgehensmodell zu finden. Wichtige Entscheidungskriterien sind dabei:

• Projektanforderungen, z.B.
  • Handelt es sich um ein Projekt mit klarem Umfang oder um eine fortlaufende Entwicklung?
  • Gibt es durch Anbindung an existierende Komponenten Einschränkungen?
  • Stehen Technologien im Projektfokus, die flexible Änderungen im Nachhinein erschweren (z.B. Kryptografie)?
  • Gibt es technische Rahmenbedingungen, die dynamische Releases erschweren (z.B. träge Deployment-Infrastrukturen oder fehlende oder unzureichend automatisierte Testsuites)?
  • Was ist die zu erwartende Komplexität einzelner Features?
• Business-Anforderungen, z.B.
  • Wie sind die Zeitpläne?
  • Gibt es eine feste Milestoneplanung?
  • Wird eine präzise Gesamtkostenschätzung im Voraus erwartet oder gibt es eine rollende Kostenplanung?
  • Können Stakeholder auf regelmäßiger Basis in den Prozess eingebunden werden?
• Anforderungen des Teams, z.B.
  • Wie groß ist das Entwicklungsteam?
  • Ist das Entwicklungsteam zeitlich und räumlich synchronisiert?

Wie immer gilt: Von Beginn an einen optimalen Modus zu finden ist schwierig. Zudem ändern sich viele Projekte im Laufe der Zeit, z.B. wachsen die Teams, die Workloads variieren, usw. Daher muss auch der Modus im Laufe des Projektes stehts re-evaluiert und an die Realität angepasst werden (ganz im Sinne des agilen Grundwerts “Responding to change over following a plan”). Dieses Vorgehen nimmt umgekehrt den Druck, bei der Wahl direkt von Beginn an zu 100% richtig liegen zu müssen.

Agile Softwareentwicklung am Beispiel von GDPR Studio

Rahmenbedingungen

Bei unserem GDPR Studio handelt es sich um ein Projekt, das wir kontinuierlich weiterentwickeln und den Kundenbedürfnissen anpassen. Auch wenn das Projekt z.T. tief in die Systeme der Kunden integriert ist, können wir hier einen relativ flexiblen Entwicklungsprozess verantworten, da wir mit unseren Integrationspartnern eng zusammenarbeiten und es kaum technische Beschränkungen auf den Projektverlauf gibt. Große Teile der Test- und Deployment-Infrastruktur sind zudem automatisiert. Einzig bei den QA-Acceptenace-Tests haben wir uns bisher aufgrund von Kosten-Nutzen-Überlegungen gegen eine Vollautomatisierung entschieden, sodass diese bei Releases manuell geprüft werden müssen.

Auf Business-Seite handelt es sich um ein komplexes, heterogen aufgestelltes Projekt. Neben internen Stakeholdern bei Mondata, arbeiten wir eng mit unseren Resellern, Integrationspartnern und Nutzern zusammen. Die Kostenplanung erfolgt dynamisch und je nach Anforderung zusammen mit verschiedenen Stakeholdern.

Entwickelt wird GDPR-Studio derzeit mit einem Kernteam von 3-5 Entwicklern, die räumlich und zeitlich relativ unabhängig voneinander agieren. Auch der Workload pro Entwickler variiert stark und hängt von den aktuellen Anforderungen des Projekts, aber auch von anderen Projekten ab.

Arbeitsweise

Unser Vorgehen ist in folgender Grafik dargestellt:

Kernstück unserer Arbeitsweise in diesem Projekt ist ein liebevoll gepflegter Backlog in Form eines GitLab Issue Trackers, auf den neben den Entwicklern z.T. auch wichtige Stakeholder Zugriff haben. Sämtliche Anforderungen, Kundenfeedbacks, Bugs, usw. werden dort zu jeder Zeit zentral hinterlegt. Unsere Entwickler kategorisieren die Issues mittels Tags und schätzen, wo nötig, die Aufwände (ganz klassisch in Zeit). Zusammen mit den Stakeholdern werden die Issues priorisiert.

Inhaltliche Abstimmungen erfolgen zumeist dezentral zwischen den relevanten Parteien. Unsere Kommunikationsmedien passen wir dabei situativ an, der Informationsfluss erfolgt mündlich, über Textnachrichten, über den Issue-Tracker oder über dedizierte Konzeptpapiere. Allerdings dokumentieren wir die Ergebnisse jeder Kommunikation im Issue-Tracker. So können alle Projektbeteiligten jederzeit den Fortschritt der einzelnen Features erfassen und Informationen gehen nicht verloren.

Releases erfolgen in der Regel alle 1-2 Monate – je nach aktuellem Workload. Während dieser Zeit werden im Issue-Tracker Issues markiert, die für das nächste Release vorgesehen sind. Unser Entwicklerteam hat dabei ein Auge darauf, dass nicht zu viele Issues selektiert werden und so das Release zu weit in die Zukunft rückt. Dabei werden auch feste Zeitvorgaben von einzelnen Issues berücksichtigt.

Für den nächsten Release selektierte Issues werden vom Entwickler-Team selbstständig bearbeitet. Dabei gibt es drei Vorgehensweisen für die Bearbeitung von Issues:

1. Reguläre Issues haben einen Umfang von weniger als 20 Arbeitsstunden. Diese Issues arbeitet das Entwicklungsteam selbstständig ab. Hierzu kommunizieren die Entwickler der jeweils benötigten Komponenten untereinander und verteilen ihre Aufgaben. Diese Kommunikation wird wiederum im Issue-Tracker festgehalten.

2. Epics sind Issues, mit einem besonders großen Arbeitsumfang (d.h. ungefähr 20-150h). Häufig werden diese Issues in kleinere Issues aufgeteilt, welche untereinander verlinkt und wieder regulär bearbeitet werden. Trotzdem hat bei Epics immer ein Entwickler einen Überblick über den aktuellen Fortschritt des Epics und stellt sicher, dass alle Einzelschritte am Ende integrationsfähig sind.

3. Hotfixes, meist Bugfixes, sind Issues die nicht auf den nächsten Release warten können. Diese werden außerhalb des normalen Zyklus veröffentlicht. Meist handelt es sich um sehr kleine Änderungen (unter 20 Zeilen), die neben Unit-Tests und Developer Integration-Tests auf dem Staging-System zusätzlich durch ein Vier-Augen-Prinzip verifiziert werden. Dafür durchlaufen sie dann einen beschleunigtes Deployment, indem sie die ausführlichen manuellen QA-Acceptence-Tests überspringen.

Zur Entwicklung gehört bei uns immer auch die Erstellung von Unit-Tests, die bereits während der Implementierung einzelner Bausteine deren korrekte Funktionsweise sicherstellen. Vermeintlich fertig entwickelte Features werden auf das Staging-System deployed. Dort testen unsere Entwickler die Integration mit anderen Komponenten und überprüfen die grundlegende Funktionalität.

Rückt der reguläre Release näher, d.h. die Zahl der selektierten noch nicht abgearbeiteten Issues sinkt, setzt sich das Entwicklungsteam einen Releasetermin. Bis dahin werden die verbleibenden Issues abgearbeitet und deren Integration geprüft.

Nach Abschluss aller Feature-Entwicklung führen wir vor jedem Release umfangreiche QA-Acceptance-Tests auf einem Staging-System durch: Für alle wichtigen Features und Flows im Tool haben wir Acceptance-Tests im Cucumber-Format definiert, die wir z.T. manuell durchtesten. Im Allgemeinen finden wir in dieser Phase noch 1-2 Integration- oder Regression-Bugs, die vor dem Release noch behoben werden. Danach erfolgt das Release über einen fast vollständig automatisierten Deployment-Prozess.

Bewertung

Essentiell für ein agiles Vorgehen ist eine stetige Selbstreflexion. Daher bewerten wir unser Vorgehen in Hinblick auf Effizienz, Planbarkeit, Geschwindigkeit, Stabilität und persönliche Entfaltungsmöglichkeiten.

Effizienz

Dank unseres kompakten Teams können wir auf Kommunikationsstrukturen weitgehend verzichten. Die dezentrale Kommunikation erlaubt einen effizienten Informationsfluss, ohne dass Beteiligte unnötig Zeit in Meetings verschwenden. Da die Ergebnisse für alle zugänglich im Issue-Tracker dokumentiert werden, verhindern wir weitgehend redundante Absprachen und verlorene Informationen.

Während der Implementierung kommt uns unsere serviceorientierte Architektur zugute, die eine Verteilung der Aufgaben im Entwicklerteam begünstigt. Einzelne Komponenten lassen sich auf diese Weise weitgehend unabhängig voneinander entwickeln. Pro Komponente gibt es meist nur zwei Spezialisten, sodass auch hier der Abstimmungsaufwand gering ist.

Zuletzt bietet unser Staging-System mit seiner weitgehend automatisierten Deployment-Infrastruktur jedem Entwickler die Möglichkeit, Änderungen schnell und unabhängig zu testen. Für größere Entwicklungen, die in mehreren unabhängigen Branches erfolgen, sind wir zudem in der Lage, mit wenigen Kommandos weitere, vollfunktionsfähige Test-Systeme aufzusetzen.

Planbarkeit

Hier beantworten wir vornehmlich die Frage, ob wir unsere Release-Termine halten können. Die Hauptgefahren für unsere Release-Termine sind die folgenden:

1. Komplexe Epics: Die Planbarkeit von Releases mit Epics haben wir durch unseren Epic-Verantwortlichen erreicht. Da dieser von Beginn an einen Überblick hat und den Fortschritt überwacht, werden bei uns in der Regel auch komplexe Features termingerecht fertig gestellt.
2. Unvorhergesehene Bugs während der QA-Tests: Durch den intensiven Einsatz von vorgelagerten Testmöglichkeiten, treten solche Probleme so gut wie nicht auf.

3. Abweichungen von den Anforderungen während der QA-Tests: In der Praxis kommt dies bei uns selten vor. Dies hat vor allem mit den Rahmenbedingungen zu tun: Zunächst hilft uns die Tatsache, dass unsere Features zumeist von überschaubarer Größe sind. Andererseits haben unsere Entwickler meist ein sehr tiefes Verständnis von großen Teilen der Applikation und überblicken z.T. auch Teile der Business-Perspektive.

   Im Prozess vermeiden wir derartige Probleme, indem wir den Detailgrad der Ausarbeitung im Backlog von der Komplexität des Features abhängig machen. Je komplexer das Feature, desto detaillierter wird im Backlog zusammen mit den Stakeholdern das Feature ausdefiniert.

   Trotzdem kann man feststellen, dass unser jetziges Vorgehen vermutlich nicht gut mit der Projektgröße skaliert. Wenn unser Projekt wächst, werden wir hier zusätzliche Strukturen einführen müssen.

Geschwindigkeit

Unter der Geschwindigkeit verstehen wir die Zeit von der Feature-Idee bis zum Live-Release des Features. Während die hohe Kommunikationseffizienz hier Geschwindigkeit bringt, verlangsamen die verhältnismäßig seltenen Releases den Prozess.

Letztendlich handelt es sich um einen Kompromiss: Die QA-Tests werden zwangsweise benötigt, um stabile, planbare und regressionsfreie Releases durchführen zu können. Andererseits ist deren (verlässliche) Automatisierung mit signifikantem Aufwand verbunden, der sich erst bei hoher Skalierung rechnet. Bei der aktuellen Projektgröße haben wir uns gegen eine Automatisierung entschieden. Den manuellen Aufwand begrenzen wir durch die verhältnismäßig seltenen Releases und nehmen dafür eine etwas geringere Geschwindigkeit in Kauf.

Je größer das Projekt wird, desto eher wird sich auch eine Automatisierung der QA-Tests rechnen. Eine andere Option für höhere Geschwindigkeit wäre eine Canary-Deployment-Infrastruktur, die sich aber auch erst ab einer gewissen Cluster-Größe rechnet. Insgesamt sind es also hauptsächlich betriebswirtschaftliche Überlegungen, die uns von kürzeren Release-Zyklen abhalten.

Stabilität

Durch die vielen Test-Ebenen (Unit, Developer Integration, QA/Acceptance) können wir die Zahl unserer Bugs sehr gering halten und auch bei großen Releases ein hohe Stabilität und Kontinuität gewährleisten. Die meisten Komponenten sind zudem bereits über einige Zeit auf dem Staging-System integriert, bevor sie veröffentlicht werden. Hier erlaubt uns unsere langsamere Geschwindigkeit einen gewissen Stabilitätsbonus. Sollten im Live-System doch mal ernsthafte Probleme auftreten, erlaubt unser klar definierter Hotfix-Prozess schnell und unkompliziert zu reagieren.

Persönliche Entfaltung

Der hohe Freiheitsgrad und das selbstverantwortliche Arbeiten ist uns bei Mondata sehr wichtig und wird durch diesen Prozess begünstigt. Der stark dezentrale und asynchrone Kommunikationsansatz ermöglicht uns zudem eine räumlich und zeitlich komplett freie Arbeitsweise. So garantieren wir den Projekterfolg nicht nur aus dem Büro mit 9-to-5 Arbeitszeiten, sondern auch aus dem Home-Office, dem Van auf Fuerteventura und in den individuellsten Tagesrhythmen.

---

Bildnachweis:
Adobe Stock/Romolo Tavani