PRODUKTIVITÄT
Feedback | Über die Art, wie man Feedback gibt
Ja, es gibt Menschen, die halten Feedback für „toxisch“. Und nein, ich Teil die Meinung nicht. Gutes Feedback, dass sachlich vorgebracht wird, hilft uns, den blinden Fleck zu erkennen und aufzulösen. Es trägt dazu bei, dass wir Dinge besser machen können. Vom „Feedback-Hamburger“ halte ich allerdings nicht viel. Ich bin voll bei Conrad Giller, gutes Feedback ist keine Besserwisserei und schon zwei Mal keine Anweisung, sondern eine Darstellung einer persönlichen Wahrnehmung und entsprechend sollte man sie auch mitteilen. Gutes Feedback muss man nicht „verpacken“, den gutes Feedback liefert einen Mehrwert und ist ein Dialog. Wir tauschen Argument aus, nicht mit dem Ziel recht zu behalten, sondern um unsere Ideen zu verbessern. Na, wer hat es erkannt? Genau, Karl Popper lässt grüßen 😉
https://t2informatik.de/blog/alles-feedback-ist-toxisch-so-ein-unsinn/
SMART | Ein Akronym für die Formulierung von Zielen, das gerne falsch verstanden wird
Ich nutze die Idee von SMARTen Zielen auch gerne immer wieder. Als Hilfestellung, nicht als knallharte Regel. Gerade mit Blick auf die von Christian Sachs beschriebenen „Fehler“ im Umgang mit den SMART-Prinzipien. Sicherlich für den einen oder anderen hilfreich:
https://cactus-competence.com/die-5-haeufigsten-fehler-bei-smart/
Automatisierung | Wie wir mit Automatisierung Routinetätigkeiten einfacher erledigen können
Routinetätigkeiten, die sich wiederholen, sind eine wunderbare Gelegenheit für Automatisierung. Ich bin da bei Weitem noch nicht soweit, wie zum Beispiel Ivan Blatter. Dabei gibt es in den meisten digitalen Werkzeugen mehr Möglichkeiten, als uns oft bewusst ist. Ich nutze zum Beispiel in Outlook schon sehr lange „automatische“ Regeln für das Postfach und die „Quicksteps“ in Outlook gehören beim mir zum Arbeitsalltag. Gerade erkunde ich die Möglichkeiten, die M365 mir bietet (ganz, dass ich dafür ein Extra-Werkzeug anschaffen) muss und probiere privat die Möglichkeiten von Notion aus. Aber auch das von Ivan Blatter erwähnte Steamdeck habe ich bereits auf dem Schirm und überlege mir schon länger, ob ich mir ein solches anschaffen soll. Ach ja und falls sich jemand wundert, wie ich es schaffe, auf verschiedenen SoMe-Kanälen über den Tag verteilt zu posten: Auch hier spielt eine Teilautomatisierung mit einigen Tools eine wichtige Rolle – ganz ohne dass ich dabei selbst online sei muss. Nur die Auswahl erfolgt noch Old School per Hand 😉 Ebenso schreibt hier keine KI für mich, auch wenn dies durch aus denkbar wäre. Da bin ich noch alte Schule.
https://traffic.libsyn.com/secure/blatternet/373_-_Automatisierungen.mp3?dest-id=163761
Briefing schreiben | In 7 Schritten zu einem guten Briefing
Um kurz zusammenzufassen und zu transportieren, worum es bei einer Sache geht und weshalb sie von Bedeutung ist, kann ein kurzes Briefing immer wieder hilfreich sein. Kurz und prägnant auf maximal zwei Seiten. Besser sogar nur eine. Zu einen für die eigene Reflexion zum Beispiel als Hilfsmittel um 5 im Kopf zu machen (Weshalb, mache ich etwas für wen und was soll dabei am Ende für wen herauskommen?). So nutze ich mit unter ein Briefing auch mal für mich als Hilfsmittel, aber auch um andere Mitwirkende zu gewinnen. Wie wir alle wissen, liegt die Kunst in der Kürze und das ist oft eine wahre Herausforderung. Für eine Langfassung brauche ich oft nicht lang. Geht recht zügig. Aber kurz und prägnant, das ist echt herausfordernde Denkarbeit. Andrea Windolph liefert mit ihrem Artikel ein paar Anregungen, wie es besser gelingen kann und soll.
https://projekte-leicht-gemacht.de/blog/business-wissen/briefing-schreiben/
Weniger ist mehr | Warum wir weniger tun sollten, um mehr zu schaffen
Es ist ein offenes Geheimnis: Je weniger wir (parallel) tun, desto mehr bekommen wir geschafft. Schaue ich mich allerdings um, erschrecken ich jedes Mal darüber, wie viele Bälle wir gleichzeitig in der Luft halten müssen. Das gilt im persönlichen Zeitmanagement genauso wie im Team oder sogar in der Organisation. Allerdings zielt Dan Rockwell zunächst nur auf die persönliche Produktivität ab. Meiner Meinung nach sollten wir aber auch im Team und besonders auch in der Gesamtorganisation mehr Fokus schaffen, damit wir insgesamt mehr geleistet bekommen. Ein anderes Thema, über das ich mich hier in Toms Gedankenblog auch schon mehrfach ausgelassen habe.
https://leadershipfreak.blog/2023/02/24/4-ways-to-do-less-and-get-more-done-today/
LEAN
Trystorming | Eine Kultur des Experimentierens fördern
Irgendwann habe ich irgendwo vor langer Zeit gelesen, dass Thomas Edison seine Mitarbeiter animiert haben soll, beständig zu experimentieren. Frei nach dem Motto, wenn es schief geht, nicht schlimm – solange wir etwas daraus lernen können. Wenn es gelingt, noch besser, weil wir eine Innovation entstanden ist. Raum für Experimente und Versuche ist essenziell, um Verbesserungen und Weiterentwicklung zu befördern. Hier greift der Blogartikel von Tim McMahon an. Und ja, dass ist kein Privileg der Agilisten. Sondern schon lange auch Kerngedanken der Lean-Welt. Oder anders ausgedrückt: Zweit Seiten einer Medallien 😉
http://www.aleanjourney.com/2023/02/establish-culture-of-trystorming.html
AGILE
Teamarten nach Wardley | Pioneere, Siedler und Städtebauer
Ich bin leider kein Kenner der Wardly Map. Dafür ist die Materie doch sehr umfangreich. Aber spannend finde ich die Idee dahinter, die sehr stark von Sun Tzu: „Die Kunst des Krieges“, einem alt-chinesischen Strategieklassiker, inspiriert ist. Die intensive Beschäftigung mit Wardleys Idee steht noch auf meiner To-Do-Liste. Warum dürfte sich vermutlich erschließen, wenn man Beiträge wie von Lars Richter liest. Hier stellt er die Teamarten nach Wardley vor, die ich mit Blick, welche Ansätze sind wann zielführend recht interessant finde.
https://cdi.digital/teamarten/
Schwierige Gespräche als Scrum Master | Vorbereitung, Hilfestellung und weitere Tipps
Es gibt Situationen, die alles andere als einfach sind. Nicht nur für Scrum Master übrigens 😉 In den allermeisten schwierigen Situationen hilft ein gut vorbereitetes Gespräch, in dem alle Seiten offen und ehrlich ihre Argumente darlegen können. Betonung liegt auf den allermeisten. Es gibt leider immer auch Situationen, in denen dies nicht möglich ist. Diese sind zum Glück, zumindest nach meiner Erfahrung nur die Ausnahme von der Regel. Die Tipps und Tricks, die Simon Flossmann in seinem Beitrag hier für Scrum Master mitgibt, sind auch für Menschen interessant, die nicht in der Rolle unterwegs sind. Die Hauptherausforderung ist nach meiner Erfahrung, sich mit seiner Sicht zurückzunehmen und sein die Argumentation seines Gegenübers zu zulassen. Ich versuche mir in den Situationen immer wieder Poppers Idee von einem kritischen Rationalismus vor Augen zu führen (da ist er schon wieder ;-)) Dabei geht es nicht darum, dass man recht behält, sondern darum, die Argumente auszutauschen und gegenseitig zu prüfen, um sie zu verbessern und sich weiterzuentwickeln. Mir hat dies schon mehrfach geholfen.
https://www.scrum.org/resources/blog/wie-du-als-scrum-master-souveran-schwierige-gesprache-fuhrst
Management-Unterstützung | Wie man die Unterstützung des Managements stärken kann
Bei manchen Agilelogen scheint Management das Feindbild Nr. 1 zu sein, während Agilisten meist verstanden haben, dass das Management, wenn man einbindet und gewinnt, ein echter Unterstützer bis Treiber sein kann. Ich habe es selbst schon erlebt. Leider nicht so oft, wie ich es mir gewünscht hätte, weil im Vorfeld bereits einiges schief gelaufen ist. Aber dort, wo es gelungen ist, war die Unterstützung der agilen Teams durch das Management top und das Zusammenspiel fast schon lehrbuchreif. Und dafür kann man einiges tun. Ein paar Tipps hierzu gibt es von Christiaan Verwijs und es sind nicht wirklich herausfordernde Ideen, sondern lediglich auf Dialog gerichtete Ansätze.
Denkfehler im Tranformationskontext | Post-Transformation Bias
Ich habe irgendwann mal von einer klugen Frau gehört, dass Best-Practice-Bullshit ist. Und zwar aus einem ganzen einfachen Grund: Best-Practice sind meist vereinfachte Erzählungen eines komplexen Kontexts, der viele Facetten außen vor lässt. Besser sei, wenn überhaupt von Good-Practices zu sprechen. So verhält es sich auch mit Transformationserzählungen die man als Grundlage für die eigenen Transformationsansatz wählt. Dazu fällt mir aus meiner Zeit im bürgerschaftlichen Engagement ein Kollege ein, der zwischenzeitlich im Ruhestand ist, der meinte: „Man erzählt immer nur, was gut gelaufen ist. Nie, was man an die Wand gefahren hat.“ So ähnlich ist auch bei den Transformationsgeschichten. Im Nachgang blendet man die Schwierigkeiten und Fehlern gern aus und erzählt nur die positiven Geschichten. Das Bild wird schwer verzerrt. Und so kommt es schnell zum Post-Transformation-Bias. So schön ich Erfolgsgeschichten als Mutmacher finde und sie auch als Inspirationsquelle für eigene „Verbesserungsversuche“ nutze, bin ich doch vorsichtig, sie 1:1 übertragen zu wollen und ermahne mich selbst immer wieder: Die Wirklichkeit ist weit komplexer. Sei also vorsichtig und Dir immer bewusst, es nicht 1 zu 1 zu übertragen. In diesem Sinne von Felix C. Stein eine kleine Erinnerung:
https://www.lean-agility.de/2023/02/post-transformation-bias.html
Raum für Lernen geben | Die 9@9-Regel
Ich bin diese Woche auf ein schönes Experiment von John Coleman gestoßen. Schön, weil ich selbst ein Mensch bin, der sich jeden Tag ca. 30 Minuten fürs „Lernen“ neuer Ideen reserviert. Ganz bewusst im Kalender. Sein Wissen zu erweitern hilft dabei, Dinge besser machen zu können, indem man das, was man tut, besser beherrscht. Oder wie es Mari Furkuwa-Gaspari mal schön ausgedrückt hat, bei Monozukuri (der japanischen Lean-Variante) geht es darum, die Dinge zu beherrschen. D. h. sein Handwerk zu beherrschen. Und wie heißt es so schön im Agilen Manifest: „Kontinuierliche Aufmerksamkeit für technische Exzellenz und gutes Design erhöht die Agilität.“ Muss ich noch mehr sagen? Eben. Ergo ausprobieren und schauen, was passiert 😉
Product Owner | Das Engagement der Stakeholder nutzen, um den Wert zu maximieren
Wie können Product Owner:innen den Mehrwert steigern? Das ist schließlich einer ihrer Kernaufgaben. Indem sie ganz eng neben dem Team, auch mit den Stakeholdern als Impulsgebern zusammenarbeiten. Was so lapidar und selbstverständlich klingt, ist nicht unbedingt immer der Fall. Das meine ich ernst. Ich habe es schon öfter erlebt, dass POs in Scrum Teams mehr oder minder das Engagement der Stakeholder wenig bis kaum gefördert haben. Es ist nicht immer einfach. Keine Frage. Dennoch wichtig und kaum zu vernachlässigen. Vielleicht inspiriert den einen oder anderen der Artikel von Mary Iqbal mal darüber nachzudenken, wie die Zusammenarbeit mit den Stakeholdern gestärkt werden kann:
https://www.scrum.org/resources/blog/how-product-owners-can-maximize-value-stakeholder-input
Qualitätsverständnis | Wie man das Verständnis für Qualität im Team verbessern kann
Vorweg, ich muss eine Lanze für brechen. Ich erlebe sehr viele Teams, die in Sachen Qualität sehr hohe Ansprüche haben. Das ist aber nicht immer der Fall. Aus verschiedenen Gründen: hoher Lieferdruck, hoher Kostendruck oder einfach unklares Verständnis, was hohe Qualität im jeweiligen Kontext genau bedeutet. Die ersten beiden Punkte sind primär Hausaufgaben für das Management (Teams können hierbei wertvollen Input liefern), dass die Rahmenbedingungen schaffen sollte, damit beste Qualität unter zuverlässigen und auskömmlichen Bedingungen erstellt werden kann. Der dritte Punkt ist eine Frage guter Kommunikation und der Entwicklung eines gemeinsamen Verständnisses und kann in jedem Team gut unterstützt werden. Beispielsweise, wie im Beitrag von Barry Overeem vorgeschlagen. Ein sehr praxisnaher Ansatz, der in der Tat gut funktioniert.
https://www.scrum.org/resources/blog/improve-your-teams-concern-quality
Scrum Master = Projektleiter? | Ein Podcast von Marc Löffler
Beim Versuch, jemanden zu erklären, was mit den Rollen in Scrum auf sich hat, kam tatsächlich schon öfter die Frage auf, ob die Rolle Scrum Master mit der Projektleitung vergleichbar ist. Ich habe dann versucht zu erklären, dass die Aufgaben einer klassischen Projektleitung im Scrum-Teams verteilt auf alle Rolle sind. Mit unterschiedlichen Schwerpunkten. Die Rolle Scrum Master mit Schwerpunkt auf die Produktivität, die Rolle des Product Owners mit Schwerpunkt auf Wertmaximierung und die der Entwickler auf die Qualität – zusammen mit der Verantwortung als Team für das Gesamtergebnis. Ich hatte zwar den Eindruck, mein Gegenüber hatte es jedes Mal einigermaßen verstanden, aber zugegebenermaßen ist es nicht ganz einfach. Insofern finde ich den Podcast von Marc Löffler zu genau dieser Frage, durch aus sehr interessant:
https://marcloeffler.eu/2023/02/24/ist-der-scrum-master-ein-projektleiter/
Toms Gedankenblog 