Agil vs Klassisch: Die Daumenregel

Agil vs Klassisch? Barry Boehm von der University of Southern California und Richard Turner von der George Washington University haben sich dieser Frage angenommen und versuchen mit einer Daumenregel mehr Sachlichkeit in die Diskussion zu bringen. In diesem FRITZ Tipp bringe ich die wichtigsten Aussagen von Boehm und Turner auf den Punkt und gebe dir eine Daumenregel mit auf den Weg.

Wann eignet sich ein agiles Vorgehensmodell?

In ihrem Artikel Using Risk to Balance Agile and Plan-Driven Methods schlagen sie ein Modell vor, um zu testen, wie sehr sich ein Unternehmen für eine agile Vorgehensweise eignet. Vielen Dank an Hans-Peter Korn für den Tipp! Boehm und Turner berücksichtigen fünf Dimensionen:

Personal

Boehm und Turner verwenden zur Einschätzung der Entwicklerfähigkeiten die Skala nach Cockburn. Sehr vereinfacht gesagt: Level 1 = Junior; Level 3 = Senior. Für eine agile Vorgehensweise sollten min. 30 Prozent der Entwickler auf Level 2 oder besser noch Level 3 sein. Agil vs klassisch? Agile Vorgehensweisen brauchen hoch qualifizierte Mitarbeiter!

Dynamik

 Agile Entwicklung macht erst Sinn, wenn sich min. 30% der definierten Anforderungen pro Monat ändern.  Wenn der Wert kleiner als 30% ist, macht eine klassische Methode mehr Sinn. Wenn also die Anforderungen bekannt sind und die Änderungsrate recht gering ist, wäre SCRUM mehr Overhead als Silver Bullet.

Eine aktuelle Studie zeigt ergänzend, ein höherer Agilitätsgrad führt zu einem höheren Projekterfolg. Die Studie bezieht sich aber ausschließlich auf Softwareentwicklungsprojekte, bei denen sich die Anforderungen bekannterweise häufiger ändern als in anderen Bereichen.

Kultur

Die Dimension Kultur erscheint mir als Einzige sehr schwammig. Wie gut kann dein Unternehmen bzw. deine Mitarbeiter mit Chaos umgehen? Ich kann mir darunter wenig Konkretes vorstellen, vermute jedoch damit die Erfahrung der Mitarbeiter mit wechselnden Bedingungen.

Eine aktuelle Studie zeigt, die Wirkung des Agilitätsgrades auf den Projekterfolg wird von der Unternehmenskultur moderiert. Dabei ist deutlich erkennbar, dass bei einem höheren Agilitätsgrad eines Projektes, welches in „Clan- bzw. Adhocracy Culture“ durchgeführt wurde, auch der Projekterfolg höher ist.

Anders gesagt, agile Softwareentwicklung ist besonders in einer dazu geeigneten Unternehmenskultur erfolgreich. Eine Unternehmenskultur, die besonders stark auf Kollaboration und Kreativität setzt und Konkurrenz und Kontrolle vernachlässigt.

Teamgröße

Je größer das Team desto eher sollte eine klassische Vorgehensweiße gewählt werden. Die agile Welt hat hierfür recht wenige Ideen, um Teams zu skalieren (LeSS, SAFe und Nexus). Stabile Umsetzungen von SCRUM of SCRUM kenne ich bisher nicht. Darüber hinaus fehlen althergebrachte Koordinationsmechanismen wie Programm- und Portfoliomanagement. Agil vs klassisch? Je größer das Projekt desto eher klassisches Projektmanagement.

Kritikalität

Wie kritisch ist das zu entwickelnde System? Handelt es sich um eine Anwendung für den Zahlungsverkehr in Banken oder ist es ein Webshop? Gemäß Böhm ist bei sehr kritischen Systemen (= lebensgefährliches Risiko) ein klassisches Vorgehen, bei Risiken nur bezüglich des Komforts ein agiles Vorgehen angezeigt.

Fazit – Agil vs Klassisch?

Barry Boehm und Richard Turner haben mir für die Entscheidung Agil vs Klassisch die perfekte Daumenregel beschert: Agile Entwicklung macht erst Sinn, wenn sich min. 30% der definierten Anforderungen pro Monat ändern. Beim CYNEFIN Framework sprechen wir in diesem Fall von komplexen Problemen. In der Praxis ist es noch viel einfacher. Wenn sich bei der Anwendung agiler Methoden alle langweilen, weil sich nichts verändert, war deine Wahl falsch.

Dr. Patrick Fritz