Prinzipien und Werte der agilen Softwareentwicklung, von Jeff Sutherland

Scrum wurde von Jeff Sutherland im Jahr 1993 erfunden und unter Mithilfe von Ken Schwaber weiterentwickelt. Anlässlich der OOPSLA-Konferenz im Jahr 1995 erfolgte die Veröffentlichung. Sutherland und Schwaber verbesserten und erweiterten Scrum in zahlreichen Softwareunternehmen und waren an der Erstellung des Agile-Manifests beteiligt. In seinem Blog blickt Jeff auf die Anfänge von Scrum zurück und spricht über empfehlenswerte Vorgehensweisen http://scrum.jeffsutherland.com.

Agile Entwicklung ist ein Begriff, der vom Agile-Manifest abgeleitet wurde. Dieses wurde im Jahr 2001 von einer Gruppe verfasst, zu der die Schöpfer von Scrum, Extreme Programming (XP), Dynamic Systems Development Method (DSDM) und Crystal, ein Vertreter der funktionsorientierten Entwicklung sowie weitere Vordenker der Softwareindustrie zählten. Mit dem Agile-Manifest wurden allgemeine übergreifender Werte und Grundsätze für die damals vorhandenen einzelnen agilen Methodiken festgelegt. Darin sind vier Kernwerte für den Aufbau leistungsstarker Teams aufgeführt.

• Einzelpersonen und deren Interaktion

• Bereitstellen funktionsfähiger Software

• Zusammenarbeit mit dem Kunden

• Reagieren auf Änderungen

Diese Kernwerte werden von den zwölf Prinzipien unterstützt, die auf der folgenden Website beschrieben sind: Manifesto for Agile Software Development.

Diese Werte stellen nicht nur Lippenbekenntnisse der Unterzeichner des Agile-Manifests dar, die bald vergessen werden. Es sind Werte für die Praxis. Jede einzelne agile Methodik nähert sich diesen Werten auf eine etwas andere Weise. Alle diese Methodiken weisen bestimmte Prozesse und Verfahren auf, denen einer oder mehrere dieser Werte zugrunde liegt.

Einzelpersonen und Interaktionen

Einzelpersonen und Interaktionen sind unverzichtbar für leistungsstarke Teams. In Studien der "Kommunikationssättigung" im Verlauf eines Projekts wurde nachgewiesen, dass Teams ohne Kommunikationsprobleme eine 50-mal bessere Leistung als der Branchendurchschnitt erzielen können. Zur Förderung der Kommunikation basieren Agile-Methoden auf regelmäßigen Überprüfungs- und Anpassungszyklen. Beispiele für solche Zyklen sind paarweise Programmierung (alle paar Minuten), fortlaufende Integration (alle paar Stunden), Standup-Besprechungen (täglich) sowie eine Prüfung und eine Retrospektive nach jeder Iteration.

Häufigere Feedbacks und Kommunikation sind jedoch nicht ausreichend, um Kommunikationsprobleme auszuräumen. Diese Überprüfungs- und Anpassungszyklen sind nur dann effizient, wenn sich die Teammitglieder durch einige unverzichtbare Verhaltensweisen auszeichnen:

• Achtung vor dem Wert jeder einzelnen Person

• Richtigkeit in jeder Mitteilung

• Transparenz aller Daten, Aktionen und Entscheidungen

• Vertrauen darauf, dass jede Person das Team unterstützt

• Engagement für das Team und dessen Ziele

Um diese Verhaltensweisen zu fördern, muss das Agile-Management eine begünstigende Umgebung bereitstellen, Teamtrainer müssen ihre Annahme erleichtern, und Teammitglieder müssen sie an den Tag legen. Nur dann können Teams ihr vollständiges Potenzial ausschöpfen.

Eine Aneignung dieser Verhaltensweisen ist schwieriger, als es den Anschein haben könnte. In den meisten Teams werden Aufrichtigkeit, Transparenz und Vertrauenswürdigkeit eher vermieden wegen kultureller Normen oder aufgrund negativer Erfahrungen mit Konflikten, die aus ehrlicher Kommunikation entstanden. Um diese Tendenzen entgegenzuarbeiten, müssen Teamleitung und Teammitglieder die positive Austragung von Konflikten fördern. Dies trägt nicht nur zu einer produktiven Atmosphäre bei, sondern hat zudem eine Reihe weiterer Vorteile:

