Zehn Jahre agile SW-Entwicklung in der Schweiz

Zufälligerweise feiert nicht nur das Label swiss made software dieses Jahr sein 10-jähriges Jubiläum, sondern auch die SwissQ Trends und Benchmarks in Software Development-Studie. Seit Anbeginn zeichne ich massgeblich für deren Inhalt verantwortlich. Daher nehme ich das Jubiläum als Anlass, eine kleine Geschichte über zehn Jahre Agilität in der Schweiz zu erzählen, die gleichermassen persönlich gefärbt wie zahlenbasiert ist. Wobei der Begriff agile Softwareentwicklung bereits ein paar Jahre vorher (2001), beim Niederschreiben des agilen Manifests geprägt wurde.

Ungefähr 2008 habe ich das erste Mal den Begriff agil gehört, auch wenn ich schon etliche Jahre vorher mit einem Entwicklungsteam zusammengearbeitet hatte, das eXtreme Programming (XP) praktizierte. Da mir das Thema immer öfter begegnete, buchte ich einen Scrum Master Kurs mit Ken Schwaber, der die Methode zusammen mit Jeff Sutherland begründet hatte; denn wo agil draufsteht, steckt oft Scrum drin. Seit Beginn unserer Umfrage setzen konstant über 80 Prozent der Teilnehmenden, die agile Ansätze verwenden, auf dieses Framework. Unterdessen wird der Begriff agil aber auch im Kontext von Skalierung, Beschaffung, Portfolio Management, HR und vielem mehr verwendet. Ich wage zu behaupten, dass das Thema 2018 auf dem Höhepunkt der Hype-Kurve angelangt ist und dort auch noch ein Weilchen verweilen wird. Es ist schon so angesagt, dass einige Leute, wenn sie den Begriff hören, zuerst mal die Augen verdrehen.

Cross-funktionale Teams

Eine Diskussion, die uns seit Langem begleitet, ist die der benötigten Fähigkeiten beziehungsweise der (nicht mehr gewünschten) Spezialisierung der MitarbeiterInnen in den agilen Teams. Scrum spricht lediglich vom Entwicklungsteam, in den Anfängen oft mit Entwicklerteam gleichgesetzt. Dies macht sich besonders im Testen bemerkbar, das, wie unsere Umfrage zeigt, zumindest in grösseren Firmen, meist zentral organisiert und klar getrennt von der Entwicklung war oder noch ist und teilweise auch offshore. Schon bald zeigte sich aber, dass die durchaus attraktive Vision der «T-Shaped»-Teammitglieder, die gleichermassen spezifizieren, entwickeln und testen können, an der Realität scheitern musste. Denn solche Superhelden sind einfach allzu rar. Was sich jedoch bewährt, ist, dass das Entwicklungsteam gemeinsam für das Ergebnis und dessen Qualität verantwortlich ist und somit alle dazu notwendigen Fähigkeiten haben muss. Bereits 2013 setzten deshalb über 50 Prozent der agilen Vorhaben auf Embedded Testing.

Interessant ist, dass sich dies beim Requirements Engineering wiederholt. Erst gerade reift die Erkenntnis, dass der PO (Product Owner) für das Schreiben guter User-Stories inklusive griffiger Abnahmekriterien, nebst Stakeholder, Backlog und sonstigem Management, schlichtweg zu wenig Zeit hat – und oft auch nicht den methodischen Rucksack. Ganz aktuell ist jetzt auch das Thema Betrieb – Stichwort DevOps, der nun auch ins Team integriert wird.

Agil versus Wasserfall

