Artikel versenden

Dr. Agil, Teil 1: Optimierungschancen durch bessere Diagnostik!




 

// /

Man kennt das Procedere vom Arzt: Patient kommt rein, erzählt „Im Rücken zieht’s, der Kopf tut weh“, beschreibt seine Gebrechen.
Der Arzt, wenn er ein Guter ist, vollzieht daraufhin einen zweifachen Schritt: er findet die Ursache für das Symptom und empfiehlt eine Behandlung, entsprechend auf Patient und Ursache abgestimmt. Wenn er ein besonders Guter ist, bezieht er neben der Symptombeschreibung weitere Faktoren mit ein, wie Alter, Geschlecht und allgemeinen Zustand des Patienten usw.

Nun kommt dieses Procedere ja auch im Arbeitseinsatz gelegentlich mal vor. Gerade bei der Einführung agiler Methoden zeigt sich, nicht zuletzt aufgrund der inhärenten Transparenz, das ein oder andere Wehwehchen, und man tut als Arzt, Coach oder Berater gut daran, die vorschnelle Diagnose zu meiden, um bei der anschließenden Behandlung nicht notgedrungen schludrig zu sein. Vor allem wenn man allzu sehr aufs Lehrbuch pocht, stellt sich nämlich schnell die Neigung ein, mit dem immer gleichen Breitband-Antibiotikum zuzuschlagen, während eine genaue Betrachtung des Patienten wahre Schätze an Optimierungen hätte zutage fördern können. (Denn, wie der geschätzte Kollege Leckzut bereits bei der Betrachtung von Strukturelementen nachgewiesen hat, sollte eine Untersuchung der Situation VOR dem Griff in den Methodenkoffer erfolgen: Komplexitätsbewältigung mit Strukturelementen)

Betrachten wir folgende Fallbeispiele:

1. Die „gelbe Zettel“-Sucht
Beobachtet wird das Zuwuchern des immer wieder aufgeräumten Boards mit gelben Zetteln, in der Fachsprache „PostIts“ genannt. Diese enthalten ungeplante Tätigkeiten, die ungefragt aufpoppen und prompt vom Team bearbeitet werden. Eine erste Analyse bestätigt, dass es sich nicht um Impediments handelt, da sie nicht den ursprünglich geplanten Arbeitsfluss behindern, sondern um tatsächlich eigenständige ToDos, die aus dem Nichts zu kommen scheinen.

In Kanban-Modellen je nach Prozessdefinition vielleicht garnichtmal schlimm, könnte man in Scrum – da nicht sein kann, was nicht sein darf – die Umsetzung dieser Tätigkeiten schlicht untersagen oder mit dem Hinweis auf das nächste Planungsmeeting zu den Akten legen. Keine gute Idee!

Wer die Analogie von oben aufmerksam verfolgt hat, wird feststellen, dass ein wichtiger Schritt bei der Behandlung übersprungen wurde: die Frage nach der Ursache! Woher stammen die ominösen Tickets, die unsere schön priorisierte Welt so böse stören? Handelt es sich vielleicht um Wartungstätigkeiten, die eigentlich von einer internen Servicestelle bearbeitet werden sollten? Sind Zuständigkeiten und Verantwortung für diese Tasks überhaupt eindeutig definiert? Handelt es sich um Tätigkeiten, die bei der Planung schlicht übersehen oder falsch beurteilt wurden? Wurde das Team in diese Prozesse eventuell nicht ausreichend eingebunden? Gibt es Linienaufgaben, die nicht ausreichend abgestimmt sind? Man sieht: die Ursachen können mannigfaltig sein, und die Behandlung ggf. eine echte Verbesserung erzielen!

2. Der ewige Prozess
Auch dies den Medizinern unter uns wahrscheinlich hinlänglich bekannt: eine Aufgabe, wohl definiert und priorisiert und nach Prio auch korrekt einsortiert, wird irgendwann in Angriff genommen und vom Owner in der entsprechenden Spalte platziert. Dort hängt sie dann. Und hängt. Und hängt.

