Mythos Agilität: Ein Meta-Blog

agile myths busted titelAls Ursprungsjahr der iterativ inkrementellen Entwicklung gilt das Jahr 1957. In [1] wird Gerald M. Weinberg, damals Mitarbeiter im „Project Mercury“ [2], mit den Worten zitiert: „We were doing incremental development as early as 1957, in Los Angeles, under the direction of Bernie Dimsdale [at IBM’s Service Bureau Corporation].“ Im Jahre 2012 verwendeten bereits 84% aller Unternehmen agile Entwicklungs-Methoden [3]. So verwundert es, dass trotzt dieser langen Historie immer noch Missverständnisse und Vorbehalte bezüglicher agiler Methoden, insbesondere Scrum, anzutreffen sind. Angeführt von: Agil sein bedeutet keine Dokumentation. Anhand von Publikationen zum Thema wollen wir diese untersuchen und aus der Welt schaffen!

Geschichte

Wenn man will, lassen sich iterativ inkrementelle Methoden sogar bis in die 1930er Jahre zurückverfolgen. Walter Shewhart, damals Bell Labs, schlug eine Reihe von kurzen Plan-Do-Study-Act Zyklen zur Qualitätsverbesserung vor. PDSA (heute bekannt unter PDCA oder Deming-Kreis) wurde in den darauffolgenden Jahren von W. Edwards Deming energisch propagiert, jedoch erst 1982 publiziert [1].

Aktuelle agile Methoden entstanden in den 1990er Jahren [4][5]. Darunter (Rational) Unified Process (1994), Scrum (1995) und Extreme Programming – besser bekannt als XP (1996). Allgemeine Popularität erlangte die agile Softwareentwicklung mit der Veröffentlichung von Kent Beck, „Extreme Programming“ im Jahre 1999 [6]. Die Entwicklung kulminierte im Agilen Manifest von 2001 [7].

Quellen und Analysen

agile myths tag cloud

Alle Agilen Mythen als Tag Cloud von wordle.net

Eine Suche nach agilen Mythen liefert aktuell über 400.000 Ergebnisse [8]. Uneinigkeit herrscht über die Anzahl der Mythen, diese reicht von 4 bis 12 mit einem Durchschnitt von 7,09 – Spaß beiseite. Wir haben uns bei der folgenden Auswertung auf die ersten zwei Treffer-Seiten beschränkt. Eine vollständige Liste der Links finden Sie am Ende des Artikels. Aber auch „offline“ wird das Thema diskutiert, z.B. in [9] „Was ist dran an Agilen Mythen?“ Insgesamt haben wir 78 Mythen ausgewertet, von denen sich die häufigsten in 7 (wie passend) Kategorien einordnen lassen.

Agil sein löst alle Probleme.

Oder: „Agile is a silver bullet.“ Als grundlegende Missverständnisse gelten: agil sein wäre schneller, einfacher, neu und nur eine vorübergehende Erscheinung. Wie gezeigt sind agile Methoden weder neu noch wegzudenken – Mythos zerstört. Allem voran steht aber die Aussage, dass Agilität alle Probleme der Softwareentwicklung löst. Dem ist mitnichten so.

Agile Methoden im Allgemeinen und Scrum im Speziellen sind auch nur Prozesse [10]; und nur einer der vielen Ursachen warum Projekte fehlschlagen liegt darin begründet, dass diese fehlerhaft angewendet wurden. Allerdings bieten agile gegenüber nicht-iterativen Methoden viele Vorteile, wie enge Kundenbeziehung, schnelle Reaktion auf Änderungen der Anforderungen und frühzeitige Identifikation von Risiken, sodass schlicht und einfach der falsche Eindruck entsteht, Agilität könne alle Probleme lösen. Im Zweifel scheitert man aber auch schneller.

Mythos zerstört.

Agil sein ist nur für einfache Projekte.

Oder: „Agile only works for trivial projects.“ Häufig auch in folgenden Variationen: agil sein wäre nicht geeignet für Greenfield-, Brownfield-Projekte, Projekte mit feststehendem Abnahmetermin und Projekten in speziellen Branchen. Es finden sich also genug Gründe, warum agile Methoden gerade für „mein“ Projekt nicht geeignet sind.

Kleine Teams bedeuten kleine Projekte, so das Missverständnis. Durch das Prinzip des Teilens und Herrschens lassen sich auch größere Projekte durch mehrere kleine Teams bewältigen. Durch Verteilen der Aufgaben nach Funktionen oder Anwendungsschichten vermeidet man Redundanz; bei der Web-Entwicklung wird dies z.B. durch Microservices erreicht [11]. Ein Scrum-of-Scrum koordiniert die Aktivitäten, speziell die Integration zu einem fertigen Produkt.

Mythos zerstört.

Agil sein bedeutet keine Dokumentation.

Oder: „Agile is anti-documentation.“ Zwei Ursachen für diesen meistgenannten Mythos werden angegeben. Im Agilen Manifest heißt es: „[Wir schätzen] funktionierende Software mehr als umfassende Dokumentation [7].“ Zudem wird Kent Beck folgender Satz zugesprochen: „Documentation may be only necessary before I die and can’t explain it personally [12].“ Dabei handelt es sich aber keinesfalls um ein Dokumentationsverbot, sondern nur um die Mahnung Dokumentation nicht um der Dokumentation willen zu erstellen.

Umfangreiche Design-Dokumente zu Beginn eines agilen Projektes sind aufgrund dessen iterativer Natur schnell veraltet. Agile Projekte bauen auf intensive Kommunikation, hier sind Dokumente als Träger der Information eher ungeeignet, denn ein Bild – sprich: User-Story – sagt mehr als tausend Worte. Sind Dokumente allerdings vom Kunden explizit gewünscht, dann werden diese selbstverständlich wie jeder andere Liefergegenstand geplant und erstellt.