Die Verbreitung der agilen Methoden hat in den letzten Jahren stark zugenommen (siehe Grafik). Im 2017 übertraf die Anzahl der Vorhaben, die vorwiegend agil abgewickelt werden, erstmals den Wasserfall – und das gleich um gut 30 Prozent. Das Gleiche stelle ich auch tagtäglich in meinem Netzwerk fest. Kaum ein Gespräch, in dem das Thema nicht erwähnt wird; es eignet sich fast schon besser zum Smalltalk als das Wetter. Wobei agil ein dehnbarer Begriff ist, denn kann man ein Projekt mit vier dreiwöchigen Iterationen, die jeweils aus einer Woche Spezi kation, Entwicklung und Test bestehen, als agil bezeichnen? Die Grenzen zwischen traditionellen und agilen Vorgehen verschwimmen in den letzten Jahren immer mehr. Agile Vorgehen, insbesondere Scrum, findet man in jeder besseren Softwaremanufaktur. Diese haben sich im Alltag etabliert und sind nicht mehr wegzudenken – auch in Unternehmen, die weiterhin auf Wasserfall setzen.

Es gibt zum einen das Nebeneinander von traditionell und agil. Gartner hat dafür den Begriff bimodale IT geprägt und de niert diesen vor allem über die unterschiedliche Geschwindigkeit in der SW-Entwicklung – eine etwas einseitige Sicht, welche aber gleichzeitig eine der grössten Herausforderungen dieser Kombination hervorhebt. Durch den abweichenden Takt, im Extremfall zwei Wochen versus sechs Monate, entstehen Integrationsprobleme. Viele dieser Systeme haben aber Abhängigkeiten zueinander, die Anpassungen an den Schnittstellen und Daten bedingen und zudem zu ungewollten Wartezeiten führen.

Andererseits gibt es auch Projekte, die beide Vorgehen parallel einsetzen – Wasserfall-Projekte mit agilen Entwicklungsteams oder agile Projekte, die in ein Phasenmodell eingebettet sind. Die Kunst besteht darin, die Vorteile – nicht die Nachteile – zu kombinieren. Doch dies gestaltet sich äusserst schwierig, da die Ansätze nicht nur unterschiedliche Prozesse befolgen, sondern auch auf andere Paradigmen setzen: fixer Umfang und Budgetrahmen versus stabile Teams und Flexibilität in der Umsetzung.

Nebst Scrum ndet Kanban eine immer grössere Verbreitung in- und ausserhalb der IT und manchmal auch in Kombination mit Scrum, im sogenannten Scrumban. Kanban und vor allem Scrum haben sich auf Teamebene etabliert. Oft werden jedoch Produkte von mehreren Teams entwickelt; der Regelung ihrer Zusammenarbeit widmet sich die agile Skalierung. Es gibt verschiedene Ansätze wie z. B. DSDM, DA oder LeSS. Weltweit wie auch in der Schweiz setzt sich jedoch vermehrt SAFe als die skalierte Methode der Wahl durch. Setzten es 2015 erst 6 Prozent ein, sind es 2018 bereits dreimal so viele.

Noch findet Agilität vor allem in der Softwareentwicklung statt. Je reifer aber die Entwicklungsteams werden, desto grösser die Reibungsverluste mit den oftmals bürokratischen übergreifenden Prozessen wie Portfolio Management, Ressourcenplanung oder Deployment, welche noch auf die klassische Projektwelt ausgerichtet sind. Was ist der zusätzliche Businessnutzen, wenn alle zwei Wochen ein auslieferbares Produktinkrement verfügbar ist, aber nur zweimal im Jahr produktiv ausgeliefert werden kann? Waren die übergreifenden Prozesse 2012 noch kein Thema, werden diese heuer als zweitgrösstes Hemmnis genannt. An erster Stelle geblieben ist hingegen die bestehende Unternehmenskultur, welche oft in Widerspruch zu den agilen Vorgehen steht und sich nicht von heute auf morgen verändern lässt.

Das Problem ist erkannt, weshalb nun vermehrt über agile Beschaffung, DevOps, Business Agility und letztendlich agile Organisationen diskutiert wird. Den Worten müssen nun aber auch Taten folgen, weshalb man sich noch länger mit dem Thema beschäftigen wird. Ich bin gespannt, worüber ich dazu in weiteren zehn Jahren schreiben werde.

Relevante Links

-->SwissQ Homepage