Drücken Sie Enter, um das Ergebnis zu sehen oder Esc um abzubrechen.

Das geheime Leben der Checklisten

Braucht man eine Checkliste für Scrum? Ist Scrum nicht so simpel, dass man sich die paar Meetings, Artefakte und Rollen nicht einfach merken kann?

Auf den ersten Blick braucht man bestimmt keine Checkliste für diesen Prozess. Doch wie ist das in großen Projekten, wenn man Scrum skalieren will? Wäre es dann nicht gut, wenn alle Scrum immer auf die gleiche Art erledigen würden und damit ein Standard entstehen würde? Bei meinen ersten Ideen zu Checklisten war genau das die Motivation. Wir wollten erreichen, dass wirklich alle wissen, wie man Scrum erfolgreich einsetzen kann. Im Laufe der Jahre haben sich aber auch immer wieder Kollegen gemeldet, die sagten:

  • „Das schränkt meine Freiheit ein!“
  • „Da fehlt ein wichtiger Schritt.“
  • „Das Team soll doch entscheiden, wie Scrum gelebt wird, nicht eine doofe Checkliste.“

Natürlich haben diese Widerstände ihren Sinn und sie weisen darauf hin, dass Checklisten nicht perfekt sind. Doch sie erfüllten ihren Zweck und deshalb gibt es sie heute noch so wie vor ein paar Jahren. Aber was macht man mit den Leuten, die einerseits recht haben, doch andererseits etwas übersehen? Die Welt wird immer komplexer, die Projekte immer größer und die Anforderungen an die ScrumMaster und Teammitglieder immer ausgefeilter. Heute reicht es nicht mehr, ein Scrum-Team zu koordinieren. Heute sollen viele Teams an unterschiedlichen Standorten mit unterschiedlichen Spezialisierungen zusammenarbeiten – und sich standortübergreifend verständigen und verstehen. Könnten dabei nicht vielleicht doch wieder Checklisten helfen? Wer nutzt denn eigentlich Checklisten?

Checkliste checked, Patient lebt

Bei diesem Gedanken bin ich zufällig auf das sehr lesenswerte Buch  „The Checklist Manifesto“ von Atul Gawande gestoßen und habe mir anschließend eine Checkliste der WHO angesehen: die „Surgical Safety Checklist“. (Die Ärztekammer Wien hat eine wunderbare Interpretation dieser Checkliste und ihrer Geschichte verfasst, sie hier)

Atul Gawande stand im Operationssaal und hatte exakt die gleichen Probleme wie wir bei unseren Scrum-Teams. Die Mitglieder des Operationsteams wechselten von Operation zu Operation und hatten oft noch nie gemeinsam gearbeitet. Jedes Teammitglied war ein absoluter Spezialist, Gawande nennt das Hyperspezialisierung: Ärzte leben eine Kultur, in der jeder Arzt für sich den Meister-Status hat. Er macht keine Fehler und weiß alles. Doch Gawande war aufgefallen, dass in unserem neuen medizinischen Zeitalter die Spezialisierungen und die Anzahl der Operationen mit ihren Millionen von Varianten so umfangreich geworden sind, dass ein Mensch gar nicht mehr alles wissen, geschweige denn alles richtig machen kann. Gawandes einfache Idee war es, mit Hilfe von Checklisten – wie auch Piloten sie verwenden – die Zahl der Todesfälle in Krankenhäusern zu reduzieren. Der Durchbruch gelang ihm viele Jahre später mit der oben genannten Surgical Safety Checklist. „Nach Implementierung der Checkliste fiel die Rate schwerer Komplikationen von 11% auf 7%, die Mortalitätsrate großer Operationen von 1,5% auf 0,8%.“ (Ärztekammer Wien)

Teamspirit durch Abhaken

Das Erstaunlichste jedoch ist, dass diese Checkliste nicht als mechanisches Instrument zu verstehen ist, das nur heruntergelesen wird und alle nicken dazu. In Wahrheit dient sie dazu, im Operationssaal ein Teamgefühl zu etablieren – aus Fremden macht sie in Minuten ein engagiertes Team. In seinem Buch beschreibt Gewande diesen Umstand sehr deutlich: Es gehe nicht um das gedankenlose Ausführen von To Do’s auf der Checkliste. Die eigentliche Stärke der Checkliste liege darin, dass durch das Fragen ein soziales System entsteht, in dem sich jeder einbringen kann und sofort seine Rolle versteht.

