Der hyperbolische Thread-Koeffizient – über Wirkungsgrad von Managern in agilen Organisationen

Ich kenne viele Manager, die KPIs lieben. Je mehr Faktoren auf eine Zahl reduziert werden, umso besser ist der KPI.

Nachdem ich mich in letzter Zeit häufiger im Umfeld der Organisationsentwicklung tummeln durfte, kam ich auf die Idee, doch einen KPI zu nutzen, um den Wirkungsgrad von Managern zu messen. Der Hintergrund meiner Überlegungen war, dass ich regelmäßig mit Managern sprechen muss, wenn eine Veränderung der Organisation notwendig ist. Manchmal muss ich dafür sehr lange auf einen Termin bei so einem Manager warten, was natürlich besonders in Organisationen, die gerne agil werden oder sein wollen, problematisch ist. Eventuell hat das Problem die Organisation schon überholt, wenn ich den Termin bekommen habe.

Hoher HTK

Ein hoher Hyperbolischer Thread-Koeffizient bedeutet eine geringe Wirksamkeit.

Nach einigem Nachdenken und der Lektüre von Gunter Duecks Meisterwerk Schwarmdumm bin ich dann zum Schluss gekommen, dass dieser Wirkungsgrad mit der Warteschlangentheorie zusammen hängt. Ein Manager, der eine kurze Queue und damit viel freie Zeit hat, ist wirksamer, als ein Manager, der eine lange Queue hat. Auf letzteren muss ich warten, wenn ich ein Anliegen habe, das reduziert seine Wirksamkeit. Der Wirkungsgrad von ersterem ist höher, weil er zeitnah reagieren kann.

Aber wie kann man das jetzt messen? Ich habe mich an meine eigene Zeit als Geschäftsführer erinnert und diese mit meinen Beobachtung vieler Manager verglichen. Dann kam mir die Idee: die ideale Quelle zur Berechnung der Wirksamkeit eines Managers ist sein Outlook-Kalender.

Ich habe mir dazu folgende Formel überlegt:
Die Wirksamkeit eines Managers verhält sich umgekehr proportional zu seinem Hyperbolischen Thread-Koeffizient [1]. Der HTK berechnet sich aus dem Median der Anzahl der Termine im Outlook pro Woche hoch dem Maximum der parallelen Termine innerhalb eines Kalenderjahres.

Die Wirksamkeit ist dann: \eta = \frac{1}{HTK} bzw. \eta = \frac{1}{MOT^{MPT}}

Wobei gilt:
MOT = med(Anzahl\ der\ Termine\ im\ Outlook\ pro\ Woche) und MPT = max(Gleichzeitig\ parallele\ Termine\ innerhalb\ eines\ Kalenderjahres)

Niedriger HTK

Ein niedriger Hyperbolischer Thread-Koeffizient bedeutet einen hohen Wirkungsgrad.

Damit hat jetzt jeder Manager einen persönlichen KPI zur Bewertung der eigenen Leistung! Und ich habe ihn erfunden.

[1] Der Begriff Hyperbolischer Thread-Koeffizient setzt sich aus mehreren wichtigen wissenschaftlichen Komponenten zusammen. Thread leitet sich aus der Tatsache ab, dass die Anzahl der parallelen Aktivitäten eine wichtige Rolle bei der Berechnung spielen. Hyperbolisch ist der Koeffizient, weil er zeigt, wie stark der oder die Betreffende es mit der eigenen Wirksamkeit übertreibt.

Planning Pattern II – Test Driven Sprint Planning

Im ersten Teil dieser Reihe habe ich erklärt, wie ein Team im Sprint Planning dafür sorgt, dass während des Sprints ein Flow entsteht. Diesmal möchte ich darauf eingehen, wie die Struktur auf dem Scrum Board den Verlauf des Sprints beeinflusst und wie man im Sprint Planning darauf Einfluss nehmen kann.

