Entwickeln mit agilen Frameworks

Viele versprechen sich von agilen Vorgehensweisen die reibungslose Umsetzung von Entwicklungsprojekten. Unterstützung findet man in vielen verschiedenartigen „agilen Frameworks“. „Agile“, gesprochen: /ˈæʤaɪl/, bringt natürlich nicht die Lösung aller Probleme. Jedoch kann ein Vorgehen anhand agiler Vorgehensweisen und Frameworks deutlich bei der Entwicklung helfen, gerade wenn man mit sich stark verändernden Märkten und komplexer werdenden Systemen konfrontiert wird.

Doch welches agile „Framework“ ist das beste, mit welchem fängt man an? Es tummeln sich doch sehr viele Abkürzungen und Buzzwords im agilen Bereich: Scrum, SoS, SAFe, Nexus, LeSS, STUf², Kanban, Lean, NERd, OpenSpace, COMPLETe, Management 3.0,….

Den perfekten Ansatz werde ich Ihnen hier nicht geben können. Jedoch kann ich ein paar Aspekte beleuchten, die Ihnen auf dem Weg durch den Dschungel helfen.

Agil, aber auf welcher Ebene?

Zuerst geht es darum, sich bewusst zu machen, dass die verschiedenen Frameworks und Konzepte verschiedene Ebenen betrachten. Folgende Pyramide [1] verdeutlicht, dass die verschiedenen Frameworks auf unterschiedlichen Ebenen ansetzen und meist gewisse Bereiche auslassen.

Die  Pyramide zeigt die Bereiche Techniken (unten), Prozesse/Vorgehen (in der Mitte) und Prozessverbesserung (oben). Zum Beispiel: eXtreme Programming, ein Konzept aus den späten 90ern, setzt hauptsächlich im Bereich der Techniken und Praktiken an. Es beschreibt Techniken wie Pair-Programming, testgetriebene Entwicklung, kontinuierliche Integration, Planning Game, iteratives Vorgehen,  etc. Scrum [4], das derzeit meist verbreitete agile Vorgehen, beschreibt hingegen keine Techniken, dafür aber Vorgehensweisen und Prozessverbesserung. Ähnliches gilt für skalierte agile Frameworks wie SAFe 4.5“ [3]. Kanban adressiert vor allem das Thema Prozessverbesserung.

Welches Konzept Sie für Ihren Bereich übernehmen, hängt von vielen Faktoren ab. Betrifft es nur Software-Entwicklung? Wieviel Teams sollen nach diesem Konzept arbeiten? Wie (un)abhängig arbeiten diese Teams voneinander? Ist verteiltes Arbeiten ein bestimmender Faktor? Soll und kann das neue Konzept im ganzen Unternehmen, in Teilbereichen oder nur in ein paar Abteilungen umgesetzt werden? Gibt es den Big Change, oder sollen schleichend ein paar Aspekte umgesetzt werden, usw. usf.

Was zeichnet agiles Arbeiten wirklich aus?

Die erste wesentliche Frage ist, warum und wozu soll ein anderes Arbeitskonzept dienen, wo sind die Schwachpunkte des jetzigen Arbeitens?

Agiles Arbeiten, wenn es vernünftig umgesetzt wird, bietet einige Vorteile, die sich in der heutigen Arbeitswelt bewährt haben. Was ist nun der wesentliche Unterschied zu herkömmlichen Prozessen und Prozesslandschaften? Herkömmliche Prozesse helfen, langjährig gesammelte Erfahrungen im Unternehmen in Vorschriften für ein Vorgehen zu gießen, weil sich diese bewährt haben. Dadurch wird ein Rahmen geschaffen, der den Mitarbeitern Hilfe bietet, um effizient ihre Arbeit machen zu können, ohne dass sie sich immer wieder die Vorgehensweisen selbst dazu entwickeln müssen. Ein Beispiel: Die Bestellung von Bauteilen oder Abrechnung der Dienstreise nach einem bestimmten festgelegten und eingefahrenen Prozess ist meist ziemlich effizient. Wenn sich jeder Mitarbeiter neu um das „wie mache ich das“ kümmern müsste, und dazu jedes Mal mit dem Chef und anderen Mitarbeitern über das „Wie“ und „Warum“ diskutieren würde, würde das das Unternehmen wesentlich mehr Arbeitszeit kosten. Hingegen:

1. Die Teilenummer in SAP anklicken,
2. Bestellung auslösen und
3. vom Leiter unterschreiben lassen,
4. vier Wochen warten,

geht doch da viel effizienter und meist schneller.

Warum funktioniert dann diese Art von Prozessen in den heutigen Entwicklungsabteilungen oft nicht mehr?

Die Antwort ist: Die Rahmenbedingungen verändern sich, die Märkte und Anforderungen verändern sich immer schneller. Ein gestern definierter Prozess kann heute schon behindernd wirken, statt unterstützend. Den Trick, den die agilen Konzepte (auch Lean- und Kanban-Ansätze zähle ich jetzt mal dazu) machen, ist, dass sie Werte und Prinzipien vorgeben. Diese sind stabil und konstant. Sie ermöglichen situationsbedingt unterschiedliche Vorgehen anzuwenden, je nach Rahmenbedingungen des konkreten Projekts.

Zum Beispiel das Prinzip der „face-to-face Kommunikation“ (siehe agiles Manifest, 2001 [2]) lässt sich sowohl in Scrum als auch in Kanban, SAFe, etc. unterschiedlich verwirklichen. Es wirkt sich, vernünftig umgesetzt, in allen Fällen positiv auf die Zusammenarbeit der Mitarbeiter aus und unterstützt so die Effizienz.

