Cirquent Blog

Erfüllen die Methoden der agilen Software-Entwicklung die hohen Erwartungen? Christian Schreyer, Certified Scrum Master und Management Consultant beim IT-Beratungsunternehmen Cirquent, stellt sich Fragen zur Praxis agiler Methoden.

Christian Schreyer, Cirquent

Die jüngste BQI-Studie „Agile Software Development – Status Report 2010“ beschreibt eine Vielzahl von Methoden. Wie sehen Sie die Entwicklung in diesem Thema?

Schreyer: Ja, die Studie bietet einen guten Überblick über die Methodenvielfalt agiler Software-Entwicklung. Auch deshalb wundere ich mich, dass immer noch viele Unternehmen und Projektverantwortliche agile Methoden als „neu“ einstufen. Da schwingt oftmals ein „und vielleicht unerprobt“ mit. Dabei reichen die Ansätze zu agilem Vorgehen nunmehr 30 Jahre zurück und sind bereits – nicht nur in der Software-Entwicklung – mit großem Erfolg eingesetzt worden. Die wichtigsten Prinzipien wurden im Agilen Manifest vor inzwischen auch schon fast 10 Jahren formuliert.

Stoßen Sie in der Praxis auf Vorbehalte gegen diese Methoden?

Schreyer: Ja, durchaus. Agile Software-Entwicklung ist auch eine Frage der Unternehmenskultur. Nach meiner Erfahrung finden sich Befürworter vorrangig in Unternehmen, die sich in sehr dynamischen Marktumfeldern befinden und folglich flexibel reagieren müssen. Das verlangt Entwicklungsmethoden, bei denen auf neue Anforderungen schnell reagiert werden kann. Daneben gibt es Unternehmen, die in ruhigeren Märkten agieren – diese Märkte werden aber mehr und mehr zu Ausnahmen. Auch dies trägt zum Erfolg der agilen Methoden bei.

Sie selbst und viele Ihrer Kollegen bei Cirquent arbeiten nach Scrum. Warum?

Schreyer: Scrum ist eher ein Framework und damit flexibler als eine dedizierte Methode. So organisiert sich das Team im Wesentlichen selbst und trägt die Verantwortung für die zugesicherten Ergebnisse. Ein weiteres Plus: Innerhalb der Iterationen eines Scrum-Projektes können wiederum andere Methoden zum Einsatz kommen, beispielsweise Extreme Programming. Dies macht den Ansatz sehr flexibel. Wir haben bei Cirquent damit über viele Jahre gute Erfahrungen gemacht, bilden an unserer Academy selbst Certified Scrum Master und Certified Product Owner aus.

Welche Bestandteile machen den Scrum-Ansatz so erfolgreich?

Schreyer: Da spielt vieles ineinander. Ich habe Projekte gemacht, in denen letztlich nur 40 Prozent der ursprünglich angedachten Funktionalitäten implementiert wurden – und die dennoch Erfolgsprojekte waren, weil dafür viel wichtigere Funktionen erst im Verlauf des Projektes hinzukamen. Der Grund: Bei Scrum erhalten die Anwender über den Product Owner Mitverantwortung, können in jeder Iteration neue Funktionalitäten aufnehmen und Prioritäten verschieben. Das macht diesen iterativen Ansatz so flexibel. Gleichzeitig trimmt Scrum auf Effizienz. Am Ende jeder Iteration steht eine lauffähige Software mit den aktuell priorisierten Funktionen. Ein weiterer Punkt ist das Time Boxing, also die klaren Zeitlimits für Meetings und Iterationen. Das ist für Anfänger im Team – und damit auch für viele Kunden – oft schwierig, aber es macht nicht zuletzt auch den Entwicklungsteams wesentlich mehr Spaß, unter diesen Bedingungen zu arbeiten.

Wie erleben die späteren Anwender den Ansatz?

Schreyer: Das Motivierende ist, dass man wirklich für die Anwender arbeitet. Sehr schnell sehen die Anwender, wie die Funktionalität in der Benutzeroberfläche abgebildet ist – und sehen damit, dass viele der vorher abstrakt formulierten Anforderungen sich in der Praxis anders viel besser realisieren lassen. Statt Anwender wie in den klassischen Methoden nach vielen Monaten mit etwas „Fertigem“ zu überraschen und dann möglicherweise Enttäuschung zu erfahren, bin ich bei Scrum und anderen agilen Methoden ganz nah am Anwender, hole früh das Feedback ab und kann jederzeit auf Änderungswünsche reagieren. Scrum wirkt sich direkt auf die Qualität der Lösung aus.

Woran können denn Ihrer Meinung nach agile Softwareprojekte scheitern? Wie kann man einem Scheitern vorbeugen?

Schreyer: Die größte Falle: Methoden wie Scrum können die Probleme aufzeigen – aber die Methode kann Probleme nicht „automatisch“ lösen. Ein einfaches Beispiel: Werden bei einer kleinen Mannschaft neben dem Scrum-Projekt viele andere Projekte parallel gefahren, so werden die täglichen Scrum-Abstimmungsmeetings zwangsläufig durch mangelnde Beteiligung geprägt sein. Man sieht also sehr schnell, dass das Staffing unzureichend ist. Damit sich diese Situation aber verbessert, braucht es nicht noch mehr Einladungen zum Meeting, sondern ein durchsetzungsstarkes Management, das für eine bessere Ausstattung sorgt. Meine Erfahrung: Stimmt das Commitment und ist die Methodenkompetenz da, sind die Erfolgsaussichten – Qualität, Zeit und Budget – von Scrum-Projekten höher als die mit klassischen Waterfall-Methoden.

Quelle: Computerwoche Beilage BQI, erschienen am 18. Oktober 2010