#LINKSDERWOCHE | 45/2023: Produktivität, Lean und Agile

Produktivität

Produktivität braucht Ineffizienz | Weshalb Effizienz nicht das Maß der Dinge ist

Um wirklich produktiv zu sein, müssen wir auch mal „ineffizient“ sein. Das klingt auf den ersten Blick komisch. Aber ich bin fest davon überzeugt, dass wir diese „ineffizienten“ Phasen des „Spinnens“ brauchen. Zum einen für unser Energiemanagement, aber auch als „Innovationsraum“, in dem wir unsere „Effektivität“ steigern, weil wir lernen, Dinge anders oder sogar besser zu machen, uns wieder auf das Wesentliche fokussieren können. So wie ich es im Blogbeitrag von Anna Koschinski wahrgenommen habe.

https://anna-livia.de/ineffizient/

Motivation/Fähigkeiten/Feedbackschleifen | Der richtige Rahmen zur Verbesserung der persönlichen Produktivität

Im Blog von J.D. Meier bin ich dieser Tage auf ein Framework gestoßen, das ich interessant finde. Es geht darum, einen Rahmen zu schaffen, der uns hilft, unsere persönliche Produktivität zu verbessern. In dem vorgestellten Ansatz kommen die Elemente Motivation, Fähigkeiten und Feedbackschleifen zum Tragen. Das passt zu mir. Wenn ich Veränderungen herbeiführen will, muss ich motiviert sein. Das heißt, ich muss es wollen und bewusst anstreben. Das Ganze muss zu meinen Fähigkeiten passen, sonst macht es wenig Sinn. Aus einem Nilpferd mache ich keine Gazelle. Das ist einfach so. Und ich brauche Feedbackschleifen, die mich besser werden lassen und gleichzeitig durch positive Verstärkung meine Motivation steigern. Das alles erklärt er ausführlich in seinem Artikel. Ein hilfreiches Reflexionsinstrument, das sicher für den einen oder anderen interessant sein könnte:

https://gettingresults.com/motivation-ability-and-feedback-framework/

Verbindlichkeit erzeugen | Meetings mit besseren Ergebnissen

Ein großes Thema, über das ich immer wieder stolpere: Verbindlichkeit. Ich weiß nicht, wie viele Sitzungen ich schon ohne konkrete Ergebnisse verlassen habe, wo ich mich am Ende gefragt habe, was ist das Ergebnis und was passiert damit. Da kann man mit ein paar Dingen sehr viel ändern. Man kann zum Beispiel, wie Dan Rockwell vorschlägt, von Anfang an die Erwartungen klären. Ich arbeite dazu gerne mit Fragen, die ich beantwortet haben möchte. Diese schicke ich allen Teilnehmern vorab als eine Art Agenda. Das ist einer von insgesamt fünf Vorschlägen, die interessant sein könnten. Auch die anderen vier finde ich spannend und hilfreich.

https://leadershipfreak.blog/2023/11/14/5-accountability-practices-that-guarantee-row-together/

Glaubensätze | Über den Umgang mit selbstlimitierenden Glaubensätzen

Wer hat keine Überzeugungen… Ich selbst ertappe mich immer wieder dabei. Und sie können manchmal ganz schöne Spielverderber sein. Genau um solche Glaubenssätze geht es im zweiten Beitrag von Dan Rockwell in den heutigen Links der Woche. Glaubenssätze, die uns selbst einschränken und damit im Weg stehen. Er listet fünf auf und zeigt, wie wir ihnen entgegenwirken können.

https://leadershipfreak.blog/2023/11/15/5-self-limiting-beliefs-that-defeat-leaders/

Lean

Jidoka I | Fehler nicht nur beheben, sondern ihre Ursachen beseitigen – bereits wen sie auftreten

