Agil im Kopf – Unser Mindset für den Weg zum gelungenen Produkt

Agiles Arbeiten ist mehr als nur ein Buzzword – es ist ein essenzielles Mindset und eine Arbeitsmethode, die in der Software-Entwicklung von zentraler Bedeutung ist. Es ermöglicht uns, innerhalb eines Projekts flexibel zu bleiben und bei Bedarf Anpassungen vorzunehmen.

Das Agile Manifesto wurde bereits im Jahr 2001 aufgesetzt und bildet die Grundlage für das agile Mindset. Es betont die Bedeutung von individuellen Interaktionen im Team, die kontinuierliche Lieferung funktionsfähiger Software und die enge Zusammenarbeit mit dem Kunden. Flexibilität und Veränderungen im Projekt sind wichtiger als eine strikte Planung des Arbeitsablaufs. In einem agilen Umfeld stehen die Teams im Vordergrund, nicht die Prozesse und Werkzeuge. Deswegen gehören eine enge und offene Kommunikation, die Autonomie unserer Teammitglieder und ein Vertrauensklima zu den Grundpfeilern eines erfolgreichen agilen Projekts.

Regelmäßiges Feedback bringt uns schneller ans Ziel

Eine gute Software für die perfekte Customer Experience zu programmieren ist komplex und es ist daher völlig normal, dass während des Projektes mehrere Iterationen notwendig sind.  Der beste Weg zu einem optimalen Produkt besteht darin, dass unsere Teams sich in kleinen Schritten ans Ziel herantasten und dabei regelmäßig kurzes Feedback sowohl vom Team als auch vom Kunden einholen. Schnelles und präzises Feedback hat einen riesigen Wert für uns, da es leichter umzusetzen ist. Nachdem die Software entwickelt und verschiedene Module miteinander verknüpft wurden, gestaltet sich eine Rückkehr zu vorherigen Entwicklungsstadien oft schwierig und aufwändig. Die Komponenten sind voneinander abhängig und eine Aktualisierung zieht weitere Anpassungen nach sich. Unser Ansatz gewährleistet, dass die richtige Expertise zum richtigen Zeitpunkt eingesetzt wird und das Produkt in die richtige Richtung entwickelt wird.

Funktionierende Software generiert das beste Feedback

Ganz nach dem Agile Manifesto legen wir großen Wert darauf, dass Software stets in einem nutzbaren Zustand ist. Das bringt den Vorteil mit sich, dass wir an einem funktionierenden Zwischenprodukt direkt testen und damit Feedback einholen können. So können wir gemeinsam mit unseren Kunden Probleme frühzeitig erkennen, Aufwände minimieren und informierte Entscheidungen treffen. Zudem verbessert es die Planbarkeit, da Deadlines durch Flexibilität im Scope realisierbar werden. Um diese hohe Kadenz für kurze Feedbackschleifen zu erreichen, nutzen wir agile Methoden wie automatisches Deployment, Code-Reviews und regelmäßige Abnahmen.

DevOps - Die Organisationskultur für noch mehr Agilität

DevOps ist eine Methodik und Organisationskultur, die die traditionell getrennten Bereiche Entwicklung und Betrieb vereint und einen starken Fokus auf Automatisierung, kontinuierliche Integration und Bereitstellung sowie umfassendes Testen legt. Bei uns ist das immer ein wichtiger Bestandteil unserer Projekte, denn indem wir direkt am Anfang eine CI/CD-Pipeline (d.h. einen Prozess für kontinuierliche Integration und Auslieferung) aufbauen, können Apps, Web-Apps oder Backends automatisch gebaut und Testversionen an Kunden und Qualitätssicherung (QA) ausgeliefert werden.

Die Studie “Accelerate State of DevOps” von Nicole Forsgren und Kolleg:innen hat untersucht und verdeutlicht, dass die Arbeit mit DevOps mit erfolgreichen Software-Teams zusammenhängt. Hier die wichtigsten Metriken, die für diesen Erfolg sorgen:

🧑‍💻 Deployment Frequency

Regelmäßige Produkt-Releases weisen auf eine hohe Reaktionsfähigkeit der Teams hin.

🚀 Lead Time for Changes

Die Zeit zwischen dem Commit (Code-Festlegung) und der tatsächlichen Live-Schaltung ist kurz. Dies ermöglicht eine schnelle Umsetzung von Änderungen.

🚨 Change Failure Rate

Die Rate der fehlerhaften Deployments ist gering, da Teams ihre Prozesse optimieren, um mögliche Probleme frühzeitig zu erkennen und zu vermeiden.

