Teil 3: Wie Agile Softwareentwicklung funktionieren kann

Über die gängigsten Fehler, die viele Unternehmen bei der Einführung von agilen Methoden machen, haben wir im Teil 2 bereits gesprochen. Im letzten Teil unserer "Agile-Trilogie" möchten wir nun aufzeigen, wie agile Softwareentwicklung eben doch funktionieren kann. Folgende Tipps und Ratschläge helfen euch beim Start und bei der Umsetzung von Softwareprojekten mit agilen Methoden:

Holen Sie sich Hilfe von Personen mit Erfahrung in agiler Softwareentwicklung

Als Einstieg in agiles Projektmanagement sind Schulungen und Online Kurse sicher ein guter Anfang. Die vier Grundprinzipien vom Agile Manifesto sind schnell gelernt. Dies alleine reicht jedoch nicht aus. Das Manifesto und dessen Bedeutung muss im Kern verstanden und die Paradigmen im hektischen Projektalltag wirklich gelebt werden.

Wir haben bei Sitewerk die Erfahrung gemacht, dass ein Team ohne oder mit wenig Erfahrung in agilem Projektmanagement stark davon profitiert, wenn eine zusätzliche Person (z.B. ein Scrum Master) mit Praxiserfahrung in agilen Vorgehensweisen ins Boot geholt wird. Diese Person kann in vielen Situationen aushelfen, in welchen das Team nicht weiter weiss. Zudem kann sie in gewisser Weise auch die Rolle eines Schiedsrichters einnehmen, der die Hand hebt, sollte man in alte Denkmuster verfallen.

Enger Kontakt zu Kunde und User

Obwohl der Product Owner das Bindeglied zwischen dem Entwicklungsteam und allen übrigen Stakeholdern, wie User, Management oder Kunde, bildet, ist es nicht optimal, wenn Entwicklerinnen und Entwickler zu stark isoliert werden. Es gibt Anforderungen und Feedback, bei denen die Meta-Ebene (Kontext, Gefühle, Pains und Gains) zu stark verloren geht, wenn sie über den PO (Product Owner) in Form einer User Story zum Team gelangen. Im Gegenzug kann ein Kunde viel mehr Verständnis für einen Bug oder eine komplexe und scheinbar teure Anforderung aufbringen, wenn ihm der Entwickler oder die Entwicklerin die Komplexität in eigenen Worten erklären kann.

Wichtig ist, dass das Entwicklungsteam zwar einen direkten und regelmässigen Austausch mit dem Kunden oder User pflegt, jedoch auch Phasen hat, in denen es ungestört arbeiten kann. Hier gilt es ein gesundes Mittelmass zu finden.

CI/CD (Continuous Integration & Continuous Delivery/Deployment) - Ein Muss für agile Softwareentwicklung

Möchte man den Kunden und den User in den Entwicklungsprozess einbeziehen und die Möglichkeit bieten, zeitnah Feedback zu geben, muss der Prozess angepasst werden, wie man Software entwickelt und ausliefert. Hier kommt CI/CD ins Spiel:

Unter Continuous Integration (CI) versteht man einen Prozess, bei dem neu entwickelte Features in kleinen Schritten und kontinuierlich in eine Software integriert werden. Dabei ist ein möglichst hoher Automatisierungsgrad und eine hohe Testabdeckung entscheidend. Andernfalls würde die Software instabil und so kurze Integrationszyklen unmöglich werden.

Früher wurde Software nur drei bis vier Mal jährlich ausgeliefert, was zu langen Feedbackzyklen führte und somit keine Agilität zuliess. Möchte man nun agil auf das Umfeld und dessen Anforderungen reagieren, muss die Software deutlich öfter und schneller ausgeliefert werden. Deshalb wird heute oft auf zweiwöchentliche Releases gesetzt, auf welche der Kunde oder ein User zeitnah Feedback gibt. So wird kontinuierlich ausgeliefert → Countinuous Delivery/Deployments (CD).

Ein gemeinsames Projektziel und eine Vision

