PRODUKTIVITÄT
Protokolle schreiben | Tipps und Muster
Auch wenn Falk Golinsky mit seinem Blogartikel eher Vereine im Visier hat, Protokolle gehören auch im Berufstalltag dazu. Wenn sie sinnvoll genutzt werden, nicht um den Bürokratiedrachen zu füttern, sondern um sinnvoll Entscheidung zu dokumentieren und später nachzuvollziehen. Ja, Agilität schafft die Dokumentation nicht ab. Sie zielt darauf ab, den Fokus auf Interaktionen und Zusammenarbeit zu legen. Nur für diejenigen, die Protokolle als „unagil“ ablehnen. Auch oder in gerade in agilen Umfeldern ist das nachvollziehen bestimmter Dinge für die Reflexion sogar elementar. Auch wenn man sie nur ungern schreibt. Man kann da sich allerdings mit guten Standards, gut vorbereiteten Vorlagen und etwas Automatisierung einiges an Arbeit ersparen. Nur mal nebenbei bemerkt.
https://moderne-vereinsorganisation.de/standards-im-verein-das-musterprotokoll-mach-es-dir-einfach/
FOMO und Informationsflut | Ein gutes Informationsmanagement schaffen
Die Verfügbarkeit von Informationen ist enorm. Das war sie aber auch schon vor dem Internet. Nur musste man dafür noch etwas mehr Hirnschmalz investieren, um in einer Bibliothek die richtigen Informationen zu finden. Heute geht es alles (vermeintlich) einfacher. Oder auch nicht. Den für mein Informations-Set-up muss ich immer noch sehr viel Hirnschmalz investieren. Gerade auch, weil beständig über zig Kanälen Unmengen an „Daten“ auf mich einströmen können. Und genau dies ist das Thema der Podcastfolge von Ivan Blatter:
https://ivanblatter.com/podcast/wissen/
Mentrale Konstrukte | Wie sie uns behindern und wie wir sie überwinden können
Mentale Konstrukte oder anders ausgedrückt unsere Vorstellung von etwas, können gelegentlich richtig lästige Spaßbremsen sein. Ich denke, so ziemlich jeder weiß, was ich meine. Das Problem dabei ist, dass uns diese Konstrukte im schlimmsten Fall blockieren und Lösungswege verbauen. Hier versucht Leo Babauta eine Brücke zu bauen, indem mit Achtsamkeitsübungen den „Knoten“ auflöst:
https://zenhabits.net/mental-constructs/
Besprechungen | Vier Werkzeuge, um Besprechungen auf Kurs zu halten
Schlechte, ineffektive und ineffiziente Besprechungen, die besser eine E-Mail gewesen wären, erleben wir alle regelmäßig. Wenn wir uns alle an die eigene Nase fassen und konsequenter werden, können wir einiges erreichen, dieser Form der unnützen Arbeit an den Kragen zu gehen. Zumindest dort, wo wir selbst die Hand drauf haben. Hierbei können die Kniffe, die Dan Rockwell in seinen Blogartikel ins Spiel bringt sicherlich weiterhelfen:
https://leadershipfreak.blog/2023/03/01/4-tools-to-keep-meetings-on-track/
LEAN
One-Piece-Flow | Wie wir näher an das Ziel des One-Piece-Flows herankommen
Wer sich mit dem TPS näher beschäftigt, der stolpert zwangsläufig irgendwann über den Begriff „One-Piece-Flow“. Auch mit Blick auf Kanban ein zentrales Element, dass wir unbedingt – auch mit Blick auf die Adaption ins agile – näher beleuchten sollten. Auch wenn die Idee aus dem Produktionsumfeld stammt. Es geht dabei um Fokus und Flow. In diesem Sinne kann ich den Artikel von Christoph Roser jedem nur ans Herz legen, der verstehen will, weshalb und wie der Ansatz von One-Piece-Flow funktioniert und weshalb dieser für das TPS so wichtig ist.
https://www.allaboutlean.com/steps-toward-one-piece-flow/
Kontinuierliche Verbessern und Lernen | Um die Perlen zu finden, braucht es auch Fehlschläge
Die Überschrift des Artikels von Kevin Meyer ist sehr deftig gewählt: Perlen und Kackhaufen der kontinuierlichen Verbesserung. Und doch trifft sie es ziemlich gut. Das kontinuierliche Reflektieren, Verbessern und Weiterentwickeln im Sinne von Kaizen bringt viele Perlen zu Vorschein, aber leider auch Fehlschläge. Und doch geht es genau darum, um Neues zu Lernen braucht es Irrtümer und das ist alles normal, nicht schlimm, wenn wir schnell aus Irrtümern und Fehlern lernen und sie zeitnah beheben. Etwas, was in der Grundidee die Agilität eine jeden Organisation ausmacht. Es braucht viele Fehlschläge, um eine die Perlen zu entdecken. Beständigkeit und Visualisierung sind dabei ein Hilfsmittel. Exploration ist nicht einmalig. Sie findet ständig statt. Verbesserung ist kein Projekt, es ist eine Daueraufgabe.
https://blog.gembaacademy.com/2023/03/03/the-pearls-and-turds-of-continuous-improvement/
AGILE
Grupppendenken im Team | Wenn die Gruppendynamik dazu führt, dass wir im Team „verdummen“
Einzeln sind wir ziemlich vernünftig, in der Gruppe drohen wir schell zu „verblöden“ (ich denke da gerade an Gunther Duecks Buch Schwarmdumm). Einer der Gründe ist eine Form der Gruppendynamik, die die meisten uns unter „Groupthinking“ kennen. Kein neues Phänomen, sondern eines, dass schon länger bekannt ist und och beständig immer wieder zu beobachten ist. Lars Richter beschreibt es hier etwas ausführlicher und versucht einige Auswege aus der Misere aufzuzeigen:
https://cdi.digital/groupthinking/
Management und agile Teams | Wie agile Teams mit Liberating Structurs vermitteln können, was von Management brauchen
Es sagt sich sehr einfach, ist in der Praxis aber alles andere als trivial in der Umsetzung: Das Management ist dafür, das die Rahmenbedingungen für agile Teams zu schaffen, dazu gehört den Rahmen und die Stoßrichtung. Das Ganze ist keine Einbahnstraße, sondern setzt einen Dialog zwischen Team und Management voraus, der nicht einfach so vom Himmel fällt. Wie alles im Leben braucht es nicht nur den Willen, sondern auch die Übung, um das gegenseitige Verständnis zu schärfen. Hilfreich können dabei auch Format aus dem Werkzeugkoffer der Liberating Structurs sein, wie sie zum Beispiel von den Barry Overeem hier im Kontext Bedürfnisformulierung gegenüber dem Management zur Anwendung gebracht werden.
Scrum-Erkrankungen | Warum wir schnell auf Fehlentwicklungen reagieren sollten
Gerade heute habe ich K1 (8 Jahre alt) erklärt, warum es wichtig ist, Unordnung und Müll sofort und gleich zu beheben. Den erstens wird es erheblich aufwendiger, wenn man damit wartet, bis sich noch mehr anhäuft und zum anderen sieht es erst mal aus wie bei Hempels auf dem Sofa werden alle anderen auch nachlässig und kippen ihren Müll achtlos in die Landschaft. Ob er es verstanden hat? Wir werden es die nächsten Tage sehen. Auf jeden Fall kann man den gleichen Effekt bei „Adaptionsfehlern“ bei Scrum beobachten. Daher macht es Sinn auch hier schon so früh wie nur möglich auf „Fehlentwicklungen“ zu reagieren, wie hier von Simon Flossmann empfohlen:
User Storys schreiben | Ein Workshopformat, dass dabei hilft gute PBI zu formulieren
User Storys erfreuen sich nach wie vor einer großen Beliebtheit als Format zur Formulierung von Product Backlog Items (PBI). Auch wenn es sich in der Praxis so manche kopfschüttelnde Auswüchse beobachten lassen, dies allerdings nur am Rande bemerkt. Übrigens bin ich der festen Überzeugung, dass gute PBI nicht im stillen Kämmerlein des Product Owners entstehen, sondern gemeinsam mit denjenigen entstehen, die sie dann auch umsetzen. Workshops wie sie hier von Mike Cohen, einem agilen Urgestein der ersten Stunde, vorgeschlagen werden, sind dabei ein sehr probates Mittel:
Spotify Engineering Cultur | Kennzeichen, Merkmale, Faktoren
Das Spotify-Modell wird gerne und oft als Referenz für agile Organisation bemüht. Ich persönlich bin etwas skeptisch, ob das immer richtig und gut ist. Zum einen entwickeln sich die „Referenzen“, die als Best-Practice-Modelle „vermarktet“ werden, oft schneller weiter als die Anpassung der Referenzmodelle erfolgt, sodass die „Lernlektionen“ verloren gehen. Und zweitens fokussieren wir dabei immer zu sehr auf die sichtbare Vorderbühne, vernachlässigen die Zusammenhänge auf der Hinterbühne. Übrigens keine „agile“ Besonderheit, sondern genauso in Bezug auf das Toyota Production System bei Lean-Adaptionen vor 20-30 Jahren genauso zu beobachten. D. h. nicht, dass man nichts mitnehmen sollten und daraus lernen kann. Es bedeutet lediglich, es sehr reflektiert und mit dem Bewusstsein zu tun, dass sehr vieles nicht offenkundig ist, was zu den Erfolgsfaktoren gehört und von daher die Referenzmodelle eher als Inspirationsquelle anzusehen, die nicht einfach kopiert werden können. Daher bitte entsprechend auch den Beitrag von Andreas Diehl lesen und nutzen 😉
https://digitaleneuordnung.de/videos/spotify-engineering-culture/