⏱️ Time to Restore Service

Probleme und Störungen werden schnell behoben, um eine schnelle Wiederherstellung der Dienste sicherzustellen.

Die DevOps-Kultur geht Hand in Hand mit diesen Metriken und legt großen Wert auf kurze Feedbackschleifen und schnelle Kurskorrekturen. Es fördert die Zusammenarbeit zwischen verschiedenen Teams und Abteilungen, vermeidet Silobildung und ermöglicht es, dass Veränderungen jederzeit vorgenommen werden können, ohne an starre Zeitrahmen gebunden zu sein.

Das Ganze sorgt bei den Teams für ein hohes Maß an Vertrauen in die Stabilität ihrer Systeme und Releases zu haben. Die kontinuierliche Integration und Bereitstellung ermöglicht es, Software rund um die Uhr zu veröffentlichen, auch am Freitag, ohne Angst vor potenziellen Problemen vor dem Wochenende. Und mit dieser Sicherheit kommt nicht nur ein großartiges Produkt bei rum, sondern auch entspannte Homies.

Es gibt verschiedene Arbeitsweisen, die den Teams dabei helfen, sich in Projekten zu organisieren. Auch wenn wir alles flexibel halten, helfen Prozesse uns dabei Rahmenbedingungen zu schaffen, die eine hilfreiche Struktur und Effizienz bieten. In unserer Arbeit nutzen wir keinen einheitlichen Prozess, denn es kommt immer auf das Projekt an und teilweise auch, ob der Kunde schon mit einem bestimmten Prozess arbeitet. 

Grundsätzlich haben Projekte verschiedene Phasen, Anforderungen und Team-Zusammensetzungen. Deshalb macht es Sinn, den Prozess auf das Projekt zuzuschneiden, statt andersrum. Bei kleineren Projekten bedeutet das zum Beispiel, dass wir die Prozesse schlanker gestalten können, weil nicht so viel Prozess-Overhead nötig ist.

Hier sind die Modelle, die wir in unserer Arbeit nutzen und oftmals miteinander kombinieren:

Extreme Programming (XP)

Extreme Programming (XP) ist eine der ersten agilen Softwareentwicklungsmethoden und wurde in den 1990er Jahren entwickelt und bildet das Fundament der heutigen agilen Arbeit. Sie wurde als eine Art Antwort auf die langwierigen und starren Prozesse des klassischen Wasserfallmodells entwickelt. 

Das Ziel von XP ist es, effizient und kundenorientiert zu arbeiten, indem kurze Entwicklungszyklen, sogenannte Iterationen oder Sprints, genutzt werden. Die Anforderungen werden in einfachen, verständlichen und kundenorientierten Beschreibungen, den sogenannten User-Storys, festgehalten. Wenn es unklare oder komplexe Probleme gibt, werden Spikes durchgeführt, um schneller mögliche Lösungen zu erkunden und zu evaluieren. Das Team strebt danach, regelmäßig kleine, funktionsfähige Versionen der Software zu erstellen und dem Kunden zur Verfügung zu stellen, um frühzeitig Feedback zu erhalten und auf Rückmeldungen schnell reagieren zu können. Also genau die Grundsätze, nach denen wir auch arbeiten!

Daraus haben sich für Entwickler:innen einige Best Practices entwickelt:

✍️ Code-Style

Einheitlicher Code ermöglicht es dem gesamten Team, leichter zusammenzuarbeiten, Verständnisprobleme zu reduzieren und eine einfache Wartung.

🤝 Collective Code-Ownership

Alle im Team sind für den gesamten Code verantwortlich und können Änderungen daran vornehmen. Dadurch wird eine engere Zusammenarbeit und Verantwortung im Team gefördert.

⚙️ Refactoring

Regelmäßiges Refactoring, also strukturelle Verbesserungen am Code ohne Funktionsänderungen, wird regelmäßig praktiziert, um die Codebasis gesund und wartbar zu halten.

🕵️ Code Reviews / Pair-Programming

Code Reviews werden durchgeführt, um potenzielle Fehler und Verbesserungsmöglichkeiten frühzeitig zu identifizieren. Beim Pair-Programming arbeiten zwei Entwickler:innen an derselben Aufgabe zusammen, wodurch das Wissen und die Qualität der Lösungen verbessert werden.

🧑‍🔬 Unit-Tests

Testing ermöglicht es, die Funktionalität einzelner Codeabschnitte zu überprüfen und Bugs frühzeitig zu erkennen.