Laut Gawande haben Checklisten zwei Funktionen:

  1. Die Checklisten verhindern, dass wichtige wiederkehrende Dinge vergessen werden.
  2. Sie dienen dazu, das Chaos zu reduzieren, indem sie das Team zum Innehalten zwingen, um darüber nachzudenken, ob es Besonderheiten gibt.

Letzteres ist der eigentlich wichtige Fall: Die Routineaufgaben sind den meisten bekannt und hier werden nur Flüchtigkeitsfehler gemacht. Doch was, wenn etwas nicht so ist, wie es sein sollte? Läuft etwas im OP nicht wie geplant, macht die Checkliste darauf aufmerksam, dass man nun in den „Emergency Modus“ gehen und miteinander reden muss. Auf diese Weise entstehen Checklisten 2. Ordnung. Die Checkliste wird zu einem Rahmenwerk und nicht mehr zu einer To-Do-Liste.

Legt man diesen Gedanken auf unsere Scrum-Checklisten für die Arbeit mit großen Teams um, bedeutet das für mich: Vielleicht können wir den Scrum-Teams in Zukunft noch besser helfen, wenn die Checklisten als Checklisten 2. Ordnung verstanden werden und wir sie vielleicht sogar mit den Teams erstellen. So können sich Teams noch besser koordinieren und die wichtigsten Probleme schneller erkennen. Gerade in großen Projekten wird das sicher zunehmend wichtiger werden.