Auch wenn Scrum Teams in der Regel cross functional sind, ist es doch weit verbreitet, dass es eine Aufteilung der Rollen zwischen Testern und Entwicklern gibt. Für viele Teams ist das auch völlig in Ordnung, wenn die Zusammenarbeit klappt. Bei einem Team, für das ich als ScrumMaster arbeiten konnte, hatte ich die Gelegenheit, mit dieser Zusammenarbeit zu experimentieren und mit dem Team gemeinsam das entwickelt, was wir später als Test Driven Sprint Planning bezeichnet haben.

Generische Test Tasks

Generische Test Tasks

Zunächst verliefen die Plannings in diesem Team so wie ich es auch schon von anderen Teams kannte: Der Product Owner präsentierte seine Storys, die Entwickler schnitten Tasks und am Ende klebten die Tester drei Zettel ans Board auf denen stand: „Test Design“, „Test Automation“, „Test Execution“. Solche generischen Tasks sind natürlich wenig hilfreich, wenn man einen guten Flow im Sprint haben möchte und sie geben auch kein Gefühl dafür, was schon erreicht wurde und was noch fehlt.

Im Laufe der Zeit gelang es uns, das Planning umzudrehen. Nachdem der Product Owner seine Storys präsentiert hatte, übernahmen die Tester die Führung des Plannings. Anhand der Akzeptanzkriterien entwickelten sie Testideen. Das waren grobe Beschreibungen eines Tests, die auf die gleichen Post-Its passten, wie die Tasks.

Scrum Board mit Testideen

Scrum Board mit Testideen

Die Testideen klebten wir neben die Storys untereinander und überlegten dann, welche konkreten Tests sich daraus ergeben würden – und was implementiert werden müsste, damit der Test grün würde. Damit erarbeiteten Tester und Entwickler gemeinsam eine Reihe von Aufgaben zu jeder der Testideen, die dann in eine Zeile neben jede Testidee passten. Das Scrum Board entwickelte ganz von selbst eine sehr übersichtliche Struktur, die es erlaubte, Fortschritt im Sprint und auch Probleme während des Tests für alle im Team extrem gut sichtbar zu machen.

Diese Erkenntnis lieferte uns dann das zweite Planning Pattern:

Entwickle aus den Akzeptanzkriterien Testideen und überlasse die Führung des Sprint Plannings den Testern. Entwickler machen die Tests grün.

Der Ansatz hat nicht nur auf dem Scrum Board zu einer Veränderung geführt. Auch während des Sprints lief die Zusammenarbeit besser. Die Idee des Test Driven Development funktioniert also nicht nur mit Unit Tests, sondern lässt sich auch auf anderen Abstraktionsebenen anwenden.

Dieser Artikel erschien zuerst im adesso Blog.

Planning Pattern I – Planen für den Flow

In dieser Artikelreihe möchte ich einige Pattern vorstellen, die agilen Teams helfen können, die Ergebnisse ihrer Sprint Plannings zu optimieren. Die meisten der Pattern sind bei der Arbeit mit Scrum Teams entstanden, sie lassen sich aber auch gut für Extreme Programming oder Kanban adaptieren.

20 Tasks am Board

20 Tasks am Board

Vor einigen Jahren kam ich als neuer Scrum Master zu einem Team, das schon eine geraume Weile zusammenarbeitete. Das Team arbeitete mit 2-Wochen-Sprints, hatte ein dreispaltiges Scrum Board, also auf den ersten Blick nichts außergewöhnliches. Allerdings hatte das Team in den letzten drei Sprints sein Commitment nicht geschafft. Was mich erstaunte, denn Aufgaben erschienen mir durchaus im Bereich des Machbaren und das Team war fit.

Als neuer Scrum Master halte ich mich immer erst mal mit Kommentaren zurück und beobachte viel. Beim Sprint Planning war ich dann erstaunt, dass das Team fast einen ganzen Tag dafür aufwendete und am Ende lediglich 20 Tasks am Scrum Board klebten. Ich fragte das Team also, ob sie sich sicher seien, dass das so ok war. Das Team meinte, ja, das wäre OK so. Es kam, wie es kommen musste – der Sprint lief schief, weil sich die Teammitglieder die ganze Zeit nur gegenseitig auf den Füßen standen und Tasks ewig „In Progress“ waren.