🙅 YAGNI (You Aren't Gonna Need It)

Entwickler:innen sollten sich darauf konzentrieren, nur die Funktionen zu programmieren, die sie aktuell wirklich brauchen. Sie sollten sich nicht unnötig mit Spekulationen über zukünftige Anforderungen beschäftigen. Das spart Zeit und Ressourcen, da man sich nur auf das Wesentliche konzentriert und nicht unnötig in Funktionen investiert, die am Ende vielleicht gar nicht benötigt werden.

Scrum

Scrum in den 1990ern als agiles Projektmanagement-Framework entwickelt, um komplexe Aufgaben effizient und flexibel zu bewältigen. Es ist nicht spezifisch für die Softwareentwicklung entstanden und ist ziemlich prozesslastig. 

Scrum arbeitet mit Sprints, die typischerweise eine Dauer von etwa zwei Wochen haben. Während eines Sprints werden spezifische Aufgaben abgeschlossen, und am Ende steht ein potenziell auslieferbares Produkt. Vor jedem Sprint wird im Sprint Planning Meeting gemeinsam mit dem Product Owner das Sprint Backlog erstellt. Am Ende des Sprints wird das Produktinkrement im Sprint Review Meeting dem Kunden präsentiert, Feedback wird gesammelt und Anpassungen werden vorgenommen. Nach jedem Sprint reflektiert das Team in der Sprint Retrospektive über den abgeschlossenen Sprint und identifiziert Verbesserungsmöglichkeiten. Das Backlog Refinement ermöglicht die Besprechung neuer Anforderungen mit dem Product Owner, und im täglichen kurzen Meeting, dem Daily Scrum, tauschen die Teammitglieder Informationen über ihren Fortschritt aus. Das bedeutet allerdings auch, dass innerhalb der Sprints eine Art Mini-Wasserfallmodell durchgeführt wird und Iterationen während des Sprints nicht unbedingt möglich sind. Um es agiler zu gestalten, kann es mit Extreme Programming kombiniert werden.

Kanban

Eine agile Methode, die sich bewährt hat, ist Kanban. Mit Kanban wird der Arbeitsfluss visualisiert und Engpässe werden identifiziert. Das Herzstück von Kanban ist das sogenannte Kanban-Board, das aus Spalten besteht, die den Fortschritt der Arbeit widerspiegeln. Die Arbeitseinheiten (z. B. Aufgaben, Features oder User Storys) werden als Karten oder Tickets auf dem Kanban-Board dargestellt und von links nach rechts durch die Spalten bewegt, während sie Fortschritte machen. Zu den Best Practices gehören getrennte Tickets pro Gewerk, Work-In-Progress-Limits und die Dokumentation von Designs/technischen Details.

Im Gegensatz zu Scrum gibt es bei Kanban keine festen Zeitrahmen wie Sprints, sondern wird als kontinuierlicher Fluss bearbeitet. Das Team kann neue Aufgaben kontinuierlich aufnehmen, wenn Kapazitäten frei werden, und an bestehenden Aufgaben arbeiten, ohne sich auf einen festen Zeitplan zu beschränken. Hierbei arbeiten wir mit dem Pull-Prinzip, das bedeutet, unsere Entwickler:innen nehmen sich die Aufgaben selbst (Pull), anstatt dass ihnen vorgeschrieben wird, was sie als Nächstes zu erledigen haben (Push). Dadurch bietet Kanban eine hohe Flexibilität bei der Anpassung an sich ändernde Anforderungen und Prioritäten. Kanban kann aber auch im Scrum verwendet werden, um den Projektstand auch visuell zu organisieren. Handelt es sich um ein großes Projekt, nutzen wir Kanplan als Methode, die einen Backlog verwendet. Dort wird das gesamte Projekt dokumentiert und das Kanban Board wird dann für den aktuellen Meilenstein genutzt, an dem wir arbeiten. Kanban wird oftmals zusammen mit der Organisationskultur DevOps eingesetzt.

Die genannten Methoden haben sich als wertvolle Werkzeuge erwiesen, um die Projekte zu strukturieren und effizient voranzubringen. Unsere Kunden schätzen die Flexibilität und Individualität, die wir in jedem Projekt bieten können. Das agile Mindset ermöglicht es uns, innovative Lösungen zu finden und den wechselnden Anforderungen gerecht zu werden.

Du bist ein Unternehmen und möchtest agil mit uns zusammenarbeiten? Melde Dich gerne!

Du bist ein:e krasse:r Digital-Expert:in und möchtest ein Homie werden? Hier entlang!