Jutta Eckstein: Der Kern der Agilität ist der ständige Fokus auf die Maximierung des Geschäftswerts. Alles andere leitet sich davon ab: Zum Beispiel erstellen wir mit jeder Iteration - also typischerweise alle zwei Wochen - ein lauffähiges Produkt, das den momentan höchstmöglichen Geschäftswert beinhaltet. Durch regelmässige Rückkopplung mit dem Kunden wird gewährleistet, dass das System auch tatsächlich den momentan höchstmöglichen Geschäftswert beinhaltet und nicht irgendetwas, das man eventuell irgendwann einmal, vielleicht aber auch nie, benötigt. Die traditionelle Vorgehensweise stellt im Gegensatz dazu den Geschäftswert erst am Ende der Projektlaufzeit sicher.

Wie gesagt, der Kern der Agilität bezieht sich auf die Maximierung des Geschäftswerts - das kann man insofern als Effizienz- oder auch Produktivitätssteigerung verstehen, als dass man sich nicht auf Unnötiges konzentriert, oder auch insofern, als dass man mit dem Produkt früher auf den Markt kann.

Den grossen Gewinn der agilen Vorgehensweise sehe ich allerdings nicht in der Produktivitätssteigerung, sondern vielmehr darin, dass durch die ständigen Rückkopplungen Risiken schneller sichtbar werden und sich Probleme nicht verstecken lassen. Dabei können sich sowohl die Risiken als auch die Probleme auf die unterschiedlichsten Bereiche beziehen. Beispielswise auf die Funktionalität, die eingesetzte Technologie, die Entwicklungsgeschwindigkeit oder auch die Qualität des Systems.

Agile Softwareentwicklung erfordert hohe Eigenverantwortung von den Mitarbeitern. Diese muss man entsprechend einfordern aber vor allem auch fördern. Die Entwickler sind nicht nur für die Schätzungen verantwortlich, sondern auch für die Aufstellung und Erfüllung des Iterationsplans. Weiterhin sind sie für die Qualität und die Einhaltung der Regeln, etwa die Verifizierung jedes Produktivcodes durch Tests, zuständig.

Der Kundenvertreter hingegen muss die Ansprüche der verschiedenen Kundengruppen unter einen Hut bringen und über entsprechende Priorisierung der gewünschten Features die Maximierung des Geschäftswerts sowie die Rückkopplung mit den Kunden sicherstellen.

Im Weiteren liegt es in der Verantwortung des gesamten Teams, regelmässig und typischerweise nach Abschluss jeder Iteration die eigene Arbeitsweise genau zu hinterfragen. Dabei werden auch Strategien ausgetüftelt, wie das Team als Einheit effektiver werden kann. In der agilen Terminologie wird dies als Retrospektive bezeichnet.

Wenn Agilität tatsächlich gelebt wird, existiert diese Gefahr nicht, da diese Vorgehensweise inhärent eine sehr hohe Disziplin von allen Beteiligten einfordert.

Gefahren sehe ich vielmehr bei Teams, die eine Vorgehensweise einsetzen, für die sie keine Verantwortung haben. Das hat oft zur Folge, dass jeder auf eigene Faust entscheidet, welche Regeln sinnvoll sind und welche nicht. Dadurch entsteht eine uneinheitliche Vorgehensweise im Team. Diese Entwicklung sehe ich häufig beim Einsatz unternehmensweiter Prozesse. Dort beobachte ich bei der Analyse üblicherweise, dass im Unternehmen drei verschiedene Vorgehensweisen existieren: die offizielle, sprich unternehmensweite, dann jene Vorgehensweise, die das Team zu leben glaubt und schliesslich die Vorgehensweise, mit der tatsächlich Code produziert wird.

Ein agiles Team hingegen übernimmt die Eigenverantwortung für die Vorgehensweise. Diese wird regelmässig mittels der Retrospektiven analysiert und das Team trifft dann gemeinsam notwendige Entscheidungen, um die Effektivität zur Maximierung des Geschäftswerts zu verbessern.

Einer der grössten Vorteile der agilen Entwicklung stellt gleichzeitig den grössten Stolperstein dar: Durch die häufige Rückkopplung auf den verschiedenen Ebenen wie Funktionalität, Kundenakzeptanz, Qualität, Schätzungen, etc., werden Probleme nicht nur schneller, sondern auch besser offensichtlich. Um Dierk König von Canoo zu zitieren: . Das ist meiner Ansicht nach definitiv etwas Positives.