• Die Prozessverbesserung hängt davon ab, dass die Teammitglieder eine Liste der Hindernisse und Probleme in der Organisation aufstellt, um sie offen in Angriff zu nehmen und entsprechend ihrer Relevanz systematisch auszuräumen.

• Innovation entsteht nur aus dem freien Austausch einander widersprechender Gedanken, einem Phänomen, das von Takeuchi und Nonaka (den Initiatoren von Scrum) studiert und dokumentiert wurde.

• Bei der Einstimmung des Teams auf ein gemeinsames Ziel müssen widersprüchliche Ziele aufgedeckt und behoben werden.

• Ein gemeinsames Engagement für die Arbeit ist nur möglich, wenn sich Personen auf gemeinsame Ziele verständigen und sich dann persönlich und im Team für deren optimale Umsetzung einsetzen.

Dieser letzte Gedanke zum Engagement, ist besonders wichtig. Einzelpersonen und Teams müssen sich uneingeschränkt in Sachen Wertschöpfung engagieren – dies ist die unerlässliche Grundlage von Softwareentwicklungsteams. Agile-Methodiken fördern das Engagement, indem sie Teams ermutigen, sich an einer priorisierten Arbeitsliste zu orientieren, ihre eigene Arbeit zu leiten und den Schwerpunkt auf die Verbesserung ihrer Arbeitsprozesse zu legen. Diese Praxis stellt die Grundlage der Selbstorganisation dar, die die treibende Kraft beim Erreichen von Zielen in einem agilen Team ist.

Um leistungsstarke Teams aufzubauen, werden bei agilen Methodiken Einzelpersonen und Interaktionen höher bewertet als Prozesse und Tools. Praktisch heißt dies, dass alle agilen Methodiken Kommunikation und Zusammenarbeit durch regelmäßige Überprüfungs- und Anpassungszyklen verbessern. Diese Zyklen funktionieren jedoch nur dann, wenn agile Führungskräfte die positive Austragung von Konflikten ermöglichen. Diese ist nötig, um eine gesunde Atmosphäre der Aufrichtigkeit, Transparenz, Vertrauenswürdigkeit, Respekt und Engagement in ihren agilen Teams herzustellen.

Funktionsfähige Software anstatt einer umfassenden Dokumentation

Funktionsfähige Software ist einer der großen Vorteile, den die agile Entwicklung in sich birgt. In allen agilen Methodiken, die im Agile-Manifest vertreten werden, wird betont, dass dem Kunden in regelmäßigen Abständen kleine Abschnitte von funktionsfähiger Software geliefert werden.

Alle agilen Teams müssen eindeutig vermitteln, was mit "funktionsfähiger Software" gemeint ist, die häufig als fertig gestellte Software angesehen wird. Allgemein gesagt, ist ein Funktionsbereich nur dann abgeschlossen, wenn alle enthalten Funktionen sämtliche Tests bestanden haben und vom Endbenutzer verwendet werden können. Teams müssen mindestens über die Komponententests hinausgehen und auf der Systemebene testen. Die besten Teams schließen in ihre Definition eines abgeschlossenen Funktionsbereichs auch Integrationstests, Leistungstests und Kundenakzeptanztests ein.

Ein CMMI Level 5-Unternehmen hat mit umfassenden Daten zu vielen Projekten nachgewiesen, dass die Definition von Akzeptanztests zusammen mit der Funktion, das serielle Implementieren von Funktionen entsprechend ihrer Priorität, das sofortige Ausführen von Akzeptanztests für jede Funktion und das Beheben sämtlicher Fehler mit höchster Priorität die Produktionszeit systematisch verkürzt und Defekte um 40 Prozent reduziert. Und dies gilt für ein Unternehmen, das ohnehin eine der niedrigsten Fehlerraten weltweit hat.

Das Agile-Manifest empfiehlt, dass Teams funktionsfähige Software in festgelegten Intervallen bereitstellen. Die Einigung auf eine Definition von abgeschlossener Software ist eine der praktischen Methoden, mit denen agile Teams die hohe Leistungsfähigkeit und hohe Qualität herbeiführen, die zur Erreichung dieses Ziels erforderlich sind.