Das „Mindset“ des Teams oder Unternehmens ist entscheidend, nicht unbedingt die Methode oder das Konzept. Arbeiten nach Werten und Prinzipien ermöglicht ein schnelles, selbstverantwortliches Handeln, wie es das sich schnell wandelnde Umfeld erfordert. Arbeiten nach starren Prozessen entzieht hingegen dem Team die Verantwortung und macht es damit unflexibel.

Agil heißt nicht: „Ich mache, was ich will“

Agile Frameworks geben oft sehr harte Rahmenbedingungen vor. Sie pressen die Arbeit durchaus in feste Bahnen und Rollen, sodass man nicht sagen kann, „agil“ heißt „ich mache was ich will“, oder „jeder organisiert sich einfach selbst, wie er will”. Die Zielsetzung agiler Frameworks ist es, die Zusammenarbeit zu unterstützen, und hierbei sind klare Vorgaben hilfreich.

Innerhalb dieser Rahmenbedingungen (inklusive Werte und Prinzipien) ist sehr viel Freiraum. Selbstorganisation und Eigenverantwortung ist hier nicht nur erlaubt, sondern auch gefordert. Hat man ein gutes, interdisziplinäres Team, können dann Entscheidungen besser und schneller getroffen werden.

Zudem lassen sich die einzelnen Framework-Vorgaben sehr an die eigenen Bedürfnisse einer Organisation anpassen, da die regelmäßige Anpassung bereits in den Vorgaben enthalten ist. Erst durch harte Rahmenbedingungen wird ermöglicht, dass die Mitarbeiter ihre Arbeit fokussieren können, ohne sich um die Zielsetzungen kümmern zu müssen, die bereits durch die Rahmenbedingungen gelöst werden.

Darin sind die Frameworks  durchaus ähnlich den herkömmlichen Prozessen, jedoch mit weiter gesteckten Rahmen und mehr Freiheit innerhalb dieser Rahmen. Im Gegensatz zu klassischer Interpretation von Prozessen versucht ein agiles Framework nicht den Einzelnen vom Denken zu befreien, sondern sein Denken optimal für die Systementwicklung nutzbar zu machen.

Agil in herkömmlichen Entwicklungsteams

Auch in erfolgreichen „klassischen“ Entwicklungsteams werden meist intuitiv viele der agilen Werte und Prinzipien umgesetzt. Oft habe ich in den Unternehmen Folgendes gesehen und erlebt, nehmen wir ein erfolgreiches, mittelständisches Unternehmen im Maschinenbau als Beispiel: In einer typischen Zusammensetzung entwickeln ein Chefingenieur, ein Abteilungsleiter, 3 Maschineningenieure, 2 Elektroingenieure (Elektrik + Elektronik, Verkabelung, Schnittstellen/Stecker) und 2 Softwareentwickler (für die Kontroll- und Bedieneinheit) erfolgreich ein Produkt. Unterstützt werden sie von einem Produktmanager, einem Einkäufer und einem zentralen Mitarbeiter aus dem Qualitätsmanagement. Solche Teams in der Größe von ca. 10 – 40 Leuten arbeiten oft sehr effektiv und effizient zusammen, ohne das Wort „agil“ kennengelernt zu haben.

Jedoch wenn solche klassische Teams wachsen, genau dann könnten agile Frameworks interessant werden. Denn es gibt viele Gründe, um wachsen zu „müssen“:

• Weil Sie zunehmend mit Zulieferern zusammenarbeiten,
• Weil eine Zusammenarbeit mit anderen und neuen Teams notwendig wird,
• Weil sie an verteilten Standorten arbeiten müssen,
• Weil das Produkt plötzlich eine hohe Variantenvielfalt bekommt,
• Weil der Software-Anteil am Produkt deutlich steigt,
• Weil sich die Marktanforderungen stetig und immer schneller verändern,
• Weil das Produkt immer individueller für den Kunden produziert werden muss,
• …

Im Wachstumsprozess gehen dann die wichtigen, oft unbewussten Erfolgsfaktoren verloren. Zum Beispiel gehört dazu: die informellen Netzwerke, bei denen jeder weiß, was der andere kann, und wer der richtige Ansprechpartner für ein Problem ist.

Fazit

Agile Konzepte und Frameworks zielen darauf ab, Erfolgsfaktoren bewusst zu installieren. Agilität ist eine Frage der Haltung,  wie Julia Grassinger in ihrem Blogbeitrag kürzlich schrieb. Meine Kollegen und ich begleiten und unterstützen regelmäßig solche wachsenden Entwicklungsteams. So konnten wir oft schon die strukturellen Veränderungen mit Erhalt oder Steigerung der Effizienz umsetzen.

Diskutieren Sie gerne agile Themen rund um die Systementwicklung auf der „Agile Systems Konferenz (ASK)“ im Oktober in München.

Oder planen Sie ihre weiteren Schritte zur agilen Transformation in der Landscape der Agilen Transformation und laden Sie sich dazu unsere Landscape herunter.

 

 

[1] Becker, Andreas: Im Kurs “Leading SAFe®, Leading the Lean Enterprise with the Scaled Agile Framework® SAFe 4.5”, 2018

[2] Das agile Manifest, 2001. http://agilemanifesto.org/iso/de/principles.html [zuletzt aufgerufen am 30.07.2018]

[3] SAFe 4.5, Scaled Agile Framework – SAFe for Lean Enterprises, https://www.scaledagileframework.com/ [zuletzt aufgerufen am 30.07.2018]

[4] Scrum.org, What is Scrum?, https://www.scrum.org/resources/what-is-scrum [zuletzt aufgerufen am 30.07.2018]