9. September 2022 von Stefan Mönk
#5 Agile Softwareentwicklung – ohne Empirie keinen Fortschritt
Agil verstanden, aber Empirie nicht erklären können? Das sollten wir ändern. Wir haben in den vorherigen Blog-Beiträgen dieser Reihe bereits einiges über Agilität innerhalb der Softwareentwicklung erfahren. Wenn wir agil Software entwickeln, setzen wir üblicherweise eine Hypothese auf. Die Hypothese umfasst meist eine Annahme über den Bedarf einer Kundin oder eines Kunden und eine Idee, wie wir diesen Bedarf befriedigen können.
Wenn wir diese Hypothese nun umsetzen, prüfen wir unser Ergebnis im Anschluss gemeinsam mit der Kundin bzw. dem Kunden. Wir prüfen aber auch den Weg hin zum Ergebnis und überlegen uns, was wir im Prozess beibehalten und was wir verbessern können. Wir inspizieren das, was wir getan haben, und adaptieren unsere Arbeitsweise, um innerhalb der nächsten Iteration noch erfolgreicher zu sein.
Was bedeutet Empirie?
Es soll heute nicht allzu geschichtlich werden, aber da Empirie nicht für alle ein Alltagsbegriff ist, möchte ich diesen Begriff zunächst einmal klären. „Empirie“ stammt aus dem Griechischen und bedeutet in etwa so viel wie „Erfahrung“ oder „Erfahrungswissen“. Der Duden beschreibt „Empirie“ mit: „aus wissenschaftlicher Erfahrung gewonnenes Wissen“.
Nun sind wir überwiegend keine Wissenschaftlerinnen und Wissenschaftler. Aber einfach gesprochen geht es primär um das systematische Sammeln von Daten, um eine aufgeworfene Theorie oder Hypothese zu überprüfen und zu verifizieren oder zu widerlegen. Das bedeutet, wir verlassen uns bei der Empirie nicht nur auf theoretische Wissenschaft, sondern machen unsere eigenen Erfahrungen.
Mit Erfahrungen machen ist es nicht getan und genauso wenig reicht es, einfach nur Daten zu sammeln. Wir wollen effizient in unserem Tun sein. Wie funktioniert das nun also mit der Empirie in der Praxis?
Empirische Prozesskontrolle
Die Empirie baut auf drei Säulen auf, die wir alle in den Prinzipien des agilen Manifests, aber auch in unterschiedlichen agilen Frameworks wiederfinden können. Mit Hilfe der empirischen Prozesskontrolle können wir Empirie anwenden und vollumfänglich von ihr profitieren.
Die drei Säulen lauten: Transparenz, Überprüfung und Anpassung.
Transparenz (Transparency)
Je transparenter wir arbeiten – einzeln oder auch im Team –, desto mehr Daten und Informationen über unser Tun haben wir. Doch wie schaffen wir Transparenz? In aller erster Linie durch Kommunikation. Wenn wir regelmäßig über unsere Ziele, unsere Arbeit und unsere Herausforderungen sprechen, machen wir bereits vieles richtig. Der Blick über die eigene Abteilung hinweg, die Offenheit, Feedback zu geben und Feedback zu erhalten, wie auch der Mut, Ergebnisse zu hinterfragen, fördern Transparenz.
In agilen Frameworks wird meist Kommunikation gefördert und gestärkt, was wiederum positive Auswirkungen auf Transparenz haben kann. Mit Hilfe von Artefakten, Events oder auch vorgegebenen Prozessen wird es uns leichter gemacht, transparent zu arbeiten. In Scrum hilft den Entwicklerinnen und Entwicklern das sogenannte Daily – also eine Art Besprechungsrunde –, Herausforderungen, die das Sprintziel beeinflussen, direkt sichtbar zu machen. Die Retrospektive fördert die Diskussion, welche Arbeitsweisen des letzten Sprints beibehalten werden sollten und welche wir verändern könnten.
Überprüfung (Inspection)
Grundsätzlich eignet sich Scrum als ein hervorragendes Beispiel für Empirie. Das Framework selbst fördert Transparenz, während sämtliche Events den Gedanken von Überprüfung und Anpassung mitbringen.
Mit Überprüfung ist die Begutachtung eines Prozesses, Ergebnisses oder einer Arbeitsweise gemeint. Wir prüfen, ob wir bereits effektiv sind oder ob wir uns verbessern können. Innerhalb des Inspizierens halten wir dann fest, was wir wahrgenommen haben. Es könnte beispielsweise sein, dass wir ein bestimmtes Meeting regelmäßig überziehen, dass wir die letzten Sprintziele nicht erreicht haben oder dass immer dieselben Personen in den Diskussionen aneinandergeraten. Es kann aber auch genauso gut sein, dass wir viel weniger Änderungen an Entwicklertickets haben, seit wir mit der Kundin oder dem Kunden die Workshops vor Ort haben. Genauso könnten wir feststellen, dass das Sprintziel öfter erreicht wird und es weniger offene Tickets am Ende eines Sprints gibt, seitdem die Entwicklerinnen und Entwickler das Sprintziel aktiv mit dem PO aushandeln.
Anpassung (Adaption)
Weder können wir alles, was wir tun oder was innerhalb unserer Umgebung passiert, überprüfen, noch können wir alles auf einmal anpassen. Unsere Zeit für Veränderung ist begrenzt. Wir versuchen uns also auf das Wesentliche zu konzentrieren. Innerhalb unseres Umfeldes geht es darum, sich in erster Linie mit den Dingen auseinanderzusetzen, die entweder den größten Erfolg versprechen oder am dringendsten gelöst werden sollten.
In der Anpassung überlegen wir uns in erster Linie sehr genau, wofür wir unsere Zeit verwenden. Zeit, die in die Anpassungen von Prozessen fließt, kann nicht in das Projektgeschäft investiert werden.
Wenn wir uns dann für etwas entschieden haben, definieren wir das Ziel und versuchen den Aufwand zur Erreichung zu begrenzen. Wie viel ist uns das Lösen des Problems wert? Hat die Zeit nicht gereicht, schauen wir wieder darauf zurück, was wir unternommen haben, prüfen, was wir noch tun müssten, und priorisieren.
Es ist schön, sich aller Probleme bewusst zu sein, das allein wird jedoch nichts verbessern. Wir brauchen also Verantwortliche, die sich auf die Umsetzung der am höchsten priorisierten Ideen konzentrieren. Das kann eine Einzelperson, jemand Außenstehendes oder das ganze Team sein.
Kontinuität
Empirie funktioniert. Sie funktioniert sogar, wenn ich sie einmalig anwende. Aber reicht das? Empirie ist weniger ein Prozess, den man starten muss, um ans Ziel zu gelangen, es ist vielmehr eine Art zu arbeiten und zu denken. Das bedeutet, erst wenn Empirie in den Köpfen der Menschen angekommen ist und gelebt wird, entfaltet sich das wahre Potenzial. Werte und Kultur können uns hierbei unterstützen.
Wir putzen uns nicht nur einmal alle paar Tage die Zähne. Und wer braun werden will, legt sich nicht einmal in die Sonne und hört dann damit auf. Es reicht nicht, in einer von vielen Situationen darüber gesprochen zu haben, dass man nicht weiterkommt und Hilfe benötigt. Wenn wir dann beim nächsten Mal schweigen und vor uns hinarbeiten, wem ist dann geholfen?
Wenn wir feststellen, dass unser Entwicklungszyklus zu lange dauert und wir ihn von vier Wochen auf zwei Wochen reduzieren, dann wird es nicht reichen, wenn wir danach nie wieder über den Zyklus sprechen. Vielleicht stellen wir schon nach sechs Wochen fest, dass die Ergebnisse noch schlechter geworden sind. Wie fatal wäre es, dies nicht transparent zu machen, um es schlussendlich zu ändern und draus zu lernen.
Empirie lebt von einem Mindset der Offenheit. Von einer Feedbackkultur. Es kann sogar wahrlich Spaß machen, sich regelmäßig darüber auszutauschen, was gut lief, was schlecht lief, was wir behalten und was wir ändern wollen, um dann zu planen, wie man es ändert.
Wir überprüfen unser Tun und wir passen es, wenn nötig, an. Wir entwickeln uns weiter und werden stetig besser. Das ist harte Arbeit, aber wer die Erfolge einmal miterlebt hat, der will sie wiedererleben.
Hinterfragt ihr euer Tun, überlegt ihr, wie ihr besser werden könnt, und plant dies ein? Wie transparent bist du in deiner Arbeit?
Weitere spannende Themen aus der adesso-Welt findet ihr in unseren bisher erschienenen Blog-Beiträgen.
Auch interessant:
Kategorie: |
|
Schlagwörter: |
Agilität Softwareentwicklung |