In einer Retrospektive konfrontierte ich das Team mit der Idee, dass ein Task nicht länger als einen Tag dauern sollte. Diese Idee kommt ja nicht von ungefähr, sie ist der Garant für einen guten Flow während des Sprints. Wir diskutierten eine ganze Weile darüber und schließlich kam eine recht interessante Betrachtung dabei heraus:

  • 1 Task <= 1 Tag
  • 1 Sprint = 10 Tage
  • 1 Team = 7 Personen
  • 1 Person benötigt =10 Tasks (folgt aus (1) & (2))
  • 7 Personen benötigen =70 Tasks (folgt aus (3) & (4))

Eines der Teammitglieder war Physiker und konnte das auf diese Weise kompakt zusammenfassen. Ein Team mit sieben Personen benötigt für einen 2-Wochen-Sprint mit 10 Arbeitstagen mindestens 70 Tasks am Scrum Board, um sicherzustellen, dass ein Task nicht mehr als einen Tag in Anspruch nimmt.

Diese Erkenntnis ist auch bereits das erste Planning Pattern:

Schneide die Tasks so, dass ihre Anzahl mindestens der Anzahl der Arbeitstage im Sprint multipliziert mit der Anzahl der Teammitglieder entspricht.

200 Tasks am Board

200 Tasks am Board

Das Team nahm die Herausforderung an und beim nächsten Planning befanden sich statt 20 plötzlich fast 200 Tasks auf dem Scrum Board. Nach einer Weile hat sich die Menge der Tasks auf 90 bis 120 Tasks pro Sprint eingependelt. Die kleinen Aufgaben führten zu einer sehr entspannten und kontinuierlichen Abarbeitung während des Sprints – das Team hatte seinen Flow gefunden. Ein angenehmer Nebeneffekt war, dass das Sprint Planning sich drastisch verkürzte.

Dieser Artikel erschien zuerst im adesso Blog.

Doch, das geht schon so. Eine Lanze für agile Job-Titel.

Im Laufe der Woche kam ein Artikel von Patrick Koglin in meinem Newsreader reingeflogen. Patrick beschreibt die Verwendung von Bezeichnungen wie Senior Scrum Master oder Junior Scrum Master als schlimm. Ich lese Patricks Artikel gern und teile seine Meinung häufig, aber in diesem Fall muss ich vehement mein Veto einlegen.

Zunächst der Aspekt, in dem ich dem Artikel zustimme: Nur, weil ein Board im Raum steht, bin ich nicht agil. Agil ist eben nicht Cargo Cult, sondern eine echte Kultur, ein Mindset. Ebenso denke ich, dass in einem agilen Team einem jungen Entwickler ebenso zugehört werden muss, wie der erfahrenen Kollegin und beide auf Augenhöhe zusammenarbeiten sollten. Gleiches gilt für Scrum Master, Product Owner und jeden Manager. Sowohl innerhalb eines Teams als auch in der Umwelt.

Dafür muss ich aber nicht agil sein, das ist schlicht und einfach der Respekt vor anderen Menschen, der diese Sichtweise gebietet.

Der Aspekt, bei dem ich grundlegend anderer Meinung bin, ist, dass es keine Senior oder Junior Scrum Master als Job-Bezeichnung geben darf. Ich bin der Meinung, dass so etwas völlig ok ist und viele Organisationen es sogar unbedingt benötigen. Ich zitiere gerne Tucholsky mit  “Erfahrung bedeutet nichts, man kann eine Sache auch dreißig Jahre lang schlecht machen.” Für mich bedeutet das, dass Bezeichnungen wie Senior nicht an das Dienstalter gekoppelt sein dürfen.

Menschen orientieren sich an solchen Bezeichnungen, sie sind Teil der Struktur einer Organisation. Wenn ich dieses Argument aus dem Hut ziehe, kommt meistens das Gegenargument, dass in solchen Organisationen die Kultur kaputt sei. Und das ist  in meinen Augen schlimm.

