Die Entscheidung für Agilität (sei es als Startup oder in einem Transformationsprozess) ist immer mit einem Zweck verbunden, so sieht es zumindest mein grenzenlos naives Selbst. Wenn ich aber einen Zweck verfolge, muss ich doch irgendwann überprüfen, ob ich mein Ziel erreicht habe, oder noch besser: regelmäßig prüfen, ob ich auf einem guten Weg bin.

Hier wird es richtig schwierig, und deswegen ist hier auch die größte Schlampigkeit aller Unternehmen zu finden. Natürlich ist mir klar, dass Agilität nicht immer und überall eine bewusste, mit einer Überlegung unterfütterte, einem Zweck dienliche Entscheidung ist. Oft genug wird das einfach gemacht … aus Gründen, und weil man das einfach machen muss, und weil das alternativlos ist, und weil alles Andere Mist ist, und was wir uns sonst noch so einreden wollen. Das Fass will ich jetzt nicht aufmachen und für mein heutiges Thema ist mir das auch scheißegal.

Ich gehe davon aus, dass Ihr, wenn Ihr das hier lest, wissen wollt, wie man Agilität messen kann. Daraus schließe ich, dass Ihr Euch ernsthaft mit dem Thema im allgemeinen beschäftigt, und wenn das der Fall ist, gehe ich auch davon aus, dass Ihr Euch mit vielen Themen bewusst auseinandersetzt, und eine Zielsetzung wird wahrscheinlich dazu gehören.

Über Motivation und Selbstzweck habe ich beim letzten mal schon ein paar Dinge geschrieben, so dass ich jetzt nicht alles dazu wiederholen möchte, dennoch werden wir früher oder später dort ankommen. Anfangen möchte ich mit Euch jedoch an einem anderen Punkt: den Regeln.

Etliche Unternehmen möchten alle möglichen Themen und Dinge quantifizierbar machen (was grundsätzlich keine schlechte Idee ist), überlegen sich, wie das bei diesem nebulösen Ding Agilität gehen kann, und fragen, wie die Teilnahmequote bei den Dailies ist, und wie viele Teams Retrospektiven machen.

Damit erfrage ich, wie viele sich an die Regeln halten. Ich erfahre natürlich nichts darüber, ob diese Regeln verstanden wurden (oder nur indirekt). Ich erfahre nichts darüber, was diese Regeln bewirken, und ich erfahre nichts über den Gesamtzustand meiner Agilität (klingt ziemlich furchtbar, oder?). Erst recht nicht, wenn ich die gesammelten Zahlen zu einer Gesamtzahl aggregiere. Was zur Hölle sollte mir ein solcher Index sagen?

Mit dem, was ich so erfahre, kann ich entweder den Kollegen auf die Finger hauen und ihnen sagen, dass sie jetzt gefälligst am Daily teilnehmen, oder ich kann nachfragen, warum keiner mitmacht. Sehr wahrscheinlich wird dann die Antwort lauten, dass meine Mitarbeiter keinen Sinn darin sehen. Damit bin ich vielleicht einen Schritt weiter, und kann herausfinden, warum Agilität in meinem Unternehmen nicht funktioniert, ohne zu wissen, was »funktionieren« bedeutet.

Klingt ziemlich bescheuert, wenn man das so liest, richtig? Und jetzt fragt Euch mal, wie das bei Euch in der Organisation aussieht. Erschrocken?

Völlig vorwurfsfrei und ohne jede Schadenfreude von meiner Seite. Wie oft tun wir Dinge ohne ein Ziel vereinbart zu haben. Keine Sorge, das geschieht in allen Organisationen. Wenn wir wissen, dass es so ist, können wir daran arbeiten.