Der Scrum-Doktor erschlägt dieses Phänomen mit der Timebox und empfiehlt stringent: Runterbrechen, in kleinere Aufgaben zerteilen. Dagegen ist grundsätzlich natürlich auch nichts zu sagen, doch sind die Diagnosen „Task zu gross“ und „Aufwand falsch geschätzt“ oft zu einfach, und die Standardbehandlung „Tasks werden kleiner“ und „bitte großzügiger schätzen“ kaschieren oft Probleme, die tiefer liegen. Besitzt die Aufgabe vielleicht Abhängigkeiten zu anderen Teams / Prozessen, die bei der Planung nicht bekannt waren oder falsch eingeschätzt wurden? Sind bei der Erledigung der Aufgabe Probleme aufgetreten, die das Teammitglied in den Statusmeetings aus irgendeinem Grund nicht nennen möchte? Wurde vielleicht aus Unsicherheit ein falscher Lösungsweg eingeschlagen, oder sind die Abnahmekriterien nicht eindeutig definiert? Ist der Task vielleicht in Wirklichkeit „on hold“, da der Owner sich um andere Dinge kümmert (siehe unten) (siehe auch oben)? Die Ursachen für ein solches Phänomen können derart unterschiedlicher Natur sein, dass eine vorschnelle Anpassung der Planungstätigkeiten dem Versuch gleichkommt, mit einem gebrochenen Arm dann eben vom Kugelstoßen auf Fußball umzusteigen.

3. Der Alleskönner
Dieses Phänomen erledigt sich im Laufe der Einführung agiler Methoden, eine gewisse Prozess-Strenge vorausgesetzt, in der Regel von selbst. Zur Phänomenologie: Den Alleskönner erkennt man sehr leicht an der Vielzahl von Tickets, die „in progress“ sind und seinen Namen tragen. Und tatsächlich ist die Prozess-Strenge inkl. entsprechender Maßnahmen zur Maßregelung das naheliegendste Mittel, dieser Unart beizukommen. Inzwischen sehe ich daher große Vorteile darin, bei der Einführung agiler Methoden am Anfang bewusst auf ein allzu strenges Vorgehen zu verzichten. (Die hier beschriebene Diagnostik funktioniert übrigens wunderbar auch „under cover“: Agile undercover) Denn: Was sagt und dieses Verhalten über das Teammitglied, das Team und das System, in dem sie sich befinden? Traut der Alleskönner seinen Kollegen nichts zu? Hat er vielleicht Grund zur Sorge, dass Aufgaben nicht richtig erledigt werden? Fürchtet er die Konsequenzen? Waren in der Vergangenheit Verantwortung und Befugnisse nicht im Gleichgewicht? Dann wird sich das nicht automatisch ändern! Wie sieht es im Team mit der Zielorientierung aus, dem Teamgeist, der daraus entsteht, dem Engagement? Kennt das Team die Ziele, kann es sie nachvollziehen und glaubt an die Möglichkeit ihrer Erfüllung? Welche Konsequenzen hat ein Verfehlen der Ziele (vor allem auch außerhalb der Grenzen des aktuellen Projekts!) für die einzelnen Teammitglieder? Gibt es hier ein Ungleichgewicht, das in Betracht gezogen werden muss?
Man beachte, dass viele der genannten Ursachen garnicht so einfach „ans Tageslicht“ zu bringen sind, vor allem, wenn die Einführung agiler Methoden „von oben verordnet“ wurde und dagegen also nichts gesagt werden darf. Entsprechend verheerend sind die Folgen, wenn man das Problem mit einer vorschnellen Maßnahme einfach erledigt statt löst.

Kennen Sie ähnliche Phänomene und Symptome, die Ihre Schritte in Richtung Agilität und Transparenz begleitet haben? Wenn ja: melden Sie sich! Es würde mich sehr interessieren, wie weit Ihre Ursachenforschung in den einzelnen Fällen ging, und welche Optimierungen dadurch möglich wurden!

Quelle Foto: © Kirill_M – Fotolia.com

| Keine Kommentare

 
Top | Impressum