PRODUKTIVITÄT
Obsidian | Gründe die für die Software sprechen
Ich habe Obsidian mittlerweile auf dem Rechner reaktiviert und bin am Ausprobieren, nicht nur weil Evernote schlingert, sondern auch, weil mich Notion als Ersatz nicht so recht überzeugen will. Daneben sprechen, so zumindest Thomas Mathoi, noch einige andere Gründe klar und eindeutig für die Software.
https://www.mathoi.at/2023/07/20/sieben-gruende-warum-ich-obsidian-nutze/
Und weil ich es gerade erwähnt habe: Es gibt laut Thomas Mathoi ein guten, einfachen Weg seinen Notizen von Evernote in Obsidian zu bringen. Ich habe es nicht ausprobiert. Wir werden sehen:
https://www.mathoi.at/2023/07/18/von-evernote-zu-markdown-und-weiter-nach-obsidian/
Dankbarkeit | Mehr Dankbarkeit empfinden
Demut und Dankbarkeit sind so schon antike griechische Philosophen Kennzeichen eines glücklichen Lebens. Und es klingt einfach. Zu einfach. Mit der Demut klappt es bei mir mal mehr und mal weniger. Auch das Thema Dankbarkeit ist mitunter eine Herausforderung. Zumindest ich sehe weiter öfter, was nicht funktioniert als das, was funktioniert. Gut, die berühmten Vergleiche mit anderen Mitmenschen (Neid) habe ich mir ziemlich gut abgewöhnt. Am Rest arbeite ich gerade (#DerTäglicheStoiker ist ein aktuelles Experiment) Dazu passt gerade, wie die Faust aufs Auge, der Beitrag von Dan Rockwell zum Thema Dankbarkeit.
https://leadershipfreak.blog/2023/07/17/let-yourself-be-happy/
LEAN
Manuell Prozessbewertung |Wie man manuelle Prozesse bewertet
Ein Grundsatz im Lean Management lautet, automatisiere, was sich sinnvoll automatisieren lässt. Das trifft besonders auf reproduzierbare Abläufe und Prozesse zu, die sich beständig wiederholt werden. Sprich: Serienfertigung. Aber auch hier gibt es Grenzen. Und so bleibt immer auch ein Rest „Handarbeit“ übrig, der nicht automatisiert werden kann. Und damit meine ich nicht individuelle Handwerksarbeit, sondern Routinetätigkeiten. Auch diese wollen regelmäßig weiterentwickelt, verbessert und vereinfacht werden. Bitte unbedingt daran denken: Eine Verbesserung ist nur dann eine Verbesserung, wenn sie den Mitarbeitenden das Leben einfacher macht und für den Auftraggeber/Kunden einen Mehrwert/Nutzen stiftet (Qualität erhöht, Herstellungskosten senkt). In diesem Sinne macht es durch aus Sinn auf eben jene manuellen Routinetätigkeiten regelmäßig einen Blick zu werden, wie es hier von John Knotts angeregt wird.
https://blog.gembaacademy.com/2023/07/21/conducting-a-manual-process-assessment/
AGILE
Retrospektiven | Weshalb ist die Retro so oft unbeliebt?
Der Scrum Leitfaden schreibt sie für das Framework am Ende jedes Sprints vor. Und auch andere agile Rahmenwerke kenne die Retrospektive oder vergleichbare Formate in anderen Bezeichnungen. Sie gilt als Markenzeichen agilen Vorgehens, dabei ist die regelmäßige Reflexion eine Idee, die schon im Lean Management zu Hause ist. Soll heißen, der ganze Zenober hat seine Daseinsberechtigung. Aus guten Gründen. Es geht um das schärfen der berühmten Säge, um dauerhaft effektiv und effizient arbeiten zu können. Klingt trivial. Und doch ist es alles andere als trivial. Weil auch hier viel schief laufen kann und entsprechend tiefe Narben im kollektiven Gedächtnis von Beteiligten entstehen, die dazu führen, dass die Retrospektive nur ungern, lästig bis hin als unproduktiv wahrgenommen wird. Das liegt mitunter daran, dass man unerfahrene Scrum Master:innen auf Teams loslässt, die man auf „Moderieren“ von Teamevents reduziert und deshalb kaum in die Rolle des Servant Leaders hineinfinden, es mag auch daran liegen, dass man den eigentlichen Zweck des Sägeschärfens vergisst und es mag mit unter auch daran liegen, dass Team im „Hamsterrad“ gefangen ist und aus dem System nicht ausbrechen kann. Es macht also durch aus Sinn über die Retrospektive als solche zu reflektieren, ob die Gelingensbedindungen gut und ausreichend sind, damit diese effektiv und effizient einem Team und seiner umgebenden Organisation hilft, das Zusammenarbeitssytem so zu gestalten, dass die Arbeit gelingt. Dazu passt der Blogartikel von Doris Weißgerber, der versucht, den Gründen nachzugehen, weshalb sich Retros in manchen Teams einer ausgeprägten Unbeliebtheit erfreuen.
https://www.teamworkblog.de/2023/07/uber-die-unbeliebtheit-von.html
Gesundheitschecks für agile Teams | Überblick über agile Health Checks
Eine gute Standortbestimmung im Vergleich zu einem Soll-Zustand ist immer eine gute Ausgangslage, um Verbesserungen zu entwickeln. Sogenannte „agile Gesundheitschecks“ sollen genau dies ermöglichen. Davon gibt es übrigens einige, wenn man in die Literatur schaut und Stefan Wolpers hat einige der bekannteren „Health Checks“ für agile Teams zusammengestellt.
https://dzone.com/articles/health-checks-for-agile-teams
Entscheidungen | Weshalb und wie Entscheidung im Team treffen?
Ich bin ein großer Freund davon, Implizites explizit zu machen. Das gilt insbesondere für die Art und Weise, wie Entscheidungen getroffen werden. Und hier kann es durch aus sehr unterschiedliche Wege, Ansätze und Vorstellungen – oft unausgesprochen in Teams – geben. Wir sollten nicht vergessen, wir bewegen uns nicht immer in einfachen Situationen, sondern häufig mit komplizierten und oft genug in komplexen Situationen. Mehrdeutigkeiten, Ambivalenzen, fließende Grenzen gehören dazu. Und ganz im Sinne der Natur dieser Situationen gibt es verschiedene Entscheidungswege, die mal mehr oder mal weniger gut geeignet sind, um in einer Situation effektive und effiziente Entscheidungen zu treffen. Mal davon abgesehen, dass es auch noch unterschiedliche Entscheidungskompetenzen geben kann, die unter anderen organisatorisch oder gar rechtlich definiert und begründet sind. Man sollte zumindest die Grundvarianten der Entscheidungsfindung in Gruppen mit allen ihren Stärken, Schwächen und ihrer Eignung für den jeweiligen Kontext kennen und deren Einsatz auch begründen können. Wichtig immer dabei: transparent machen. Weshalb gerade diesen Ansatz und wozu, noch besser was passiert mit den Ergebnissen. Und dies möglichst zu Beginn. Übrigens eine eherne Regel aus der Bürgerbeteiligung. Simon Flossmann reist in seinem Beitrag kurz an, weshalb es wichtig ist, offen und transparent zu kommunizieren, ob, weshalb und wie eine Entscheidung getroffen wird. Ferner zeigt er die vier Grundvarianten einer Entscheidungsfindung in einem Team (die hierarische ausgenommen) auf.
Agile Leadership | Klares Bekenntiss für Werte und dienende Führung
Beim Begriff „Agile Leader“ schlagen zwei Herzen in meiner Brust. Das eine wehrt sich dagegen, dass das Attribut „Agile“ vor alles Mögliche vorangestellt wird, selbst vor Dinge, die für mich zunächst nicht mit „Agile“ zu tun haben, sondern sich auf Gelingensbedingungen im Allgemeinen beziehen. Das gilt im Übrigen auch für das Thema Führung. Auf der anderen Seite ist mir natürlich bewusst, dass wer sich auf die agilen Prinzipien beruft, auch eine andere Form der „Führung“ braucht, die die Umsetzung unterstützt. Der Artikel von Jay Rahman zielt primär auf die zweite Stoßrichtung ab, enthält aber auch Aspekte, die ich losgelöst von Lean oder Agile als Kernelemente einer guten, gelingenden Führung verstehe. Was mir allerdings fehlt, ist hier das klare und eindeutige „Bekenntnis“ am Ende des Tages einen Beitrag leisten, gute Ergebnisse zu liefern, die einen echten Wert erzeugen.
https://www.scrum.org/resources/blog/10-commitments-agile-leader
Team Topologies | Eine Einführung
Eines der wenigen „Frameworks“, dass in das ich mich noch nicht vertiefend eingelesen habe, ist die „Team Topology“. Im Framwork werden vier Typen von Teams unterschieden
- Stream Aligned Teams (Wertstrom ausgerichtet)
- Platform-Teams (standardisierten Bereitstellung ihrer Dienste als Plattform)
- Complicated-subsystem Teams (Kooperation über mehrere Teams hinweg an einem Thema über Komponenten)
- Enabling Teams (unterstützen andere Teams bei der Implementierung einer neuen Fähigkeit)
Gerade in skalierten Umfeldern sicherlich hilfreich. Mit ein Grund, weshalb auch SAFe auf die Team Topology von Matthew Skelton und Manuel Pais verweist. Ich würde allerdings eher auf den Flight Levels setzen. Bei Letzteren finden wir uns im Flight-Level-System 2 wieder, bei dem es um die konkrete Ausgestaltung der Koordination und Zusammenarbeit verschiedener „Gerade in skalierten Umfeldern sicherlich hilfreich. Mit ein Grund, weshalb auch SAFe auf die Team Topology von Matthew Skelton und Manuel Pais verweist. Ich würde allerdings eher auf den Flight Levels setzen. Bei Letzteren finden wir uns im Flight-Level-System 2 wieder, bei dem es um die konkrete Ausgestaltung der Koordination und Zusammenarbeit verschiedener Teilsysteme (Teams) geht. Dazu mehr von Andreas Diehl:
https://digitaleneuordnung.de/blog/team-topologies/
Projekt oder Produkt? | Scrum ist ein Produkentwicklungsframework!
Alter Kaffee sollte eigentlich der „Diskurs“ darüber sein, ob Scrum ein Projektmanagementframework oder Produktentwicklungsframework ist. Für mich persönlich zumindest ist die Diskussion längst abgeschlossen. Ein Projekt ist ein einmaliges Vorhaben mit einem bestimmten Ziel. Das kann durch aus auf Produktentwicklung zutreffen. Muss aber nicht. Und es kann auf Scrum geführte Entwicklung zutreffen, muss aber nicht. Sprich: Scrum kann ich genauso wie Kanban oder fast jedes andere agile Framwork, auch nutzen um Projekte zu managen. Und doch macht es Scrum nicht zu einem Projektmanagementframework. Den nicht alles ist ein Projekt und nicht alles sollte ein Projekt sein. Insofern teile ich die Auffassung von Dave West, dass es um „Produkte“ geht, die wir mit Scrum entwickeln und nicht um Projekte.
https://www.scrum.org/resources/blog/why-scrum-all-about-products
Scrum als kalter Kaffee | Ist Scrum kalter Kaffee von gestern?
Und noch mal kalter Kaffee als Thema 😉 Ist Scrum kalter Kaffee fragt Marc Löffler, um das Ganze im Podcast zu vereinen. Natürlich ist Scrum nicht kalter Kaffee, auch wenn mittlerweile mit Scrum genauso viel Schindluder getrieben wird wie mit allen guten „Werkzeugen“, die irgendwann mal entwickelt wurden. Das ganz zum Nachhören im Podcast:
Toms Gedankenblog 