In eine ähnliche Richtung steuert der Nokia Test (http://www.think-pi.de/Nokia-test-deutsch). Auch wenn es ein wenig weiter reicht, geht es doch in der Hauptsache um die Einhaltung der Scrum Regeln, was auch mein Hauptproblem mit diesem Test ist: es geht nur um Scrum.

Ich will aber nicht testen, ob ich mich an ein Framework halten kann (dafür brauche ich keinen Test). Ich möchte wissen, was die Entscheidung hin zu Agilität meiner Organisation bringt. Wie »agil« ich tatsächlich bin, ist mir vollkommen egal. Der Zweck heiligt die Mittel.

Für alle, die jetzt einen Herzinfarkt bekommen: hier der Kontext:

Wenn ich das anders sehen würde, wäre Agilität reiner Selbstzweck. Ich nutze Agile Methoden und bekenne mich in der Organisation zu Agilität, weil ich etwas erreichen will – nach außen zum Kunden hin, nach innen zu meinen eigenen Kollegen hin (vielleicht um anfallende Arbeiten besser zu organisieren und Belastungsspitzen zu minimieren) oder beides, oder aus ganz anderen Gründen. Zuerst kommt mein Ziel, dann meine Entscheidung für den Weg zum Ziel. Agilität in einer Organisation ist immer nur das: ein Weg hin zu einem bestimmten Ziel.

In der Konsequenz interessiert mich also nicht, wie agil ich bin, sondern wie gut ich in Bezug auf mein Ziel bin. Daher hat es schlicht und ergreifend keinen Sinn, Agilität zu messen. Puristen mögen das anders sehen, aber dies ist meine höchst pragmatische Sicht der Dinge.

Trotzdem möchte ich nicht auf dieser Erkenntnis enden, weil ich keinesfalls sage, dass man das Messen einfach sein lassen sollte. Ganz im Gegenteil: Messungen und Erfolgskontrollen sind unfassbar wichtig, und nicht nur einmal, sondern regelmäßig. Ich bin davon überzeugt, dass gerade in der Organisationsentwicklung – und genau darüber reden wir hier – ein iterativ empirisches Vorgehen genau richtig ist.

Für jedes Ziel, dass ich mir setze, will ich wissen, wann dieses Ziel erreicht ist. Das bewahrt mich zum einen davor Wischiwaschi-Ziele zu definieren, zum anderen vor endlosen Diskussionen, ob das Ziel erreicht wurde, oder nicht. Solche Diskussionen sind völlig sinnlos, kosten Zeit und Kraft und bringen uns nicht im mindesten voran. Diskussionen darüber, wann ein Ziel erreicht ist, möchte ich am Anfang führen. Das macht mir mein weiteres Vorgehen sehr viel leichter.

Wenn ich weiß, wann mein Ziel erreicht ist, dann weiß ich, was ich messen kann. Damit weiß ich natürlich noch nicht zwingend, wie ich das messen kann, aber im Moment ist das noch nicht wichtig. Erst wenn ich einen Indikator finde, wann mein Ziel erreicht ist, dann kann ich mir weitestgehend sicher sein, dass mein Ziel auch konkret genug ist.

Beispiele für Ziele, die nicht konkret genug sind? Ich möchte besser werden in all seinen Variationen. Ich möchte flexibler reagieren können. Ich möchte kürzere Wege haben. Was auch immer…

Die größte Schwierigkeit bei der Formulierung eines Ziels ist immer die Konkretisierung. Eine Sache zu finden, die mir nicht gefällt, und dann zu sagen, dass ich darin besser werden möchte, ist sehr einfach, aber das genügt eben nicht. Je konkreter ich werde, desto zielgerichteter kann ich agieren. Erst dann kann ich messen.

Ich möchte mehr Items im Monat schaffen. OK, ich vergleiche die Zahlen monatsweise. Habe ich dann mein Ziel schon erreicht, wenn ich nur ein Item besser bin? Wenn ich es mit einer Zahl ausdrücken kann, bin ich konkret genug, und erst dann kann ich Dinge messen. Mein Ziel beinhaltet also immer auch einen konkreten Wert. In diesem Beispiel also: ich möchte 100 Items mehr im Monat schaffen. So kann ich sehr genau sehen, ob mein Ziel erreicht wird oder nicht.

Natürlich stelle ich mir auch die Frage, ob das Ziel realistisch ist, schließlich leben wir nicht in einer Phantasiewelt. Unrealistische Ziele sind höchst demotivierend, also sollte ich hier nicht irgendeine Zahl nennen, sondern muss die Organisation und die Grenzen des Systems sehr gut kennen, um realistische Ziele formulieren zu können. Im allgemeinen funktioniert das nicht, wenn eine Programmleitung nackte Zahlen betrachtet und einen Prozentwert aufschlägt. Ich muss auch mit den Menschen sprechen, die mein Ziel am Ende umsetzen sollen. Mindestens deren Meinung interessiert mich auch.

Aber zurück zum eigentlichen Messen. Kenne ich mein Ziel, weiß ich, was ich messen will. Oft genug ist die Messmethode dann schon weitestgehend klar. Wenn wir über Stückzahlen sprechen (z.B. auch über die Anzahl bearbeiteter Tickets), kann ich diese einfach zählen. Sprechen wir über Durchlaufzeiten, muss ich nur die Zeit stoppen. Reden wir über Qualität, bin ich oft genug bei Bugs oder Supportanfragen – kann ich ebenfalls ganz einfach zählen.

Ich möchte dahin kommen, Dinge zählen zu können. Je einfacher die Messmethode ist, desto spürbarer sind die Ergebnisse. Ich kann auch die Überstunden meiner Kollegen zählen oder deren Krankheitstage (natürlich nicht individuell, sonst steigt mir der Betriebsrat aufs Dach).

Ganz kurz zusammengefasst: Es ist sinnlos, einen Index auf Agilität zu setzen. Wenn ich etwas messen will, dann messe ich das, was ich mit Agilität erreichen will. Dafür muss ich mir klar machen, dass Agile immer nur ein Mittel zum Zweck ist.

Facebooktwitterredditpinterestlinkedintumblr