Nur wenn man die Probleme erkennt, kann man sie auch adressieren. Ich beobachte jedoch immer wieder, dass dies zu wenig genutzt wird und dass es immer wieder Bestrebungen gibt, die offensichtlichen Probleme nicht sehen zu wollen. Zur Verdeutlichung ein Beispiel: Ein agiles Team misst und kennt daher auch seine Entwicklungsgeschwindigkeit. Das heisst, es ist vollkommen verifizierbar und transparent, wieviel mit jeder Iteration geliefert werden kann. Mithilfe dieser Entwicklungsgeschwindigkeit rechnet man dann den Gesamtprojektplan hoch, beziehungsweise verifiziert ihn regelmässig. Das Ergebnis dieser Verifikation kann nun sein, dass das Endziel nicht in der gegebenen Zeit erreichbar ist. In solchen Situationen erlebe ich immer wieder, dass das Management dies nicht wahrhaben will und die Augen davor verschliesst. Es nutzt dieses mächtige Werkzeug der Entwicklungsgeschwindigkeit nicht, um sich mit dem Kunden insofern abzustimmen, was letztendlich in der gegebenen Zeit geliefert werden kann, beziehungsweise soll. Stattdessen wird die Entwicklungsgeschwindigkeit ignoriert, die Kunden werden nicht gewarnt und weiterhin wird ihnen versprochen, dass das Unmögliche möglich sei.

Agile Entwicklung verlangt Transparenz und Offenheit und dies auch - oder gerade - gegenüber dem Kunden.

Gerade Mission-Critical-Projekte profitieren davon, da man sich mithilfe eines agilen Prozesses auf das Wesentliche konzentriert und nicht die Zeit mit Unnützem verplempert. Weiterhin ist es gerade für solche Projekte essenziell, frühzeitig die Risiken und Probleme zu erkennen. Aus diesem Grund waren meine ersten agilen Projekte allesamt geschäftskritisch.

Mir persönlich ist das Risiko bei einem grossen und verteilten Team zu hoch, einen anderen als einen agilen Prozess einzusetzen. Bei einem umfangreichen Team besteht die Gefahr, dass jedes Team ein eigenes System entwickelt und am Ende nicht ein einziges kohärentes Produkt entsteht. Ausserdem stellt die Zusammenarbeit verschiedener Teams an sich schon ein grosses Risiko dar, so dass es umso wichtiger ist, alle Risiken so früh wie möglich auszuschliessen - und genau das erlaubt eine agile Vorgehensweise.

Man kann immer dann gefahrlos einen anderen als einen agilen Prozess einsetzen, wenn man die Domäne gut kennt. Etwa dann, wenn man mit einem bestimmten Team in der Vergangenheit bereits ähnliche Produkte entwickelt hat, das Projekt weiterhin komplett ohne jegliches Risiko ist und der Zeitpunkt für die Präsenz am Markt unkritisch ist.

Das ist auf die übliche Inkubationszeit von Neuentwicklungen zurückzuführen. Im Vergleich zu manch anderen ging es bei der agilen Vorgehensweise sogar recht schnell. So haben sich beispielsweise relationale Datenbanken erst nach rund 20 Jahren letztendlich durchgesetzt. Die Objektorientierung hat gar von 1967 bis Anfang/Mitte der 90er Jahre gebraucht bis sie im Mainstream angekommen war.

Das liegt meiner Ansicht nach vor allem daran, dass es immer mehr Domänen gibt, die es sich einfach nicht mehr leisten können, ihr Produkt erst am Ende der Entwicklungszeit auf den Markt zu bringen. Sowohl das Internet als auch die zunehmende Globalisierung fordern die Beschleunigung hinsichtlich Marktverfügbarkeit ein.

Zur Person

Jutta Eckstein ist als internationale Beraterin und Trainerin tätig. Sie verfügt weltweit über einen einzigartigen Erfahrungsschatz mit der Umsetzung agiler Prozesse in mittleren bis grossen Projekten, wovon auch ihr Buch «Agile Software Entwicklung im Grossen» handelt. Sie ist Mitglied der AgileAlliance sowie des Technical Advisory Board der SET (Software Engineering Today) 2008. Im Weiteren gehört sie den Programmkomitees verschiedener weiterer europäischer und amerikanischer Konferenzen zum Thema Agilität an.

Begriffserklärung

Ziel der agilen Software-Entwicklung ist es, den gesamten Entwicklungsprozess zu optimieren, indem er verschlankt wird. Dafür werden die Projektziele, das lauffähige System sowie die Kunden ins Zentrum gerückt, während der bürokratische Aufwand auf ein Minimum reduziert wird. Die agile Software-Entwicklung versteht sich als Gegenbewegung zu den traditionellen Vorgehen, die zunehmend als schwergewichtig, dokumentenlastig und bürokratisch angesehen werden.

Die Wurzeln der agilen Software-Entwicklung reichen bis Anfang der 1990er-Jahre zurück. Grosse Popularität erreichte sie 1999, als das Buch «Extreme Programming Explained» von Kent Beck erschien. Das darauf hin wachsende Interesse an Extreme Programming ebnete den Weg für weitere agile Prozesse und Methoden.
Das Fundament der agilen Software-Entwicklung bildet das 2001 niedergeschriebene «Agile Manifest» der AgileAlliance.