Die agile Kolumne

Was hat Dr. House mit Scrum zu tun?

Stefan Roock

Kennen Sie Dr. House? Dr. House ist die Hauptfigur der gleichnamigen TV-Arztserie (dienstags, 21:15 Uhr auf RTL). Zu Dr. House und seinem Team kommen die Patienten, bei denen die klassischen Herangehensweisen der Schulmedizin versagen. Und meistens rettet Dr. House diese Patienten. Er ist medizinisch genial. Er braucht aber sein Team, mit dem er sich auf den ersten Blick jedoch nur streitet. Wenn man genauer hinsieht, helfen diese Streitereien Dr. House aber bei der Reflexion und liefern ihm die Impulse für seine Ideen.

Seine medizinische Genialität ist allerdings nicht ohne seine Macken zu bekommen (Zitat Dr. House: „Menschlichkeit wird überbewertet.“). Dr. House ist medikamentenabhängig, zynisch und respektlos gegenüber Patienten, Freunden, Kollegen und Vorgesetzten („Natürlich nimmt der Patient Drogen. Und natürlich lügt er uns an. Er ist ein Teenager!“). Und natürlich liegt gerade darin der Reiz der Serie begründet. Von dem medizinischen Drumherum verstehe ich nur Bruchteile, aber darum geht es ja auch nicht.

Dr. House

Eine der medizinischen Strategien von House meine ich aber dennoch identifiziert zu haben: Fast immer ist die erste Hypothese über die eigentliche Krankheit falsch oder unvollständig. Die verordnete Therapie macht den Patienten also nicht wieder gesund. Dr. House und sein Team tappen im Dunkeln. Manchmal verschlimmert Dr. House dann die Situation des Patienten absichtlich. Zum Beispiel dadurch, dass er Medikamente wieder absetzt, die etwas Linderung brachten oder indem er Medikamente einsetzt, die ganz sicher die Symptome verschlimmern. Ich weiß nicht, ob sich dieses Vorgehen mit medizinischen Ethikgrundsätzen verträgt, aber im Fernsehen funktioniert es. Der Zustand des Patienten verschlechtert sich rapide, wodurch die eigentliche Ursache seines Krankheitsbildes sichtbar wird. Und so kann Dr. House dann in letzter Minute doch noch die richtige Therapie festlegen und den Patienten retten.

[ header = Seite 2: Perspektivenwechsel ]

Perspektivenwechsel

Auf einer Scrum-Schulung hat mich einmal einer der Teilnehmer gefragt, ob er als Businessanalyst am Daily Scrum teilnehmen dürfe. Nach der obligatorischen „It Depends“-Antwort stellte ich fest, dass wir ausreichend Zeit hatten, uns das Problem genauer anzusehen. Also fragte ich nach den Hintergründen. Es stellte sich heraus, dass die Businessanalysten so weit ins Projektgeschehen involviert waren, dass sie zum Scrum-Team gehören sollten – entweder als Teil des Realisierungsteams oder als Teil des Product-Owner-Teams. In jedem Fall hätte ich sie unter den gegebenen Bedingungen gerne beim Daily Scrum dabei gehabt.

Der Teilnehmer teilte meine Einschätzung und berichtete, dass der Scrum Master ihn aus dem Daily Scrum ausgeschlossen hatte. Die Ursache war, dass er im Daily Scrum für zu viel Unruhe gesorgt hatte. Er hatte nämlich immer wieder Änderungen an den Anforderungen des Sprint Backlog, die noch berücksichtigt werden müssten. Und dieses Durcheinander wollte der Scrum Master im Daily Scrum nicht haben. Nachvollziehbar, aber…

Das Verbannen des Businessanalysten aus dem Daily Scrum schafft Linderung, beseitigt das ursächliche Problem aber nicht. Warum möchte der Businessanalyst, dass während des Sprints Änderungen am Sprint Backlog vorgenommen werden? Warum schafft er es nicht, die Anforderungen bereits zur Sprint-Planung stabil zu haben? Ist er nicht ausreichend ausgebildet, hat er nicht genug Zeit, oder liegt ein strukturelles Problem in der Organisation vor?

Nehmen wir einmal an, der Scrum Master hätte den Businessanalysten nicht aus dem Daily Scrum ausgeschlossen. Dann hätte sich der „Gesundheitszustand“ des Teams wahrscheinlich rapide verschlechtert – die Fieberkurve, die wir Sprint Burndown nennen, hätte das ganz deutlich gezeigt. Dadurch wäre die Chance entstanden, Zeit in die Problemanalyse zu investieren, das ursächliche Problem zu identifizieren und dieses Problem nachhaltig zu beseitigen. Man hätte eine der besonderen Stärken von Scrum ausgenutzt: Scrum deckt Probleme schonungslos auf und macht das Fortbestehen der Probleme fast unerträglich.

Ist Dr. House also ein Scrum Master? Er wendet in den beschriebenen Fällen zwar dasselbe Verfahren an wie Scrum, aber letztlich sollte ein Scrum Master genau das Gegenteil von zynisch, respektlos und medikamentenabhängig sein.

Ich will mit meinem Beispiel die Arbeit des genannten Scrum Masters nicht abwerten. Ich kenne nur den Teil der Geschichte, den der Businessanalyst erzählt hat, und die Handlungsweise des Scrum Masters kann durchaus sinnvoll gewesen sein – um z. B. dem Team zu zeigen, wie sich störungsfreie Arbeit anfühlt. Und auch mit ausgeschlossenen Businessanalysten macht Scrum das Problem sichtbar. Beim Sprint Review wird es offensichtlich. Dort werden die Businessanalysten darauf hinweisen, dass die realisierte Funktionalität nicht wirklich zu den Anforderungen passt. Mittel zur früheren Erkennung/Behebung des Problems können dann vielfältig sein: Vom Schreiben besserer Storys über mehr Vorbereitung und klareres Mitteilen des Zusammenhangs beim Planning-Meeting, kürzeren Sprints bis ihn zum Einbeziehen der Businessanalysten in die Daily Scrums.

Dipl.-Inform. Stefan Roock ist Senior IT-Berater bei der it-agile GmbH in Hamburg. Er verfügt über mehrjährige Erfahrung aus agilen Softwareprojekten (Scrum, XP, FDD) als Coach, Trainer, Projektleiter und Entwickler. Er ist Autor der Bücher „Software entwickeln mit eXtreme Programming“ und „Refactorings in großen Softwareprojekten“.
Geschrieben von
Stefan Roock
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.