Umsetzung von agiler Softwareentwicklung in kleinen/mittelständischen Unternehmen

Im März 2017 haben wir bei uns in der statmath GmbH die agile Softwareentwicklung Schritt für Schritt eingeführt. Agile Softwareentwicklung ist in aller Munde und jede größere und auch kleinere Firma versucht diese umzusetzen.
Es stellen sich jedoch viele Fragen, zu denen wir in der Anfangsphase Antworten finden mussten. Diese Antworten können nicht pauschal oder in irgendwelchen Foren beantwortet werden, denn jede Firma ist anders aufgebaut und muss die besten Antworten für sich finden.
Nun aber erst einmal von Anfang an. Viele werden sich fragen:

Was ist agile Softwareentwicklung eigentlich?

Hierfür möchten wir den Artikel von Wikipedia zitieren, denn dieser fasst die Bedeutung sehr gut zusammen:

Agile Softwareentwicklung ist der Oberbegriff für den Einsatz von Agilität (lateinisch agilis: flink; beweglich) in der Softwareentwicklung.
Je nach Kontext bezieht sich der Begriff auf Teilbereiche der Softwareentwicklung – wie im Fall von Agile Modeling – oder auf den gesamten Softwareentwicklungsprozess – exemplarisch sei Extreme Programming oder Scrum aufgeführt.
Agile Softwareentwicklung zeichnet sich durch selbstorganisierende Teams, sowie eine iterative und inkrementelle Vorgehensweise aus.
Es wird versucht, mit geringem bürokratischem Aufwand und Regeln auszukommen und sich schnell an Veränderungen anzupassen, ohne dabei das Risiko für Fehler zu erhöhen.

Mit diesen Prinzipien soll die Softwareentwicklung flexibler und schlanker gestaltet werden als bei den klassischen Modellen (z.B. Wasserfall-Modell) sowie die Verantwortung mehr auf die Teams verteilt und dadurch auch jedem Mitarbeiter mehr Informationen zur Verfügung gestellt werden.

Einführung bei statmath
Für die Einführung bei statmath haben wir einen Mitarbeiter zwei Wochen lang in ein großes Unternehmen in Berlin geschickt, welches die agile Softwareentwicklung nach dem „Scrum“-Modell umsetzt. Dort konnte er live erleben, wie „Scrum“ eingesetzt werden kann und welche Probleme dadurch auftreten können. Als er aus Berlin zurückgekommen ist, hat ihm die Geschäftsführung freie Hand gegeben, um das erlernte in dem Team „App“ (welches neu definiert wurde) von statmath umzusetzen.
Um eine erfolgreiche Umsetzung der agilen Softwareentwicklung im Team zu erreichen, stand an erster Stelle die Information und Einbeziehung der unmittelbar und auch im weiteren Verlauf beteiligten Mitarbeiter. Hintergrund, Sinn und Ziele der Umstellung wurden von Beginn an offen kommuniziert. Die folgende bildliche Darstellung des „Scrum“-Modells hat uns sehr weitergeholfen:

Umsetzung agile Softwareentwicklung mit Scrum-Prozess

Der Scrum-Prozess (Quelle: Wikipedia)

 

