Methodik in der myleo / dsc – Extreme Programming und wie wir es leben

Wenn es um agile Softwareentwicklung geht, fällt den Allermeisten sofort Scrum als etabliertes Vorgehensmodell ein. Ebenso wichtig für die myleo / dsc, aber weitaus weniger bekannt, ist das sogenannte Extreme Programming (XP). Während Scrum sehr konkrete Methoden und Werkzeuge bietet, verzichtet XP als ein maximal problemorientiertes und flexibles Vorgehensmodell weitestgehend auf starre Vorgaben und setzt stärker auf allgemeine Grundsätze. Daher sind XP und Scrum als agile Vorgehensmodelle in der Praxis sehr gut miteinander kombinierbar – so auch bei leogistics. Den kleinsten gemeinsamen Nenner aller agilen Vorgehensmodelle bildet hierbei das „Agile Manifest“, welches von den Erfinder:innen aller etablierten agilen Methodiken unterzeichnet wurde:

• Individuen und Interaktionen haben Vorrang vor Prozessen und Werkzeugen
• Lauffähige Software hat Vorrang vor ausgedehnter Dokumentation
• Zusammenarbeit mit Kunden hat Vorrang vor Vertragsverhandlungen
• Das Eingehen auf Änderungen hat Vorrang vor strikter Planverfolgung

XP wurde von Kent Beck, Ward Cunningham und Ron Jeffries begründet, die auch Erstunterzeichner des „Agilen Manifestes“ waren. Die Erfahrungen aus der XP-Methode flossen später in die Begründung der agilen Softwareentwicklung ein.

Was genau versteht man unter XP und wie hilft es uns bei der täglichen Entwicklung in der myleo / dsc?

„Die Kunden sind Teil des Teams“

Kunden als einen Teil des Teams anzuerkennen, ist ein wichtiger Grundsatz des XP. Für die myleo / dsc sind daher sowohl unsere Beratung als auch das UI/UX-Team tagtäglich im Austausch mit unseren Kunden. Dies ermöglicht uns maximale Flexibilität, um zu jeder Zeit neue Anforderungen an die Lösung zu erkennen und in die Entwicklung einzuplanen, bestehende Lösungen zu überarbeiten oder auch obsolete Anforderungen zu verwerfen.

Innerhalb des Gesamtteams der myleo / dsc sind kleinere Entwicklungsteams etabliert. Diese bestehen nach den Scrum-Prinzipien aus festen, nicht wechselnden Mitgliedern aus den Bereichen UI/UX-Design, Entwicklung und Tests und stehen sehr eng mit der Beratung in Kontakt. Unsere Entwicklungsteams arbeiten hierbei nach Scrum, sodass wir bei leogistics mehrere agile Methoden gleichzeitig anwenden.

Damit die Gesamtlösung trotz der individuellen Entwicklungsteams wie aus einem Guss entstehen kann, kommt ein weiterer wichtiger Grundsatz von XP zum Tragen:

„Collective Ownership“

Bei leogistics berücksichtigen wir bei der täglichen Arbeit unsere selbst auferlegten Coding-Standards in Form von einheitlichen Custom Controls und gesamtheitlichen Entwicklungs- und Designrichtlinien. Zur Vermeidung von Inselwissen sind zudem die Architekten der jeweiligen Entwicklungsteams sowohl im Frontend als auch im Backend im kontinuierlichen übergreifenden Austausch und tragen alle aktuellen Schlüsselinformationen in ihre jeweiligen Teams. Darüber hinaus wird das Wissen in den regelmäßigen Community Calls breit gestreut.

Auch das sogenannte „Pair Programming“ hat sich als Methodik für komplexere Features und MVPs zur Vermeidung von Inselwissen fest in dem Mindset der myleo / dsc Entwicklungsteams etabliert. Wichtig zu erwähnen ist hierbei, dass Pair Programming auch über die Entwicklungsteams hinweg genutzt wird, wir also das Scrum-Prinzip der nicht wechselnden Mitglieder diesbezüglich etwas auflockern. Zwar bleiben alle Mitglieder jederzeit Teil ihres jeweiligen Teams, dürfen aber bei komplexeren Aufgaben in Kooperation mit Mitgliedern aus anderen Teams zusammentreten und auch gemeinsam Lösungen entwickeln. Der Bildung von Inselwissen, gerade bei neuen und komplexen Features, wird dadurch in der myleo /dsc sehr früh entgegengewirkt.

Das Pairing ist außerdem eine wirkungsvolle Methode, um das agile Mindset im Team weiter zu etablieren. Agiles Arbeiten muss immer wieder gefestigt und weiterentwickelt werden. Um das zu gewährleisten, muss jedes Teammitglied wissen, was agiles Arbeiten bedeutet. Durch das Pairing sind die Teams in der myleo / dsc in der Lage, sich gegenseitig zu unterstützen und zu fordern, um die Zusammenarbeit auf ein neues qualitatives Level zu heben.

Trotz all dieser Maßnahmen ist aber natürlich auch unsere Software nie vollständig optimiert und frei von Fehlern, was uns zu einem weiteren XP-Grundsatz bringt:

