In dieser Folge geht es um Agile in IT-Operations. Solltest du nicht in IT-Operations tätig sein, keine Berührungspunkte damit haben, kann diese Folge trotzdem super spannend für dich sein, weil sich auch viel in Agile generalisieren lässt, was nicht Softwareentwicklung ist. Kai und ich teilen mit dir unsere Ideen, welche Prinzipien aus der Agilität auch in IT-Operations komplett Sinn machen und wie man diese gerade in IT-Operations anwenden könnte, welche Gedanken man sich machen kann und vielleicht auch welche Dinge man sich aus Scrum klauen kann, weil diese auch in IT-Operations Sinn machen. Wir wünschen dir viel Spaß damit.
Wer agile Arbeitsweisen wie Scrum oder Kanban schon einmal eingeführt hat, weiß, dass Widerstände ein Teil der Sache sind. Jede Veränderung in einer Organisation hat immer wieder Felder von Widerstand. Was ist deine persönliche Rolle im Umgang damit und wie kannst du mit Menschen, Teams und Systemen besser umgehen, die im Widerstand zu solchen Veränderungen sind?
Darum geht es in dieser Folge. Wir teilen unsere Praxiserfahrungen und Tipps dazu, die dir helfen, effektiver in solchen Umfeldern zu sein.
Viel zu viele Meetings! Wer Scrum einführt und auf agiles Arbeiten setzt, kennt das Problem: irgendwer nörgelt immer darüber, dass es jetzt so viele neue Meetings gibt. Wir schauen uns die Symptome dieser Problematik an: hat Scrum wirklich so viele Meetings und was müssen wir tun, um sie effektiver zu gestalten?
Wir haben über die letzten Jahre einige Leitfragen entwickelt, die dabei helfen ein agiles Team zu starten. Mit der Klärung dieser Bereiche wird es deutlich einfacher in die richtige Richtung als Team unterwegs zu sein. Sie eignet sich für scrum sowie mit ein paar Modifikation für Kanban Teams, um grundlegend mit dem agilen Arbeiten zu beginnen, aber auch als Reflexionshilfe für bestehende Teams.
Der dazugehörige Download findet sich unter dieser Folge, wir erklären im Podcast im Detail was wir wann, wie und warum moderativ tun, um das canvas auszufüllen.
Warum kann es legitim sein ein Team Assessment durchzuführen?
Wie gehen wir da ran, mit welcher Haltung und wir stellen Dir ein ganz konkretes Werkzeug vor, welches wir lieben und oft benutzen und stellen Dir auch drei Arten vor, wie Du dieses für Dich in Deinem Alltag benutzen kannst.
Darf, soll oder muss ein Scrummaster oder Agilecoach eigentlich auch ein Performancecoach sein?
Wir haben ChatGPT gefragt und waren mit der Antwort völlig unzufrieden. In einem munteren Diskurs pflügen wir uns durch unsere Erfahrungen, wie individuelles und teambezogenes Performancecoaching in das Bild von agilen Vorgehensweisen passt.
Ein agiles Team durchläuft in seiner Teamentwicklung vier Schritte von dem Aufstellen eines vielleicht ersten vermeintlichen product backlogs bis zur messbaren Wirkung auf das Geschäftsmodell des Unternehmens. Dieser Entwicklungsweg ist herausfordernd und darf begleitet werden durch Haltung und Methoden. In diesem Podcast beleuchten wir diese Entwicklungsschritte und was unsere Erfahrungen damit in Unternehmen uns gelehrt hat.
Heute gehen wir mit einem Prinzip aus dem agilen Manifest den kollektiven Burnout an, das uns hilft „nein“ zu sagen. Wir erklären Dir, warum es schwer ist nein zu sagen und welche vier Bedingungen Du in Deinem Projekt oder Produkt brauchst, damit Du nein sagen kannst, damit wir am Ende „ja“ zu den wirklich wichtigen Dingen sagen können.
9 neue Erkenntnisse für agile Teams mit Magic Maze
Dieser Artikel ist Ursprünglich im Januar 2020 erschienen.
Magic Maze für agile Teams -Was bisher geschah…
In meinem letzten Artikel zu Magic Maze hatte ich die uns bis dato 9 bekannten Erkenntnisse zusammengefasst und mit euch geteilt. Seitdem ist natürlich nicht Schluss gewesen. Ich selbst hatte bei Kunden mehrfach die Gelegenheit Magic Maze einzusetzen und zusammen mit meinem
Kollegen Veit sowie Stefan Zumbrägelbeim Global Scrum Gathering in Wien eine Open Space Session zu Magic Maze zu hosten. Mein Highlight bezüglich Magic Maze dieses Jahr war allerdings ein Certified Scrum Master Training mit Björn Jensen . Ich war als Co- Trainer mit dabei und konnte mit den Teilnehmern recht früh am ersten Tag eine Runde Magic Maze
Neun neue Erkenntnisse für agile Teams mit Magic Maze spielen, um sie für agiles Arbeiten zu sensibilisieren. Das hat nicht nur sehr viel Spaß gemacht, sondern auch noch richtig gut funktioniert. An dieser Stelle nochmal „Danke an Björn“ für diese tolle Gelegenheit und das Vertrauen!
Aber warum erzähle ich euch das alles? Es gab natürlich neue Erkenntnisse, insgesamt 9 neue Erkenntnisse für agile Teams mit Magic Maze. Und genau das treibt mich an, Magic Maze weiter mit Teams und in Trainings einzusetzen. Ich werde die bisher bekannten Erkenntnisse nicht nochmal hier zusammenfassen, dafür bitte den oben verlinkten Artikel lesen.
Feedback aus der Community
Kurz nach dem letzten Beitrag kam schon der erste Kommentar von Abigail Leijten, in dem sie zwei Erkenntnisse geteilt hat.
„Mut: es gehört Mut dazu, am Anfang dich als erste am Tisch zu setzen, wo du gar nicht genau weißt, was passieren wird.“ Das kann ich bestätigen, ich habe mehrfach größere Gruppen gehabt, bei denen wir auch die Rolle des Beobachters hatten und sich der Tisch somit erst zögerlich gefüllt hat. Das kann man in Retrospektiven auch oft beobachten. Man bittet das Team Beobachtungen zu teilen und es dauert eine Weile, bis sich der Erste traut oder freiwillig spricht. Sowohl im Spiel, als auch in der Retro, passiert aber nichts Schlimmes, wenn man die Initiative ergreift. Schönes Thema über das man im Debrief sprechen kann.
„Als Teil des „Agiles Mindset“ ist auch ein Satz „Jeder hat seine eigene Geschwindigkeit“. Wir hatten den Fall, wo manche Leute 3 Runden gebraucht haben, bevor sie den Teleporter komplett verstanden haben. Auch das war für die Gruppe ein schönes Learning.“ Das ist eine weitere tolle Erkenntnis, wie ich finde. Mir fällt das auch oft auf. Ich interpretiere da auch rein, dass man Leute nicht mit Informationen überladen und erwarten kann, dass es alle sofort verstanden haben. Man kann das Spiel noch so oft und ausführlich erklären – erst wenn es los geht, merkt man, ob es wirklich verstanden wurde.
Vielen Dank Abigail, dass du diese tollen Impuls mit uns geteilt hast!
Was wir neues gelernt haben
Ich knüpfe gleich an. Ich würde noch einen Schritt weitergehen und die Erkenntnis ziehen „einfach mal Machen“. Bei der Produktentwicklung wissen wir nicht, ob wir das Richtige bauen, bis wir den Kunden um Feedback bitten. So geht es mir als Facilitator des Spiels auch oft. Ob die Spieler meine Anweisungen verstanden haben, sehe ich erst, wenn sie es spielen. Und bisher hatte es keine Gruppe zu 100% verstanden. Das konnte dann aber schnell angepasst werden im Spiel. Ich weiß nicht, wie viel Zeit es gekostet hätte, um die Missverständnisse beim Erklären auszuschließen bzw. ich glaube es ist nicht möglich. Also Erkenntnis bzw. Parallele zu agilem Arbeiten, einfach mal machen und Feedback einholen!
Es gilt die Prime directive (von Norman L. Kerth). „Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.“ Übersetzt: „Unabhängig davon, was wir entdecken werden, verstehen und glauben wir aufrichtig, dass jeder sein Bestes in der gegebenen Situation mit dem verfügbaren Wissen, den Ressourcen und unseren individuellen Fähigkeiten getan hat.“ Wie sehr diese Haltung hilft, erkennt man bei Magic Maze in den Phasen, in denen gesprochen werden kann. Ist das erste Fingerpointing vorbei, haben die Teams in der Regel verstanden, was ihnen weiterhilft ihr Ziel zu erreichen und was nicht. Fingerpointing hilft nie! So ist es auch in Retrospektiven. Nicht umsonst ist die Prime directive dort so wichtig. Dieser Punkt baut ebenfalls sehr schön auf den Punkten 11 und 12 auf, wie ich finde.
Läuft man bei Magic Maze ein Feld zu weit, kann man diesen Fehler selbst nicht korrigieren. Man braucht Hilfe aus dem Team. Diese Erkentiss hat dazu geführt, dass die Runde gemerkt hat, dass es auch im Alltag OK ist, um Hilfe zu bitten, wenn man sich in eine Sackgasse manövriert hat. Denn man bedenke Punkt 13, es gilt die Prime directive; man hat es ja nicht absichtlich gemacht.
Der letzte Punkt aus meinem vorherigen Artikel bezog sich darauf, dass man durch lange Planung am Anfang nicht besser vorhersagen kann, wie sich das Labyrinth aufbauen wird. Ein Team hat dies noch um die Aussage „eine Schätzung am Anfang wäre sehr sehr ungenau“ ergänzt. Das Team weiß, dass es alle Mittel hat, um die Aufgabe zu lösen, aber es hätte sich nicht gut gefühlt eine feingranulare Schätzung abzugeben. Sicher ein tolles Learning für Personen außerhalb eines Entwicklungsteams. Nehmt den Punkt gerne gezielt mit ins Debrief, wenn ihr im Alltag Probleme mit den Ansprüchen an Schätzungen habt.
In den Phasen auf der Sanduhr wird immer fleißig gesprochen und geplant. Doch dann kommt oft alles anders. Das führte zu der Erkenntnis, dass eine gemeinsame Sprache und gemeinsames Wording nicht selbstverständlich sind. Auch das ist bei Scrum oft zu beobachten. Daher führe ich sehr gerne Grundlagentrainings mit neuen Teams durch, um die verschiedenen Taxonomien ans Licht zu bringen und eine gemeinsame zu verankern.
Der „Tu was Stein“ kann von jedem Spieler genutzt werden, um einem andren Spieler zu signalisieren, dass er etwas tun kann, das dem Team weiterhilft. Im Spiel passiert das sehr natürlich und unverzüglich, sobald eine solche Situation erkannt wird. Die Analogie zu Scrum ist das Impediment. Ein Spieler hält unwissentlich den Betrieb auf. Es ist total OK und auch wichtig, dies sofort anzusprechen. Im Spiel passiert das von alleine. Warum sollte das also im Alltag nicht ebenso selbstverständlich werden?
Ich schließe mit einem für mich schönsten Sätze in einem Debrief, der auch keiner weiteren Erklärung bedarf „Das Spiel hat aus Fremden innerhalb kürzester Zeit ein Team gemacht“
Wir konnten mal wieder die Klappe nicht halten 🙊, was die Einführung agiler Methoden betrifft. Vom Einzelteam zur größeren Landschaft teilen wir Erfahrungen, Muster und Bitte-Nicht‘s!
