#LINKSDERWOCHE | 42/2022: Produktivität, Lean und Agile

PRODUKTIVITÄT

Tagebuch schreiben | Warum es eine gut Idee ist und wie es gelingt?

Ich schreibe kein klassisches Tagebuch. Eher eine Art Journal, in dem ich Ideen/Gedanken/Beobachtungen und ähnliche Dinge, die mir im Lauf des Tages begegnen. Allein dies hilft mir, wesentlich reflektierter zu sein und den Kopf freier zu bekommen, als wenn ich es nicht tun würde. Diesen Weg habe ich für mich durch Ausprobieren entdeckt. Es gibt allerdings einige Wege, ein Tagebuch als Reflexion zu nutzen. Und ich kann dem Raten probiert es aus. Egal wie, es hilft bei der Reflexion ungemein. Ich kann es daher nur empfehlen. Wie auch Ivan Blatter, der mit seiner Podcastfolge genau dies aufzeigt.

https://ivanblatter.com/podcast/287-tage/

Selbstzweifel | Warum Selbstzweifel gut sind

Ein gesundes Selbstvertrauen schadet sicherlich nicht. Zu viel Vertrauen in sich selbst endet allerdings schnell in Fehlentscheidungen und Arroganz. Das Pendant sind Selbstzweifel. Aber auch nur in einem gesunden Maß. Selbstzweifel als Gegengewicht zum Selbstvertrauen halte ich für sehr, sehr wichtig. Das reflektierte Bewusstsein über die eigene Schwächen und Fähigkeiten auf Basis der bewussten Wahrnehmungen der eigenen Erfahrungen, Fehlschläge und Erfolge. Insofern kann ich den folgenden Beitrag von Dan Rockwell zur Lektüre guten Gewissens empfehlen.

https://leadershipfreak.blog/2022/10/13/the-insane-side-of-self-belief/

LEAN

Killerphrasen | Wie Killerphrasen „Verbesserungen“ im Keim ersticken

Ein schöner Artikel von Götz Müller ist mir dieser Tage in die Hände gefallen. Im Prinzip sagt es schon die Überschrift. Die Art und Weise, wie wir kommunizieren, wenn jemand Probleme anspricht, führt dazu, ob wir Verbesserungen im Keim ersticken oder es ermöglichen. Offen auszusprechen, dass man eine Beobachtung gemacht hat, für die man noch keine Lösung hat, ist wichtig. Weil man in der gemeinsamen Reflexion Lösungen erarbeiten kann. Würde ich das immer wieder ab, ersticke ich bereits im Keim jedes Engagement im Sinne einer „Verbesserungskultur“. Dies kommt, wenn man genau hinhört, öfter vor, als uns liebt sein dürfte.

https://www.geemco.de/artikel/warum-loesungen-nicht-immer-loesungen-sind/

Psychologische Sicherheit | Voraussetzung, um Kaizen mit Leben zu füllen

Zum bereits erwähnten Artikel von Götz Müller passt auch seine Podcastfolge „Kaizen2go“ rund um psychologische Sicherheit im Lean Kontext. Eine Voraussetzung, um überhaupt offen über Verbesserungen und Weiterentwicklung, Probleme und Hindernisse sprechen zu können.

https://www.geemco.de/artikel/kaizen-2-go-301-psychologische-sicherheit-und-resilienz-im-lean-kontext/

Losgrößen | Weshalb kleine Losgrößen?

Eigentlich sollte man meinen, je mehr vom Gleichen zu produzieren ist gut, aber Toyota ist einen anderen Weg gegangen und hat auf kleine Losgrößen in der Produktion gesetzt. One-Piece-Flow gilt als Ziel, dass nicht immer erreichbar ist. Weshalb ist das das so? Und wie kriegt man diese mit den Bedürfninissen der Massenproduktion in Einklang? Hierzu hat Christoph Roser eine Artikelserie begonnen, die Licht ins Dunkel bringen kann.

https://www.allaboutlean.com/reduce-lot-size-3/

AGILE

Scrum und Kanban kombiniert | Geht das überhaupt? Und wenn ja, wie?

