Agile Maturitätsmodelle, welche die agile Reife eines Teams prüfen, sind weit verbreitet in der IT-Industrie. Man könnte nun meinen, dass Dinge, die weit verbreitet sind, auch einen entsprechenden Nutzen bringen. Leider ist dem meist nicht so (siehe auch https://www.scrum.org/resources/blog/heres-whats-wrong-maturity-models). In diesem Artikel erkläre ich dir, wie ein typisches Maturitätsmodell aufgebaut ist und anhand von drei Faktoren, welche Problematiken damit verbunden sind. Zum Schluss zeige ich dir eine Möglichkeit, wie du die Problematiken der traditionellen Maturitätsmodelle umschiffen kannst.

Typische Merkmale eines Maturitätsmodells

Als erstes müssen wir klären, was denn ein typisches Maturitätsmodell ausmacht. Grundsätzlich geht es davon aus, dass es verschiedene Stufen der Agilität (mehrheitlich vier bis sechs) gibt, die in aufsteigender Reihenfolge erlangt werden können. Eine Stufe kann dabei nicht übersprungen werden. Zuerst muss eine Stufe vollständig erlangt werden, erst dann geht’s weiter mit der nächsten Stufe.

Um zu prüfen, ob eine Stufe erreicht ist, gibt es eine Liste mit (grösstenteils sehr konkreten) Fragen, die beantwortet werden müssen. Je mehr Fragen mit “Ja” beantwortet werden können, desto höher ist die erreichte Punktzahl. Entweder beantwortet das Team selbst die Fragen oder ein externer “Assessor” beantwortet sie nach Beobachtung des Teams. Am Ende ergibt sich eine Gesamtpunktzahl mit der erzielten “Maturität”. Aus den Fragen, welche mit “Nein” beantwortet wurden, ergibt sich somit automatisch das Verbesserungspotential für das bewertete Team.

Problem Nr. 1: Maturitätsmodelle sind statisch und starr 

Wie oben erwähnt, bestehen typische Maturitätsmodelle aus einem Set an Fragen, die es zu beantworten gilt. Das Problem dabei ist, dass eine Änderung von Fragen im Modell (z.B. aufgrund von neuen Erkenntnissen) dazu führt, dass die Werte nicht mehr vergleichbar sind. Daher bleiben solche Modelle meist über längere Zeit stabil, um diesem Problem zu begegnen. Das macht sie natürlich sehr starr und schwerfällig gegenüber Änderungen. Wie wir alle wissen, ändern sich die Vorgehensweisen in der IT rasend schnell. Mit diesen Änderungen veralten die Maturitätsmodelle ebenfalls sehr schnell und werden damit je länger desto weniger relevant.

Zudem ist dieser fixe Fragenkatalog für ein Team ziemlich langweilig. Spätestens nach dem zweiten Mal wird es die Fragenbeantwortung entweder an jemanden delegieren oder nur noch oberflächlich beantworten, ohne dabei gross nachzudenken. Das ist jedoch genau das Gegenteil von dem, was ein Maturitätsmodell erreichen möchte. Dass sich Teams selbst hinterfragen und von sich aus bessere, effizientere Wege finden, ihre Arbeit zu erledigen.

Problem Nr. 2: Maturitätsmodelle sind einengend 

Eine weitere Problematik besteht in der Art und Weise der Fragen. Meist werden Praktiken abgefragt, welche zwar agiles Arbeiten bedingen, jedoch lediglich die Spitze des Eisbergs darstellen (vgl. auch Blog von Boris).

Daneben gibt es eine Vielzahl von unterschiedlichen Praktiken, die je nach Teamzusammensetzung, entwickeltes Produkt, Branche, Entwicklungsvorgehen, Skills, usw. sehr unterschiedlich sein können. Vielleicht fehlt ja genau diese eine Praktik, die perfekt für das spezifische Team wäre und einen hohen Nutzen bringen würde. Es scheint daher ein wenig anmassend zu sein, mit einem Maturitätsmodell zu wissen, welche Praktiken für ein Team “gut” sein sollten. Fokussiert ein Modell hingegen auf Werte und Prinzipien, so ist die Beantwortung der Frage überwiegend Auslegungssache und wird pro Team unterschiedlich interpretiert. Dies ist jedoch ein Graus für das Management, möchte es doch eine Vergleichsbasis haben. Das führt direkt zum nächsten Punkt.

Problem Nr. 3: Maturitätsmodelle werden zweckentfremdet

Mit Maturitätsmodellen, welche am Ende eine Punktzahl ausspucken, ist dem Missbrauch Tür und Tor geöffnet. Für ein klassisch denkendes Management ist dies ein perfektes Instrument, um die agile Reife von Teams zu vergleichen und im schlechtesten Fall sogar noch finanzielle Anreize (z.B. im Rahmen von MbO Prozessen) daraufzusetzen. Agilität ist jedoch sehr individuell und entwickelt sich in jedem Team anders. Sobald ein Team merkt, dass damit gemessen und verglichen wird, wird es das “Spiel” mitspielen und die Fragen so beantworten, dass es in einem guten Licht dasteht. Damit ist der Nutzen ad absurdum geführt und stellt lediglich eine Belastung (waste) dar.

Dass es auch anders gehen kann, seht ihr im nächsten Abschnitt.

Unsere Alternative: SPF Agile Health Check

Was unterscheidet nun unseren “SPF Agile Health Check” von den oben skizzierten Modellen?

Aufbau SPF Agile Health Check

Der “SPF Agile Health Check” besteht aus fünf Dimensionen, mit denen sich das Team auseinandersetzt:

• Wert erzeugen
• Qualität liefern
• Fokussiert bleiben
• Als Team agieren
• Beweglich bleiben

Diese fünf Dimensionen sind typisch für agil vorgehende Teams.

• Als Beispiel ist es Aufgabe im Product Ownership (in Scrum z.B. via Product Owner), den Wert des Produktes des Teams zu maximieren. Qualität ist in agilen Vorgehen ein inhärentes Merkmal.
• Qualität ist nicht verhandelbar. Falls die Qualität vermindert wird zugunsten von schnellerer oder umfangreicherer Lieferung, so stellt dies eine technische Schuld dar und muss in Zukunft irgendwann wieder abgebaut werden. Erlaubt der PO dies zu oft, so wird das Produkt sukzessive schlechter in der Qualität. Im Extremfall führt dies dazu, dass entweder die Kunden abspringen (obwohl man ja viel Funktionalität geliefert hat) oder dass das Team im Sprint nur noch mit dem Herstellen einer vernünftigen Qualität beschäftigt ist und deshalb keine neuen Features mehr liefern kann.
• Der Fokus ist sogar ein dedizierter Wert im Scrum Guide. Fokus erreicht ein Team in Scrum automatisch, da es innerhalb kurzer Frist, z. B. zwei Wochen, ein funktionierendes Produktinkrement liefern muss. Weiter wird im Scrum Guide ein Product Goal sowie ein Sprint Goal definiert. Dies stellt ebenfalls eine Fokussierung dar.
• Teams stellen den eigentlichen Motor in der Agilität dar. In Teams wird Wert geschaffen. In Teams arbeiten Individuen zusammen und es entsteht Interaktion, Kommunikation, Zusammenhalt, Identifikation und vieles mehr. Wie wichtig Teamarbeit ist, zeigen diverse Studien. Details sind hier schön erklärt: https://www.atlassian.com/blog/teamwork/the-importance-of-teamwork
• Beweglichkeit, der eigentliche Ursprung des Wortes Agilität (Engl: agile, Lat: agilis für beweglich, flink) ist in der modernen Softwareentwicklung ein Grundelement seit der Gründung des “Manifesto for Agile Software Development” (2001). Reaktion auf Veränderung wird dort höher gewichtet als die Planbefolgung. Dies ermöglicht in einer schnelllebigen Welt (VUCA) auf Veränderungen möglichst rasch zu reagieren.

Zu jeder dieser fünf Dimensionen besteht jeweils ein Set an Aussagen. Diese Aussagen beurteilt das Team nun anhand von zwei Kriterien:

• Wie leicht fällt es uns dies zu tun?
  
• Wie regelmässig tun wir dies?
  

Als Resultat entsteht am Ende ein Bild pro Dimension mit einer Einschätzung des Teams zu den vorhandenen Aussagen:

Agile Health Check – Dimension Wert

Nach Beurteilung der fünf Dimensionen diskutiert das Team darüber, wo es gerne Fortschritte machen möchte und welche Massnahmen es zur Umsetzung definiert. Daraus ergeben sich die folgenden Vorteile:

Flexibilität im SPF Agile Health Check

Wie oben ersichtlich ist, können die Fragen pro Dimension spezifisch für das Team, das Produkt, die Branche oder das Entwicklungsvorgehen sein. Das spielt letztlich keine Rolle hinsichtlich des Ergebnisses. Wenn ein Team findet, dass bei ihnen zum Beispiel eine andere Dimension zusätzlich wichtig ist, so kann es diese selbstverständlich hinzufügen oder eine bestehende ersetzen. Dabei ist zu beachten, dass die Fragen bezüglich der Kernwerte der Agilität nicht “herauskonfiguriert” werden.

Weiter sind auch die zu bewertenden Aussagen flexibel und können nach Bedarf angepasst werden. Dies geht spielend einfach, kann sich ebenfalls von Team zu Team unterscheiden. Wir stellen zwar ein Grundgerüst an Aussagen aufgrund unserer Erfahrung mit unzähligen Teams zu Verfügung. Dies stellt aber kein Muss dar. Es hat sich aber als bewährt herausgestellt und es ist eine Frage von Kosten/Nutzen, wieviel Zeit der Kunde in eine konfigurierte Version investieren möchte.

Somit ist unser “SPF Agile Health Check” rasch an neue Gegebenheiten und Entwicklungen angepasst. Und da keine Zahl zum Maturitätslevel als Ergebnis vorhanden ist und damit auch ein Vergleich von Teams bewusst keinen Sinn ergibt, ist das Modell auf Änderungen gut vorbereitet.

Offenheit und Individualität des SPF Agile Health Check

Wie vorher grade erwähnt, ist das Anpassen auf spezifische Team- oder Firmengegebenheiten kein Problem. Orientiert sich ein Team an Scrum, so sind die Fragen in diese Richtung zu beantworten. Wenn ein Team nach Kanban vorgeht, dann sind die entsprechenden Begriffe aus der Kanban-Welt relevant.

Findet ein Team eine Frage als nicht relevant, so wird sie elegant aus dem Spiel genommen. Dies beeinträchtigt weder das Ergebnis noch das Vorgehen im Workshop. Im Gegenteil, das sichtbar machen führt dazu, dass diese bewusste Entscheidung des Teams transparent ist und bei einer nächsten Durchführung wieder ins Bewusstsein rückt.

Im Workshop selber findet bei der Positionierung der Frage auf dem Flipchart die entscheidende und wertvolle Diskussion statt. Damit wird innerhalb des Teams eine gemeinsame Sicht auf den Stand der Agilität erarbeitet. Es geht nicht um das “Erfüllen” von vordefinierten Kriterien. Das fördert letztlich den Teamzusammenhalt und am Ende hat man ein gemeinsam erarbeitetes, sichtbares Resultat.

Und letztlich der Spassfaktor beim SPF Agile Health Check

Durch die lockere Art des Arbeitens mit Flipchart und Zeichnungen wird zudem der Widerstand gegen solche “Assessments” reduziert, da schnell klar wird, dass es nicht um die Erreichung von einem Zustand geht, sondern ein gemeinsames Bild zur Agilität geschaffen wird. Ebenfalls ist die Positionierung innerhalb der beiden Achsen keine Wissenschaft, da die Achsen bewusst “schwammig” gehalten werden. Das soll verhindern, dass plötzlich die Komponente Auswertung und Vergleichen ins Spiel kommt.

All das führt dazu, dass Teams einen “SPF Agile Health Check” nicht als formales Assessment betrachten, sondern als Möglichkeit, als Team weiterzuwachsen und besser zu werden. Ziel erreicht 🎯!

Möchtest du auch einen Versuch wagen? Dann sprich mit uns. Gerne führen wir für dich einen “SPF Agile Health Check” durch, damit auch die dies erleben kannst und mit deinem Team weiterführen kannst.

“Wir sind schon agil, wir müssen nichts mehr anpassen!”

Wie oft habe ich diesen Satz in den letzten Jahren schon gehört.

Da kriege ich kurz einen Puls von 180. Dann muss ich mich zurücklehnen und mir wieder das Kernprinzip der Agilität in Erinnerung rufen: “Bessere Wege finden, um Software zu entwickeln.” (Agile Manifesto). Das agile Manifest ist nun schon seit 20 Jahren online. Wer lediglich diesen ersten Satz des Manifests gelesen und verstanden hat, weiss, dass Anpassungen zur Agilität dazu gehören. Viele kennen sogar noch die vier Wertepaare vom Manifest, die wenigsten jedoch die darunter angehängten 12 agilen Prinzipien.

Also dreimal kurz durchatmen. Der Mensch ist ja bekanntlich ein Gewohnheitstier. Frei nach dem Motto: “Never change a winning horse.” Wenn wir uns einmal eine Verhaltensweise zugelegt haben, die funktioniert, dann lassen wir nur ungern davon ab. In der heutigen VUCA Welt ist das Festhalten an alten Gewohnheiten keine gewinnbringende Strategie. Das mussten schon viele Firmen in den letzten Jahren schmerzhaft erfahren. Kleinere und beweglichere Firmen konnten neue Marktbedürfnisse schneller abdecken oder sich rascher an die Änderungen anpassen.

[Klaus Schwab, WEF Davos Februar 2015]

Auf das Verhalten der Mitarbeiter in Firmen bezogen bedeutet dies, dass durch stetiges Lernen bestehende Gewohnheiten hinterfragt und neue Wege und Verhaltensmuster angewendet werden. Ein weit verbreitetes Instrument in der agilen Welt dafür ist die Retrospektive. In der durch den Scrum Master geführten Retrospektive hinterfragt das Team seine bestehenden Abläufe, sucht nach Verbesserungen, diskutiert offen über Fehler und bringt so jeden einzelnen in seiner Entwicklung weiter. Damit dies tatsächlich passiert, ist (insbesondere in der Retrospektive) eine grosse Portion Mut und Offenheit erforderlich. Ich muss den Mut haben, Fehler einzugestehen. Daraus zu lernen. Das ist für viele in bestehenden Firmenkulturen sehr schwer. Dort werden nämlich Fehler für “finger pointing” und Abmahnungen missbraucht. Den Chefs fällt dies sogar noch schwerer, da sie zum Chef ernannt wurden, weil sie besser als die anderen sind, d.h. ihnen passieren natürlich auch keine Fehler. Zumindest sieht das die Organisation so. Mit selbstorganisierten Teams in der agilen Welt ist dieser Umstand aus dem Weg geräumt. Die Mitglieder des Teams müssen einander für ihre Versäumnisse verantwortlich machen. Das gelingt nur durch echtes und ehrliches Feedback. Was wiederum eine Portion Mut erfordert! Manchmal muss man auch ein negatives Feedback äussern und dies möglichst ohne sein Gegenüber zu verletzen.

Es ist darum nicht verwunderlich, dass der Scrum Guide mit der Version aus dem Jahr 2016 folgende Werte als Basis des Scrum-Frameworks aufgenommen hat:

• Fokus

• Respekt

• Mut

• Offenheit

• Selbstverpflichtung

Zusammen mit den tragenden Pfeilern der Transparenz, Überprüfung und Anpassung entfaltet sich das Scrum Framework zum Effizienzmotor. Leider verstehen viele Firmen nicht, dass genau diese Werte die Basis ist, um agil zu werden. Lediglich durch die Einführung von neuen Prozessen, Rollen und Artefakten wird eine Firma noch lange nicht agil. Erst wenn die Menschen in der Organisation die oben genannten Werte spüren und auch vorgelebt bekommen, dann wird ein agiler Ruck durch die Firma gehen. Dann werde ich auch nicht mehr den Satz hören müssen: “Wir sind schon agil, wir müssen nichts mehr anpassen!”

In diesem Sinne: Habt Mut und geht neue Wege. Je häufiger ihr neue Wege geht, desto mehr wird dies zu eurer neuen Gewohnheit und ihr werdet selber zum “fast fish” :-).