Eine Idee zur Vermeidung von Verschwendung durch Fehler ist Jidoka. Es gibt Versuche, das Wort aus dem Japanischen ins Deutsche zu übersetzen. Meistens treffen sie nicht zu. Im Prinzip geht es darum, dass man erkennt, dass ein Fehler vorliegt. Man stoppt die Arbeit, geht auf Ursachenforschung (in die Tiefe) und leitet Maßnahmen ein, die eine Wiederholung verhindern. Klingt einfach. Aber Hand aufs Herz, wer macht das schon? Genau. Die wenigsten. Der Fehler wird behoben. Selten die Ursache. Fertig. Das macht das Jidoka-Prinzip, so einfach es auch sein mag, so unglaublich effektiv. Es stammt ursprünglich aus der Produktion, lässt sich aber auf fast alle Bereiche übertragen. Statt nur Fehler (schnell) zu beheben, gehen wir gleich in die Tiefe und suchen nach den Wurzeln des Problems, damit es in Zukunft nicht mehr passieren kann. Mit anderen Worten: Wir sorgen dafür, dass es nicht wieder passieren kann. Davon wünsche ich mir oft genug mehr. Mehr von Tim McMahon:

http://www.aleanjourney.com/2023/11/jidoka-find-issue-stop-and-fix-it.html

Jidoka II | Eine der tragenden Säulen des TPS

Und weil ich gerade Jidoka erwähnt habe, hier noch eine kleine Ergänzung: Jidoka ist eine der Säulen des Toyota Production Systems, wie Andre Kürzel schreibt. Übrigens: Wer mehr darüber erfahren möchte, dem empfehle ich Lean auf gut Deutsch von Mari Furukawa-Caspary.

https://leanbase.de/publishing/post/rfzdd-die-zwei-saulen-des-toyota-produktionssystem

Hoshin Kanri und Obeya | Strategische Steuerung mit Hosin Kanri und Obeya – wie die Verknüpfung Strategie und Operations mit Visualisierung gelingt

Ich erinnere mich an die Zeit, als die BSC (Balanced Score Card) der heißeste Scheiß in Sachen Strategie war. Heute reden viele von Objectives and Key Results. Ich frage mich immer öfter, warum so wenige Hoshin Kanri auf dem Schirm haben. Okay, hat keinen fancy und hippen Namen in Denglisch. Der Begriff kommt aus dem Japanischen. Nicht von ungefähr. Er kommt, man ahnt es, wieder einmal aus dem Toyota-Kontext. Für OKR-Anwender wird es sicher die eine oder andere bekannte Parallele geben, wie Feedback- und Anpassungszyklen. Etwas nachteilig finde ich die Bezeichnung KPIs. Die meisten sogenannten KPIs sind nach meinem Empfinden nicht wirklich Key Performance Indicators. Ein anderes Thema, das ich nur am Rande streife. Zurück zum Thema. Der Artikel von Norbert Evers ist für mich insofern interessant und spannend, weil er zeigt, wie Hoshin Kanri mit Obeya deutlich besser umgesetzt werden kann. Übrigens etwas, was sich auch auf OKR-Implementierungen übertragen lässt.

https://obeya-association.com/2023/11/08/hoshin-kanri-as-a-blueprint-for-your-obeya/

Agile

Ausbrennen verhindern | Wie man das Ausbrennen von Teams verhindert

Sich für etwas zu begeistern und es gerne zu tun, ist ein ehrenwertes Ziel. Aber es hat auch eine Kehrseite. Wer für etwas brennt, läuft auch Gefahr, auszubrennen. Gerade sogenannte High-Performance-Teams zeichnen sich dadurch aus, dass sie mit Begeisterung bei der Sache sind. Genau das, was wir eigentlich anstreben. Aber wie alles im Leben hat auch das seine Schattenseiten. Nicht umsonst heißt es, auf ein nachhaltiges Arbeitstempo und -pensum zu achten, um nur ein paar Stichworte zu nennen. Das ist mitunter gar nicht so einfach, wer will schon bremsen, wenn es mal richtig gut läuft. Fakt ist aber auch, dass ein Team-Burnout sehr schnell zu einer sehr teuren Angelegenheit werden kann. Es liegt also durchaus im wirtschaftlichen Interesse, das Ausbrennen eines Teams oder einzelner Mitglieder zu verhindern. Gute Scrum Master*innen u.ä. wissen dies und scheuen sich nicht davor, entsprechend aktiv zu werden. Auch dies ist eine Eigenschaft, die gute Servant Leader auszeichnet. Der Blogbeitrag von Christiaan Verwijs geht näher darauf ein und gibt erste Impulse, wie man im Team gegebenenfalls gegensteuern kann – übrigens ohne zu sehr in die Selbstorganisation des Teams einzugreifen.