Die obige Abbildung beschreibt den Prozess von Scrum und deren Aufbau. Am Anfang und im zeitlichen Verlauf im Hintergrund steht immer der Produkt-Backlog, der die verschiedenen Aufgaben priorisiert und mit einem gewissen Schwierigkeitsgrad speichert (in unserem Falle in Storypoints, genaueres dazu gibt es hier http://www.ksimons.de/2011/06/story-points-verstandlich-erklart/). In diesem Beispiel wird alle 30 Tage der Sprint-Backlog mit Aufgaben gefüllt. Dabei ist zu beachten, dass diese Organisation vom ganzen Team gemacht wird und somit dadurch schon alle Teilnehmer wissen, welche Aufgaben in den nächsten 30 Tagen zu bearbeiten sind. Durch die Priorisierung wird sofort klar, welche Aufgaben als erstes erledigt werden müssen.
Die Aufgaben werden physisch an einem Storyboard aufgehangen, sodass jeder den aktuellen Fortschritt sehen kann und an welchen Aufgaben die Teammitglieder zurzeit bearbeitet. Die folgende Abbildung zeigt exemplarisch ein Storyboard des App-Teams der statmath GmbH.

Agile Softwareentwicklung durch ein physisches Storyboard

Physisches Storyboard

 

Das Storyboard hat bei uns die gleichen Zustände wie unser weiterhin verwendetes Redmine Ticketsystem. Dadurch können wir die Aufgaben in Redmine definieren und den Status entsprechend am Storyboard aktualisieren. Somit verschmelzen an dieser Stelle ein schon lange vorhandenes System mit dem neuen Modell.

Nachdem nun der Sprint geplant wurde, kann mit der Bearbeitung der Aufgaben beginnen. Damit alle Teammitglieder immer auf dem neusten Stand sind und ggf. anderen besser zuarbeiten können, gibt es jeden Morgen ein Stand-Up. In diesem Stand-Up erzählen die Teammitglieder kurz, was sie am Tag davor gemacht haben und was sie für den aktuellen Tag geplant haben. Dadurch weiß jeder im Team, was die Kollegen zurzeit machen und kann die eigenen Aufgaben entsprechend koordinieren um die Zusammenarbeit zu optimieren. Am Ende des Stand-Ups werden noch die „Feelings“ von allen Teammitgliedern abgefragt. Dabei soll von jedem Teammitglied mit der Zahl 0 („Auf keinen Fall“) bis 5 („Klappt!“) bewertet werden, ob das Sprintziel erreicht werden kann. Dadurch wird eine noch bessere Kommunikation und Diskussion zwischen allen Teilnehmer angeregt.

Nachdem nun ein Sprint am letzten Tag angekommen ist, wird mit dem Team eine Retroperspektive („Retro“) veranstaltet. In einer Retro wird rückblickend der Sprint von allen Teammitgliedern analysiert und es wird besprochen, was gut und was schlecht gelaufen ist. Ebenfalls wird versucht, mögliche Verbesserungen für den nächsten Sprint zu identifizieren.
Durch diese stetigen Updates und Rückblicke wird die Arbeit immer effektiver und für alle transparent.
Nun beginnt ein neuer Sprint mit der gemeinsamen Planung, den Stand-Ups, usw.!

Die Theorie hört sich sehr gut an und scheint leicht umsetzbar, doch oft hängt es natürlich an den Kleinigkeiten. Gerne möchten wir euch noch kurz einige individuelle Probleme schildern und wie wir diese gelöst haben:
Problem: Bei statmath arbeiten nicht nur Vollzeitangestellte sondern auch Teilzeitkräfte, Werkstudenten und 450€-Kräfte. Dadurch ist ein stetiges Stand-Up oder eine Retro nicht immer möglich
Lösung: Um einen stetigen Informationsfluss und effektive Arbeitsweise zu ermöglichen, haben wir die Arbeitszeiten so koordiniert, dass in einem Team alle Mitglieder sowohl bei der Retro als auch bei der Planung dabei sein können. Natürlich kann das auch per Skype oder Telefon erfolgen.
Problem: Einige Mitarbeiter von statmath arbeiten öfters im Homeoffice und können somit das physische Storyboard nicht sehen oder verändern.
Lösung: Wir haben ein eigenes auf Redmine basierendes digitales Storyboard gebaut, wodurch alle Teilnehmer immer auf die aktuellsten Informationen zugreifen können.

Agile Softwareentwicklung durch ein digitales Storyboard

Das digitale Storyboard

 

Nachdem diese Startschwierigkeiten identifiziert und gelöst wurden, haben wir „Scrum“ auch in die anderen Teams hineingetragen und die ersten Schritte begleitet. Wie auch in unserem App-Team gab es anfangs Startschwierigkeiten und neue kleinere Probleme die gelöst werden mussten. Durch gute Zusammenarbeit, Kommunikation und mit Hilfe der Retros konnten diese genau spezifiziert und gemeinsam gelöst werden.
Jedes Team konnte somit seine individuellen Bedürfnisse mit einbringen und sich mit teamspezifischen kleinen Abänderungen in „Scrum“ sehr gut wiederfinden.

Zusammenfassend lässt sich sagen, dass die Einführung von agiler Softwareentwicklung die statmath GmbH noch aktiver, flexibler sowie koordinierter gemacht hat und wir dadurch unsere Prozesse stetig verbessern können.

Verfasst von Jean Zimmermann am 25. Oktober 2017