Geschichte und Überblick

Die ersten Ideen zur agilen Softwareentwicklung, damals noch als leichtgewichtige Softwareentwicklung bezeichnet, entstanden Mitte der 90er-Jahre. Der Ursprung von Scrum ist sogar noch älter und Extreme Programming entstand Ende der 90er. Das agile Manifest wurde 2001 veröffentlicht. Das ist für ein Thema aus dem IT-Bereich lange, lange her. Der Top-PC 1995 hatte 8 MB RAM und kostete 4000 DM.

Als hippes, aktuelles Trend-Thema kann man die agile Softwareentwicklung 2019 nicht mehr bezeichnen.

Eine Umfrage von 2005 ergab, dass 14 % aller Unternehmen agil arbeiteten (Forester Research), 2013 waren es schon 85 % (VersionOne) und 2016 95 % (VersionOne). Agile Softwareentwicklung ist mittlerweile der Standard in der Softwareentwicklung.

Was heißt es aber, agil zu arbeiten? Die Agile Alliance hat 2018 noch einmal definiert, dass man unter agiler Softwareentwicklung einen Sammelbegriff für eine Reihe von Methoden und Praktiken, die auf den Werten und Prinzipien des Manifests Agiler Softwareentwicklung basieren, versteht.

Diese Werte und Prinzipien können auf https://agilemanifesto.org/ nachgelesen werden und haben sich größten Teils etabliert. Niemand entwickelt mehr über Monate im stillen Kämmerlein Software, da wir heute regelmäßig in kurzen Zeitabständen unsere Software ausliefern.

12 Prinzipien der agilen Softwareentwicklung

In den IT-Abteilungen bei onOffice arbeiten wir nach Kanban, haben also eine agile Grundphilosophie. Aber wie schaut ein Check gegen alle 12 Prinzipien der agilen Softwareentwicklung aus?

Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufriedenzustellen.

Wir halten nur sehr wenige Änderungen bewusst zurück, deshalb erhalten unsere Beta-Kunden zweimal pro Woche die neu entwickelten Funktionen. Große Änderungen oder Erweiterungen werden durch Feature-Flags so lange zurückgehalten, bis die Funktionalität so vollständig ist, dass ein Kunde damit arbeiten kann. Sie werden dann im Beta-System direkt zur Verfügung gestellt.

Heiße Anforderungsänderungen selbst spät in der Entwicklung willkommen. Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden.

Die Reaktion auf Veränderungen ist wahrscheinlich einer der ersten Punkte, die man mit agiler Softwareentwicklung in Verbindung bringt – und trotzdem ist es einer der schwierigsten.

Die Weitergabe der Arbeitspakete an die Input-Queues der Entwicklerteams ist bewusst flexibel gehalten, entweder gibt es wöchentliche Termine oder die Teams befüllen die Input Queue nach Bedarf. Einziges Grundprinzip: Bereits begonnene Arbeitspakete sollen, wenn möglich, nicht unterbrochen werden. Der Test ist Kopfsache.

Liefere funktionierende Software regelmäßig innerhalb weniger Wochen oder Monate und bevorzuge dabei die kürzere Zeitspanne.

Wir haben zwei getrennte Systeme, ein Live- und ein Beta-System. In beiden Systemen wird zweimal pro Woche der jeweils aktuelle Stand ausgeliefert. Im Live-System handelt es sich im Normalfall um reine Bugfix-Releases. Das Beta-System erhält dadurch zweimal pro Woche neue Funktionen, die ausgewählten Beta-Kunden direkt zur Verfügung gestellt werden.

Das Live-System erhält nach einer Woche Feature-Freeze alle Änderungen der letzten Wochen, in der Regel am ersten Dienstag des Monats.

Fachexperten und Entwickler müssen während des Projektes täglich zusammenarbeiten.

Fachexperten sind unsere Produktmanager. Jede Anpassung wird von einem Produktmanager angestoßen, der auch Hauptansprechpartner bei Fragen ist. Die geplanten Änderungen werden von einem Entwickler und einen Softwaretester geprüft und besprochen, falls Diskussionsbedarf besteht. Auch während der Umsetzung stehen die Produktmanager als Ansprechpartner für Fragen immer zur Verfügung.

Errichte Projekte rund um motivierte Individuen. Gib ihnen das Umfeld und die Unterstützung, die sie benötigen und vertraue darauf, dass sie die Aufgabe erledigen.