Zusammenarbeit mit dem Kunden vor Vertragsverhandlungen

Im Verlauf der vergangenen zwei Jahrzehnte haben sich die Projekterfolgsraten weltweit mehr als verdoppelt. Dies wird kleineren Projekten und häufigen Lieferungen zugeschrieben, die es dem Kunden ermöglichen, in regelmäßigen Abständen Feedback zu funktionsfähiger Software abzugeben. Die Autoren des Manifests haben eindeutig einen wichtige Erkenntnis formuliert, als sie betonten, dass die Einbindung des Kunden in den Softwareentwicklungsprozess entscheidend für den Erfolg ist.

Dies wird durch agile Methodiken gefördert, indem ein Vertreter des Kunden eng mit dem Entwicklungsteam zusammenarbeitet. Das erste Scrum-Team hatte z. B. Tausende von Kunden. Da es nicht praktikabel war, sie alle in die Produktentwicklung einzubinden, wurde ein Kundenbevollmächtigter (ein so genannter Produktbesitzer) ausgewählt, der nicht nur die Kunden vor Ort vertritt, sondern auch Management, Vertrieb, Support, Kundendienst und andere Projektbeteiligte. Der Produktbesitzer hatte die Liste der Anforderungen alle vier Wochen zu aktualisieren, wenn das Team funktionsfähige Software freigab, sodass die aktuellen Gegebenheiten und das reale Feedback von Kunden und Projektbeteiligten berücksichtigt werden konnten. Dadurch konnten die Kunden die entstehende Software mitgestalten.

Das erste XP-Team begann mit einem internen IT-Projekt. Die Teammitglieder konnten mit einem Unternehmens-Endbenutzer täglich zusammenarbeiten. Für etwa 10 Prozent der Zeit können Beratungsfirmen und interne Teams einen Endbenutzer gewinnen, der täglich mit dem Team arbeiten kann. Die übrigen 90 Prozent der Zeit müssen sie mit einem Bevollmächtigten zusammenarbeiten. Dieser Kundenbevollmächtigte, der von XP-Teams als Kunde bezeichnet wird, arbeitet mit den Endbenutzern zusammen, um eine eindeutige, nach Prioritäten sortierte Liste von Funktionen zu erhalten, die von den Entwicklern implementiert werden sollen.

Die tägliche Zusammenarbeit mit dem Kunden (oder dem Kundenbevollmächtigten) ist einer der Hauptgründe dafür, dass agile Projekte im Durchschnitt und weltweit eine mehr als doppelt so hohe Erfolgsrate wie herkömmliche Projekte haben, wie die Branchendaten beweisen. Agile-Methodiken erkennen diese Tatsache an, und daher wurde in den Entwicklungsteams eine Stelle speziell für den Kundenvertreter eingerichtet.

Reagieren auf Änderungen anstelle von strikter Planverfolgung

Das Eingehen auf Änderungen ist wesentlich beim Erstellen eines Produkts, mit dem der Kunde zufrieden ist und das einen Geschäftswert liefert. Branchendaten verweisen darauf, dass sich während der Entwicklung einer Software mehr als 60 Prozent der Produkt- bzw. Projektanforderungen ändern. Selbst wenn herkömmliche Projekte pünktlich, im Rahmen des veranschlagten Budgets und mit allen geplanten Funktionen fertig gestellt werden, sind Kunden häufig unzufrieden, da das erhaltene Produkt nicht ihren Erwartungen entspricht. " "Humphrey's Law" besagt, dass Kunden nie wissen, was sie möchten, bevor sie die funktionsfähige Software in Händen halten. Wenn Kunden bis zum Abschluss eines Projekts keine funktionsfähige Software sehen, ist es zu spät, um ihr Feedback zu integrieren. Agile-Methodiken sehen das Kundenfeedback über das gesamte Projekt vor, damit das Feedback und neue Informationen während der Entwicklung des Produkts integriert werden können.

