Sven & Matti @ InterviewIch habe noch nie etwas von gelangweilten NASA-Teams gehört. Technische Probleme einer Marslandung werden offensichtlich als positive Herausforderung angenommen.

Sind die Aufgaben weniger technisch, dann generiert das übliche Breittreten von Problemen allerdings tendenziell noch mehr problematische Effekte als Lösungen. Bei konventionell geführten Retrospektiven  bleibt dann von dem, was bisher gut lief, zu oft nur ein schmächtiges «Weiter so!» übrig, ohne erkennbaren Effekt. Bessere Idee: statt des ermüdenden «Problemtalk» baut man besser auf dem Erreichten auf und überlegt gemeinsam, wie man vom erreichten Stand x auf x+1 kommen könnte. Diese Sicht verbreitet sich immer mehr.

Der 35. Agile Monday im Coworking Space Nürnberg stand diesmal unter dem Motto «Lösungsorienterte Retrospektiven».

Über die Einladung der Agile-Monday-Organisatoren Martin Heider, Sven Winkler und René Füger  habe ich mich sehr gefreut und am ersten schönen Frühlingsabend mit zwei Dutzend Teilnehmern eine lösungsorientierte Retrospektive nach Appreciative Inquiry durchgespielt (Materialien dazu gibt’s als Anhang unter diesem Posting). Die Retrospektive drehte sich praktischer Weise um die Zukunft des Agile Monday selbst.

Vorweg: ein toller Abend!

In eigener Sache: wir haben die Autorenlinks für Kommentare hier auf pragmatic-teams.de auf auf dofollow umgestellt.

Oder einfacher ausgedrückt: Kommentiere hier und verbessere Deinen Pagerank.

Puzzled Kitty © David K

Agile Teams leben in der Grauzone: Skills und Aufgaben sind keine Frage von Schwarz oder Weiß, ich oder Du.

Wenn die Testerin zum «Bottleneck» wird, weil Entwickler nicht wissen (wollen), wie man ein Testskript anwirft: schlecht fürs Ziel. Wenn der Product Owner (PO) keinen Sinn darin sieht, von Anfang an mit der Testerin an brauchbaren Akzeptanzkriterien zu feilen: schlecht fürs Ziel. Wenn die Testerin zwar programmieren könnte, aber sich sträubt, auch mal Unittests zu erweitern: schlecht fürs Ziel.

Der Scrum Guide sagt:

Unabhängig von der verrichteten Arbeit werden die Mitglieder des Entwicklungs-Teams als Entwickler bezeichnet. Scrum sieht keine anderen Titel für die Mitglieder eines Entwicklungs-Teams vor; es gibt keine Ausnahme von dieser Regel

Das bedeutet für das interdisziplinäre Team eben nicht, dass jeder wirklich alles und noch dazu gleich gut können muss. Es bedeutet, dass jeder zu jedem Zeitpunkt Meister, Geselle und Azubi zugleich ist, nur eben auf unterschiedlichen Gebieten - und immer wieder von neuem.

Agiles Teamwork lebt von dieser Grauzone. Davon, dass nicht danach gefragt wird, wer für das Erreichen des Ziels verantwortlich ist, weil die Antwort ohnehin klar ist: das gesamte Team.

Wann immer das Schwarz-oder-Weiß-Spiel («Was soll ich denn noch alles können?», «Das ist nicht mein Job!», …) gespielt wird, um letztlich gar nichts außerhalb der eigenen Expertise kennen lernen zu müssen: schlecht fürs Ziel. Eine meiner wichtigsten Fragen an jedes Team ist deshalb: wie spielt Ihr denn statt dessen das Meister-Geselle-Azubi-Spiel, so dass es funktioniert?

Shu-Ha-Ri-Sprints: lernen, verstehen, vermitteln

Ein interessanter Weg neben z.B. Workshops, Schulungen und Communities of Practice (CoPs): das Team erklärt jeden Sprint zu einem Shu-, Ha- oder Ri-Sprint, rotierend.

Spickzettel Nr. 2: Scrum FlowDownload gefällig? Ab heute gibt es in der Rubrik «Ressourcen», unter der ich nach und nach zum Beispiel meine Arbeitsblätter veröffentliche, den zweiten Agilen Spickzettel,  «Scrum Flow». Er steht unter einer Creative-Commons-Lizenz, schon allein deshalb, weil ich gerne Bildmaterial verwende, das viele freundliche Mitmenschen nach demselben Prinzip veröffentlicht haben.

Spickzettel heißt das Ganze, weil keine langatmigen Erklärungen darauf zu finden sind, sondern knappe Zusammenfassungen in Stichworten, als Gedächtnisstütze.

Allen agilen Teams und Coaches viel Spaß damit - und natürlich freue ich mich über alle Kommentare dazu: allgemeine hier, die zum Spickzettel am besten direkt auf der jeweiligen  Spickzettelseite.

«Feedback? Gerne - aber bitte konstruktiv, und nicht von oben herab!»

What do you see? © Bill WardAb sofort biete ich als neuen Service das Assessment Agiles Arbeiten (A³) - für alle, die

• den erreichten Stand agilen Arbeitens zuverlässig einschätzen wollen,
• an einer konstruktiven externen Sicht z.B. auf Ursachen und Menge von «Sand im Getriebe» interessiert sind und
• konkrete Anregungen und Vorschläge für die Weiterentwicklung der eigenen agilen Arbeit suchen.

Ich freue mich schon auf unser erstes Gespräch darüber!