https://medium.com/the-liberators/in-depth-how-to-prevent-high-performing-teams-from-burning-out-409aa9896caa

Balance zwischen Führung und Autonomie | Führen ohne zu Bevormunden – ein beständiges Abwägen und Ausbalancieren

Fast passend zum vorhergehenden Thema habe ich einen Beitrag von Mary Iqubal im Gepäck. Es geht um die Balance zwischen Führung und Selbststeuerung des Teams. Eine Beobachtung, die ich auch schon in der Praxis machen durfte, sind Scrum Master*innen, die über das Ziel hinausschießen und – nicht zu wenig – sondern zu viel steuernd eingreifen. Das schadet dem Ganzen genauso wie das andere Extrem. Was ich aus meiner Erfahrung sagen kann, ist, dass diese Balance kein leichtes Unterfangen ist. Das erfordert schon einiges an Erfahrung und Fingerspitzengefühl, was man eben nicht in einem zweitägigen Workshop lernt. Und, auch das muss ich zugeben, es ist in jedem Team und in jedem Umfeld auch für erfahrene Scrum Master/Agile Coaches immer wieder eine Herausforderung im Sinne eines Herantastens, das einiges an Reflexionsfähigkeit erfordert, auch wenn es sich hier vielleicht etwas einfacher darstellt und liest.

https://www.scrum.org/resources/blog/balancing-self-management-and-guidance-art-agile-leadership

Velocity | Limitierung der parallelen Arbeit über Velocity-Obergrenzen

Velocity ist eine „klassische“ Scrum Metrik. Sie taucht zwar nirgendwo im offiziellen Scrum Guide auf, erfreut sich aber in Scrum-Kreisen seit gefühlt grauer Vorzeit großer Beliebtheit. Ich habe in den Links der Woche schon mehrfach angedeutet, dass ich die Velocity als eine Teammetrik verstehe, mit der ein Team sichtbar machen kann, wie nachhaltig seine „Arbeitsbelastung“ ist. Das Ziel sollte eine gleichmäßige Velocity sein. Man kann die Velocity also durchaus als „Limit“ für paralleles Arbeiten verstehen, wie es Felix Stein in seinem Beitrag beschreibt. Ob das gut ist, steht auf einem anderen Blatt. Wie Felix auch schreibt, ist Velocity letztlich nur der sichtbare Output, nicht das Outcome. Ich verwende Velocity eigentlich nur noch in unerfahrenen Teams, die noch ein Gefühl dafür entwickeln können, was sie in einem Sprint leisten können und was nicht. Daher ist es für mich eher eine zeitliche Verbesserungsmetrik, um die Lernerfahrung des Teams in Bezug auf die Arbeitsbelastung zu unterstützen. Sobald es sich eingespielt hat und stabil ist, kann man es weglassen.

https://www.lean-agility.de/2023/11/velocity-ii.html

Story Mapping | 5 der häufigsten Fehler

Ich bin ein großer Fan von Story Mapping. Es ist ein gutes Werkzeug, um PBIs zu definieren, Zusammenhänge sichtbar zu machen und zu erkennen. Es kann aber auch viel schief gehen. Angefangen von der Verzettelung in Details bis hin zur fehlenden Verknüpfung mit konkreten Ergebnissen. Der Artikel von Jeff Patton greift insgesamt fünf der häufigsten Fehler in diesem Zusammenhang auf. Wer weiß, worauf er achten muss, kann leichter erkennen, wenn etwas schief zu gehen droht.

https://jpattonassociates.com/5-story-mapping-mistakes/

Hinterlasse einen Kommentar

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