1 Einleitung

Agile Softwareentwicklung hat es in den Mainstream geschafft. Nach beinahe fünfzehn Jahren nach dem Agilen Manifest sind agile Vorgehensweisen keine exotischen Modelle mehr von Eigenbrötlern, die sich ihre eigene Welt schaffen, sondern eine anerkannte und bewiesenermaßen erfolgreiche Art und Weise, Software zu entwickeln1. Agile Entwicklung ist heute nicht nur erfolgreich, sondern deutlich erfolgreicher als klassische, wasserfallorientierte Vorgehensmodelle – dafür haben wir heute Evidenz.

Mussten wir vor zehn Jahren immer wieder den Beweis antreten, so sind wir heute einen bedeutenden Schritt weiter: Es ist nicht nur die Akzeptanz im breiten Feld vorhanden, ein großer Teil der Unternehmen strebt agile Entwicklungspraktiken und -methoden initiativ an. Darunter ganz besonders Scrum, das aus heutiger Sicht sicherlich das erfolgreichste Framework2 unter den agilen Vorgehensweisen ist. Scrum erfreut sich zunehmender Beliebtheit und Verbreitung. Immer mehr Unternehmen und Teams setzen Scrum und agile Entwicklungspraktiken ein oder behaupten das zumindest.

Als Scrum Coach komme ich zu vielen Unternehmen, und als Trainer führe ich viele Gespräche mit Teammitgliedern oder Vertretern von Organisationen, die Scrum – oft schon seit Jahren – verwenden. Dabei stelle ich manchmal fest, dass es viele Missverständnisse gibt, was Agil und Scrum ausmacht und was nicht.

1.1 Agile Softwareentwicklung

Im Gegensatz zu den klassischen Vorgehensweisen stützen sich agile Prozesse auf frühes und häufiges Feedback aufgrund von fertiggestellten Teillieferungen. Diese Teile müssen jedoch voll funktionsfähig sein, um den Anspruch an wertvolles Feedback zu erfüllen. Nur wirklich funktionierende Software erzeugt realistisches Feedback. Pläne, Diagramme oder Folienpräsentationen im Kontrast dazu verlangen danach, dass sich Menschen immer etwas vorstellen müssen, denn das Ergebnis ist (noch) nicht real. Je nach Komplexität und Vorstellungsvermögen der Beteiligten entsteht damit auch realistisches oder eben unrealistisches Feedback. Im klassischen Vorgehen entsteht reales Feedback oft erst nach Durchlauf vieler Phasen, was oft mehrere Monate, manchmal sogar mehr als ein Jahr dauert.

Iteratives Vorgehen

Im Kern einer jeden agilen Vorgehensweise stehen so genannte Iterationen, das sind Zyklen fixer Dauer, die zum Ziel haben, Feedback zu liefern. In iterativen Vorgehensweisen werden sämtliche Aktivitäten, die wir aus den klassischen Vorgehensmodellen kennen, wie Analyse, Design, Implementierung, Testen, Integrieren, Systemtest etc., durchgeführt, jedoch mehrmals. Wir durchlaufen diese Phasen in Zyklen.

Inkrementelles Vorgehen

Bei der inkrementellen Entwicklung wird das iterative Vorgehen verwendet, jedoch auf andere (neue) Teile des Systems angewendet (manchmal wird hierfür auch der Terminus „iterativ-inkrementell“ verwendet). Es handelt sich also um eine Erweiterung des Produkts, und die Iteration betrachtet damit eine neue Entwicklung3 Bei der inkrementellen Entwicklung wird auch der Prozess verbessert. Das Ergebnis einer Iteration ist ein Inkrement des Produkts, es wird damit ausgehend von einem kleinen, funktionierenden Durchstich ständig erweitert und funktional gehalten.

Inkremente sind beispielsweise Features oder Teile der Produkt­funktionalität. Es ist wesentlich, festzustellen, dass bei der inkrementellen Entwicklung ein vertikal durch die Systemarchitektur liegender Querschnitt geliefert wird. In klassischen Vorgehensweisen geschieht oft das exakte Gegenteil, es werden dabei horizontale Schichten sequenziell und oft gänzlich geliefert. Ein funktionaler und damit feedbackfähiger Querschnitt ist erst nach Lieferung der letzten Schicht möglich. Aus diesem Grund erfolgt bei klassischer Entwicklung das Testen der Funktionalität sehr spät.

In der inkrementellen Entwicklung konzentriert man sich auf kleine (vertikale) Teile, die auch sehr früh getestet werden können. Alle anderen Aktivitäten können damit auch beinahe zeitgleich in einer Iteration erledigt werden (Details dazu werden in Kapitel 6 vertieft).

Das Entwicklungsvorhaben wird nicht mehr für den gesamten Umfang und damit auch nicht für die gesamte Zeit im Detail geplant. Eine Planung mit hohem Detailgrad beschränkt sich hier auf die kommende Iteration. Planung und Entwicklung und damit auch die Validierung der Planung wechseln sich in raschen Rhythmen ab.

Mit einem deutlich geringerem Detailgrad beschäftigt sich der nächsthöhere Planungshorizont, der der unmittelbar folgenden Iterationen: Hier werden nur mehr gröbere Ziele auf Basis der Erkenntnisse aus den bisherigen Iterationen geplant.