Diesen Punkt sehen wir in der IT-Leitung als eine unserer wichtigsten Aufgaben an.
Trotz oder gerade wegen der selbstorganisierten Teams versuchen wir, alle Entwickler zu unterstützen und ihnen den Rücken zu stärken, ohne uns zu weit einzumischen.

Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteams zu übermitteln, ist im Gespräch von Angesicht zu Angesicht.

Geplante Anforderungen werden bei uns immer schriftlich festgehalten und geprüft. Sobald Unklarheiten auftreten, sind alle Seiten (QA, Entwicklung und Produktmanagement) dazu angehalten, das direkte Gespräch zu suchen. Im Entwicklerteam haben wir trotz der Größe ein gemeinsames Weekly-Standup, in dem die einzelnen Teams kurz über ihre Milestones berichten und allgemeine Informationen für alle weitergegeben. Führen wir größere organisatorische Änderungen durch, treffen wir uns immer und stellen die Änderungen vor. E-Mail nutzen wir nur für unkritischen Themen.

Funktionierende Software ist das wichtigste Fortschrittsmaß.

Dieser Punkt ist ein Teil des »Rücken Freihaltens« aus dem Abschnitt weiter oben. Es ist logisch, dass eine gute, funktionierende Software das Ziel in der Softwareabteilung ist. Hier trifft man häufig auf ein Kennzahlen-Dilemma: Es gibt Zahlen, die wesentlich einfacher zu ermitteln sind, als eine Kennzahl über »funktionierende Software« (Durchlaufzeiten, Projektzeiten).

Agile Prozesse fördern nachhaltige Entwicklung. Die Auftraggeber, Entwickler und Benutzer sollten ein gleichmäßiges Tempo auf unbegrenzte Zeit halten können.

Kanban bietet hier schon eine sehr gute Grundlage. Durch das Pull-Prinzip entscheiden die Entwickler selbst, wann sie ein Arbeitspaket beginnen. Wir schätzen die Projekte in Blöcken, sehen diese Schätzungen aber eher als Komplexitätsschätzungen an. Es ist völlig in Ordnung, dass verschiedene Entwickler unterschiedlich lange für einzelne Projekte benötigen.

Ständiges Augenmerk auf technische Exzellenz und gutes Design fördert Agilität.

Bei uns gilt der Grundsatz »Qualität geht vor Geschwindigkeit«. Gerade im Bereich Code-Qualität, OOP und Architektur wollen wir uns permanent weiterentwickeln und erarbeiten viel über interne Schulungen. Andererseits ist in einer Software, die im Ursprung mittlerweile 15 Jahre alt ist, natürlich nicht alles perfekt – im Gegenteil. Jeder weiß, dass man häufig auf eigene Änderungen zurückschaut und sich ärgert. Das sollte immer ein Anreiz sein, es in Zukunft besser zu machen. Bei allen Änderungen gilt bei uns das Pfadfinderprinzip: Der eigene Lagerplatz (Quellcode) sollte immer sauberer verlassen werden, als man ihn vorgefunden hat.

Einfachheit – die Kunst, die Menge nicht getaner Arbeit zu maximieren – ist essenziell.

Das KISS-Prinzip halte ich in einem immer größer werdenden Entwicklerteam für eines der wichtigsten Grundprinzipien. Dank Code-Reviews und Werkzeugen zur Codeanalyse (wir setzen z. B. sonarQube ein) stellen wir sicher, dass dieses Prinzip auch möglichst weit eingehalten wird.

Die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbstorganisierte Teams.

Den Weg der selbstorganisierten Teams gehen wir in der Softwareentwicklung seit einigen Monaten. Es gibt aktuell keine Teamleiter und die Teams entscheiden selbst, wer die Abstimmung mit dem Produktmanagement vornimmt oder Ansprechpartner für neue Arbeitspakete ist. Jedes Team stimmt auch selbst mit dem Produktmanagement ab, wie und wann neue Projekte an die eigene Input-Queue übergeben werden.

In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann und passt sein Verhalten entsprechend an.

Im Zuge der Selbstorganisation entscheiden die Team selbst, wie und wann Meetings zur Selbstreflexion stattfinden. In unserer Teamkultur werden häufig Dinge in Frage gestellt, diskutiert und neu erfunden.