PRODUKTIVITÄT
Umgang mit Fähigkeiten | Weshalb ein Hammer zwar ein gutes Werkzeug ist, aber im falschen Kontext verwendet, eine schlechte Idee ist
Der richtige Umgang mit Werkzeugen ist eine „Kunst“ für sich. Ein Hammer ist genau das richtige Werkzeug für einen bestimmten Zweck, nämlich Nägel einzuschlagen. Aber Schrauben kann ich damit nicht drehen. Dazu brauche ich einen Schraubenzieher, mit dem ich aber keine Nägel in eine Wand oder ein Brett treiben kann. Ähnlich verhält es sich mit unseren Fähigkeiten, die wir im Laufe der Zeit entwickeln. Dan Rockwells Blogpost erinnert mich ein wenig an das Buch „Leadership: Myth and Reality“ von Stanley McChrystal, Jeff Eggers und Jason Mangone (Redline 2021). Fähigkeiten können in einem Kontext sehr wertvoll sein, aber in einem ganz anderen zu einem Problem werden. Dafür ein Bewusstsein zu entwickeln, halte ich für extrem wichtig. Das gehört für mich zum reflektierten Handeln. Zu erkennen, wann die eigenen Fähigkeiten unpassend sind und gegebenenfalls zurückzutreten, jemandem mit den passenden Fähigkeiten den Vortritt zu lassen und die eigenen Fähigkeiten entsprechend weiterzuentwickeln, zu lernen, ein neues „Werkzeug“ sinnvoll einzusetzen, ist manchmal eine Herausforderung. Aber es hilft, über sich selbst hinauszuwachsen.
https://leadershipfreak.blog/2024/05/10/my-battle-with-a-tractor-tools-make-the-job/
Entschleunigung | Die bewusste Entschleunigung ist als wertvolle Ressource
Wir leben in einer schnelllebigen Welt, in der Nachrichten in Sekundenschnelle um die Welt gehen. Was wir vergessen: Gute Entscheidungen brauchen ihre Zeit. Oder wie der Volksmund sagt: Gut Ding will Weile haben. Die bewusste Entschleunigung, wie sie Leo Babauta anregt, scheint mir genau das Richtige zu sein, was wir als Gegengewicht zu unserem Geschwindigkeitsrausch brauchen. Kreativität, gute Entscheidungen und „innere Ruhe“, all diese Dinge brauchen Zeit und Geduld oder anders gesagt: bewusste Entschleunigung.
https://zenhabits.net/slow-retreat/
Obsidian | Plugin für Zeitstempel
Liebe Obisidian-Fans aufgepasst: Thomas Mathoi hat wieder ein spannendes Plugin entdeckt, das für Euch interessant sein könnte. Mit dem Plugin „Update time on edit“ könnt Ihr die Änderungshistorie Eurer Notizen besser nachvollziehen. Mehr dazu unter folgendem Link:
https://www.mathoi.at/2024/05/08/das-update-time-on-edit-plugin-fuer-obsidian/
Wozu | Eine der zentralen Fragen
Nicht nur im Kontext der Bürgerbeteiligung ist das Weshalb und Wozu extrem wichtig. Ich habe vor Jahren über ein Art Of Hosting Training gelernt, wie wichtig zu Beginn es ist, zu klären, was mit den Ergebnissen passiert und dass es zentral für den Erfolg ist, immer wieder das Wozu klar zu definieren. Das gilt im Kleinen, wie im Großen. Gib Deinen Mitmenschen das „weil“ mit und Du wirst sehen, wie offen sie Dir gegenüber sind.
https://demokratie.plus/227-wieso-weshalb-warum/
LEAN
Kritik | Hat Lean seine Seele verloren?
Im Blog von Bob Emiliani bin ich auf ein fiktives Interview mit Taiichi Ohno gestoßen, dem wir unter anderem Kanban verdanken. Von verschiedenen Leuten aus dem TPS-Umfeld habe ich schon kritische Töne zu „Lean“, wie es oft gelebt wird, gehört. Und auch mir als Halbwissenden ist immer wieder eine Diskrepanz zwischen angelsächsischer und japanischer Prägung aufgefallen. Vieles wurde „oberflächlich“ übernommen, die dahinter stehenden Prinzipien gingen leider oft genug verloren. Genau das nehme ich als Kritikpunkt wahr.
https://bobemiliani.com/taiichi-ohnos-view-of-lean/
AGILE
Schätzung | Weshalb agile Projekt sich „verspäten“ …
Jede Schätzung, so gut sie auch sein mag, ist eine Wette. Je komplexer der Bereich, desto größer ist die Wahrscheinlichkeit, dass die Schätzung zutrifft. Das liegt in der Natur der Sache, wie Mike Cohn zeigt. Es wird nur gerne vergessen. Prognosen in die Zukunft sind immer mit „Unsicherheiten“ behaftet. Und so sollte es auch nicht verwundern, wenn in hochkomplexen Umfeldern die Prognosen nicht die zuverlässigsten sind. Das liegt in der Regel nicht daran, dass das Team nicht gut genug ist oder schlecht arbeitet, sondern daran, dass wir bei komplexen Herausforderungen nur schwer alle Fakten erfassen können: Wir kennen sie schlicht und einfach oft noch nicht. Genau diese Unschärfen lassen sich nur bedingt kalkulieren, auch wenn der Artikel vorschlägt, Puffer einzubauen, bleibt es eine Wette mit Risiko.
https://www.mountaingoatsoftware.com/blog/top-reason-your-projects-are-late
Scrum Master:in | Wenn Scrum Master:innen zum begrenzenden Faktor werden
Vor ein paar Tagen hatte ich im privaten Kontext ein interessantes Gespräch, aus dem ich am Ende heraushören konnte, dass jemand ungute Erfahrungen mit Scrum Master:innen gemacht hatte. Wie ich herausgehört habe, war hier jemand eher „übergriffig“ am Werk. Was mir erzählt wurde, ähnelte in weiten Teilen den Punkten, die Ciprian Banica beschreibt. Zumindest habe ich einige Punkte wiedererkannt. Und ja, ich denke sehr wohl, dass Scrum Master:innen durchaus gut gemeint, zu viel des Guten tun und so ein Team behindern können. Gerade deshalb brauchen wir selbstkritisch reflektierende Scrum Master:innen und Agile Coaches, die nicht nur gut in Scrum und anderen Frameworks ausgebildet sind, sondern auch die Fähigkeiten und Fertigkeiten mitbringen, sich selbst beständig zu hinterfragen.
https://www.scrum.org/resources/blog/can-scrum-master-limit-their-team
Coaching Haltung | Nicht nur für Scrum Master
Achtung: Scrum Master und Agile Coaches sind keine „Coaches“ im engeren Sinne. Sie nehmen eine Coaching-Haltung ein und wenden Coaching-Techniken an, sind aber keine Coaches im Sinne der Definition. Das wird gerne vergessen und führt dann zu dem bereits erwähnten „übergriffigen“ Verhalten. In der Rolle Scrum Master oder auch Agile Coach gibt es einen Auftrag der Organisation unterstützend zu wirken. In dieser Rolle agieren wir als laterale Führungskräfte. Das ist wichtig. Wir „coachen“ nicht im engeren Sinne (eines Coaches), sondern nehmen eine coachende Haltung ein. Diese coachende Haltung ist Gegenstand einer Reihe von Blogbeiträgen von Simon Flossmann:
Product Backlog Items | Wer schreibt sie jetzt?
Der Scrum Guide sieht die Verantwortung für das Product Backlog bei der Rolle des Product Owners. Das bedeutet aber nicht, auch das steht im Scrum Guide, dass die Rolleninhaber alles selbst machen müssen. Sie sind für das Ergebnis verantwortlich, können aber jede Hilfe in Anspruch nehmen, die sie dafür benötigen. Dazu gehört eben auch die Unterstützung durch das Scrum-Team bei der Formulierung der PBIs. Mehr dazu von Mary Iqubal:
https://www.scrum.org/resources/blog/who-writes-product-backlog-items-scrum
Produktvision und Scrum Events | Ein nicht zu unterschätzender Zusammenhang
Die Produktvision und die Scrum Events sind enger miteinander verbunden, als vielen bewusst ist. Ähnlich wie der Nordstern in der Verbesserungsmatrix ist die Produktvision der Bezugspunkt, der den Kurs bestimmt. Dies gilt auch für die einzelnen Events wie Daily, Retrospektive, Review … Der Artikel von Lavaneesh Gautam regt an, die Produktvision in den einzelnen Scrum Events entsprechend zu nutzen.
https://www.scrum.org/resources/blog/product-vision-scrum-events
Toms Gedankenblog 