Ich finde es völlig ok, zwischen Junior und Senior Scrum Mastern zu unterscheiden. Der Junior Scrum Master ist einer, dem ich helfe, großartig zu werden. Der Mensch ist es schon, der Scrum Master muss einiges erleben. Und damit der Scrum Master das kann, bekommt er Unterstützung von einem Senior, der schon war, wo der Junior noch hin will. So einfach ist das.

Und ja, ich finde es absolut gerechtfertigt, wenn jemand stolz darauf ist, ein Senior Scrum Master zu sein und sich diese Bezeichnung verdient hat, indem er ganz viele Teams großartig gemacht hat und jede Menge unerfahrene Scrum Master an seinem Wissen und Können hat teilhaben lassen. Das ist Agilität.
Die Ablehnung von Job-Titeln aus Prinzip ist hingegen Cargo Cult.

User Experience – ein cooles Thema

Ein Geschichte, wie sie jeden Tag passieren kann, wenn man als Consultant unterwegs ist: Mitten in der Nacht kommt man von einer langen Zugfahrt müde in sein Hotel. Vorher noch zehn Minuten durch den Regen gelaufen, ist man pitschnass. Der Checkin verläuft zäh wie üblich und dann erreicht man schlussendlich doch sein Zimmer.

Nur, dass es da tierisch kalt ist. Zum Zähneklappern kalt. Aber es ist zu spät, um mit der Rezeption zu diskutieren, also ab ins Bett, die zweite Decke drüber gezogen und Augen zu.

Nächster Tag. Nachfragen an der Rezeption, es ist kalt im Zimmer. Die Antwort ist nicht sonderlich befriedigend. Das sei normal, sagt man dort, denn die Heizung heizt nicht mehr sondern kühlt. Da es um diese Jahreszeit eigentlich warm sei, wäre das auch in Ordnung so. Und es ist kompliziert die Heizung umzustellen.

Was hat das mit User Experience zu tun? Ganz einfach: diese Heizungsanlage ist ein Beispiel für eine miserable User Experience. Vermutlich, weil hier der zentrale User bei der Erstellung gar keine Rolle gespielt hat. Der wichtigste User einer Heizung in einem Hotel ist der Gast. Und als Gast wünscht man sich, dass die Heizung heizt, wenn es draußen kalt ist. Und dass sie kühlt, wenn es draußen warm ist. Warmes und kaltes Wetter richten sich aber nicht nach dem Kalender. Wetter passiert einfach.
Der Hausmeister ist, auch wenn das vielleicht naheliegend ist, nicht der zentrale User der Heizungsanlage. Er bedient sie, aber das macht nur einen geringen Teil der Nutzung aus. Für ihn ist es bequem, dass die Heizung sich nach dem Kalender richtet, da muss er sich nicht darum kümmern. Für die Gäste ist es unbequem.

Was kann man aus dieser Erfahrung lernen? Ganz einfach: Es ist wichtig, die zentralen User eines Systems zu erkennen, auch wenn sie auf den ersten Blick nur passive Rollen spielen. Wenn deren User Experience miserabel ist, führt das zu Ablehnung des gesamten Systems. So auch heute früh an der Rezeption. Es haben sich viele Gäste beschwert.Man hätte auch eine Heizung mit Temperatursensor einbauen können. Aber davon hätte der Hausmeister nix gehabt.

Bertrand Meyer: Agile! The Good, the Hype and the Ugly

Bertrand Meyer: Agile! The Good, the Hype and the Ugly

Bertrand Meyer: Agile! The Good, the Hype and the Ugly

Das erste Buch, dass sich objektiv und neutral mit Agilität auseinandersetzt, ist mir natürlich eine ebenso objektive und neutrale Rezension wert – und ich werde sie inkrementell verfassen.

Nachdem ich in einem Kommentar zu einem infoQ-Artikel geschrieben habe, dass ich eine Rezension verfassen würde, bin ich gerade dabei das Buch zu lesen.

Eigentlich habe ich Bertrand Meyer immer geschätzt, seine Bücher über Objektorientierte Softwareentwicklung haben mich im Studium begleitet. Er gehörte zu den Großen.