Alle Agile-Methodiken weisen integrierte Prozesse auf, mit denen die Pläne in regelmäßigen Abständen entsprechend den Feedbacks vom Kunden oder Kundenbevollmächtigten geändert werden können. Die Pläne werden so konzipiert, dass der höchste Geschäftswert immer an erster Stelle steht. Da 80 Prozent des Werts durch 20 Prozent der Funktionen geliefert wird, werden optimal ausgeführte agile Projekte häufig vorzeitig abgeschlossen, während die meisten traditionellen Projekte später als geplant beendet werden. Dies führt zu zufriedeneren Kunden, und auch die Entwickler haben mehr Spaß an ihrer Arbeit. Agile-Methodiken basieren auf der Erkenntnis, dass für den Erfolg Änderungen eingeplant werden müssen. Daher wurden Prozesse implementiert (z. B. Prüfungen und Retrospektiven), anhand derer Prioritäten regelmäßig entsprechend den Kundenfeedbacks und dem Geschäftswert verschoben werden.

Agile ist ein Überbegriff - Methodiken sind Implementierungen

Agile Entwicklung stellt keine Methodik an sich dar. Es handelt sich vielmehr um einen übergreifenden Begriff, mit dem verschiedene agile Methodiken beschrieben werden. Bei der Unterzeichnung des Agile-Manifests im Jahr 2001 zählten hierzu Scrum, XP, Crystal, FDD und DSDM. Seitdem wurden Lean-Prozesse als weitere wertvolle Agile-Methodik eingeführt, die daher in der Abbildung später in diesem Thema ebenfalls aufgeführt sind.

Jede agile Methodik weist einen etwas anderen Ansatz zum Implementieren der Kernwerte des Agile-Manifests auf, ebenso wie viele Computersprachen die Kernfunktionen der objektorientierten Programmierung auf verschiedene Weise abbilden. Eine aktuelle Umfrage zeigt, dass etwa die Hälfte der Agile-Praktiker darauf verweisen, dass sich ihr Team mit Scrum befasst. Weitere 20 Prozent sagen, dass sie sich für Scrum mit XP-Komponenten entschieden haben. Weitere 12 Prozent verlassen sich ausschließlich auf XP. Da mehr als 80 Prozent der agilen Implementierungen weltweit Scrum oder XP darstellen, liegt der Schwerpunkt von MSF for Agile Software Development v5.0 auf den Kernprozessen und Verfahren von Scrum und XP.

Scrum ist ein Framework für agile Entwicklungsprozesse. Es umfasst keine bestimmten Entwicklungsverfahren. Bei XP hingegen liegt der Schwerpunkt auf Entwicklungsverfahren, es ist jedoch kein übergreifendes Framework der Entwicklungsprozesse vorhanden. Das bedeutet nicht, dass von Scrum keine bestimmten Entwicklungsverfahren empfohlen werden oder dass XP über keinen Prozess verfügt. Im ersten Scrum-Projekt wurden z. B. alle Entwicklungsverfahren implementiert, die nun unter dem Namen XP bekannt sind. Das Scrum-Framework für Softwareentwicklung ist jedoch so konzipiert, dass es einem Entwicklungsteam den Einstieg in zwei oder drei Tagen ermöglicht, wohingegen die Implementierung von Entwicklungsverfahren häufig viele Monate dauert. Daher wurde die Frage, wann (und ob) bestimmte Verfahren implementiert werden sollen, dem jeweiligen Team überlassen. Die Scrum-Mitgestalter Jeff Sutherland und Ken Schwaber empfehlen Scrum-Teams einen sofortigen Start und das Erstellen einer Liste von Hindernissen und eines Prozessverbesserungsplans. Wenn Entwicklungsverfahren als Hindernisse identifiziert werden, sollten Teams als Verbesserungsmöglichkeit über XP-Verfahren nachdenken. Die besten Teams führen ein durch XP-Verfahren ergänztes Scrum aus. Scrum ermöglicht XP die Skalierung, und XP ermöglicht Scrum eine effiziente Funktionsfähigkeit.

In der folgenden Tabelle wird die Austauschmöglichkeit von Schlüsselbegriffen in Scrum und XP veranschaulicht.

Scrum	XP
Produktbesitzer	Kunde
Scrummaster	XP-Trainer
Team	Team
Sprint	Iteration
Sprint-Planungsbesprechung	Planspiel

Siehe auch

Konzepte

Planen und Nachverfolgen von Projekten

Weitere Ressourcen

MSF for Agile Software Development, Version 5.0