Ich bin ein großer Freud von Scrum und Kanban. Beides zwei Ansätze, die ich sehr schätze und auch gerne kombiniere. Dass sich beides kombinieren lässt, ist eigentlich hinlänglich bekannt. Dafür gibt es schon ausreichend Belege. Was ich allerdings nicht gut finde sind „Rosinenpickerei“, bei der man sich aus den beiden Ansätzen, das rauspickt was einem gefällt und zusammenwurschtelt, ohne sich vorher Gedanken zu machen, warum und weshalb die Kernelemente wichtig sind. Ich habe nichts dagegen gegen Reflektiertes einpassen in den eigenen Kontext, nur um es klarzustellen, aber die Kernelemente sind nicht ohne Grund Kernelemente. Und da hört dann der Spaß auf, weil dann eben das Zusammenspiel nicht mehr zusammenpasst. Und genau dies darf bei einer Kombination von Scrum und Kanban nicht passieren. Dessen sollte man sich bewusst sein, wie Barry Overeem hier verdeutlicht:

https://medium.com/the-liberators/can-teams-use-scrum-and-kanban-simultaneously-d5a0051a6b99

Ownership | Ohne Einfluss und Befugnisse keine Eigenverantwortung

Wie fördert man die Eigenverantwortung? Indem man die Verantwortung überträgt. Je mehr man die Eigenverantwortung einschränkt, desto weniger wird auch proaktiv Eigenverantwortung übernommen. Oder mit anderen Worten, wenn ich nichts entscheiden darf, warum sollte ich dann eigenverantwortliche handeln? Klingt schlüssig, oder? Tja, die Realität ist oft eine andere. Und dann wundert man sich, dass ein Team irgendwie nicht eigenverantwortlich aktiv ist. Warum sollten sie auch. Sie haben in diesen Fällen meist keine Entscheidungsbefugnis. Genau hierauf bezieht Simon Klees sich. Und in der Tat kann ich es bestätigen. Teams, die bei jeder Entscheidung von Dritten abhängig sind, lernen sehr schnell den Frust kennen, der dann dazu führt, dass die Verantwortung „wegdelegieren“. Naheliegend. Sie können nur für die Dinge Verantwortung übernehmen, die sie auch beeinflussen können.

https://medium.com/serious-scrum/i-keep-telling-my-team-to-take-ownership-but-they-just-wont-1da4cdab9d62

Sprintziele | 9 Prinzipien rund um gute Sprintziele

Das Sprintziel ist der „Kompass“ für den Sprint. Und ich bin fest überzeugt, dass ein gutes Iterationsziel immer eine gute Idee ist, weil es hilft, den Fokus als Team zu halten. Allerdings ist es nicht immer einfach ein wirklich gutes Sprintziel zu formulieren. Das erlebe ich in der Praxis immer wieder. Sehr hilfreich in diesem Kontext können die Prinzipien ein, die Stephan Wolpers hierzu definiert. Sie gehen über die reine Formulierung hinaus. Unter anderem halte ich es für extrem wichtig, offen auch mit den Anspruchsgruppen zu kommunizieren. Transparenz ist Trumpf.

https://dzone.com/articles/sprint-goal-principles

Produktziele | Weshalb Umsatz kein gutes Produktziel ist

Ich bin ein großer Fan des Toyota Nordsterns. Und das liegt mit unter auch daran, dass dort Kundenzufriedenheit, Qualität, kontinuierliches Lernen/Verbessern und Wertschätzung aller Beteiligten im Wertschöpfungsprozess zentral verankert sind. Man findet keine Finanzkennzahlen oder sonst übliche Unternehmensindizes in der richtunggebenden Vision. Es geht immer um Wertschätzung und konsequente Ausrichtung auf Bedürfnisse auf die Wertschöpfung für diejenigen, die am Ende das Ergebnis abnehmen. Das auf Produktziele heruntergebrochen, wie es Magdalena Firlit tut, halte ich für zentral. Den, wer konsequent die Bedürfnisse derer bedient, die die Leistung abnehmen, muss sich am Ende um seinen Umsatz nicht viel Gedanken machen.

https://www.scrum.org/resources/blog/revenue-good-product-goal

Scrum Master und Product Owner | Wie können Scrum Master*innen ihre Product Owner*innen wirklich unterstützen