„Refactoring ist Teil der Entwicklung“

Im XP gilt, dass potenzielle Fehlerquellen und unvorteilhaftes Coding während der Entwicklung überarbeitet werden. Das sogenannte Refactoring ist hierbei Teil der täglichen Arbeit der Entwicklungsteams und wird in unserem Mindset als notwendig erachtet. Wichtig ist hierbei, dass wir stets ganz nach dem Pfadfinderprinzip vorgehen und immer ein lösungsorientierter Ansatz im Vordergrund steht. Auch leben wir eine offene Fehlerkultur sowohl intern als auch in der Kommunikation mit unseren Kunden.

Selbstverständlich haben auch Tests zur Qualitätssicherung in der myleo / dsc einen sehr hohen Stellenwert, womit wir zu einem weiteren Grundsatz von XP kommen:

„Testphasen und Testtiefe sind Teil der agilen Zyklen“

Unseren Entwicklungsteams gehören grundsätzlich auch Mitglieder des Testteams an, wodurch sowohl das Schreiben der automatisierten Tests als auch die Testtiefe in unsere agilen Prozesse eingebunden werden. Dies ermöglicht uns höchste Flexibilität bei der Entwicklung der Integrationstests, um auch die Zuverlässigkeit neu entstandener Features zu gewährleisten und Fehler frühzeitig zu erkennen. Eigenentwicklungen in Form von Custom Controls im UI und den Services im Backend sichern wir zusätzlich mit Unit-Tests ab. Das Schreiben der Unit-Tests ist hierbei fest als Bestandteil der Entwicklung etabliert.

Last, but not least befasst sich ein weiterer wichtiger Grundsatz von XP mit der Komplexität und Regelmäßigkeit von Releases:

„Releases sind eine Management-Entscheidung und keine Entwickler-Entscheidung“

Derzeit veröffentlichen wir unsere Releases der myleo / dsc im Rhythmus von 14 Tagen, wobei wir hier noch Optimierungspotenzial sehen und zukünftig auch Feature-getriebene Batchreleases anstreben. Doch bereits heute gilt der Grundsatz, dass unsere Entwicklungsteams nur die Lösungen entwickeln und bereitstellen. Wann diese veröffentlicht werden, ist keine Entscheidung der jeweiligen Entwicklungsteams, sondern liegt einzig in der Management-Entscheidung, die Gesamtlösung im derzeit vorgegebenen Intervall zu aktualisieren.

Abschließend lässt sich sagen, dass der Weg für die myleo / dsc hin zu einer agilen Entwicklungsmethodik mit Hilfe von Scrum und XP auch manchmal steinig war. Doch der stetige Wunsch, sich weiterzuentwickeln und der unglaubliche Team-Spirit vom Management bis hinein in die Entwicklungsteams brachte uns mit Hilfe von Scrum und XP dorthin, wo wir heute stehen:

„So konsequent wie leogistics agile Softwareentwicklung lebt, ist am Markt nur sehr, sehr selten zu beobachten.“

Diese und ähnliche Aussagen bekommen wir immer wieder von neuen Kolleginnen und Kollegen aus der internen und externen Entwicklung zu hören. Besonders hervorzuheben ist hierbei, dass der größte Teil der Entwicklungsteams in der myleo / dsc fast ausschließlich remote arbeitet. Gerade in der agilen Softwareentwicklung entstehen hierdurch besondere Herausforderungen und laut landläufiger Meinung gilt es auch heute noch als nachteilig bis hin zu unmöglich, die Arbeit aus dem Homeoffice und die agile Softwareentwicklung miteinander zu vereinbaren. So ist selbst im “Agilen Manifest” zu finden: „The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.” Die leogistics beweist in der myleo / dsc immer wieder aufs Neue, dass effektives agiles Arbeiten auch remote möglich ist.

Trotz der sehr erfolgreichen Nutzung agiler Methoden sind wir bei der myleo / dsc weiterhin bestrebt, unsere Prozesse fortlaufend zu professionalisieren. Besonders im Kontext komplexer Software mit mehreren Teams ist das Projektmanagement eine große Herausforderung. Einen Gesamtüberblick der involvierten Teams und Prozesse erhält man zum Beispiel mit einem Blick auf das Scaled Agile Framework (SAFe). Dort sind Scrum und XP für größere Projekte fest miteinander zu einer Lösung verknüpft, die in SAFe als ScrumXP bezeichnet wird. Dabei gibt Scrum die Richtlinien für das Team vor und XP die technische Methodik.

Zuletzt bleibt zu erwähnen, dass XP noch deutlich mehr Prinzipien umfasst, wir uns hier aber auf die für leogistics derzeit relevanten Kernaspekte konzentriert haben. Doch auch hier gilt, dass wir uns bezüglich der verwendeten Methoden und Prinzipien von XP in einer fortlaufenden Transformation befinden, was letztlich auch in Zukunft einer der wichtigsten Schlüssel zum erfolgreichen agilen Arbeiten in der myleo / dsc bleibt.