Mythos zerstört.

Agil sein bedeutet keine Planung.

Oder: „Agile is anti-planning.“ Dieser Mythos lässt sich leicht wiederlegen, denken Sie nur an die tagesaktuelle Planung im Daily Scrum und das Sprint Planning für den nächsten Sprint Zyklus. Im agilen Umfeld, gibt es jedoch keine statische Planung zu Beginn des Projektes und auch keinen allein Verantwortlichen für diese. Iterative Planung gilt als Herausforderung für das Team, welche gemeinsam über die gesamte Projektlaufzeit erfolgt. Was zur Folge haben kann, dass sogar mehr Aufwand in die Planung fließt, als in klassischen Projekten.

Allerdings kann auch hier nicht grundsätzlich auf langfristige Planung verzichtet werden. Je nach Kunde, Sponsor oder anderen Stakeholdern sind vertragliche Verpflichtungen, wie z.B. Leistungsumfang und Abnahmetermin bindend. Eine Lösung kann ein übergeordnetes Projektmanagement nach PMI oder PRINCE2 sein, die beide agile Ausprägungen besitzen [13][14].

Mythos zerstört.

Agil sein bedeutet kein Design.

Oder: „Agile is anti-architecture.“ Agil sein bedeutet nicht gegen Architektur zu sein, sondern nur gegen eine detaillierte, zu Beginn festgeschriebene Architektur. Man lebt Design-Prinzipien wie KISS – „keep it simple and stupid“ – oder YAGNI – „you aren’t gonna need it [15][16].“ Entgegen dem Versuch Programme durch zusätzlichen generischen Code auf mögliche zukünftige Anforderungen vorzubereiten – welche dann so doch nicht eintreten – implementiert man nur die Funktionalität die aktuell benötigt wird.

Somit ist sichergestellt, dass zeitnah mit der Implementierung begonnen werden kann. Das Design erfolgt iterativ und inhärent während der Entwicklung und der Planungsrunden. Design ist also omnipräsent! Architekturänderungen erfolgen meist nicht explizit, sondern implizit durch Refactoring. Man spricht hier von „emergent design“ [17].

Mythos zerstört.

Agil sein macht Skalierung unmöglich.

Oder: „Agile does not scale.“ Wir sehen dies als eine Variante des Einfache-Projekte-Mythos. Skalierung (nach oben) ist schwierig, egal unter welcher Methodologie. Wenn möglich, sollte zuerst versucht werden die Projektgröße zu reduzieren; ist dies nicht möglich, dann gilt es die Teilaufgaben so zu strukturieren, dass sich die empfohlenen Teamgrößen (ca. 3-9 bei Scrum) ergeben. Agile Verfahrensweisen die gut skalieren sind Entwickeln, Testen, Refactoring, Pair Programming. Mit zunehmender Teamgröße werden Sprint Planning und Daily Scrum dagegen ineffektiv. Außerdem steigt die Anzahl der Kommunikationskanäle mit negativen Auswirkungen auf die Kommunikation, dem Herzstück der Agilität.

Ein nennenswerter Lösungsansatz ist die Einführung separater Integrations-Teams. Weitere werden in [18] angedeutet. Aus den Mitgliedern eines initialen Design-Teams erzeugt man die späteren Entwicklungs-Teams. Verschiedene Teams werden lose über Synchronisationsmechanismen und Meilensteine gekoppelt. Bereitstellung firmeneigener dedizierter Teams, die ausschließlich die Aufgabe haben agile Methoden zu lehren. Durchführung von Jobrotation in dem Sinne, dass die einzelnen Mitarbeiter phasenweise die Teams wechseln und so verschiedene Module bearbeiten.

Mythos plausibel.

Agil sein bedeutet undiszipliniert sein.

Oder: „Agile is undisciplined.“ Meist dient die Proklamation agiler Vorgehensmodelle nur als Vorwand für unkoordinierte Softwareentwicklung. Zudem ist es bequem, nur die „einfachen“ agilen Praktiken, wie das Stand-Up zu leben, die „schweren“ Sachen, wie das Entwickeln jedoch zu unterlassen. Hier ist das Management gefragt. Es ist nicht mehr die Kommandozentrale, sondern gibt Visionen, Ziele und Bedingungen vor, in dessen Grenzen die Teams selbstorganisiert agieren können.

Zudem fördern die agilen Prinzipien die Disziplin im Team. Warum? Es besteht der Zwang zum Testen, zum Einholen von Rückmeldungen, zur regelmäßigen Auslieferung von funktionsfähiger Software, zu häufigen Planänderungen und zur Kommunikation – insbesondere schlechter Nachrichten. Agile Vorgehensmodelle und Cowboy-Coding haben nichts gemein [19]!

Mythos zerstört.

Nachtrag

Bonus-Mythos: Agile Teams müssen am selben Ort arbeiten, oder: „Agile does not work for distributed teams.“ Wahrscheinlich abgeleitet von „Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteams zu übermitteln, ist im Gespräch von Angesicht zu Angesicht [7].“ Dass dies nicht zutreffen muss, zeigt unser erfolgreiches agile@brightONE Konzept [20][21]. Mythos zerstört.

Welche Vorurteile haben Sie gegenüber agiler Software-Entwicklung? Oder: Welchen Vorurteilen begegnen Sie als Verfechter agiler Methoden? Welche Argumente werden Ihnen von den Befürwortern bzw. Skeptikern entgegengebracht?

Alle Mythen im Überblick:

Nie wieder einen Blogartikel verpassen >>> Zum Blog-Newsletter anmelden

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

4 × 1 =