Artikel

Dr. Agil, Teil 2: Befundkatalog

Beitrag von Udo Loeb
29. Oktober 2012

Nachdem in der letzten Ausgabe unseres Magazins die Phänomenologie der Einführung agiler Methoden für einige Diskussionen sorgte (Dr. Agil, Teil 1), hier eine Fortsetzung. Dazu sei angemerkt, dass diese „unstrukturierte Sammlung“ beobachteter Phänomene natürlich keinen Anspruch auf Vollständigkeit und wissenschaftliche Genauigkeit erhebt. So soll bspw. auf eine ausgefeilte Kategorisierung verzichtet werden, und unklare Abgrenzungen sowie Überschneidungen der geschilderten Krankheitsbilder werden zugunsten einer offenen und unverblümten Erfassung des Sachbestandes bewusst in Kauf genommen. Kommentare und Feedback sind natürlich weiterhin höchst willkommen!

Hier also weitere Befunde, dem geneigten Kollegium in der ein oder anderen Form eventuell bereits bekannt:

1. Der Subtask-creep

Der Subtask-creep ist, im Gegensatz zu anderen Befunden, recht einfach zu erkennen, wenn auch schwer von ähnlichen, eher harmloseren Phänomenen zu unterscheiden. Es handelt sich schlicht um eine Teil-Tätigkeit, aus der sich eine ungeahnte Vielzahl von Problemen und zusätzlicher Arbeit ergibt.

Nun liegt es in der Natur der Subtasks, dass sie nicht so detailliert beschrieben sind wie das Arbeitspaket an sich, dass sie keine dokumentierten Abnahmekriterien besitzen und meist auch nicht mit einem Wert (Storypoints, Aufwand usw.) versehen sind. Außerdem gibt es viele Gründe, warum man sich dabei “verzetteln” kann (im wahrsten Sinne des Wortes). Auf einen “Themenkomplex” möchte ich dabei genauer eingehen: Oft entstehen neue Teil-Tätigkeiten oder explodierende Aufwände durch fehlendes Wissen, mangelnde Qualität oder nicht absehbare fachliche Abhängigkeiten. Dann gilt: Obacht! Spätestens wenn bei einem Subtask eine Diskussion ausbricht, ob die aktuell durchgeführten Tätigkeiten von den Zetteln am Bord noch abgedeckt sind oder nicht, sollte der erfahrene Doktor ganz genau hinschauen!

Gerade wenn bei der Teambildung Domänen-Wissen und Expertentum aufgebrochen wurde, sind solche Probleme, wenn man ehrlich ist, kaum vermeidbar. Erst recht, wenn mit der Bildung von Teams auch die Ownerschaft für Produkte und Komponenten neu organisiert wird. Ebenso einleuchtend ist eben auch, dass einem der SCRUM-Standard an dieser Stelle nicht zwangsläufig weiterhilft, da er ja den „idealen“ Prozess beschreibt – und nicht die Stolpersteine auf dem Weg dahin. Und deshalb, liebe KollegInnen, ist es ungeheur wichtig, auf „kleine“ Symptome wie den subtask creep zu achten und die entsprechenden Prozesse zu steuern. Wenn eine Teilaufgabe zu einer Vielzahl ungeplanter Tätigkeiten führt, so kann dies nämlich bedeuten, dass

der Bearbeiter sich während der Umsetzung in neue Themenkomplexe einarbeiten muss, er
auf Fehler oder Qualitätsprobleme gestoßen ist oder
die Konsequenzen einer Änderungen nicht überschauen konnte.

All dies sind halbwegs normale Erscheinungen, doch achten Sie darauf, dass der Bearbeiter

zu 1. die nötige Unterstützung und den nötigen Austausch bekommt, dass sich

zu 2. keine unüberschaubaren Baustellen auftun (die Früherkennung von Qualitätsproblemen und die Minimierung von Verlusten ist eine Wissenschaft für sich!) und