Mehr Kundenwert in kürzerer Zeit

Agile Prozesse liefern schneller bessere Ergebnisse und sind fokussiert auf die frühe Bereitstellung von Kundenwert. Es wird bei der Priorisierung auf die Auslieferung von Features mit hohem Kundenwert geachtet. Mit jedem Inkrement steht so nach wenigen Wochen ein lieferbarer Teil des Produkts zur Verfügung, das im Idealfall vom Kunden bereits genutzt werden kann.

In einem typischen Scrum-Projekt wird z. B. alle zwei Wochen ein voll funktionsfähiger Teil der Software geliefert und steht für Feedback durch Kunden, Anwender oder Management zur Verfügung. Durch den Fokus auf die frühe Auslieferung von Features mit hohem Kundenwert entsteht deutlich früher ein bereits einsetzbares Produkt, das auf die Problemstellung fokussiert ist.

1.2 Agile Werte und Prinzipien

Die Bewegung in Form einer Ablehnung von klassischen, schwerfälligen Methoden und Vorgehensmodellen begann in den frühen 90er Jahren damit, dass einzelne Produktentwicklungsteams die bisher bekannten Prozesse der Softwareentwicklung wie iterativ und inkrementelles Vorgehen weitergetrieben haben. Darunter fallen auch Ken Schwaber und Jeff Sutherland, die Scrum entwickelt haben. Neben ihnen gab es eine Reihe weiterer, heute bekannter Persönlichkeiten, die ähnliche Praktiken einsetzen und damals noch „leichtgewichtig“ genannte Methoden entwickelten. Viele von ihnen haben dazu auch auf wissenschaftlichen Konferenzen publiziert. Die zweite Hälfte der 90er Jahre war geprägt von vielen alternativen teilweise sehr revolutionären Ansätzen, die allesamt gegen die schwergewichtigen Methoden ankämpften.

Das Agile Manifest

Im Februar 2001 trafen sich diese Personen und versuchten zusammenzutragen, was ihre Vorgehensweisen gemeinsam haben, und kamen – obwohl sie es zuvor nicht glaubten – am letzten Tag zu einer Menge an Werten, die sie gleichermaßen hochhielten, und einem Dutzend Prinzipien sowie zu einem Konsens über deren Formulierung. Sie erschufen ein Manifest aus Werten, basierend auf Vertrauen und Respekt für einander, die die Organisationsmodelle fördern, die auf Individuen und Zusammenarbeit fußen. Übersetzt klingt das Manifest in etwa so:

Wir entdecken dadurch bessere Wege, Software zu entwickeln, indem wir es selber tun und andere dabei unterstützen, es zu tun. Durch diese Arbeit sind wir dazu gekommen,

• Individuen und deren Interaktionen über Prozesse und Werkzeuge,
• funktionierende Software über umfassende Dokumentation,
• die Zusammenarbeit mit dem Kunden über Vertragsverhandlungen und
• das Eingehen auf Veränderung über das Befolgen eines Plans

zu stellen. Während die Dinge auf der rechten Seite durchaus einen Wert darstellen, schätzen wir die Dinge auf der linken Seite mehr.

Sehr oft wurde dieses Manifest missverstanden und fehlerhaft interpretiert. Keineswegs war damit gemeint, dass es von nun an gar keine Dokumentation mehr geben sollte, sondern lediglich hinterfragt werden muss, wie viel Dokumentation nun wirklich notwendig ist und dass es besser ist, eine funktionierende Software zu haben, als schöne Dokumente, aber keine Software dazu.

Diese Aussagen wurden durch zwölf Prinzipien gestützt, die den Kern der agilen Softwareentwicklung definieren. Diese Prinzipien greifen ineinander und wirken als Ganzes:

1. Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Lieferung werthaltiger Software zufriedenzustellen.
2. Wir begrüßen veränderte Anforderungen auch in einer späten Entwicklungsphase. Agile Prozesse nutzen Veränderungen für den Wettbewerbsvorteil des Kunden.
3. Liefere funktionierende Software häufig, von wenigen Wochen bis zu wenigen Monaten, mit einer Präferenz für kürzere Intervalle.
4. Anwender und Entwickler müssen täglich zusammenarbeiten.
5. Entwickle Projekte um motivierte Personen herum. Schaffe die Umgebung und Unterstützung, die sie benötigen, und vertraue ihnen, dass sie ihre Arbeit machen.
6. Die effizienteste und effektivste Methode, Informationen in ein und innerhalb eines Entwicklungsteams zu übermitteln, ist von Angesicht zu Angesicht.
7. Funktionierende Software ist das primäre Maß für Projektfortschritt.
8. Agile Prozesse fördern nachhaltige Entwicklung. Die Sponsoren, Entwickler und Anwender sollen unendlich lang ein konstantes Entwicklungstempo beibehalten können.
9. Kontinuierliche Aufmerksamkeit für technische Exzellenz und gutes Design unterstützt Agilität.
10. Einfachheit – die Kunst, unnötige Arbeit zu vermeiden – ist essenziell.
11. Die besten Architekturen, Anforderungen und Designs entstehen in selbstorganisierenden Teams.
12. Das Team reflektiert in...