Ist Agilität messbar?

Agilität agil messbar TitelKlassische Assessment-Techniken und Regelwerke sind stark in der traditionellen Softwareentwicklung verwurzelt. Wir kennen u.a. CMMI® für die Bewertung des Softwareentwicklungsprozesses und TMMi® bzw. TPI NEXT® für den Testprozess. Der Begutachtete erwirbt durch sie – falls unabhängig durchgeführt – einen objektiven Blick auf die aktuelle Projekt- oder Unternehmenssituation in den Bereichen Entwicklung und Test. Viel nützlicher jedoch sind die resultierenden zeitlich gestaffelten Empfehlungen. Zusätzlich zum Standard sind solche Empfehlungen unserer Meinung nach stets durch ökonomische Betrachtungen, d.h. minimal eine Kosten-Nutzen-Analyse, zu unterfüttern.

Kann man ebenso agile Strukturen auf ihre Reife untersuchen? Oder ist es ein Widerspruch zu den Prinzipien agiler Softwareentwicklung; steht doch im agilen Manifest bereits: „[…] value individuals and interactions over processes and tools.

Agilität als Prozess

Sind Prozesse und ihre Einhaltung für die Verfechter der agilen Softwareentwicklung also nur ein Gräuel? Mitnichten. Im weiteren Verlauf wird bereits relativiert: „[…] while there is value in the items on the right, we value the items on the left more.“ Die Notwendigkeit von geregelten Abläufen wird somit anerkannt, aber nicht zum Schlüsselfaktor des Erfolges eines Projektes erhoben. Wichter denn je sind Kundenzufriedenheit durch wertige Software, Kommunikation, motivierte Individuen und technische Exzellenz; nachzulesen in den zwölf agilen Prinzipien. Auch als „klassisch“ ausgebildeter Test- und Projektmanager kann ich das unbesehen unterschreiben.

Betrachtet man es nüchtern, so ist auch Scrum (exemplarisch aus dem Zoo der agilen Methoden herausgegriffen) nur ein Prozess. Nur durch dessen Einhaltung und die einhergehende Einhaltung der zwölf agilen Prinzipien erreicht eine derart ausgerichtete Organisationseinheit effizient ihre Ziele. Dabei geht es nicht um eine weitere Formalisierung bzw. Überregulierung von Prozessen, Dokumentationen usw., wie sie klassischen Regelwerken oft vorgeworfen wird. Wir können und wollen also nichts anderes beurteilen als die Reife der Ausprägung – der implementation – von Scrum – dem interface – in einer Organisation; um die Analogie zu Java zu bemühen. Schließlich ist Agilität nicht mit Chaos gleichzusetzen!

Was die Erfahrung lehrt

Meine Erfahrung lehrt, dass Agilität auf verschiedenste Art und Weise gelebt wird – oder auch nicht. Wir betrachten dabei nicht die Auswirkungen auf die Softwarequalität. Als Testmanager erlebt. Bei einem mittelgroßen Anbieter von location based services war Agilität, d.h. Scrum ausgerufen. Begünstigt durch eine vorherrschende Start-Up Atmosphäre wurde dies zumindest anfangs auch formal gelebt. Überlange Sprintzyklen, überzogene daily scrums und ad hoc Arbeiten waren aber bereits an der Tagesordnung. Über die Zeit und bedingt durch Umstrukturierungen fiel man leider zurück in einen klassisch, chaotischen Test- und Entwicklungsprozess.

Auf einer Konferenz gehört. Im letzten Jahr hat ein Anbieter für Medizintechnik eindrücklich beschreiben, wie eine agile Transformation erfolgreich durchgeführt werden kann. Die Sprintzyklen der nach Funktionen getrennten Scrum-Teams werden über einen heartbeat getauften Mechanismus synchronisiert. Alle Rollen (z.B. Scrum Master) haben ihre eigene Community zum Erfahrungsaustausch. Die Scrum-Teams sind weiterhin in ein klassisches Projektmanagement-Framework nach PMI eingebunden; um nur drei Feinheiten hervorzuheben.

Als Solution Consultant erfahren. Ein Start-Up im Bereich cloud services unterhält nach Anwendungsschichten getrennte Scrum-Teams, die in situ nur aufgrund der technischen Fähigkeiten der Teammitglieder funktionieren; Prozesse werden nach persönlichem Verständnis gelebt. Es fehlen Mechanismen zur Abstimmung untereinander, beispielsweise für einen Integrationstest; hauptsächlich bedingt durch mangelndes Problembewusstsein im Management. Zudem werden teilweise eherne Regeln von Scrum, wie z.B. die Beschränkung der Teamgröße, missachtet.

