PRODUKTIVITÄT
Nichts bereuen | Mit dem Bewusstsein der eigenen Vergänglichkeit im heute und hier leben
Der Blogartikel von Anna Koschinski mit dem Titel „Nichts bereuen“ hat eine sehr persönliche Note, die mich an meine eigene Familiengeschichte erinnert. Seit 29 Jahren mahnt mich der frühe Tod meines Vaters (ich habe ihn bereits um mehrere Jahre überholt) immer wieder, bewusster durchs Leben zu gehen. Eine Parallele, die ich in dem Artikel wiedererkannt habe. Und eine Lektion, an die ich mich selbst immer wieder erinnere, wenn ich – wie so oft – vergesse, dass es auf das Hier und Jetzt ankommt und ich mir Raum nehmen sollte für die Dinge und Menschen, die mir wichtig sind.
https://anna-livia.de/nichts-bereuen/
Jahresentspurt | Was will ich im letzten Quartal des Jahres noch umsetzen?
Das Jahr ist schneller vorbei als man denkt. Wir haben September. Wenn ich mir anschaue, was ich mir in diesem Jahr alles vorgenommen habe und was ich davon geschafft habe, dann ist – wie jedes Jahr – noch viel Luft 😉 Zeit darüber nachzudenken, was ich unbedingt noch umsetzen möchte. Das nehme ich zumindest aus dem Podcast von Ivan Blatter mit.
https://ivanblatter.com/podcast/q4/
AGILE
Verbesserungsroutine | Die Coaching-Kata als Hilfsmittel für die Entwicklung einer „Verbesserungsroutine“
Diejenigen, die mit mir häufiger zu tun haben, wissen, dass ich verschiedene Ansätze aus dem Toyota Production System sehr schätze, von denen – nebenbei bemerkt – einige sogar Pate gestanden haben für das, was wir unter dem Label „Agile“ als typische Praktiken bezeichnen. Dazu gehört auch die „Coaching-Kata“ von Toyota als Teil der Verbesserungs-Kata. Wie Edgar Rodehack wende ich sie gerne und immer wieder an. Mit der Routine der Coaching-Kata lässt sich eine „Verbesserungsroutine“ entwickeln, die das Bewusstsein für die ständige Weiterentwicklung und Verbesserung im Sinne von Kaizen schärft:
https://www.teamworkblog.de/2023/09/tooling-7-wie-problemlosung.html
Backlog Refinement | Refinenment als beständige Verfeinerung und Verbesserung
Das Backlog Refinement ist, zumindest nach meinem Verständnis, auch eine Form der kontinuierlichen Weiterentwicklung und Verbesserung. Beim Refinement geht es darum, „Verbesserungen“ zu sammeln, sichtbar zu machen, zu bewerten und zur Umsetzungsreife zu bringen. Es findet kontinuierlich statt. Nicht die Zusammenarbeit steht im Vordergrund, sondern die Arbeitsergebnisse in Form von Lösungen und Inkrementen. Hier sehe ich auch den Schlüssel zum Erfolg einer „agilen“ Arbeitsweise, die sich schrittweise immer besseren Lösungen nähert. Dazu passt, was Rob Galen in wenigen Worten auf den Punkt bringt: „I’ve found that refinement is an activity and mindset central to effective team execution“.
https://rgalen.com/agile-training-news/2023/4/27/my-learnings-on-backlog-refinement
Online Formate | Facilitation-Tipps für Remote-Formate
Auch wenn einige Großkonzerne bereits die Rückkehr von „Remote“ ins Büro angekündigt haben, bin ich fest davon überzeugt, dass die Zeit ohne virtuelle Meetings, Workshops und andere Formate vorbei ist. Niemand ist mehr bereit, für einen 2-stündigen Workshop eine 8-stündige Anreise in Kauf zu nehmen. Das ist auch völliger Unsinn. Aus der Ferne ist vieles möglich und gute Moderatoren können auch aus der Ferne vieles produktiv gestalten. Einige Tipps dazu finden sich im Blogbeitrag von Simon Flossmann, den ich hier verlinke:
Product Owner | Kein guter Product Owner ohne gutes Team
Agiles Arbeiten ist Teamarbeit. Unabhängig davon, welchen Rahmen man dafür wählt. Es gibt zwar verschiedene Rollen, die jeweils einen Fokus haben, aber nur im Zusammenspiel können diese Rollen ihre Wirkung wirklich entfalten. Das gilt für Scrum, Kanban genauso wie für SAFe, LeSS oder was auch immer. Gute Ergebnisse entstehen durch gute Zusammenarbeit, insbesondere wenn es darum geht, unterschiedliche Sichtweisen zusammenzubringen, um die bestmögliche Lösung für eine Herausforderung zu entwickeln. Gute Product Owner in Scrum-Umgebungen wissen das und arbeiten eng mit den „Entwicklern“ zusammen. Das kommt im Podcast der Product Owner sehr gut zum Ausdruck:
https://produktwerker.de/ohne-team-bist-du-nix/
Nicht-Technische Führung in agilen Technik-Teams | Muss man als Servant Leader Fachwissen der Entwickler haben?
Es gibt die berühmte und durchaus berechtigte Frage, wie viel technische Expertise ein Scrum Master in einem technischen Umfeld mitbringen soll und muss. Meine Antwort: Der oder die Rolleninhaber:in muss kein Experte sein und auch keine einschlägige Erfahrung besitzen. Was aber jeder Nicht-Techie, der als Servant Leader für Tech-Teams fungiert, mitbringen sollte, ist ein Grundverständnis, um mit den Experten auf Augenhöhe kommunizieren zu können und deren Probleme zu verstehen. Mit anderen Worten: Ich muss als Coach eines technischen Entwicklungsteams nicht selbst Entwickler gewesen sein. Aber ich sollte zumindest verstehen, wie sie arbeiten und ihren „Code“ (Sprache u. ä.) soweit verstehen, dass ich nachvollziehen kann, wo der Schuh drückt. Dasselbe gilt für das Management. Mein Job ist es nicht, Expertenlösungen zu entwickeln, mein Job ist es, den Experten zu helfen, ein Umfeld zu schaffen, in dem sie diese entwickeln können. Mein Fokus ist ein anderer, aber das gegenseitige Grundverständnis hilft beiden Seiten dabei. Der Blogbeitrag von Mary Iqbal drückt das für mich sehr gut aus:
https://www.scrum.org/resources/blog/non-technical-leaders-scrum
OKR | Der OKR-Zyklus als Referenzmodell
Ich entwickle mich mehr und mehr zum „OKR-Skeptiker“, was mehr damit zu tun hat, dass ich in meinem Streben nach Einfachheit die Vielzahl der Rahmenwerke mit weiteren neuen Rollen und Artefakten als kontraproduktiv empfinde und immer mehr die Idee der Kanban-Prinzipien aufgreife, die darauf abzielen, das Bestehende evolutionär weiterzuentwickeln. Ein weiterer Punkt ist, dass ich bei vielen Implementierungen – übrigens bei allen Frameworks – die „Methodenfokussierung“ und die absolute Befolgung des „Standards“ als Problem sehe. Es ist also mehr die praktische Anwendung als die Theorie, die mich zum „Skeptiker“ macht. Als „Referenz“ für die Umsetzung in der Praxis selbst finde ich OKR nach wie vor interessant. Der OKR-Zyklus, wie von Lars Richter beschrieben, kann helfen, den richtigen Rahmen für strategische Themen zu schaffen. Ich kann den Zyklus an die bestehende Organisation anpassen und nutzen, indem ich bestehende „Runden“ und Rollen weiterentwickle. Der OKR-Zyklus wird zum Referenzmodell und nicht zu einer zusätzlichen Struktur.
https://cdi.digital/okr-zyklus/
Velocity | Ein relative Metrik für das Team. Nur für das Team
Velocity ist kurz gesagt der „Durchsatz“ in Storypoints. Wie wir wissen, sind Storypoints relativ, da jedes Team seinen eigenen Referenzpunkt hat. Genau aus diesem Grund ist die Velocity als Metrik für Vergleiche zwischen Teams völlig ungeeignet. Und trotzdem versuchen es immer noch viele Managementvertreter. Glücklicherweise ist die Velocity als Metrik auf dem Rückzug. Denn wie gesagt, selbst für ein Team ist die Metrik nur für den Durchsatz aussagekräftig. Die Qualität der Ergebnisse und der Nutzwert der Ergebnisse werden nicht wirklich sichtbar. Dies schränkt den Nutzen der Velocity selbst für ein einzelnes Team zur Identifikation von Verbesserungen deutlich ein. Und wie gesagt, die Velocity ist und bleibt eine Metrik nur für das Team, die allein nur eine begrenzte Aussagekraft hat. Mehr dazu von Stefan Wolpers:
https://www.scrum.org/resources/blog/illusion-velocity
Teamstrukturen schaffen | Teamübergreifende Zusammenarbeit gestalten, die Kollaboration ermöglicht
Gibt es so etwas wie eine „optimale Teamstruktur“, die universellen Gesetzmäßigkeiten folgt? Da bin ich etwas skeptisch. Dazu spielen zu viele Faktoren eine Rolle. Was ich aber guten Gewissens sagen kann, ist, dass einige Prinzipien helfen können, sich gut funktionierenden Grundstrukturen für Teams anzunähern. Gute Zusammenarbeit, auch teamübergreifend, ist nichts, was man einfach mal schnell entwirft, sondern was gut durchdacht sein will. Das sollte nach der Lektüre des Artikels von Lars Richter klar geworden sein. Kein Team agiert allein. Es ist immer Teil eines größeren Ganzen und an den Schnittstellen entstehen die Probleme. Sie können nie „perfekt“ gelöst werden. Die Schnittstellen können so gestaltet werden, dass die Probleme möglichst gering und für die Beteiligten „lösbar“ sind. Das setzt einiges an Denkarbeit voraus.
https://cdi.digital/teamstrukturen/
Abgrenzung | Ist der Agile Coach ein Coach?
Vielleicht erinnert sich der eine oder andere noch an einen Beitrag von Felix Stein, in dem es um die Abgrenzung von Coaching und Agile Coaching ging. Das Thema wird in der Podcastfolge mit André Claassen und Felix Stein aufgegriffen. Spannend für die Selbstreflexion, denn es mag Parallelen zwischen Coaching und Agile Coaching geben, aber es gibt auch klare Unterschiede. Und darüber sollten wir uns im Klaren sein. Eine gute Inspiration für Scrum Master:innen, Agile Coaches und artverwandte Rollen.
MANAGEMENT
Rolle leben statt Stellen besetzen | Weshalb wir unser Augenmerk deutlich mehr auf Rollen und Rollenverständnis richten sollten
Der Unterschied zwischen einer Rolle und einer Stelle ist ein Thema, das mich – wenn ich darüber nachdenke – schon viel länger beschäftigt, als darüber diskutiert wird. Inzwischen habe ich sogar meinen Frieden mit der Stellenbeschreibung gemacht. Bis zu einem gewissen Grad macht sie Sinn. Wie ein guter Standard als Bezugspunkt, der nicht in Stein gemeißelt ist, sondern ständig weiterentwickelt wird und als relativer Vergleichswert dient. Leider ist dieses Verständnis in unseren Bereiten nicht sehr ausgeprägt. Beim Lesen des Blogbeitrags von Olaf Hinz kam mir der Gedanke, dass sich genau dieses Verständnis eines „guten Standards“ auch beim Thema Rolle vs. Stellenbeschreibung widerspiegelt. Wenn wir Standards als relative und nicht als absolute Bezugspunkte verstehen würden, wäre manches einfacher. Hinter jeder Stellenbeschreibung verbergen sich letztlich Rollen, die mit Leben gefüllt werden wollen, und das gelingt am besten im Dialog mit den Beteiligten. Übrigens: Eine Stellenbeschreibung hat auch ihr Gutes. Es gibt durchaus Organisationen, die „Flexibilität“ missbrauchen. Hier kann die gute alte Stellenbeschreibung helfen, dem Missbrauch entgegenzuwirken:
Toms Gedankenblog 