Nach mehreren Jahren (angeblicher) agiler Softwareentwicklung ist es interessant zu sehen, wie der Begriff “agile” gerne zum Motto eines chaotischen und unkoordinierbaren Gewusels werden kann.
Aber bevor ich in einen Rausch von Anschuldigungen, Verfluchungen und verzweifelten Rundumschlägen verfalle – eine kurze Vorstellung von dem was agile Softwareentwicklung leisten soll.
Wikipedia beschreibt die Zielsetzung von agiler Softwareentwicklung wie folgt:
Das Ziel Agiler Softwareentwicklung ist es, den Softwareentwicklungsprozess flexibler und schlanker zu machen, als das bei den klassischen Vorgehensmodellen der Fall ist. Man möchte sich mehr auf die zu erreichenden Ziele fokussieren und auf technische und soziale Probleme bei der Softwareentwicklung eingehen. Die Agile Softwareentwicklung ist eine Gegenbewegung zu den oft als schwergewichtig und bürokratisch angesehenen traditionellen Softwareentwicklungsprozessen wie dem Rational Unified Process oder dem V-Modell.
Häufig wird sich vor allem auf die ersten beiden Sätze konzentriert, die selbstverständlich eine große Bedeutung haben. Aber aus meiner Sicht hat aber der letzte Satz eine interessante Nebenbedeutung.
Im Folgenden werde ich mich auf die Vorgehensweise nach Scrum konzentrieren, da sie meist als Vorzeige-Prozess verwendet wird und sich viele Firmen dies auf die “Fahnen” schreiben.
Agile Softwarentwicklung wird als Gegenbewegung zu bürokratischen Prozessen angesehen. Was hier nur häufig scheinbar hinzugefügt wird, ist das Abschaffen von (notwendigen) formalen Regeln.
- So ignoriert man des öfteren, dass ein Sprint in sich unveränderbar ist – das dies auch legitim sein kann, werde ich gleich erläutern.
- Daily Scrums z.B. werden teilweise wie ein Kaffeeklatsch behandelt oder – noch schlimmer – werden als Plattform für das Management verwendet um dem Team neue Priorisierungen mitzuteilen.
- Beliebt sind auch Sprintplanungen, in denen dem Team vorgeschrieben wird, wieviel Zeit es für welche Aufgaben haben darf.
- Teammitglieder erscheinen gar nicht oder zu spät zu Meetings.
- Daily Scrums beinhalten entweder zu viele oder zu wenige “Pigs” bzw. “Chickens” verhalten sich wie “Pigs”.
- Sprintziele bzw. Commitments werden nicht ernst genommen.
- …
Eine kleine Übersicht über Anhaltspunkte, dass es mit dem agilen Prozess nicht ganz so gut bestellt ist, gibt folgende Seite über Scrum-Smells.
Die Konsequenzen, wenn der “Gestank” (dt. für Smell) nicht berücksichtigt wird, sind einerseits lange Entwicklungszeiten und häufige Wartungsaktionen, da die Anforderungen nicht klar waren/sind oder Aufgaben permanent verschoben werden und andererseits Versuche Probleme mit klassisch bürokratischen Mitteln zu kompensieren, wie minutiös ausgearbeiteten Konzepten. Dadurch verlangsamt sich zusehends und dramatisch die Entwicklungszeit und damit die Reaktionszeit auf Kundenwünsche und Bugs. Ebenso wird die Flexibilität des Teams auf die reine Programmierung reduziert, die dann ggf. noch durch (von sich selbst übermäßig überzeugte) Code-Reviewer ad absurdum geführt wird.
Da dies kein komplettes Buch über die Vor- und Nachteile von Scrum respektive agiler Softwareentwicklung werden soll, möchte ich nur Folgendes festhalten:
Agile Softwareentwicklung besitzt genausoviel oder teils sogar mehr Formalismus als klassische Softwareentwicklung. Allerdings wird versucht den bürokratischen Aufwand zu reduzieren. Agil heisst hier vor allem, dass das Team wesentlich flexibler agieren und reagieren kann, als es in klassischen Prozessen ist und nicht, dass die Aufgabenstellung beliebig agil geändert werden kann. Dieser erhöhte Formalismus bedarf aber ebenso einer durchgängigen Disziplin aller Beteiligten. Ist diese Disziplin gegeben lassen sich auch innerhalb einer Iteration die Anforderungen bis zu einem bestimmten Grad ändern. Falls nicht, ist davon – wie es im Allgemeinen in der Literatur vorgegeben ist – abzuraten.
