PRODUKTIVITIÄT
Deep Work: Wann ist es sinnvoll? Wann nicht?
Deep Work ist durch Cal Newport sicherlich vielen ein Begriff. Er hat ein gutes Buch zum Thema geschrieben, dass ich zu lesen lohnt. Das Ganze etwas pragmatisch aus der praktischen Brille, schaut sich Ivan Blatter in seinem Podcast an, wenn er die Frage aufwirft, ob eigentlich alle immer Deep Work praktizieren müssen/sollen? Dazu gibt es, wie immer bei Ivan gleich noch ein paar praktische Tipps zur Umsetzung mit dazu. Wie immer kurzweilig und hörenswert:
https://ivanblatter.com/podcast/deep-work-alle/
Office 365: Lists
Ich mag keine Listenansichten und überhaupt stören mich bei vielen Aufgabentools, dass mir der Gesamtüberblick zu allen relevanten Informationen visuell nicht besteht. Deswegen nutzte ich Lists in Office 365 nicht wirklich und arbeite – zwischenzeitlich lieber – mit einem virtuellen Informationscockpit (Obeya-Room), das ich mir mithilfe eines virtuellen Whiteboards gebaut habe (und, in das ich mein Personal Kanban integriert habe). Das ist jedoch meine persönliche Vorliebe, die sich sicherlich nicht so ohne Weiteres übertragen lässt. Listen haben ihre Daseinsberechtigung und dafür gibt es schon seit einiger Zeit auf in Office 365 ein digitales Helferlein mit dem Namen Lists, dass sich in MS Teams integrieren lässt. Mehr dazu von Sigrid Hess:
https://www.teamworkblog.de/2021/04/microsoft-365-lists-einfache.html
Zeit nehmen: Wie wir es schaffen uns mehr Zeit für sinnvolle Aufgaben zu nehmen
Zeit hat man nicht, man nimmt sie sich. Klingt banal. Wir wissen: Ist es nicht. Wie schaffen wir es, dass wir die die Dinge, die uns besonders wichtig und sinnvoll erscheinen, besser in unseren Alltag integrieren? Leo Babauta beschreibt hierzu 6 Schritte. Einfach umzusetzen? Nicht ganz. Möglich? Ja. Effektiv? Auf jeden Fall.
https://zenhabits.net/meaningful-work-time/
Entzaubern: Mythen entzaubern bevor es zu spät ist
Es gibt hartnäckige Mythen in der Arbeitswelt, die einfach nicht aus der Welt zuschaffen scheinen. Diese steht im Fokus der Ausführungen von Dan Rockwell, der es auch schon in der Überschrift zum Ausdruck bringt: Weg mit ihnen, bevor sie zum Problem werden. Und sie werden zum Problem.
https://leadershipfreak.blog/2021/04/20/reject-this-myth-about-management-before-its-too-late/
Zeitfresser im Büro: Die 3 alte Bekannte und 15 weitere Freunde
Im Blogartikel von Sebastian Reimer werden insgesamt 18 Zeitfresser im Büro gelistet, von denen uns die meisten sicherlich sehr bekannt vor kommen. Insbesondere die Top 3 waren schon so häufig in den Links der Woche dabei … Spannend finde ich allerdings in diesem Beitrag „Lean“-Brille.
https://www.lean-service-institute.de/die-3-haeufigsten-zeitfresser-im-buero/
LEAN
Lean Thinking: Die Perspektive der Anderen einnehmen
Mit Lean Thinking assoziere ich eine Denkweise, bei der Prozesse und Abläuf aus Sicht der beteiligen Anspruchsgruppen betrachtet wird. Diese Gedanke findet sich übrigens nicht nur im Lean Management, sondern auch im agilen Bezug wieder. D. h. wir nehmen immer wieder die Perspektive von anderen Beteiligten ein und versuchen uns ins sie hineinzudenken, um besser zu verstehen. Jon Miller zeigt in in seinem Beitrag, wie dies aus einer Lean-Perspektive gelingen kann:
https://blog.gembaacademy.com/2021/04/19/going-out-of-our-minds-with-lean-thinking/
Kaizen: Problemlösungskomptenz verbessern lohnt sich immer
Den Beitrag von Josh Howell den ich nachfolgend verlinkt habe, ist jetzt nicht wirklich spekatulär. Aber zeigt eines sehr schön auf: Verbessere die „Problemösungskompetenz“ vor Ort und die Investition zahlt sich schnell aus. Warum? Weil es darum geht, Problem möglichst nah an den „Kunden“ zu lösen. Ganz im Sinne des Lean Thinkings. Wenn wir versuchen Problem „zentral“ zu lösen, sind wir vom Problem oft zu weit entfernt und stecken Unmengen an Ressourcen in große, technische Lösungen
Lean ist kein Zauberstab: Warum es keine Wundermittel gibt
Götz Müller beschreibt ein Phänomen, dass ich in Bezug auf Agiltät fast genauso erlebe und kenne. Wir sind jetzt lean (oder agil) und alle Probleme sind behoben. Pustkuchen. Ist nicht so. Kann ja auch nicht anders sein, auch wenn man sich es gerne wünscht. Mit dem Fingerschnippen und alle Probleme sind gelöst, würde ich zwar gerne können, weiß aber, dass dies nicht funktioniert. Und so ist auch hier. Man muss aktiv etwas tun. Wir bekommen zwar Hilfsmittel an die Hand, aber die zeigen uns in der Regel erst, wo das Problem liegt, dass es zu beheben gilt:
https://www.geemco.de/artikel/warum-lean-kein-zauberstab-ist/
AGILE
Agiles Manifest: Warum es (immer) noch Sinn macht
Ich bin ein Freund des agilen Manifests. Auch wenn der eine oder andere meint, man müsse es fortschreiben. Diese Notwendigkeit sehe ich übrigens nicht. Es ist für mich nach wie vor die Leitlinie, wenn ich die Frage, was Agilität ist, beantworten soll. Daher berufe ich mich auch gerne auf die Werte und Prinzipien, wenn ich Agilität erkläre. Leider hatte ich (noch) nicht das Glück, die Unterzeichner der agilen „Verfassungserklärung“ persönlich kennenzulernen, sondern muss mich auf Artikel wie von Ben Linders (der einige – nicht alle – erwähnt) verlassen, um zu verstehen, was die Autoren angetrieben hat. Das ist für mich wichtig, um den Sinn hinter dem agilen Manifest selbst besser zu verstehen und auch am Ende besser erklären zu können:
https://www.benlinders.com/2021/the-agile-manifesto-why-agile-makes-sense/
Selbstorganisation: Der Versuch Begriffsklärung
Der Begriff Selbstorganisation ist mittlerweile so weit verbreitet, dass er nahezu unreflektiert überall auftaucht. Und diese unreflektierte stört mich gelegentlich. Ja, ich weiß. Habe es neulich – in einem anderen Kontext – schon zu hören bekommen, ich soll doch mal bitte den Konstanzer Verwaltungwissenschaftler zu Hause lassen und Beißreflexe meiner akademische Sozialisation bei Seite legen. Will ich aber nicht. Nicht, wenn es um Selbstorganisation geht. Weil es durch aus Sinn macht, darüber zu sprechen, was man darunter versteht. Und das dieser Diskurs wichtig ist, belegt meiner Erachtens auch die Tatsache, dass im Scrum-Leitfaden zwischenzeitlich nicht mehr von Selbstorganisation, sonder von „selfmanaged“ die Rede ist. Die Gründe hier zu kann man in den diversen – auch in der Links der Woche – verlinkten Artikeln zu den jüngsten Änderungen im Scrum-Leitfaden sehr gut nachlesen. Daher verzichte ich darauf, sie hier aufzuführen. Aber was ist jetzt Selbstorganisation. Hierzu möchte ich auf zwei Beiträge verweisen, die ich für lesenswert halte. Einen Beitrag von Stephanie Borgert und eine Replik von Andreas Zeuch. Das es sich hier um zwei – sich in Teilen widersprechende – Meinungen handelt, ist übrigens ein großer Vorteil, um die Argumente prüfen und verbessern zu können.
https://www.changex.de/Article/essay_borgert_selbstorganisation_entfesseln
Autonomiefalle: Was passiert, wenn man die Autonomie erhöht ohne die Voraussetzung für autonme Entscheidungen zu schaffen
Im Blog von Felix Stein bin ich über folgenden Beitrag gestolpert, der sich mit der Autonomie-Falle beschäftigt. Die Autonomie-Falle beschreibt das Phänomen, dem wir immer dann begegnen, wenn wir in Organisationen beginnen, die Entscheidungsautonomie zu erhöhen. Grundsätzlich eine gute Sache. Nur es ist leider nicht immer ganz so einfach wie auch – der im Artikel erwähnte ehemalige U-Boot-Kapitän David Marquet erfahren durfte (ein sehr interessantes Buch übrigens). Es nicht damit getan, einfach Entscheidungen zu delegieren, man muss dabei auch ein paar Dinge berücksichtigen, den um Entscheidungen im Sinne der Gesamtorganisation treffen zu können, muss das erforderliche Wissen vorhanden entwickelt werden. Man sieht hier sehr schön, wie Selbstorganisation und höhere Autonomie der Entscheidungen eben nicht Selbstläufer sind, sondern durch aus erst einmal Arbeit bedeuten, bevor sie ihre Wirkung erzielen können.
https://www.lean-agility.de/2021/04/die-autonomie-falle.html
Product Owner: Wenn der/die Rolleinhaber*in zum Engpass wird …
Ralf Kruse greift in der verlinkten Podcast-Folge ein Thema auf, das durch aus Bedeutung hat. Und zwar mit erheblichen Auswirkungen auf ein Scrum-Team. Product Owner*innen haben eine wichtige Rolle in einem Scrum-Team. Eine Rolle, die man nicht unterschätzen darf. Und wenn diese passiert, wird der/die Rolleninhaber*in schnell zum Engpass. Das hat oft nichts mit der Person an solches zu tun, sondern ist sehr vielschichtig. Man sollte sich dabei vor Augen führen, dass viele POs immer noch aus der Rolle des klassischen Projekt- oder Produktmanagements kommen und entsprechend sozialisiert sind und/oder gar noch in klassischen Strukturen tätig sind. Das kann eine Ursache hierfür sein. Hier sind die Scrum Master gefragt, partnerschaftlich mitzuwirken, die jeweiligen Rolleninhaber dabei zu unterstützen sich zu entwickeln und nicht zum Engpass des Teams zu werden. Mehr dazu:
https://enablechange.de/2021/04/20/hilfe-mein-product-owner-wird-zum-bottleneck/
Scrum: So richtig an die Wand fahren …
Gelegentlich hilft es, sich vor Augen zu führen, wie man etwas richtig schnell an die Wand fährt. Beim „Paradoxen Brainstorming“ nutzt man diesen Effekt unter anderem auch. Man stellt sich vor, was man braucht, um das Projekt gegen die Wand zu fahren und leitet Maßnahmen ab, die dem Entgegenwirken. Marc Löffler hat Euch die Mühe abgenommen, Euch Gedanken zu machen, wie man eine Scrum-Implementation an die Wand fährt. D. h. alles was Ihr nach dem Anhören seiner Podcast-Folge tun müsst, ist Euch überlegen, was dann das Gegenteil, nämlich der Erfolgsfaktor ist und wie Ihr diesen umgesetzt bekommt. Außerdem habt Ihr erste Hinweise, auf was Ihr achten müsst, um frühzeitig entgegenzusteuern, damit Eure Implementation eben nicht an die Wand fährt.
Backlog I: Hilfreiche Fragen rund um den Backlog für Produc Owner*innen
Der Product Backlog ist mit eines der zentralen Werkzeuge des Product Owners. Damit zu Arbeiten kann sehr herausfordernd sein. Das ist eine Beobachtung, die ich in der Vergangenheit schon öfter gemacht habe. Gerade wenn die POs erst kurz Zeit von der klassischen Welt kommend agil arbeiten sollen. Herausforderungen löst man und dafür gibt es natürlich – Scrum ist ja nicht erst vor Kurzem entstanden – Erfahrungswerte, die glücklicherweise von auch geteilt werden. So wie in dem folgenden Beitrag von Stefan Wolpers, der hier mithilfe von Leitfragen unterstützt, besser zu verstehen, was zu tun ist. Achtung, es sind Leitfragen. Keine Checkliste, die man abhaken kann. Ich habe sie mir näher angesehen und denke, dass sie nicht nur für „Neulinge“, sondern auch für fortgeschrittene POs interessant sein dürften.
https://www.scrum.org/resources/blog/po-interview-questions-product-backlog-and-refinement
Backlog II: Wie prirosiere ich den Product Backlog?
Der Artikel von Cate Lawrence fasst einige bekannte Methoden der Backlog-Priorisierung zusammen. Es gibt da noch einige mehr, die ich ebenfalls gerne verwende/empfehle, hier aber nicht gelistet sind. Welchen Ansatz man idealerweise für sein Projekt wählt, hängt sehr stark von den Erwartungen der Anspruchsgruppen, der Art des Projekts und den Rahmenbedingungen ab, wobei sich im Kern alle Methoden ähneln. Es geht immer darum, den „Wert“ für die Anspruchsgruppen des Projekts effizient und effektiv zu erhöhen.
https://dzone.com/articles/how-to-prioritize-your-product-backlog
OKR: Die dunkle Seite der Macht
Wie alles auf der Welt haben auch OKRs nicht nur positive Seiten, sondern auch sie ihre Schattenseiten. Diese dunkle Seite der OKRs sind Gegenstand eins Gastbeitrag von Antoinette Weibel und Meike Wiemann im Blog der Corporate Rebels (den ich übrigens wärmstens empfehlen kann). Wie so oft ist auch hier die Kernaussage, dass etwas, was gut ist, sich verkehrt, wenn ich es übertreibe. Und dies gilt eben auch für die OKRs.
https://corporate-rebels.com/dark-side-of-okrs-and-why-we-should-care
MANAGEMENT UND LEADERSHIP
Sprache und Führung: Wie wir durch Sprache führen und unser Umfeld gestalten
Sprache – das wissen wir spätestens seit der „Entdeckung“ des Konstruktivismus – spielt eine nicht gerade unbedeutende Rolle und doch nutzen wir sie im Alltag oft unbewusst und unreflektiert. Wir erzeugen damit eine Wirklichkeit, die im Gegensatz stehen kann, zu dem, was wir eigentlich postulieren. Sprich, wir konstruieren uns durch die Sprache, die wir nutzen unsere Wirklichkeit. Das passiert in der Führung genauso wie in unserem sonstigen Alltag. Auf diesen Zusammenhang weist der Beitrag von Marcus Raitner hin, der gegen Ende seines Artikels sehr schön zeigt, wie wir durch die Fragen, die wir stellen, Entscheidungen lenken und beeinflussen, damit jedoch auch unsere Umwelt konstruieren.
Implizite Führung: Wie man über Kommunikation führt
Joachim Schlosser stellt das implizite Führen durch Kommunikation in einer zweiteiligen Artikelserie in den Fokus, die vollgepackt mit Praxistipps zum Thema ist. Der erste Teil bezieht sich auf den Kalender und E-Mail-Kommunikation, im zweiten bezieht er sich auf Teamchats und Teammeetings. Fast jeden der Tipps kann ich nur unterstreichen. Gerade in Zeiten, in denen die Führung auf Distanz höchste Relevanz hat, aber auch in der Zeit danach sind die Anregungen zielführend.
https://www.schlosser.info/implizite-fuehrung-1/
https://www.schlosser.info/implizite-fuhrung-2/
Klassische Führungsbremsen: Hartnäckige Probleme der Führung und ihre Lösung
Die 7 allgemeinen Prinzipien, die hartnäckige Probleme der Führung erklären, titelt Dan Rockwell. Da werde ich doch glatt hellhörig und schaue genauer hin. Und ja, es ist was dran. Zu nächst war ich versucht, diesen Beitrag unter Produktivität einzuordnen, dann habe ich mich doch entschieden, ihn hier unter Leadership und Management zu verlinken. Es sind genau die Punkte, die ich bei vielen Führungskräften immer wieder beobachte und erlebe, die er hier nennt, die diese Bremsen ihren Job richtig gut zu machen.
Toms Gedankenblog 