PRODUKTIVITÄT
„Dramen“ auflösen | 7 Tatiken, um Dramatikern im Arbeitsumfeld die Bühne zu nehmen
Ich habe in der Tat in meinem Berufsleben einige Dramen, Tragödien und sogar Komödien erleben dürfen. Vieles wäre vermeidbar gewesen, wenn manche Mitmenschen mit offenen Karten gespielt hätten und man diesen die Bühne entzogen hätte. Hilfreich dabei die 7 Taktiken von Dan Rockwell. Das ist übrigens mit einer der Gründe, warum ich sehr viel Wert auf Transparenz lege, die von manchen Menschen in meinem Umfeld als anstrengend empfunden wird.
https://leadershipfreak.blog/2022/07/29/7-tactics-to-solve-drama-at-work/
Klarheit | Die Klarheit eines bewussten „Nein“
Ich habe selten ein Problem mit einem klaren „Nein“. Dafür jedoch ein ganz großes mit einem „Ja“, dass ein opportunistisches und unverbindliches Eventuell ist, aber so nicht kommuniziert wird. Nein, ist vollkommen in Ordnung. Zumindest so, wie es Sandra Brauer beschreibt. Es ist eine klare Entscheidung für oder gegen etwas. Es bedeutet Klarheit, Selbstschutz, letztendlich auch Verlässlichkeit. Mit einem Nein kann ich als Empfänger umgehen. Diese Klarheit vermisse ich zunehmend bei vielen Zeitgenossen.
https://t2informatik.de/blog/nein/
LEAN
A3-Report | Mehr als nur „Formular“ befüllen
Auch wenn die Bezeichnung A3-Report dazu verleitet, diesen einfach „nur“ wie ein Formular auszufüllen, so steckt doch mehr dahinter. Das schreibt Tracey Richardson in dem folgenden Beitrag recht treffend. Der A3-Report entwickelt sein Potenzial als „Denkprozess“, bei dem die Visualisierung wir eine Strukturhilfe unterstützt.
https://www.lean.org/the-lean-post/articles/create-a-real-a3-do-more-than-fill-in-boxes/
Manifesto for Lean Management | Ein Diskussionsimpuls von Bob Emiliani
Bob Emiliani lädt zur Diskussion ein. Er ist der Meinung, dass die Lean Community etwas neuen Schwung gebrauchen kann und als Ausgangsbasis stellt er sein Manifesto for Lean Management in den Raum. Ich habe die 15 Seiten noch nicht vollständig gelesen, aber einige Impulse waren für mich erhellend und spannend.
https://bobemiliani.com/manifesto-for-lean-management/
Flow | Was ist der „Flow“ überhaupt?
Der Begriff „Flow“ findet sich im Lean Management und in der agilen Welt. Wir nutzen ihn alle sehr häufig. Und ich würde sogar behaupten recht unreflektiert. Der Artikel von Christoph Roser greift das ein Stück weit auf. Seine Sicht der Dinge ist sehr aus der Produktion getrieben, enthält aber auch für Menschen in der reinen Wissensarbeit ein paar spannende Impulse und dürfte helfen, den Begriff Flow etwas klarer zu sehen. Den die reine „Flow Time“ ist nicht unbedingt ideal, um etwas darüber auszusagen, wie wir den Flow im Sinne einer wertanreichenderen Arbeit verbessern können (es fällt vielleicht auf, es geht nicht um Kosteneffizienz, sondern um Wertanreicherung!).
https://www.allaboutlean.com/what-is-flow/
AGILE
Evidenzbasierendes Management | On Product Index als KVI
Ich bin schon länger begeistert von den Möglichkeiten, die Key Value Indicator des evidenzbasierenden Managements in agile Teams bieten, um Verbesserungsmöglichkeiten sichtbar zu machen. Die „klassischen“ Metriken wie Velocity und Lead Time greifen mir oft zu kurz. KVIs wie On Product Index, Time to Feedback u. ä. bieten weitere Möglichkeiten. Eine dieser KVIs stellt Lars Richter in dem folgenden Beitrag vor: On Product Index. Eine nicht ganz einfache Metrik, wie auch Lars beschreibt und für mich in den meisten Teams sicherlich nicht meine erste Wahl, aber durch aus sinnvoll.
https://cdi.digital/on-product-index/
Stakeholder | Wenn das Enagement der Anspruchsgruppen fehlt …
Ein „Albtraum“: Das Team hat sich megamäßig ins Zeug gelegt und zum Review am Ende des Sprints erscheint kein einziger Stakeholder oder sie tauchen auf, aber man hat das Gefühl, sie sitzen nur ihre Zeit ab. Wenn so etwas passiert, klingeln beim mir die Alarmglocken. Da ist irgendetwas richtig übel verrutscht. Wenn kein oder kaum Interesse vonseiten der anspruchsberechtigten da ist, ist für mich die erste Frage, die ich mir dann unwillkürlich stelle, hat das Projekt eine Daseinsberechtigung? Ist das Weshalb klar formuliert und getroffen oder geht das Projekt komplett an den Bedürfnissen der Anspruchsgruppen vorbei? Die nächste Frage, die ich mir dann stelle, haben alle verstanden, warum wir am Ende des Sprints eine Review durchführen? Haben sie wirklich verstanden, dass das Team hier ihren Input braucht? Man könnte auch das Format, die Inhalte und die Gestaltung des Reviews ins Visier nehmen. Aber meist, so hat es mich meine Erfahrung gelehrt, ist diese Frage eher „Feintuning“. Stefan Wolpers bringt noch einen weiteren Punkt mit ein, der mit Sicherheit auch eine Rolle spielt: Nimmt das Team überhaupt die Stakeholder ernst? Den, wenn es niemand interessiert, was ich als Feedbackgeber von mir geben, warum sollte ich mich noch äußern? Das hängt dann zwar für mich mit der Frage zusammen, ob das Projekt dann noch eine Daseinsberechtigung hat, ist dennoch durch aus eine Frage, die man auch mal einem Team stellen darf.
https://www.scrum.org/resources/blog/unengaged-stakeholders-sprint-review-making-your-scrum-work-25
Feedback | Besseres, früheres Feedback bekommen
Über das Thema fehlendes Stakeholder-Engagement nähern wir uns so gleich der Bedeutung von frühem Feedback. Das ist die große Stärke der agilen Ansätze. Schnell früh Feedback generieren. Nicht um schneller zu werden, sondern um früher zu lernen. Darum geht es. Früher lernen, was wirklich gebraucht wird, um – ganz im Sinne einer Nachhaltigkeit – keine unnötigen Arbeiten zu machen, sondern nur die Dinge, die wirklich weiterführen. Die Vorschläge, die Mike Cohen macht, um das Feedback zu verbessern, geben daher eine gute Ergänzung zum Artikel von Stefan Wolpers:
https://www.mountaingoatsoftware.com/blog/7-ways-to-get-and-improve-fast-feedback
Daily Scrum | Wie führt man ein Daily Scrum durch?
Wie viele habe ich irgendwann noch die drei klassischen Fragen fürs Daily gelernt, die zwischenzeitlich nicht mehr Teil des Scrum Leitfadens sind. Aus guten Gründen. Sie sind nicht immer der beste Weg. Das hängt sehr vom Team ab. Ein gut eingegroovtes Team findet seinen Weg, der ideal passt. Ich persönlich mag es am liebsten, wenn ein Team – ganz ohne Moderator – vor dem Taskboard klärt, welche Fortschritte es gibt, was als Nächstes ansteht und wo es ggf. Abstimmungsbedarf gibt, sodass die Informationen unkompliziert fließen. Passend zum Kontext. Das ist mein Wunschbild. Je nach Kontext braucht es dann mal die eine oder andere „ritualisierte“ Unterstützung nach Bedarf, Aufgabe und auf das Team gemünzt. Das kann sehr unterschiedlich aussehen, wie Felix Stein es mit verschiedene Möglichkeiten aufzeigt:
https://www.lean-agility.de/2022/07/daily-meeting.html
Sprintziel | Wie man zu einem Sprintziel kommt …
Ich schätze kurz- und mittelfristige Ziele als Kompass und Zielzustand sehr. Für den langfristigen Kompass neige ich mehr zum Nordstern als prozessuale Beschreibung. Man merkt, hier schwingt die Idee Verbesserungs-Kata mit 😉 Mir geht es weniger darum, dass dann ein Ziel auf Teufel komm raus erreicht werden muss, sondern zum einen, um die Bestimmung des Fokus und zum anderen die Möglichkeit, einen Soll-Ist-Abgleich zu ermöglichen, aus dem am Ende sich eine Lernerfahrung ableiten lässt. Genau hierfür halte ich das Sprintziel wertvoll. Es gibt uns Richtung und erlaubt uns zu entscheiden, was im Sprint wichtig ist und was wir weglassen können und es erlaubt uns festzustellen, ob wir etwas lernen können. Aus der Beobachtung und meinem Erleben weiß ich, wie schwer es manchmal sein kann, als Team ein Sprintziel zu definieren. Mit den drei Ideen von Simon Flossmann lässt sich das Hindernis auflösen. Sie funktionieren. Ich habe das schon ähnlich mit Teams gemacht. Probiert es einfach aus.
Skalierung | Braucht es mehr als eine/n Product Owner*in in skalierten Teams?
Die Frage würde ich eher mit einem „es kommt darauf an“ beantworten. Auch wenn manches Framework wie LeSS ganz im Sinne von Mary Iqbal klar sagt: Ein Produkt = ein PO – auch bei skalierten Teams. Dafür spricht in der Tat auch einiges und im Grundsatz bejahe ich diese Argumentation. Wie so oft gibt es aber auch Ausnahmen von der Regel. Auch bei skalierten Frameworks übrigens. Diese Ausnahmen sind glücklicherweise selten, den in diesen Fällen handelt es sich um Großprojekte mit einem Umfang, die dann noch ganz andere Herausforderungen mit sich bringen und auf die man gerne verzichten kann. Fürs Protokoll: Versucht das Skalieren zu vermeiden, so lange, wie es möglich ist und reduziert die Abhängigkeiten zwischen Teams, so gut es geht. Das schont die Nerven aller Beteiligten. Nur wenn es nicht anders möglich ist, skaliert und greift dann auf die passenden Lösungen zurück. Die Auswahl ist recht groß, prüft gründlich welchen Weg ihr einschlagen wollt.
https://www.scrum.org/resources/blog/can-we-have-more-one-product-owner-scrum
Blick hinter die „Kulissen“ | Warum die offenkundigen Scrum-Artefakte oft nicht die besten Indikatoren sind
Den Blogartikel von Marty de Jonge verstehe ich als Aufruf, hinter die Kulissen zu blicken und bei der Betrachtung eines Scrum-Teams nicht auf die offensichtlichen und gut sichtbaren Scrum-Elemente zu fokussieren, sondern Wert und Prinzipien stärker in Visier zu nehmen. Werkzeuge und Prozess sowie Praktiken sind zwar der offenkundig erkennbare Teil, der leicht zu erfassen ist, dennoch sind diese eben „nur“ Werkzeuge und Hilfsmittel. Wer einen Hammer hat und weiß, dass man damit einen Nagel in die Wand schlagen kann, muss nicht unbedingt verstanden haben, was der Mehrwert eines Nagels in der Wand ist. Dafür braucht es ein tiefergehendes Verständnis über Zusammenhänge und Wirkungen, die man erzielen kann. Das Pendant hierzu sind im Scrum-Kontext die gelebten Werte und Prinzipien, die nicht ganz so leicht bemessen werden können.
https://medium.com/serious-scrum/have-you-understood-scrum-or-are-you-just-faking-it-3531600aa65f
Selbstmanagende Teams | Was bedeutet Selbstmanagement?
Das Phänomen kennen sicherlich viele: „Das Team ist doch selbstmanagend. Sie sollen ihre Probleme selbst lösen.“ Das zumindest ist mir in jüngerer Zeit tatsächlich öfter begegnet. Quasi als Gegenextrem zum Management, dass dem Team gar keinen Freiraum lässt, kommt das andere Extrem der „vollständigen Verantwortungsdelegation“ durch das Management. Und da will mir dann er Kragen platzen. Selbstmanagende Teams werden als Ausrede verwendet, um die Verantwortung loszuwerden! Da schüttelt es mich nur. Selbstmanagende Teams brauchen gute Führung. Auch selbstmanagende Teams brauchen einen Rahmen, einen Auftrag, Rahmenbedingungen. Da ist der Job des Managements. Hierauf geht David Spinks ausführlicher ein, weswegen ich es mit einer kurzen Einführung belasse:
https://medium.com/serious-scrum/what-does-self-management-mean-anyway-76de9b64bf3b
Produktivitätsparadoxon | Wie individuelle Produktivität und Teamproduktivität kollidieren können
Ich betone immer wieder, dass niemand allein arbeitet. Wer an seiner persönlichen Produktivität arbeitet und Verbesserungen an seinem Zeitmanagement vornimmt, sollte nie vergessen, dass dies Auswirkungen auf die Menschen haben kann, mit denen man zusammenarbeitet. In einem Team sogar noch mehr, wie Agne Kelminskiene sehr treffend herausarbeitet. Die individuelle Produktivität und die Teamproduktivität können durch aus miteinander in Konflikt geraten. Ein probates Mittel, das dabei helfen kann, ist ein teamweites WiP-Limit und regelmäßige Reflexion im Team 😉
https://medium.com/serious-scrum/the-paradox-of-productivity-79d3d053cbaa
LEADERSHIP
Überraschung | 4 Dinge für die Leadership nicht verantwortlich ist
Ich sehe die Führung in der Verantwortung, Rahmenbedingungen zu schaffen, aber in der Verantwortung, dass Dinge passieren. Das aber wird leider oft erwartet, widerspricht meines Erachtens dem Anspruch, mit erwachsenen Menschen zu arbeiten, die wissen, was sie tun und die man nicht mit der Peitsche zur Arbeit treiben muss. Dazu passt der Artikel von Dan Rockwell recht gut, der genau hier ansetzt und klärt, was nicht in die Verantwortung von Leadership gehört:
https://leadershipfreak.blog/2022/07/27/4-surprising-things-leaders-arent-responsible-for/
Toms Gedankenblog 