Was ist agile Entwicklung?

Agilität ist in aller Munde, manchmal verstecken sich Chaos-Projekte hinter diesem Deckmantel. Das brauchen Sie nicht? Ich zeige Ihnen, was ich unter agiler Entwicklung verstehe und wie Sie mit dieser Methodik Vorteile für Ihr Business erreichen.

Kleine Einführung in agile Entwicklung

Was ist agil und warum brauche ich das?

In unserer schnelllebigen Zeit müssen wir schnell auf Anforderungen des Marktes reagieren, um erfolgreich zu sein. Langfristige, starre Pläne sind dafür eher hinderlich.
Also gar nicht planen und ad hock neue Ideen umsetzen? Mit dieser Strategie versinkt unser Projekt ganz sicher schnell im Chaos.
Mit dem Einsatz von agilen Methoden und Techniken gehen wir einen Mittelweg...wir planen flexibel. Was vielleicht erstmal wie ein Widerspruch klingt, ist erprobte Praxis, bisher vor allen Dingen im Bereich der Softwareentwicklung.
Wir starten mit einer groben Vision des Produktes und definieren immer genau den Teil detaillierter, der als nächstes bearbeitet werden soll. Damit spart man endlose Klärungsrunden im Vorfeld, kann Ideen und Erkenntnisse, die im Projektverlauf entstehen und reifen, einfließen lassen und trägt der Tatsache Rechnung, dass viele Komponenten langfristig unsicher sind.
Im agilen Manifest, welches 2001 unter anderem von Ken Schwaber, Mike Beedle und Jeff Sutherland, den drei Begründern von Scrum unterzeichnet wurden, werden die Grundsätze für agile Entwicklung so beschrieben:
"Wir erschließen bessere Wege, Software zu entwickeln, indem wir es selbst tun und anderen dabei helfen.
Durch diese Tätigkeit haben wir diese Werte zu schätzen gelernt:
  • Individuen und Interaktionen mehr als Prozesse und Werkzeuge
  • Funktionierende Software mehr als umfassende Dokumentation
  • Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung
  • Reagieren auf Veränderung mehr als das Befolgen eines Plans