Vielleicht habt ihr ja eine Idee für eine solche Checkliste und wollt sie mit uns teilen?

  • Auf einer Skala von 1 bis 10 für Nützliches für Teams würde ich ein Computerprogramm, welches ein Team benutzt (z.B. JIRA) auf 1 einstufen, ein Kochrezept (für das Mittagessen) bei drei und eine gute Checklist bei 10 einordnen.

    Warum ist dem so?

    Ein Computerprogramm basiert auf einen Algorithmus, der am Ende immer das als Ergebnis hat was vorher in ihm hinein codiert wurde. Das nennt man dann deterministisch, d.h. dass es sich am Vormittag nicht anders verhält als am Nachmittag – ein und er selbe input kommt immer zum selben Ergebnis und das ebenso unabhängig von den mit ihm hantierenden handelnden Personen die es bedienen. Es ist im Grunde letztlich auf eine Tabelle zurückgeführt – erfunden 1936 von Alan Turing, die Theorie dahinter die universelle (Turing)Maschine. Davon agbeleitet erfande er die universelle Turingmaschine, die jedes Programm berechnet. Besonder wichtig: Berechnen in diesem Kontext heißt ausführen!!! Das ist im Grunde bei jedem Computer heute noch so. Algorithmen nennt man das, Eingabe, Abarbeitungsvorschriefentabelle und Ausgabe, thats it. Die Abarbeitungsvorschriftentabelle ist fest und abstrahiert in modernen Computersprachen wie Java abgebildet und wird vom sogenannten Prozessor Schritt für Schritt abgearbeitet.

    Von diesem Standpunkt aus sind Computerprogramme per se dumm (auf der Skala bei 1). Auch wenn es sich um künstliche Intelligenz oder neuronale Netze handelt die das vorgaukeln. Jedes Programm ist letztlich für einen Zweck geschaffen. Der Zweck ist dem Programm immanent.

    Aber wie das Programm zustande gekommen ist wird dabei meist nicht mit in die Diskussionen eingebracht. Auf der Implementierungsebene hat es zB 2 Jahre gedauert bis ein Team das Programm entwickelte. Letztlich führt es allerdings bei gleichen Eingaben immer zu gleichen Ausgaben. Wenn das Programm da ist, dann kann die Zeit die zum Berechnen dauert mit 0 angegeben werden, weil es nur von der Ausführungsgeschwindigkeit des Rechners abhängt. Mit anderen Worten: Man weiss im Vorhinein immer schon was rauskommen wird, nur sind wir dessen nicht immer bewusst. (Deshalb sind wir nur mit online lernen in einer Wissensabwärtsspirale, weil nichts neues gelernt wird)

    Soviel zur Vorgeschichte.

    Interessant ist aber auch, wie das Ergebnis zustande gekommen ist. Mit Ergebnis meine ich im obigen Fall das Computerprogramm. Das zustande kommen, das ist das was Teams machen – das nimmt NIE den Lauf einer Berechnung, sondern IST IMMMER eine Frage des Aushandelns vieler Personen.

    Es ist also ein Unterschied wie ein Algorithmus zustande kommt und dem Algorithmus selbst und noch einmal ein Unterschied in der Anwendung des dessen. Die Anwendung ist eine Rückinterpretation des Ergebnisses auf die Welt.

    Weiters interessant, das beim Auftrag ans Team es viele Interessentengruppen gibt. Auftraggeber, Team, Kunde, Anwender.

    Nun zur Checklist

    Im Grunde ist die Checklist auch eine Handlungsanleitung, zumindest eine Hilfe dazu: Schau in ihr nach, ob das was du gerade siehst mit dem Übereinstimmt was in der Liste steht. Wir haben wieder genau die selbe Fragestellung: Wer ist hier der Auftraggeber wer der Kunde, usw.

    ADAPTIVE CHECKLISTEN:

    Betrachten wir zuerst die Beispiele von Checklisten die meist das Team selbst aufstellt und die von diesem auch verwendet werden – die adaptiven. Ich nenne sie deshalb so, weil sie von denen die sie verwenden selbt aufgestellt, adaptiert und reflektiert werden.

    ZB die Definition of Done (DoD) für eine User Story, oder die DoD für einen Sprint oder ein Release. Hier wird definiert, welche Qualitätskriterien welches Inkrement haben muss um als fertig bezeichnet werden zu können.
    Was ist hier der interessante Aspekt?

    Wozu überhaupt, wenn nur das Team sich selbst kontrolliert?
    Erstens entsteht beim Aufstellen dieser Checklist immer eine heftige Diskussion einerseits über Inhalt und Detailiergrad, aber auch um Qualität.(Storming nach Tuckman)

    Zweitens wird dann die Handhabung diskutiert, für wen und für welchen Zweck ist diese Liste gedacht. (Norming nach Tuckman)

    Oft verwendet der Product Owner bei der Abnahme die Checklist, damit nichts wichtiges vergessen wurde.

    Und schon haben wir es wieder vermischt die drei unterschiedlichen Aspekte. Das Aufstellen benötigt Aushandeln, damit es überhaupt erst dazu kommt, dann der Inhalt mit Detailierung, dann die Verwendung.

    Wichtig ist, dass ein Aushandeln stattfindet, dass überhaupt zuerst ein Bewußtsein für etwas Gemeinsames, ein gemeinsames Bild eine gemeinsame Sprache ein gemeinsamer Anspruch stattfindet (Forming nach Tuckman) mit verschiedenen Ansprüchen und vor allem mit Wertschätzung und Vertrauensaufbau.

    Das Team definiert sich damit selbst und zeigt auch nach außen wofür es steht. Damit kann es zB argumentieren wenn Druck gemacht wird. ZB wenn die Testabdeckung auf 80 Prozent in der DoD ist, so wird kein Codefragment ausgeliefert, das durch wenige oder keine Tests abgesichert ist. Vielleicht ist das dann auch noch gekoppelt mit automatischen Build Systemen, die wiederum nicht liefern wenn die Schranke zu kein ist.

    Letztlich soll es beim Aufstellen dieser Checklisten darum gehen eine gemeinsame Strategie für Nachhaltigkeit zu schaffen, sowie einen Umgang und ein Bewußtsein für Verantwortlichkeiten und für wen ist Qualität in welcher Form transparent sein soll festzulegen. Bei der DoD wird dann oft die Qualitätsabteilung mit einbezogen, befragt, oder überhaupt erst bewusst wahrgenommen.

    Hier wird die Checkliste durch das Team am besten selbst organisiert geschaffen (eventuell vom Scrum Master als must have initiiert). Die Anwendung erfolgt auch durch das Team, eventuell den Product Owner. Die Qualitätssicherung der DoD erfolgt zB in einer Retrospektive. Hier bedarf es zumindest in der permanenten Hinterfragung – immer wieder eine kleine Metapositon einnehmen.

    WICHTIG: ich sehe diese Art von Checklist nicht so notwendig bei der unmittelbaren Anwendung, sondern vielmehr als Reflexion, als gemeinsames commitment was uns wichtig ist. Wie und in welcher Kultur sind sie zustande gekommen. Wird sie vorgegeben, von der Organisation, von den einem Architekten, von einem Teamleiter oder leiterin oder vom Team selbst erstellt.

    Hier sind wir wieder bei den Computerprogrammen (oder Kuchenrezepten), dort ist es auch so. Wichtig (und interessant) ist nicht nur wie sie funktionieren und wie sie angewendet werden, sondern ein wesentlicher Punkt für Veränderung und Nachhaltigkeit in Unternehmen ist die Intention warum sie da sind, das Zustandekommen (Commitment) und Aushandeln mit den notwenigen Reflexionsmöglichkeiten Gemeinsamkeit zu Schaffen.
    Für jede Art von Artefakten braucht es eine Kultur.

    Bei einer Produktentwicklung mit mehreren Teams kann eine übergreifende adaptive DoD Checkliste sehr hilfreich sein. So können basale Dinge für alle Teams gelten, für ein spezielles Team kann ein zusätzliches Kriterium eingeführt werden, welches nur für dieses gilt. Hier gilt wieder das selbe für ein Team. Es müssen sich mehrere Team untereinander einigen, wenn sie eine gemeines Qualitätsbasis möchten.

    NICHT ADAPTIVE CHECKLISTEN:

    Damit meine ich Checklisten die vorgegeben sind. Meist werden diese nicht verändert und kommen von „außen“. Ein Beispiel ist die ScrumChecklist von Boris Gloger. Ich zumindest als Scrum Master verändere diese nicht, weil es auf den ersten Blick keinen Sinn macht dies zu tun. Warum sollte ich eine Prozess verändern der einfach in der Beschreibung ist und warum sollte ich mir die Arbeit antun das alles nochmals zu erfinden? Oder doch? Warum gibt es in vielen meist großen Firmen die Notwendigkeit eigene Scrum Handbücher zu verfassen, die nicht nur adaptieren, sondern jedes Detail neu erfinden?

    Vorteile des nicht Veränderns der Checklist:
    In Ihr ist der Aufbau, die Teilnehmer und Artefakte auf der taktischen und strategischen Ebene aufgelistet. Sie hilft dabei immer wieder den Fokus zu haben wenn man beispielsweise von einem Vorhergehenden Meeting abgelenkt ist: Sind alle da, Leitet das SP1 der PO usw. Wir über das was und nicht über das wie diskutiert. Ich persönlich finde diese Art von Checklisten als sehr hilfreich. Man findet dazu ca. 600 verschiedene Bücher und tausende Communities. Standardisierung hat definitiv Vorteile.

    Diese Checklisten sind aber von einer anderen Art:
    – Sie wurden nicht mit dem Team gemeinsam erstellt
    – Der Einfluss der Veränderung ist eher gering, meist möchte man einen standardisierten Prozess haben, welcher wie Boris es nennt „einfach“ ist.

    Dazu mehrere Argumente:
    Erstens – Keine Reflexion von Scrum mit den Teams:
    Oft werde ich als Scrum Master gefragt, warum dieses und jenes Meeting notwendig ist, Warum eigentlich ein Sprint immer zwei Wochen dauert usw. Diese Fragen zielen manchmal darauf ab, das ein Impediment das ist, oder wirklich etwa nicht verstanden wurde. Z.B Kein Respekt des Product Owner vor dem Commitment bringt fragen nach dem Sinn von Reviews.

    Oft steht hinter solchen Fragen aber auch das nicht mitreden dürfen und ich habe schon mehrfach gehört, alles darf hinterfragt werden nur der Scrum Prozess eben nicht. Hier sind es oft auch wieder Impediments wie ineffiziente Meetings die es zu beseitigen und zu erklären gilt.

    Sehr vereinzelt höre ich aber auch den Wunsch den Prozess selbst variaben und anpassbar zu gestalten. Wie steht es also mit der Unverrückbarkeit dem heiligen Gral dem Prozess selbst, dessen Hüther der Scrum Master ist? Und ich muss ehrlich sagen, mich irritieren diese Fragen immer. Der schale Beigeschmack ist am Beginn jeder dieser Diskussionen, dass beim Prozess keine Partizipation gibt. Beim genaueren hinsehen, und das ist das beruhigende und meist mein Argument wird der Prozess vom geamten Team, bzw von den Teams mit Hilfe des Scrum Masters umgestaltet. So hatten wir zB die Estimation Meetings abgeschafft, weil es ausrechte mit der Anzahl der Stories die fertiggestellt werden konnten ein Forecast für die Planung zu machen. Oder wir haben das Storyschreiben den Teams übertragen, weil der Product Owner für zwei Teams überfordert war. Wir haben WIP Limits aus Kanban auf das Scrum Board mit aufgenommen, und und und. Der Prozess ist sehr einfach. Darin sehe ich nicht den schon oft gehörten Nachteil, dass vieles nicht definiert ist, aber den größten Vorteil, weil nur dann kann diskutiert werden, wenn nicht alles von vorherein festgelegt ist.

    Andere Variante: Aufweichung des Prozesses:
    Man könnte auch sagen der Scrum Master ist für die Produktivität zuständig (und den Prozess nicht mehr so stark betonen). Der Product Owner ist für die Vision zuständig (und die Priorisierung und das Storyschreiben nicht mehr so stark betonen). Das Team ist für die Qaualität zuständig (und die Lieferung nicht mehr so stark betonen).

    In einer radikaleren Form, oder als paradoxe Intervention bei einer Retrospektive könnte man auch den gesamten Scrum Prozess hinterfragen, und das Team abstimmen lassen, ob doch lieber Kanban oder wieder Wasserfall machen wollen. In seltenen Fällen ist Kanban vielleicht auch wirklich sinnvoller und es ist auch immer sinnvoll sich der Machtfrage zu stellen nach der Macht über den Prozess. Damit einhergehend was laterale Führung heißt, was ist der Unterschied von Management und Servant Leadership und wer darf wo mitreden.

    Hier kann zB das Modell des Gruppendynamische Raum helfen:
    Dieser Raum hat die drei Dimensionen: Zugehörigkeit (Wer ist drinnen und wer draußen), Macht (oben und unten) und Intimität (Nähe und Distanz). Damit erhält man ein Instrumentarium – ein Gedankenexperiment, einen gedanklichen Raum — zur Klärung wer gehört in welcher Form dazu, wer ist im Zentrum, wer am Rande. Klärung wie ist das Verhältnis von Leitung und Führung, wie kommen Entscheidungen zu Stande. Betroffene / Beteiligte. Wie finden Auseinandersetzungen statt. Auf der Zugehörigkeitsachse können Teammitglieder auch das Verhältnis zu Kunden, die wichtiges Feedback liefern betrachtet werden. Auf der Machtachse interessiert zum Beispiel wie kommen Softwarearchitekturentscheidungen zustande. Auf der dritten Achse könnten auch das Wir Gefühl betrachten oder die Form der Intensität der Zusammenarbeit, separiert in Einzelbüros, oder in einem Teamraum mit intensiven Austausch und häufiges Pair Programming. Mit Hilfe des Modells lässt sich auch analysieren, ob eine Achse tabuisiert wird. Wird beispielsweise nicht über Macht gesprochen, oder äußerst sich dieser Faktor anders. Die Einbeziehung und Beachtung der drei Dimensionen braucht einen respektvollen Umgang durch den Scrum Master – Respekt schafft Wertschätzung.

    Ich bin der Meinung, dass es sich in jedem Fall lohnt sich dieser Fragen zu stellen, entweder nur als Scrum Master für sich selbst, besser noch als Scrum Master mit dem Team bzw. Teams.

    Im Film „Mein wunderbarer Arbeitsplatz“ werden Beispiele gegeben, wo Teams die Atonomie gegeben wird über ihren Prozess den sie leben wollen selbst zu entscheiden. Nur die Vision wird von außen vorgegeben. Die Führungskräfte fungieren meist als Coaches. Wichtig war in allen darin vorkommenden Beispielen, dass die Teams selbstorganisiert sind und sie einen Sinn bekommen und die mehr an Verantwortung. Also: Ein Scrum Master als Coach für Selbstorganisation, ein Product Owner für die Vision, möglichst kleine Teams thats it, oder?

    Und bei Rainhard K. Sprenger: Es ist unser aller Aufgabe Platz zu machen für die deren Weg wir bereiten. Den Beitrag weiterzureichen, den wir unsererseits erhalten haben und der uns überleben lies. So wie wir ernten, was wir nicht gesät haben, so sollten wir sähen, was wir nicht ernten werden. Wir sollten den Ich Aspekt unseres aufgeschossenen und allzeit gereizten Bewusstseins begrenzen, das heißt uns ernst nehmen, aber nicht wichtig – das ist radikal führen.

    Die Computermetapher anders in einem buddhistisches Sprichwort verpackt:
    Man sollte nicht den Finger, der auf den Mond weist, für den Mond selbst halten.

    WAS IN DER SCRUM CHECKLIST FEHLT:
    Neben der Ebene der Strategie und Taktik die Ebene der Werte bzw. Wertehaltung. Das woran wir noch glauben: Fokus, Commitment, Respekt, Offenheit und Mut. Daran sollten sich bei welchen Abweichungen auch immer alle halten.

  • Gerhard Grimm

    Ein sehr interessanter und m.E. notwendiger Aspekt, der (fast) jeder Checkliste aus meiner Sicht beigeheftet werden sollte, bis Ersteller m/w und Nutzer m/w diese Sichtweise angenommen haben. Dieser Nutzen-Aspekt wird aus meiner Erfahrung VIEL zu wenig thematisiert. Meist wird die CL als Kontrollzettel missbraucht, um Verantwortung und Haftung von sich auf andere schieben zu können. Ein entsprechend negatives Image haben dann oft Checklisten und werden „mit spitzen Fingern“ angefasst.