Pseudo-Agile Softwareentwicklung: Zeit für ein Meta-Manifest (Teil 1)

Quelle: Wikipedia.org

Heute sagt eine Mehrzahl von Firmen von sich, dass sie sogenannt "agil" Software entwickeln. In Bezug auf den kompletten Software-Entwicklungsprozess handelt es sich aber in aller Regel um eine Pseudo-Agilität. So geben den bei Umfragen auch immer mehr Firmen an, dass sie nicht so ganz genau wissen, nach welcher Methode sie entwickeln.

Diese Pseudo-Agilität äussert sich etwa darin, dass meist nur die Software-Entwickler selber agile arbeiten. Der Auftraggeber und die Fachvertreter in der Regel nicht oder nur ungenügend. Oder es gibt trotz agilem Vorgehen einen Endtermin mit klaren Abnahmekriterien.

Diese Pseudo-Agilität hat zwei Ursachen:
1] Meist kennen nur die Software-Entwickler selber das agile Vorgehen und können sich mit diesem auch identifizieren. Andere Stakeholder schätzen zwar die Flexibilität, wollen die Nachteile aber trotzdem nicht akzeptieren.

2] Das agile Manifest hat einzelne Prinzipien, die sich so in der Praxis meist nicht 1:1 so umsetzen lassen.

Die Prinzipien vom agilen Manifest:

1] Zufriedenstellung des Kunden durch frühe und kontinuierliche Auslieferung von wertvoller Software:
Sicher ein wichtiger Aspekt. Wobei es hier nicht nur einfach um die Zufriedenstellung geht. Es ist vor allem auch eine vertrauensbildende Massnahme.

2] Agile Prozesse nutzen Veränderungen (auch spät in der Entwicklung) zum Wettbewerbsvorteil des Kunden:
Das wäre zwar schön, ist aber leider in der Realität ein Stück weit ein Feigenblatt des Manifests. Durch eine Änderung der Anforderung müsste allenfalls eine komplett andere Architektur der Software gewählt werden. Und alle bis dahin entwickelten Iterationen müssten gegeben falls nochmals entwickelt werden. Diese Zeit hat in der Praxis aber niemand - resp. will sich niemand nehmen und auch nicht bezahlen. Die Änderungen werden also in der Praxis mit den bereits vorhandenen Mitteln umgesetzt. Ob dies mittel- bis langfristig ein Wettbewerbsvorteil bringt, bleibt offen.

3] Lieferung von funktionierender Software in regelmässigen, kurzen Zeitspannen:
Ein guter Punkt, der zwei Aspekte abdeckt: Er dient auch der Stärkung des Vertrauens in die Entwicklung wie der Punkt 1. Weiter dient er auch der Motivation der Entwickler. Lauffähige Software motiviert mehr, auch wenn sie nur klein ist, als eine Menge Code wo man noch nicht weiss, ob er läuft.

4] Nahezu tägliche Zusammenarbeit von Fachexperten und Entwicklern während des Projektes:
Ein guter Punkt - der leider in der Praxis längst nicht bei allen Projekten möglich ist. Gerade die echten wichtigen Fachexperten sind häufig im Tagesgeschäft. Dort werden sie gebraucht weil sie wichtig sind und deshalb sind sie auch Fachexperten. Ein Fachexperte der immer Zeit hat, ist wahrscheinlich kein echter Experte.

5] Bereitstellung des Umfeldes und der Unterstützung, welche von motivierten Individuen für die Aufgabenerfüllung benötigt werden:
Wichtiger Punkt. Gehört aber eher zu den allgemeinen Führungsaufgaben. Dies betrifft längst nicht nur die Software-Entwicklung oder ein agiles Vorgehen.

6] Informationsübertragung nach Möglichkeit im Gespräch von Angesicht zu Angesicht:
Persönliche Kommunikation ist sehr wichtig und für grössere Projekte über eine längere Zeit nicht komplett ersetzbar. Dennoch bieten die neuen Technologien von Video-Telefonie/-Konferenzen und die Teilung von Inhalten hier effiziente Möglichkeiten.