Jetzt habe ich das erste Kapitel gelesen und muss feststellen: Meyer demontiert sich in unerhörtem Ausmaß selbst. Nicht nur, dass schon in der Einleitung deutlich wird, dass er die Grundlagen agiler Methoden nicht verstanden hat, er definiert vielmehr in einer Auflistung diverser Praktiken aus dem agilen Umfeld alles als “gut”, das seiner Meinung nach nicht aus der agilen Community entstammt und alles als “schlecht”, das seiner Meinung eben aus dieser Community kommt.

Dabei interessiert ihn nicht, ob die betreffende Praktik sich irgendwo bewährt hat (User Story) oder tatsächlich von Agilisten zuerst beschrieben wurde (Continuous Integration). Ersteres ist schlecht, weil das eben so ist, letzteres ist nicht neu, weil es gut ist und es damit nicht agile sein kann.

Ich bin jetzt erst mit dem ersten Kapitel durch und über alle Maßen enttäuscht. Ich lese in diesem Buch vor allem Frust, aber wenig Sachlichkeit.

Continue reading

Ulf Brandes, Pascal Gemmer, Holger Koschek & Lydia Schültken: Management Y

Ulf Brandes, Pascal Gemmer, Holger Koschek & Lydia Schültken: Management Y

Ulf Brandes, Pascal Gemmer, Holger Koschek & Lydia Schültken: Management Y

Allen, die als Nicht-ITler ins Thema Agilität und vor allem Führung im agilen Kontext einsteigen wollen, sei dieses Buch wärmstens empfohlen. Wer – wie ich – schon länger mit diesen Themen unterwegs ist, wird allerdings wenig neues entdecken.

Der Aufbau des Buches erinnerte mich sehr stark an Fearless Change. Zunächst wird im Teil Mehr Menschlichkeit im Management! die grundlegende Motivation für das Buch erklärt. Die von den Autoren vertretenen Ansichten teile ich auch – bis auf die Tatsache, dass Taylor unverdient mal wieder viel zu schlecht wegkommt.

Im zweiten Teil des Buches wird Management Y aus vier Sichten beschrieben: Organisation gemeinsam erleben, Liefern, was gebraucht wird, Menschen ehrlich begeistern und Kunden wirklich verstehen.Der zweite Teil ist eine Runde Sache und für Einsteiger super. Alle vier Blickwinkel werden kompakt beschrieben und moderne Wege gezeigt, sich ihnen zu stellen. Einziges Manko ist, dass bestimmte Modelle sehr stark im Fokus stehen – vielleicht weil sie den Vorlieben der Autoren entsprechen.

Mit insgesamt 24 Pattern ist der dritte Teil sehr hilfreich, wenn man sich in der Welt agiler Praktiken orientieren will. Wer regelmäßig in der Community unterwegs ist, Blogs liest oder schon andere Bücher zum Thema kennt, wird aber nur schwerlich etwas Neues finden.

Der Ausblick am Schluss ist für mich persönlich etwas zu esoterisch. Ich mache zwar regelmäßig Yoga und meditiere auch sehr gerne – aber das passt nicht zu einem Buch, dass das Wort Management im Titel trägt.

Der Titel ist auch das, was ich an dem Buch im Wesentlichen kritisieren muss. Ich bin ein großer Verfechter des Management 3.0 und empfand das Buch von Jurgen Appelo als einen Meilenstein der Management-Literatur. Management Y hat mit Management …wenig zu tun. Es ist eher eine Ideensammlung und ein Startpunkt für Menschen, die sich mit dem Thema Agilität auseinandersetzen wollen. Wer sich mit Führung – oder Management – in agilen Organisationen auseinandersetzen will, kommt nach wie vor an Appelo nicht vorbei.

Mein Fazit: Das Buch ist super. Für mich persönlich war es viel zu flach. Aber ich bin auch nicht die Zielgruppe. Es gibt dennoch vier Sterne bei Goodreads, weil die Zusammenstellung im Buch für Einsteiger richtig Klasse ist – und die sind mit Sicherheit auch die Zielgruppe :-)

Vertraue der Macht – Schätzen ohne Bezugssystem

