×

Wandel vom klassischen Software-Entwicklungsprozess zur agilen Arbeitsweise

SCRUM Management Board

Ein Projekt wird agiler …

Wir befinden uns im Jahr 2020 – 19 Jahre nachdem das „Agile Manifest“ formuliert wurde und blicken zurück auf die Entwicklung, die unser Projekt in den letzten 2 Jahren gemacht hat. Dazu versetzen wir uns in die Vergangenheit in das Jahr 2018 zurück.

Es handelt sich um ein Projekt, welches bis dato über 12 Jahre existiert und Jahr für Jahr Software produziert, die dann millionenfach unterwegs ist. Es gibt jede Menge gewachsene Strukturen und Prozesse, die sich über die Jahre etabliert haben, um die große Anzahl an Anforderungen geordnet umzusetzen. Schaut man jedoch ein wenig genauer hin, unterstützen diese Prozesse nur bis zu einem gewissen Grad die Umsetzung und lassen einen ab einem bestimmten Punkt alleine. Dies zeigt sich besonders bei Projektspitzen, wo der anfallende Arbeitsaufwand kaum zu bewältigen ist. Es stellt sich daher die Frage, wie wir rund 35 Mitarbeiter optimal organisieren, um möglichst flexibel auf sich ändernde Umstände zu reagieren.

Workshop-Phase

Alles beginnt mit einem zweitägigen Workshop zur Selbstreflexion an dem wir unsere alltäglichen Aufgaben beleuchten. Dies geschieht unter Anleitung zweier sehr erfahrener Coaches, die sowohl moderieren, als auch eine Blick von außen hineinbringen, denn bei so einem langfristigen Projekt bleibt eine gewisse Betriebsblindheit nicht aus. Am Ende kommt heraus, dass viele Probleme, die wir identifiziert haben, sich lösen lassen, wenn wir bereit sind etwas zu ändern. Und die Änderung heißt in diesem Fall: Wir begeben uns auf die Reise zu mehr Agilität.

Die erste Aufgabe, die wir anpacken, ist die fachliche Gliederung, so dass möglichst homogene Themenkomplexe entstehen – denn das ist zu dem Zeitpunkt nicht mehr gegeben. Doch nun passen die vorhandenen Teams nicht mehr zu den Themenkomplexen, so dass auch die Teamstrukturen überdacht werden müssen. Heraus kommen drei Teams, die in ihrer Struktur weitaus stimmiger sind als zuvor, wenn gleich man sich bei der Größe (leicht) oberhalb der optimalen Teamgröße für agile Teams befindet, doch das ist vorerst so gewollt.

Als nächstes wollen wir die schon hohe Kommunikationsbereitschaft der Teams noch weiter erhöhen und teamübergreifend Synergieeffekte ausnutzen. Daher trifft es sich gut, dass wir die Chance haben, alle Teams zusammen auf einem Flur innerhalb des Gebäudes zusammenzuziehen. Räumliche Nähe lässt etwaige Hürden in der direkten Kommunikation gar nicht erst entstehen und insbesondere die Küche wird zu einem regen Austausch genutzt.

Aufgaben-Überblick und Planung

Der nächste Schritt ist nun schon durchaus ambitionierter, war es doch in der Vergangenheit so, dass die Themen die Personen gefunden haben und nicht umgekehrt.  So manch einer ist in Arbeit ertrunken und es kamen immer mehr Themen oben drauf. Es muss also mehr Transparenz und Wissenstransfer geschaffen werden. Jeder soll wissen, was dem Team als Ganzes oder dem Teammitglied im Einzelnen für Aufgaben bevor stehen, um diesen dann auch im Team begegnen zu können. Jedem soll die Möglichkeit gegeben werden, Hilfe einzufordern oder aber auch aktiv Hilfe anbieten zu können. Dazu haben wir kurze, tägliche Treffen am Anfang des Arbeitstages etabliert (Dailies), in dem das Team kurz inne hält, um sich für den Arbeitstag zu wappnen. In diesen Treffen werden neue Themen personenneutral vorgestellt und für die weitere Abarbeitung priorisiert an einer Pinnwand festgehalten. Anschließend ist es die Aufgabe des Teams, diese Themen entsprechend abzuarbeiten, wobei darauf geachtet wird, dass sich ein einzelner nicht mit Aufgaben überlädt, die hoch priorisierten Aufgaben aber dennoch schnellst möglich abgearbeitet werden.