Das gute Zusammenspiel innerhalb des Scrumteams über alle Rollen hinweg ist für das Gelingen ein zentraler Erfolgsfaktor. Und das gelingt meist dann, wenn Scrum Master*innen ihre Rollen so verstehen und wahrnehmen, dieses Gelingen zum Ermöglichen und zu unterstützen. Dazu gehört die jeweiligen Rollen in Scrum (und natürlich im Umfeld) „befähigen“. Aber wie unterstützt man als Scrum Master*in einen Product Onwer*in sinnvoll? Magdalena Kucharska versucht hierauf eine Antwort zu geben und diese geht über die „methodische Beratung“ weit hinaus.

https://www.scrum.org/resources/blog/how-can-scrum-master-support-product-owner

Übertragung in den Folgesprint | Kritisch oder nicht? Auf was es ankommt

Wenn meine Beobachtung zutrifft, ist es eine Falle, in die nahezu alle frischgebackenen Scrum Master*innen tappen: Überbewertung von Sprintübertragungen. Klar sind sie nicht schön. Aber sie kommen in jedem Team vor. Viel wichtiger finde ich jedoch, was haben wir an werthaltigen Ergebnissen erzielt und welche Erkenntnisse haben wir gewonnen. Darauf zu achten, halte ich viel spannender. Und genau hier sollte man bei „Sprintübertragungen“ darauf achten. Was lernen wir daraus? Was haben wir gelernt, um es besser einzuschätzen und welche Erkenntnisse ziehe wir daraus? Ist es überhaupt sinnvoll weiterzuführen? Was sollten wir stattdessen tun? Ist das „Commitment“ noch zielführend? Insofern kommt mir einiges aus dem Blogpost von David Pereira bekannt vor.

https://medium.com/serious-scrum/how-bad-are-sprint-carry-overs-banish-or-welcome-them-7a5ce0dc9ec6

Scrum „lernen“ | Weshalb Scrum in die Umsetzung zu bringen herausfordernd ist

Die Leichtgewichtigkeit von Scrum fasziniert mich seit meiner ersten Begegnung mit dem Rahmenwerk vor 14 Jahren. Und doch wusste ich auch gleich von Anfang, Scrum zu implementieren ist eine Herausforderung. Allein meine Begeisterung ist nicht bei jedem in meinem damaligen Umfeld auf Gegenliebe gestoßen. Schließlich verlangte Scrum ein radikales Umdenken. Und viele der von Mike Cohen genannten Herausforderung habe gleich zu Beginn meiner ersten Gehversuche erleben dürfen. Ich würde ja gerne sagen, dass sich das geändert hat – aber leider habe ich immer wieder dieses Déjà-vu in der Praxis 😉 Okay, ich kenne es ja mittlerweile und habe damit gelernt umzugehen und es macht mir sogar Spaß, sonst würde ich meinen Job nicht machen.

https://www.mountaingoatsoftware.com/blog/8-reasons-scrum-is-hard-to-learn-but-worth-it

Besser kein Scrum | 10 Kontexte in denen Scrum keine gute Idee ist

Bei aller Begeisterung für Scrum, es gibt Kontexte, da rate ich schlicht und ergreifend davon ab, Scrum zu implementieren. Einfach, weil Scrum hier nicht der passende Weg ist. Scrum ist ein Rahmenwerk, das für die Entwicklung komplexer Lösungen gemacht wurde. Es macht zum Beispiel wenig Sinn, die Lohnbuchhaltung jeden Monat neu zu erfinden. Wir wissen, wann wir was tun müssen, damit die Gehälter jeden Monat ihren Weg auf das Konto der jeweiligen Kolleg*innen findet. Das war jetzt relativ einfach. Manchmal ist es schwieriger. Mit den 10 Punkten, die Willem-Jan Ageling auflistet, wird es etwas leichter, einzuordnen, ob Scrum eventuell nicht geeignet ist. Am Ende ist aber auch nur eine Hilfestellung. Keine Checkliste. Das ist wichtig. Es ist eine Reflexionshilfe.

https://medium.com/serious-scrum/10-situations-where-scrum-is-a-burden-for-developers-469d9afdf9d1

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden /  Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden /  Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden /  Ändern )

Verbinde mit %s

Diese Seite verwendet Akismet, um Spam zu reduzieren. Erfahre, wie deine Kommentardaten verarbeitet werden..