Setzt sich das Entwicklungsteam ausschliesslich mit User Stories und Features auseinander, fehlt ihnen das Big Picture und die Vision fürs Ganze. Lasse ich beispielsweise jemanden 1000 Stunden Steine aufeinander stapeln, ohne ihm den Grund dafür zu sagen, wird er schnell einmal ein Motivationsproblem haben. Zeige ich ihm aber ein Foto einer Pyramide und frage ihn, ob er diese mit mir bauen möchte, stapeln sich die Steine beinahe von selbst. So ist es auch bei einem komplexen Softwareprojekt. Das Team braucht eine Vision. Es muss sehen, woran es arbeitet und welcher Mehrwert dabei kreiert wird.

Schaffen Sie Vertragsmodelle, die Agilität auch tatsächlich zulassen

Um agil arbeiten zu können und dem Management dennoch eine finanzielle Planbarkeit zu ermöglichen, bieten sich folgende beiden Modelle der Zusammenarbeit an:

Agiler Festpreis: Bei diesem Modell werden Personal-Resourcen (Bsp. ein Scrum-Team mit drei Developers und einem Scrum Master) und dessen Rate pro Sprint (oder sonstige Zeiteinheit; z.B: zwei Wochen oder ein Monat) festgelegt. Zudem wird ein Projektbudget definiert, was wiederum durch die Team-Rate auf die exakte Projektdauer schliessen lässt. Das Einzige, was sich nun ändern kann, ist der Projektscope. Und genau das ist der Clou der Sache. Der Projektscope soll sich ja den im Projekt hinzugekommenen bzw. geänderten Anforderungen oder den neuen Umständen entsprechend anpassen können. Dies bei 100% finanzieller Planbarkeit.

Verrechnung nach Aufwand: Auch bei dieser Methode werden Personal-Resourcen und deren Rate festgelegt. Es wird monatlich abgerechnet und solang gearbeitet, bis das Produkt die Anforderungen des Kunden erfüllt. Dieses Modell erfordert volle Transparenz, viel Vertrauen und eine sehr enge Kollaboration zwischen Auftragnehmer und Kunden. Sind diese Punkte gegeben, ist diese Methode hocheffizient und man holt das Maximum aus der verrechneten Zeit heraus.

Hinterfragen Sie, seien Sie kritisch zu sich selbst → Retrospektiven

Es versteht sich von selbst, dass man als Team, das Agile Software Development neu implementiert, nicht gleich bei der ersten Iteration optimal unterwegs ist. Der Paradigmenwechsel braucht Zeit und jedes Team muss den für sich besten Weg erst einmal finden. Das gilt auch für Teams, die Agilität schon länger leben. Verbessern kann man sich immer.

Um sich als Team stetig zu verbessern, ist Feedback und ein offener Austausch unter den Beteiligten notwendig. Dazu eignen sich beispielsweise Team Retrospektiven, die jeweils am Ende einer Iteration durchgeführt werden und die Qualität des vergangenen Sprints bewerten. Dabei geht es nicht um den Output resp. die Software selbst, sondern vielmehr um weiche Faktoren, also wie gut das Team beispielsweise untereinander funktioniert hat. Es wird offen und transparent über positive, aber auch negative Dinge gesprochen. Ziel ist es dann, diese Punkte mit Hilfe von Action Items für den kommenden Sprint besser zu machen. So kann sich das Team stetig verbessern, was sich langfristig auf die Performance, aber auch auf einen guten Team Spirit auswirken wird.

Es gibt unzählige Arten, wie eine Team Retrospektive durchgeführt werden kann. Hier einige Ideen.

(https://www.funretrospectives.com/category/retrospective/)

Squad Health Check Model

Ebenfalls interessant ist der von Spotify entwickelte Ansatz vom "Squad Health Check Model", bei dem sich das Team anhand verschiedener Faktoren bewerten und einen Trend identifizieren kann.

(https://engineering.atspotify.com/2014/09/16/squad-health-check-model/)

Fazit

Wichtig ist, dass Agilität viel mehr als ein fancy Buzzword der letzten Jahre ist. Es ist ein Paradigmenwechsel, eine neue Sichtweise, ja gar eine neue Arbeits- oder sogar Lebensweise. Eine agile Transformation ist nie zu Ende, genauso wenig, wie es eine digitale Transformation ist. Das Wichtigste ist, dass man damit anfängt, man immer wieder hinterfragt und anpasst und sich somit iterativ zu verbessern versucht. Eine agile Transformation erfolgreich zu meistern, ist nichts, was in Tagen oder Wochen geschieht. Es erfordert viel Geduld und kann Monate bis zu Jahren dauern, bis die neue Sichtweise bei allen verankert ist.