7] Als wichtigstes Fortschrittsmass gilt die Funktionsfähigkeit der Software:
Das ist ein kleiner Trugschluss im agilen Manifest. Gerade zusammen mit Punkt 2] lässt sich der Fortschritt kaum messen. In der aktuellen Iteration hat man viele lauffähige Funktionen - und im nächsten Schritt muss man sie auf Grund von Veränderungen umschreiben und ergänzen. Damit lässt sich kaum ein Fortschritt messen. Es zeigt sich, dass gar nicht alle Prinzipien gleichermassen angewendet werden können.

8] Einhalten eines gleichmässigen Arbeitstempos von Auftraggebern, Entwicklern und Benutzern für eine nachhaltige Entwicklung:
Das wünscht sich jeder Fabrik-Manager. Ist aber eine Illusion. Gerade Softwareware-Entwickler in der kreativen Phase haben ein unregelmässiges Arbeitstempo. Auch sind die Auftraggeber und Benutzer meist nicht zu 100 % für ein Projekt zur Verfügung. Entsprechend können auch sie in aller Regel kein gleichmässiges Arbeitstempo erbringen.

9] Ständiges Augenmerk auf technische Exzellenz und gutes Design:
Ein sehr guter Vorsatz. Wie in Punkt 2] schon erwähnt würde dies aber dazu führen, dass man häufiger wieder ganz von vorne beginnen müsste. Das macht niemand. Die technische Exzellenz und das gute Design werden daher in der Praxis bei notwendigen Änderungen schön gefärbt. Man versucht so viel wie möglich mit der bereits entwickelten Lösung/Architektur zu realisieren.

10] Einfachheit ist essenziell:
Das ist ein weites Prinzip mit viel Spielraum für Interpretation. So in der Form in der Praxis wenig hilfreich.

11] Selbstorganisation der Teams bei Planung und Umsetzung:
Wäre ein schöner Ansatz, der in der Praxis aber selten funktioniert. Häufig alleine aus dem Grund, dass nicht alle Stakeholder nur dem Team angehören. Über deren Ressourcen lässt sich dann nicht einfach so verfügen, auch nicht über die Fachverantwortlichen als Beispiel. Das Prinzip reduziert sich dabei in der Praxis meist auf die Software-Entwickler selber. Auch kann in der Realität häufig nicht selbstbestimmt über Test-Ressourcen etc. verfügt werden. Diese müssen ordentlich geplant und bestellt werden.

12] Selbstreflexion der Teams über das eigene Verhalten zur Anpassung im Hinblick auf Effizienzsteigerung:
Guter Ansatz, der natürlich nicht nur für Software-Entwicklung gelten sollte. Als Team ist es in der Praxis meist deshalb nicht ganz einfach umsetzbar, weil die Teams als ganzes von Projekt zu Projekt nicht so stabil sind. Die Teams werden je nach Anforderungen und Themen jeweils (teilweise) neu zusammen gesetzt. Auch hier gilt. dass sich das Prinzip in der Praxis meist nur auf die Software-Entwickler selber bezieht.

Zwischenfazit:

Das agile Manifest kommt von Software-Entwickler und betrifft in erster Linie auch nur Software-Entwickler. Es ist aber auch für diese kaum möglich, allen Prinzipien gleichermassen gerecht zu werden. Es gibt potentielle inhärente Zielkonflikte. An einer Software-Entwicklung sind jedoch verschiedene Parteien beteiligt. Das Vorhaben der Software-Entwicklung als Ganzes mit allen Beteiligten, lässt sich daher kaum rein agil wie proklamiert umsetzen.

Braucht es ein Meta-Manifest?

Die Welt da draussen ist komplexer als einfache Methoden. Wo Menschen sind, gibt es Meinungen, Standpunkte und persönliche Interessen. Häufig wird mit einem Software-Projekt nicht nur das Ziel der Software selber verfolgt. Und das ist auch richtig so. Software soll Mittel zum Zweck sein. Aber welcher Zweck soll erfüllt werden? Nicht selten spielen Business-Strategien und Taktiken eine wichtige Rolle. All diese Themen sind im agilen Manifest überhaupt nicht adressiert.

Es stellt sich daher die Frage: Brauchen wir ein Meta-Manifest? Ein Manifest, wo andere Stakeholder und Betroffene als Software-Entwickler auch angesprochen werden? Ein Manifest, dass den ganzen Prozess der Software-Entwicklung abdeckt? Ein Manifest das Hinweise gibt, wie mit Zielkonflikten innerhalb der Prinzipien umzugehen ist?