Ein große Herausforderung für Teams in neuen Projekten ist die initiale Schätzung der anstehenden Aufgaben. Selbst wenn man eine abstrakte Einheit wie Story Points zur Bewertung der Größe von Aufgaben heranzieht, ist die erste Schätzung alles andere als trivial. Ich habe festgestellt, dass gerade Planning Poker für die erste Schätzung nur sehr eingeschränkt geeignet ist.

Planning Poker ist eine gute Methode, um Schätzungen für Aufgaben zu ermitteln, wenn in den Domänen und Technologien bereits Wissen vorhanden ist. Gerade am Anfang eines Projektes gibt es aber genau dieses Wissen oft nicht und Teams tun sich schwer, diese Schätzungen für einzelne Items abzugeben. In solchen Situationen hat es sich bewährt, Aufgaben nur relativ zueinander zu schätzen und das Bezugssystem erst im Nachhinein festzulegen. Da Story Points eine abstrakte Einheit sind, die nicht mit einem festen Faktor in andere Einheiten umgerechnet werden kann, ist das problemlos möglich.
Continue reading

Back to COBOL – natürlich mit Unit Tests

Ich hätte nie gedacht, dass ich mich nach über 10 Jahren noch einmal mit COBOL beschäftigen würde. Aber nun habe ich ein Team, das mit COBOL arbeitet und Scrum machen soll.

Nun sind COBOL und Scrum zwei Dinge, die die meisten Menschen, die ich so kenne, nicht oft in einem Satz verwenden. Das soll aber kein Grund sein, sich nicht mit der Materie zu beschäftigen. Letztes Wochenende habe ich OpenCOBOL – neuerdings GNU-Cobol – via homebrew auf dem Mac verfügbar gemacht.

Das war aber nur der erste Schritt, denn mein eigentliches Ziel war die Grundvoraussetzung für agile Software-Entwicklung mit COBOL zu nutzen. Na? Genau: Unit Tests! Mit CobolUnit gibt es dafür auch ein Framework, das aber schon seit einer Weile nicht maintained wird. Die letzten Commits sind von 2009, das versprach ein Abenteuer.
Und das wurde es dann auch. Ich habe mich von Fehlermeldungen wie
error: indirect goto in function with no address-of-label expressions
zu
ld: can't link with bundle (MH_BUNDLE) only dylibs (MH_DYLIB) file '/Users/gbeine/GitHub/gbeine/COBOLUnit/COBOLUnitLib/lib/libCobolUnit.dylib' for architecture x86_64
durchgearbeitet.

Am Ende ist es mir gelungen, CobolUnit mit GNU-Cobol in der Version 1.1 und dem GCC 4.9.1 zum Laufen zu bringen. Das Resultat schaut recht erfreulich aus:

|--- Suite1
| Test 'CTU0S1T1 * SUCCESS * (006 Assertions, 000 Failures. 000 errors)
| Test 'CTU0S1T2 * SUCCESS * (006 Assertions, 000 Failures. 000 errors)
|--- SUCCESS

|--- Suite2
| Test 'CTU0S2T1 * SUCCESS * (008 Assertions, 000 Failures. 000 errors)
|--- SUCCESS

********************************************************************
* SUCCESS *
* (003 test cases, 003 success, 000 failures, 000 errors) *
********************************************************************
(00 min:00 sec:01 ms)

Meine Änderungen dazu habe ich – natürlich – auf GitHub zur Verfügung gestellt. Nur für den Fall, dass das außer mir noch irgendwo auf der Welt irgendjemand nutzen möchte…

Einheit Story Points?

Nach der Frage um den Sinn des Schätzens und den Storys der Größe 1 drehte sich die dritte Frage, die ich auf der Agile World diskutieren durfte, war ob Schätzgrößen Einheiten haben oder nicht.

Mike Cohn schreibt in seinem Blog, dass die Größe von Backlog Items eine nicht spezifizierte Funktion aus Risiko, Aufwand und Unsicherheit ist. In einem anderen Artikel schreibt er, dass es einen Zusammenhang zwischen Aufwand und Größe einer User Story gibt.
Continue reading