Auch der Prozess, wie die Themen in das Team gelangen und anschließend durch das Team abgearbeitet werden, muss angepasst werden. So durchläuft jetzt ein Fehlerticket eine Vorabanalyse auf nicht-technischer Basis bevor es einem Entwickler zur technischen Analyse und dann ggf. technischen Umsetzung vorgestellt wird. Die Entwickler sind zudem konditioniert, ein solches Fehlerticket möglichst schnell komplett durch den Prozess zu befördern, bevor sie sich mit neuen Themen auseinander setzen.

Diese Maßnahmen sind zunächst die Antwort auf kurzfristige Störungen von außen, bleibt aber noch die Bearbeitung der langfristigen Aufgaben, das Einbauen neuer Funktionen in das System. Die Entscheidung fällt für eine ähnliche Herangehensweise wie bei den Störungen, jedoch nutzt man hier ein anderes Zeitfenster. Wenn neue Funktionen eingebaut werden sollen, sind diese oftmals  noch zu groß formuliert und müssen in kleinere Teile zerlegt werden, so dass sie handhabbarer werden. Dies passiert zusammen mit den Stakeholdern dieser neuen Funktion und bildet die Roadmap für die Umsetzung. Die einzelnen Teile werden ebenfalls priorisiert an einer Pinnwand festgehalten und in einem separaten Treffen dem Team zur Bewertung vorgestellt (Backlog Refinement). Dabei können Unklarheiten identifiziert werden, die dann bis zur wirklichen Bearbeitung noch aufgearbeitet werden können. In regelmäßigen, gleichen Abständen kommt es dann zur Zusammenstellung der nächsten Aufgaben, die es umzusetzen gilt, um die Roadmap nicht aus den Augen zu verlieren (Sprintplanung). Dazu werden Ziele formuliert und dem Team vorgestellt, anhand derer es dann die relevanten Teile identifiziert und in den Vorrat des nächsten Abarbeitungszeitfensters übernimmt. Die konkrete technische Umsetzung, deren Planung und die Festlegung wer es umsetzt, liegt dann in der Verantwortung des Teams. Am Ende des Zeitfensters werden die Ergebnisse dann wieder den Stakeholders in einem dedizierten Treffen (Sprintreview) präsentiert, so dass diese ggf. nachsteuern können. Zudem reflektiert das Team sich selbst und arbeitet Missstände auf, sofern es welche gegeben hat (Retro), bevor es dann in erneute Abarbeitungsphase einsteigt, die nach genau demselben Schema abläuft.

Unser Fazit, aber nicht das Ende

Zurück im Hier und Jetzt im Jahr 2020: nach etlichen Durchläufen der eben beschrieben Art und Weise, müssen auch wir kurz inne halten und die Vergangenheit reflektieren. Wir hatten, wie eingangs geschildert, Probleme identifiziert und wollten sie mit Prozessen und Prinzipien aus der Agilen Welt angehen und lösen. Die Umsetzung erfolgte nicht immer nach Lehrbuch, sondern immer auch auf unsere Projektsituation angepasst. So haben wir einen Weg gefunden und sind diesen auch erfolgreich gegangen. Den einen oder anderen Zweifler haben wir auf dieser Reise mitgenommen und überzeugt mitzumachen, mitzugestalten. Es ist schön zu sehen, wie die eigenverantwortliche Arbeitsweise innerhalb der Teams und auch teamübergreifend Früchte trägt und wie das engere Zusammenarbeiten und die offene, direkte Kommunikation innerhalb der Teams den Wissenstransfer weiter fördert.

Dies ist jedoch bei Weitem nicht das Ende der Reise. Da wir, wie eingangs bereits erwähnt  in den gewachsenen Prozessen des Kunden eingebettet sind, versuchen wir auch unsere Umgebung soweit wie möglich auf unserer Reise mit einzubeziehen und zu überzeugen, ein wenig agiler zu werden. Dies ist in Teilen auch schon sehr gut gelungen. Wichtig ist jedoch, dass  wir uns selbst dabei nie aus den Augen verlieren und uns den Gegebenheiten auch weiterhin wenn nötig anpassen.

Von Sebastian Kuebler | 3.03.2020
Sebastian Kuebler

Softwareentwicklung