Schwerpunkt
W
ie versuchen sich SoftwareEntwickler herauszureden, wenn kein Liefertermin in Sicht ist und ein Projekt mangels Planung vollends im Chaos versunken ist? „Wir arbeiten agil, mit minimalen Overhead!“ Diese Aussage ist natürlich eine Provokation für alle Fans agiler Methoden. Schließlich entwickeln heutzutage viele Unternehmen erfolgreich agil Software. Gleichzeitig kennt jeder Entwickler oder Tester auch agile Software-Projekte, die gescheitert sind. Scheitern kann bedeuten, dass das Projektteam nicht zum festgelegten Termin und nicht im Kostenrahmen geliefert hat. Scheitern kann genauso bedeuten, dass das Management ein Projekt nicht agil fortführt, sondern einen Wechsel zurück zum Wasserfalloder V-Modell verlangt. Jenseits aller Emotionen, die agile Methoden teils heute noch auslösen, diskutiert dieser Artikel drei Ursachen für das Scheitern agiler Projekte, die auf Diskrepanzen zwischen der Anwendung agiler Praktiken und den Erwartungshaltungen bzw. Anforderungen an Software-Projekte im Unternehmenskontext zurückzuführen sind.
UNPASSENDE ENTWICKLUNGSMETHODE Im Rahmen des State of Agile Report von VersionOne [VO16] wurden Befragungsteilnehmer nach Gründen für das Scheitern von agilen Projekten gefragt. Bei den Antworten fällt auf, dass viele Gründe einen Bezug zum Unternehmenskontext haben. 46 Prozent der Befragten gaben als häufigsten Grund einen Widerspruch zwischen Unternehmenskultur und agilen Prinzipien an. Zwei weitere Antworten mit Bezug zum organisatorischen Kontext belegen die Plätze 3 und 4 („fehlende Unterstützung des Managements für die agile Arbeitsweise“ und „mangelnde Unterstützung für kulturellen Wandel im Unternehmen“). Weiter sprechen 36 Prozent der Teilnehmer von externem Druck, dem Wasserfallmodell zu folgen (Platz 6).
Ausgabe 44 | September 2017
Sind solche Konflikte zwischen einem Projekt und seinem Unternehmenskontext höhere Gewalt, die wie ein Tornado über ein agiles Projekt hinwegfegt und es scheitern lässt? Nein. Die Aussage, ein agiles Projekt sei an der Firmenkultur gescheitert, ist ein Euphemismus für die späte Erkenntnis der Entwickler, eine ungeeignete Entwicklungsmethodik gewählt zu haben. Mathematiker erschaffen sich mittels Definitionen eine Welt, in der sie Sätze postulieren und beweisen. IT-Projekte hingegen finden in realen Unternehmen in einem vorgegebenen organisatorischen Kontext statt. Wer eine
3
16
für zwei Jahre die Anforderungen und erstellt Spezifikationen und Design-Dokumente. Danach wird zwei Jahre entwickelt, bevor der Kunde die Lösung sieht. Inzwischen haben sich aber die Business-Szenarien so geändert, dass die Software bereits wieder veraltet ist und nicht wie geplant genutzt werden kann. Sie muss erst noch überarbeitet werden, was das Projekt um weitere zwei, drei Jahre verlängert. Dieses Problem möchte das Agile Manifest – zu Recht – überwinden. Doch findet man heute in Projekten oft das andere Extrem: eine starke Kurzfristigkeit. Einige agile Software-Projekte
GRÜNDE
WARUM AGILE PROJEKTE AN DER UNTERNEHMENSORGANISATION SCHEITERN.
unpassende Entwicklungsmethodik wählt, ist für das Scheitern des Projekts selbst verantwortlich, egal wie hipp eine Software-Entwicklungsmethode gerade ist. Eine ungeeignete Methode ist demnach die erste mögliche Ursache, warum agile Projekte am realen Unternehmenskontext scheitern können.
AGILITÄT, PLANUNG UND BUSINESS CASES Das Agile Manifest [Bec01] hält das Reagieren auf Veränderung für wichtiger als das Befolgen eines Plans. Diese These hat natürlich einen Hintergrund. Beim altbekannten V-Modell gibt es oft mehrjährige Planungen. Das Projekt-Team analysiert
haben einen planerischen Horizont, der kürzer ist als die Lebenserwartung einer Stechmücke. Ihr Planungshorizont beträgt wenige Wochen. Der Vorteil dieses Vorgehens liegt vermeintlich auf der Hand: Die Entwickler können mittels der Kurzfristplanung gut abschätzen, welche Lieferobjekte bis zum Sprint-Ende fertig sind und diese gemäß der Planung ausliefern. Entspricht ein Lieferobjekt nicht ganz den Erwartungen der Anwender, können die Entwickler im nächsten Sprint Anpassungen vornehmen. Die Entwickler erhalten positives Feedback, das motiviert. Die Anwender sind zufrieden, da sie quasi jeden Wunsch erfüllt bekommen. Doch diese Harmonie und der schöne Schein trügen. Die subjektive Selbsteinschätzung der