zu 3. die Abgrenzung der zu bearbeitenden Aufgaben klar definiert und die Zusammenarbeit mit „ehemaligen Ownern“ funktioniert.

Dies sind nur drei Beispiele, die verdeutlichen sollen, wie wichtig die Beachtung „kleiner Zeichen“ ist.

Ein weiteres Phänomen, das gehäuft beim Übergang von Expertentum zu Teamwork auftritt, ist das folgende:

2. The daily off topic

Wenn Teams neu aufgebaut und die ersten täglichen Statusmeetings durchgeführt werden, ist es ganz natürlich, dass das Zusammenspiel mit dem Board oder sonstigen Instrumenten in der Gruppe erst gelernt werden muss. Auch die Ausrichtung der Kommunikation auf relevante Inhalte geschieht in einem Prozess. Dabei kommt es mit erstaunlicher Regelmäßigkeit vor, dass ein oder mehrere Teammitglieder konstant am Thema vorbei berichten bzw. sich der Zusammenhang zwischen dem Bericht und den Zetteln auf dem Board nicht ohne Weiteres erschließt.

Auch hierbei gilt es zu unterscheiden zwischen „harmlosen“ Symptomen wie den Gern- und Viel-Rednern und solchen, bei denen tatsächlich ein Grund für die Einforderung von Aufmerksamkeit besteht. Denn was sagt uns die Person denn eigentlich genau? Berichtet sie von Input, der aus anderen Teams oder von Experten kam? Hat sie sich mit externen Stellen besprochen oder sonstige Informationsquellen konsultiert? Wurde sie vielleicht selbst von außerhalb des Teams in Beschlag genommen? Befindet sie sich in vermeintlich unstrukturiertem Austausch mit verschiedenen anderen Bereichen und Parteien, für die vielleicht der Output dieses oder des nächsten (oder übernächsten) Sprints relevant sein wird?

Dann lohnt es sich wahrscheinlich, der Sache nachzugehen! Wahrscheinlich gibt es ernst zu nehmende Gründe für die Unsicherheit, denn vielleicht ist tatsächlich nicht klar, wie das Zusammenspiel mit anderen Stakeholdern, Experten, wie die Integration der gelieferten Pakte mit den neuen, agilen Methoden funktioniert. SCRUM bzw. ein agiles Vorgehen allein garantiert keinesfalls eine gute Abstimmung zwischen Teams und eine gute Zusammenarbeit der unterschiedlichen Unternehmensteile, die bei der Fertigstellung, Konfiguration und Verifizierung eines Produkt notwendig ist.

Stellt der Kollege vielleicht zwischen den Zeilen die Sinnhaftigkeit der geplanten Aufgaben in Frage? Dann kann das, so unschön es vielleicht durch die Prozessbrille aussehen mag, durchaus gerechtfertigt sein. Denn natürlich ergibt sich der Sinn einer Aufgabe sowie die „Schönheit“ einer Lösung nur aus dem größeren Zusammenhang, und damit ist gar nicht mal der große Business Case gemeint: auch die Umsetzung einer verhältnismäßig kleinen Systemkomponente kann gut oder schlecht geplant und konzipiert sein in Abhängigkeit von anderen Komponenten und der künftigen Entwicklung und Verwendung des Gesamtsystems. Hier müssen Fragen und das Einfordern von Informationen erlaubt sein und beantwortet werden. Und auch wenn das natürlich nicht sinnvoll im daily status meeting geschehen kann, poppen dort nunmal die geschilderten Symptome als erstes auf.

Und wird der Kollege von anderen Teams und Stellen in Anspruch genommen und berichtet off topic davon, so muss auch dies gesteuert und in der Planung berücksichtigt werden.

Wir sehen also wieder einmal: Augen auf bei der Einführung von SCRUM!

Weitere Beiträge zum Thema finden Sie unter Agilität. Und Teil 3 meines Befundkataloges ist bereits in Arbeit. Über Anregungen und Kommentare freue ich mich.

| Keine Kommentare