PRODUKTIVITÄT
Being busy | Wie das Effizienzhamsterrad in den Tunnelblick führt und wir am Ende effizient in die falsche Richtung strampeln
Being busy. Fröhlich im Hamsterrad der Effizienz die Runde drehen. Kennen sicherlich einige. Wir sind geschäftig, hoch effizient und – ups – in der falschen Richtung unterwegs. Kommt öfter vor. Oder wir sind derart ausgelastet, dass wir nur noch reagieren, statt mittel- bis langfristig zu antizipieren. Ein Thema, das mir öfter begegnet. Übrigens nicht nur auf individueller Ebene. Nein, sogar auf Organisationen hochskaliert. Gut, ich bin mittlerweile sehr sensibilisiert. Aus verschiedenen Gründen. Und wie es so sein soll, werde ich sofort hellhörig, wenn ich Artikel wie Steffen Hartmann entdecke, die genau auf das Thema Bezug nehmen. Schön auf den Punkt bringt er, wie der „Tunnelblick“ wieder besseren Wissens dazu führt, dass die Organisation in die Falle geht. Meister Konfus lässt grüßen.
https://blog.mayflower.de/14281-busyness-as-usual.html?cookie-state-change=1668371059566
Klarheit | Warum Klarheit für ein gutes Zeitmanagement so wichtig ist
Klarheit ist für viele zentrale Voraussetzung. Gerade um aus der Being-Busy-Falle auszubrechen. Klarheit bedeutet zu verstehen, was es wirklich bracht und verhindert, dass wir strack in die falsche Richtung tredeln. Und genau dieses Thema steht im Fokus der aktuellen Podcastfolge von Ivan Blatter, der sehr hörenswert ist:
https://ivanblatter.com/podcast/klarheit-basis/
Demut und Bescheidenheit | Wege Demut in Besprechungen mit Leben zu füllen
Demut und Bescheidenheit sind Kennzeichen für ein gutes Zusammenarbeiten. Sich selbst zurückzunehmen und andere in den Fokus zu stellen, Interesse zu zeigen fördert die Zusammenarbeit. Auch in Besprechungen. Und damit auch die Besprechungsqualität. Eine Erfahrung, die ich in der Vergangenheit bereits mehrfach machen konnte und aus eigener Erfahrung bestätigen kann. Vor diesem Hintergrund empfehle ich gerne den Beitrag von Dan Rockwell zum Thema Vorleben einer demütigen Haltung in Besprechungen:
https://leadershipfreak.blog/2022/11/10/7-ways-to-teach-humility-in-team-meetings/
Unterstützung finden | Mit „Wisdom Circle“ kollegiale Beratung erhalten
Dan Rockwell bezieht sich zwar auf Führungskräfte, aber ich würde sagen, dass die Idee sich nahtlos auf alle Rollen übertragen lässt, in denen wir unterwegs sind. Einzelkämpfertum ist ungesund. Bringt uns nicht weiter. Ich arbeite gerne mit anderen zusammen, binde sie in die Entwicklung meiner Ideen ein. Das Feedback hilft mir, neue Impulse zu entwickeln, Irrtümer aufzudecken, Sackgassen zu erkennen und neue Türen zu entdecken. Dafür habe ich – je nach Thema und Umfeld verschiedene „Kreise“ aufgebaut, die ich sehr schätze. Wen auch eher „intuitiv“ statt strukturiert, wie es hier beschrieben wird. Die Struktur ähnelt sich.
https://leadershipfreak.blog/2022/11/08/leaders-need-support-too/
AGILE
Workflows gestalten | Workflows werden von Menschen gemacht
Der Hinweis von Jim Benson passt in die Lean-Welt ebenso wie in die agile Welt: Workflows werden von Menschen gemacht. Das wird erstaunlich oft vergessen. Zu schnell sind wir bei Werkzeugen und Hilfsmitteln statt bei er Frage, was brauchen die Menschen, damit die Dinge gelingen. Die Dinge, nicht die Menschen bestimmen dann den Arbeitsfluss und wir wundern uns mit Sicherheit eines Tages, warum die Ergebnisse nicht stimmig sind und Prozesse überbordend, eher ungesund gestaltet sind und das Gelingen schwerfällt:
https://www.modusinstitute.com/blog/workflow-is-made-of-people
Epics, Features und User Stories | Der Versuch eine Begriffsentwirrung
Ich musst erst herzlich lachen, als ich den Artikel von Mike Cohen in meinem RSS-Reader entdeckt habe. Was sind die Unterschiede zwischen Epics, Features und User Story? Genau diese Frage tauchte kurz vorher auch in meinem Umfeld auf. Ob da wohl das gleiche Team mit im Spiel war? Vermutlich nicht. Und doch genau im passenden Moment. Die Idee mit einem „Beispiel“ zu visualisieren und Klarheit zu erzeugen, hatte mir noch gefehlt und wenn ich dann noch auf eine Größe wie Mike verweisen kann, macht es auch noch leichter, den Vorschlag zu positionieren.
https://www.mountaingoatsoftware.com/blog/stories-epics-and-themes
Priorisierung von Featuren | Der Ansatz der wertgetriebenen Entwicklung
Feature im Product Backlog priorisieren, dass stelle immer wieder fest, ist eine große Herausforderung. Was häufig fehlt: passende Kriterien. Zu unklar, zu wenig griffig und unbestimmt ist in den meisten Fällen, was eigentlich „Mehrwert“ für wen erzeugt. Eine Situation, die ich schon öfter erlebt habe. Mit klarer Richtung, mit klaren Referenzkriterien fällt die Priorisierung sehr leicht. Man hat einen Fixpunkt. Die „wertgetriebene Entwicklung“ (schon etwas älter), die Simon Flossmann vorstellt, ähnelt einem Vorgehen, dass ich in ähnlichen Situationen präferiere und – ich würde behaupten – erfolgreich – genutzt habe. Im Prinzip ist es die Frage „Was wollen wir für wen erreichen und weshalb? Welchen „Nutzen“ stiftet es für den Abnehmer?“ die hier umgesetzt wird. Funktioniert übrigens auch sehr gut, wenn man sich Prozesse von recht nach links anschaut, um zu prüfen, wie man diese effektiver machen kann.
Retrospektiven | Data Science einsetzen, um Einsichten für die Retro zu gewinnen
Ich muss zugeben, beim Lesen des Artikels von Dr. Ina Humpert und Ronja Köhling, wurde mir klar, dass ich bestimmte Möglickeiten von JIRA noch gar nicht kannte. Peinlich. Dabei schaue ich mir schon sehr gerne mal „Daten“, um Abweichungen zu suchen, die auf mögliche Verbesserungen hindeuten. Und dies, obwohl ich bei KPIs eher vorsichtig bin, auch weil ich der Meinung bin, dass man diese mit kritischer Vorsicht genießen muss. Gerade die Velocity ist für mich allein wenig aussagefähig. Sie sagt etwas über den Output aus, aber nicht über das Outcome, die Werthaltigkeit der Ergebnisse und mögliche Blockaden aus. Und doch können Metriken in der Kombination einiges verraten, nämlich wo es sich lohnt tiefer zu bohren. Von daher werde ich mir den Artikel in Ruhe ein 3. und 4. zu Gemüte führen mal schauen, was ich für mich mitnehmen kann.
https://t2informatik.de/blog/data-science-in-retrospektiven-nutzen/
Scrum in große Organisation | Nicht einfach, aber auch nicht unmöglich
Scrum in Großunternehmen funktioniert nicht? Quatsch. Funktioniert. Davon bin ich überzeugt. Klar, in einem großen Unternehmen gibt es viel Schnittstellen und so ein Scrum-Team ist in ein nicht ganz einfaches, weil doch mindestens kompliziertes Umfeld eingebunden. Aber es funktioniert. Ich durfte bereits solche Teams erleben. Im Prinzip trifft es der letzte Absatz des Blogbeitrags von David Pereira auf den Punkt: Nicht nur die Spielregeln sind von Bedeutung, auch wie die Spieler das Spiel spielen. Wie gesagt, es ist nicht einfach – aber keinesfalls unmöglich.
https://medium.com/serious-scrum/scrum-doesnt-work-for-big-companies-how-true-is-that-8fd5bf1ae817
SAFe I| Ein empirischer Blick auf das Skalierungsframework
Ich bin was SAFe betrifft, eher der Fraktion der Skeptiker zu zuordnen. Das hat Gründe, die gar nicht so selbst mit dem Framework selbst so sehr zusammenhängen, da es bekanntermaßen bewährte Methoden, Ansätze und Praktiken zusammenführt und versucht zu einem großen Werkzeugkoffer zusammenzuführen, die Bedürfnisse skalierter Umfelder gerade in große Konzern bedient. Das ist durchaus legitim. Problematisch sind meines Erachtens die Vielzahl an Zertifizierungen mit den entsprechenden Kosten und schirre Wirkmächtigkeit des Werkzeugkastens, der fast schon wie eine Blaupause auf viel wirkt und in Folge oft das notwendige reflektierte Auseinandersetzen vermissen lässt. Die hohe Komplexität, die SAFe mit sich bringt, sehe ich ebenfalls sehr skeptisch, weil Skalierung ohne hin schon in komplexen Umfeldern stattfindet und hier zusätzlich verstärkt werden könnte. Und doch muss ich bei aller Skepsis zugeben, dass SAFe Elemente bietet, die hilfreich sind. Die kritische Auseinandersetzung mit Frameworks ist wichtig und gut. Ideologische Grabenkriege sind allerdings nicht förderlich. Daher gefällt mir die evidenzbasierende Betrachtung von Christiaan Verwijs auf SAFe und auffordert, weg vom Framework mehr den Blick auf „Qualität der Ergebnisse“ und Prozessgesundheit zu achten. Wenn beides passt, spiel das Framework ohnehin eine untergeordnete Rolle.
https://medium.com/the-liberators/in-depth-is-safe-really-that-bad-ed5c5c706e42
SAFe II | Warum SAFe oft nicht die beste Lösung ist …
Und wenn ich schon anführe, dass ich SAFe gegenüber eher skeptisch bin, bietet sich der Beitrag von Christ Knecht an, der aufzeigt, was die Punkte sind, die meine Skepsis gegenüber SAFe auslösen. Wie schon erwähnt, es ist nicht alles schlecht. Es gibt dennoch einige sehr kritische Punkte, die gewürdigt werden sollten. Und wie oben schon erwähnt, am Ende zählen die Qualität der Ergebnisse und der Prozesse. Das sollte immer an erste Stelle stehen. Mit einer der Gründe, warum ich mich seit längerer Zeit verstärkt mit den Wurzeln im Lean Management beschäftige, die sehr viel wertvollen Input hierfür liefern.
https://digitalien.org/knecht/safe-ist-nur-eine-mittelgute-idee
Schattenseiten der Agilität | Wenn sie vom eigentlichen Problem „ablenkt“
Der Blogpost von Marcus Raitner ist kurz und prägnant. Mit dem, was er zum Ausdruck bringt. Die Beobachtung, die diesem Blogpost zugrunde liegt, dürfte reflektierten Agilisten mehr als bekannt vorkommen. Agilität ist in der Breite angekommen. Auf dem Papier. Und doch dient sie als Rechtfertigung, die „Verantwortung“ abzuschieben, statt die wahren „Ursachen“ im System anzugehen. Wenn es mit der Agilität nicht klappt, dann liegt es am Team oder dem Mindset der Einzelnen. Nicht am System drumherum, nicht an der Führung, nicht an den Rahmenbedingungen. Aber halt, da war doch noch was? Genau. Der Fokus ist falsch. Aber es ist einfach, statt echte Verantwortung zu übernehmen und die tiefergehenden Wurzeln anzugehen, lieber weiterhin Schuldige suchen. Und ja, Agilität selbst macht es zum Teil sogar möglich. Teams sind ja selbstorganisiert und sollen gefälligst selbst die Hindernisse beseitigen. Auch diejenigen außerhalb ihrer Einflusssphäre.
Servant Leadership | Die oberste Direktive agiler Führung
Ein Beitrag von Rob Galen ist mir dieser Tage besonders in Auge gestochen. Weshalb? Er hat die Rolle der Führungskräfte im Zuge von Transformationsprozessen im Fokus. Weiter oben habe ich bereits auf Marcus Raitner verwiesen. Gefühlt gehören die Beiträge für mich zusammen. Es geht um die Rolle der Führung im Kontext der Agilität. Und da gibt es noch viele Baustellen. Führungskräfte, die sich als „dienende Führung“ verstehen, so meine Hypothese, arbeiten verantwortungsvoll am System, statt die Verantwortung unter dem Vorwand der Agilität abzuschieben.
https://rgalen.com/agile-training-news/2022/7/3/the-real-elephant-in-the-room
Kanban | Prinzipien und Praktiken
Ich bin bekennender Kanban-Fan. Die 6 Kernprinzipien und 6 Kernpraktiken enthalten enorm viel hilfreiches Futter für eine Lernende, sich beständig weiterentwickelnde Organisation. Apativ, offen und doch Rahmen setzend. In meine Augen wird Kanban noch viel zu oft unterschätzt und auf „Visualisierung“ und „WiP-Limit“ reduziert, ohne das Potenzial auszuschöpfen. Auch wenn der Beitrag von Ninja Granzow nicht wirklich neue Erkenntnisse liefert, möchte ich die Gelegenheit nutzen, nochmals auf die Grundlagen zu verweisen:
https://www.agile42.com/en/blog/kanban-principles-practices
Agilität | Weshalb?
Wer mich kennt, der weiß, dass ich gerne nach dem Weshalb frage. Das Weshalb als Ausgangspunkt, um zu verstehen, was wir erreichen wollen. Wenn wir besser verstehen, was wir für wen erreichen wollen, gelingt uns das „Liefern“ der gewünschten Ergebnisse leichter. Das gilt auch für die Frage, weshalb wir Agilität anstreben. Nach Felix Stein sind es vier Cluster: Discovery, Delivery, Reparatur, Resilienz. Neugierig? Hier geht es weiter:
https://www.lean-agility.de/2022/11/discovery-delivery-reparatur-resilienz.html
Toms Gedankenblog 