Bei uns erfolgreich gelebt. Auch bei einem unserer Auftraggeber, einer Online-Handelsplattform setzt man auf verteilte Scrum-Teams, die zudem nearshore angesiedelt sind. Die disziplinarische Führung dieser Teams übernimmt ein klassischer Teamleiter. „inshore“ residiert der Product Owner und ein sogenannter Code Buddy, der allen als technischer Berater zur Verfügung steht. Ein klassischer Projektleiter ist verantwortlich für die übergeordnete Planung und Steuerung; er ist zudem Ansprechpartner des Auftraggebers. Ein Lenkungsausschuss aus nearshore und inshore Vertretern ist für die strategische Planung und die Überwachung des Projektfortschritts verantwortlich.

Von Schwer- und Leichtgewichten

Wie bestimmt man nun den agilen Reifegrad dieser Organisationen? Eine flüchtige Suche nach Bewertungsmaßstäben für den agilen Prozess brachte folgendes zu Tage. In [PiMä06] wird anhand von Fallstudien beschrieben, wie man CMMI® zur Bewertung des agilen Softwareentwicklungsprozesses bzw. als Hilfestellung bei der Einführung agiler Prozess einsetzen kann. Grundsätzlich spricht nach Meinung der Autoren nichts gegen die Verwendung von CMMI®, jedoch ist man sich bewusst, dass natives CMMI® im agilen Umfeld nicht immer die korrekten Interpretationen zulässt. Um dennoch zu einer Bewertung zu gelangen wurden klassische in CMMI® definierte Ziele auf agile Methoden abgebildet. Ein mögliches Mapping ist in [Marcal06] beschrieben. (Eine entsprechende Untersuchung von TPI NEXT® meinerseits steht noch aus.)

Ein kurzes, knackiges Quiz, welches sich selbst nicht ganz ernst nimmt, ist Teil von [Shore07]. „Sort of like the quizzes you find in fashion magazines, but more sophisticated.“ Es ist gedacht für die Selbsteinschätzung eines Teams mit dem Ziel Verbesserungspotentiale und Risiken aufzudecken. In den Kategorien „denken“, „zusammenarbeiten“, „freigeben“, „planen“ und „entwickeln“ werden simple Fragen gestellt wie: Treffen die Entwickler jemals Annahmen, anstatt nachzufragen? Die Auswertung erfolgt dann nach dem bewährten Ampel-Prinzip.

Neue Abkürzungen im Anmarsch

Auch formale für den agilen Prozess neu entwickelte Modelle existieren, unter anderem das Agile Maturity Model (AMM), das Objectives, Principles and Practices (OPP) Framework und der Sidky Agile Measurement Index (SAMI) aus dem Agile Adoption Framework. Besonderes Augenmerk wollen wir auf SAMI legen, erscheint dieser doch subjektiv am gründlichsten entwickelt und weiter verbreitet.

Das Agile Adoption Framework wird beschrieben in der Dissertation eines Herrn Ahmed Sidky und besteht aus zwei Teilen. Teil Eins. Ein agiler Gradmesser (SAMI), bestehend aus fünf agilen Reifegraden („gemeinschaftlich“, „evolutionär“, „effektiv“, „lernfähig“ und „(all)umfassend“), zum Identifizieren des agilen Potentials eines Projektes oder einer Organisation. Dabei werden fünf agile Prinzipien, z.B. die technische Exzellenz beleuchtet. Diese Prinzipien sind direkt aus den zwölf agilen Prinzipien (s.o.) abgeleitet und bilden die Grundlage für die zugeordneten agilen Methoden, z.B. pair programming und user stories. Des Weiteren stellt SAMI dem Assessor 300(!) Fragen, Indikatoren genannt, für die Beurteilung zur Verfügung.

Teil Zwei beschreibt einen vier-stufigen Prozess mit dem Ziel um (a) herauszufinden, ob die jeweilige Organisationseinheit bereit für eine agile Transformation ist (oder nicht), und wenn ja (b) auf Basis ihrer Möglichkeiten festzulegen, welche agilen Methoden am sinnvollsten einzuführen sind. Stufe 1: Identifikation von Kontra-Indikatoren, z.B. fehlende Managementunterstützung. Stufe 2: Ermittlung des SAMI. Stufe 3: Gegenprobe. Ist die Organisationseinheit in der Lage, den in Stufe 2 ermittelten, theoretisch möglichen Reifegrad zu erreichen? Stufe 4: Abstimmung über die tatsächlich einzuführenden agilen Methoden. In dieser letzten Stufe vollzieht sich der Übergang vom Formalismus hin zur individuellen Beratung. (Eine leichtgewichtige Einführung auf Englisch findet man in [1] und [2].)

Um die Eingangsfrage zu beantworten: Ja, Agilität ist messbar. Die Praxis lehrt, dass man die Frage, wie agil die eigenen Prozesse sind sogar stellen muss. Für ein Assessment kann man aus einem breiten Spektrum adaptierter klassischer und moderner Techniken wählen. Profitieren Sie von unserer Erfahrung im Bereich der Prozessanalyse und der agilen Entwicklung.

Nie wieder einen Blogartikel verpassen >>> Zum Blog-Newsletter anmelden

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

fünf × zwei =