Das heißt, obwohl wir die Werte auf der rechten Seite wichtig finden, schätzen wir die Werte auf der linken Seite höher ein."
Damals lag der Fokus strikt auf der Softwareentwicklung, inzwischen hat man aber dieses Regelwerk erfolgreich auf andere Bereiche adaptiert, so dass man gedanklich "Software" mit "Produkte" ersetzen kann.
Aufbau agiler Projekte nach Scrum
Ich möchte hier kurz auf die agile Arbeitsweise nach dem Scrum Regelwerk, welches gerade in der Software-und Produktentwicklung weit verbreitet ist, eingehen.
Scrum ist kein Modell, welches genaue Handlungsanweisungen vorgibt, sondern ein Rahmenwerk für agiles Prozessmanagment.
Termintreue gewinnt
Bei Scrum wird mit sehr kurzen Entwicklungszyklen, “Sprint” genannt, von maximal 4 Wochen gearbeitet.
Zeit und Preis für jeden Sprint sind fix, der Scope ist variabel.
Damit gewinnt man das Vertrauen des Kunden und kann sehr kurzfristig auf Änderungswünsche reagieren.
Regelmäßige Auswertungen, sowohl das Ergebnis der Arbeit als auch die Arbeitsweise betreffend, verbunden mit den erwähnten kurzen Zyklen ermöglichen effektives empirisches Lernen…einem Grundprinzip von Scrum…und damit der kontinuierlichen Verbesserung.
Wer bestimmt, was entwickelt wird?
Eine Person, in Scrum der Product Owner, verkörpert die lebende Produkt Vision und erweitert und verbessert diese kontinuierlich. Dabei berücksichtigt er die Bedürfnisse der Stakeholder und ist für die Requirement Analyse verantwortlich. Außerdem fließen Erkenntnisse aus dem Markt, technische Aspekte sowie ständig wachsende Erfahrungen in seine Betrachtungen ein.
Basierend auf diesen Bestandteilen, definiert er ein sich ständig entwickelndes Sammelsurium an Anforderungen für das Produkt, in Scrum sind das die User Storys im Product Backlog.
Er entscheidet, natürlich unter Berücksichtigung aller Abhängigkeiten, wie der Scope priorisiert wird. Dabei steht er in engem Kontakt zu allen Stakeholdern, um ihre Interessen zu berücksichtigen.
Und wer entwickelt?
Das Entwicklungsteam besteht aus einer kleinen Gruppe von Entwicklern und arbeitet selbstorganisiert. Es diskutiert und verfeinert mit dem Product Owner die Anforderungen und ist für deren Schätzung verantwortlich.
Entwickler in Nicht-Software-Projekten sind dann respektive alle Personen, die an der Umsetzung des Projekts arbeiten.
Gemeinsam wird am Anfang eines Sprints das Ziel definiert und das Scrum Team wählt aus den höchst priorisierten Anforderungen die passenden aus.
Das Entwicklungsteam ist sowohl für die detaillierte technische Lösungsfindung, die Umsetzung sowie deren Test verantwortlich.
Das Entwicklungsteam steht im regelmäßigen Austausch untereinander sowie mit Product Owner und Scrum Master, um die geplante Arbeit eigenverantwortlich zu organisieren und als Team am Ende des Sprints ein funktionierendes Produkt zu liefern.
Was ist das Ergebnis?
Dieses funktionierende Produkt ist das Ziel eines jeden Sprints, was nicht bedeutet, dass nach jedem Sprint ein Release erfolgen muss. Das entscheidet auch der Product Owner wieder unter Berücksichtigung der Interessen der Stakeholder.
In der Praxis ist es auch nicht immer möglich, ein wirklich nutzbares Produkt am Ende jedes Sprints zu erhalten, man sollte aber die Arbeitspakete möglichst mit diesem Ziel schnüren.
Mit dem funktionierenden Produkt haben Sie immer am Sprintende einen Zwischenstand, den Sie tatsächlich ansehen, ausprobieren und idealerweise auch kurzfristig launchen können, um direktes Kundenfeedback zu erhalten.
Anhand dieses Zwischenergebnisses können die Stakeholder die Wichtigkeit der nächsten Anforderungen neu bewerten oder auch Anforderungen streichen bzw. neu aufnehmen. Diese Änderungen sind im agilen Frameset erwünscht, tragen sie doch wesentlich zur Verbesserung des Produkts bei.
Erfahrungen machen und aus Fehlern lernen
Sollte das Ergebnis einmal nicht Ihren Erwartungen entsprechen, können Sie kurzfristig reagieren, in dem der Product Owner die Anforderungen im Product Backlog überarbeitet, ggf. einige löscht oder neu priorisiert, um möglichst gleich im nächsten Sprint gegenzusteuern.
Im Worst Case “verlieren” Sie einen Sprint, wenn Sie sich entschließen, mit dem Endstand des vorhergehenden Sprints und re-definierten Anforderungen weiter zu machen.
Das ist kein Beinbruch, sondern gehört zum empirischen Lernen, einer Grundidee der agilen Arbeitsweise.
Der Master of Desaster
Damit sich Ihre agilen Projekte gerade nicht zum Desaster, sondern zum Erfolg entwickeln, ist regelmäßige Begleitung, Coaching und Reflexion wichtig. Dafür gibt es im Scrum Modell den “Scrum Master”.
Er hilft, die vielen Herausforderungen, die es bei der Umsetzung der agilen Arbeitsweise zu meistern gibt, zu erkennen und zu lösen. Er unterstützt sowohl das Scrum Team als auch die ganze Organisation beim Erlernen, Umsetzen und kontinuierlichem Leben und Verbessern agiler Methoden. Außerdem ist er für das Beseitigen von “Hindernissen aller Art” im Entwicklungsteam zuständig, angefangen von Umgebungsproblemen, über kurzfristigen Klärungsbedarf von Anforderungen bis hin zu persönlichen Differenzen im Team.
Der agile Projektmanager
Auch wenn das Scrum Modell diese Rolle nicht vorsieht, ist sie doch in den meisten Unternehmen vorhanden und notwendig.
Wichtig ist, dass der Projektmanager die Prinzipien der agilen Entwicklung kennt und teilt, damit er nicht durch das Anwenden ungeeigneter klassischer Projektmanagement-Methoden, wie z.B. Anfordern von Statusberichten, die Agilität stört.
Meist gibt es viele übergreifende Aufgaben, die der Projektmanager übernehmen muss, da das Scrum Team nicht allein und abgeschirmt auf der grünen Wiese arbeitet, sondern Teil eines Unternehmens bzw. Gesamtprojekts mit vielen unterschiedlich arbeitenden Teams ist.