Produktivität
Orte der Wissensarbeit | Es ist nicht immer das Büro …
Wie Marcus Raitner treffend feststellt, ist „Wissensarbeit“ nicht unbedingt an den Arbeitsplatz gebunden. Ganz abgesehen davon, dass Wissensarbeit nicht, wie viele meinen, ausschließlich „Büroberufen“ vorbehalten ist. Egal ob Handwerker, Maschinenführer oder „Manager“, die guten Ideen zur Lösung von Hindernissen und Herausforderungen bei der Arbeit kommen uns oft gerade nicht am Arbeitsplatz – sondern gerade dann, wenn wir unsere Gedanken schweifen lassen können. Beim Abendspaziergang, bei der Gassirunde, unter der Dusche … Und ja, hier arbeiten wir. Auch wenn das für manche schwer zu verstehen ist.
https://raitner.de/2024/07/solvitur-ambulando-wissensarbeit-findet-nicht-immer-im-buero-statt/
Persönlich wachsen | Drei unkonventionelle Wege
Ich bin dieser Tage auf einen Beitrag von Dan Rockwell gestoßen, der dazu auffordert, vermeintlich unkonventionelle Wege zu gehen, wenn es um unser persönliches Wachstum geht. Beginnen, bevor man bereit ist, ist durchaus ungewöhnlich. Erinnert mich ein wenig an Effectuation. Erkunden, ohne genau zu wissen, wohin die Reise geht. Herantasten und Ausprobieren nach dem Prinzip des verkraftbaren Verlustes. Kann ich sehr empfehlen. Auch „Irritationen“, die andere bei uns auslösen, als Lernchance zu sehen, finde ich sehr spannend, wenn auch manchmal sehr herausfordernd. Beim dritten Punkt bin ich persönlich noch etwas unschlüssig. Aber lest selbst.
https://leadershipfreak.blog/2024/07/11/unlocking-potential-3-unconventional-growth-strategies/
Obsidian | Gespeicherte Suchabfragen
Obsidian ist ein sehr vielseitig einsetzbares Werkzeug und ich schätze es sehr, auch wenn ich im Moment aufgrund diverser Projektzwänge teilweise darauf verzichten muss. Sehr gut gefällt mir die Suchfunktion, die sehr zuverlässig und effizient funktioniert. Spannend, Suchanfragen lassen sich gut abspeichern. Wie das geht, zeigt Thomas Mathoi in einem ausführlichen Blogbeitrag.
https://www.mathoi.at/2024/07/10/obsidian-kaizen-gespeicherte-suchabfragen/
Agile
Retrospektiven | Damit die Zeit nicht knapp wird
Die Timebox für die Retrospektive ist laut Scrum-Guide ausreichend bemessen, um zu Ergebnissen zu kommen. Und ich erlebe bei eingespielten Teams eher selten, dass die Zeit nicht ausreicht. Eher das Gegenteil. Wie gesagt, eingespielte Teams. So ein eingespieltes Team fällt nicht vom Himmel, sondern das erarbeitet man sich Stück für Stück, eben auch mit Hilfe der Retrospektiven. Wenn es gerade in dieser Phase holprig zugeht, viele Dinge noch geklärt und besprochen werden müssen, dann ist der Zeitbedarf doch größer und manchmal kann es passieren, dass die Zeit knapp wird. Hier können verschiedene Moderationstechniken, aber auch bereits eine gute Vorbereitung unterstützend wirken. Simon Flossmann stellt drei geeignete Ansätze vor. Ich selbst setze oft darauf, dass das Team eine gemeinsame Beobachtungssammlung erstellt, in der die Häufigkeit der Beobachtung und die Wirkung auf das Team bereits bewertet wurden. Ich kombiniere dies gerne mit einer Mini-Reflexion am Ende des Daily. So können Kleinigkeiten schon gelöst und geklärt werden, ohne auf die Retrospektive zu warten bzw. wir haben schon einen guten Überblick über die Themen der Retrospektive und können entsprechend vorbereitet in die Retrospektive gehen.
Refinement | Wie sich das Refinement integrieren lässt
Auch wenn das Refinement als „Event“ nicht Teil des Scrum Guides ist, halte ich es für einen der zentralen Hebel für das Sprint Planning und das Backlog Management. Hier werden Anforderungen und Fragen im Vorfeld geklärt, Fragen aufgeworfen, die bis zum Sprint Planning geklärt werden können und Product Owner erhalten frühzeitig wichtiges Feedback für ihre Vorbereitung. Der Verzicht auf Refinement hat massive Auswirkungen auf die Produktivität des Teams. Mary Iqbal zeigt auf, welche Möglichkeiten es gibt, das Refinement in den Teamprozess zu integrieren.
https://www.scrum.org/resources/blog/you-cant-skip-refinement
Scrum Master vs Agile Coach | Ein unglückselige Diskussion
Ich weiß nicht, wann und wo man begonnen hat, zwischen Agile Coaches und Scrum Mastern zu unterscheiden. Ich persönlich sehe keine harte Grenze. Scrum Master ist eine „methodische“ Rolle im Scrum Leitfaden. Das ist vorgegeben. Und ja, Scrum geht von einem Team aus. Aber die Rolle ist nicht explizit nur auf das Scrum Team fokussiert. Man kann versuchen, Agile Coaches weiter zu fassen, eher auf einer übergeordneten Flughöhe und methodisch nicht auf Scrum fokussiert (beides gilt aber auch für erfahrene Scrum Master, die ihre Rolle ernst nehmen). Es ist schwierig und ich denke, dass die Diskussion nicht wirklich zielführend ist. Die These, dass ein Scrum Master ein Junior Agile Coach ist, ist für mich jedenfalls nicht haltbar. Eine Diskussion, die auch Barry Overeem aufgreift und ziemlich gut trifft.
https://www.scrum.org/resources/blog/scrum-master-junior-agile-coach
Agile Teams als Investoren | Weshalb eine „Föderalisierung“ der Entscheidungsstrukturen sinnvoll sein kann
Ein sehr schöner Impuls von Stephan Wolpers empfiehlt, agile Teams als Investoren zu betrachten. Ich weiß, damit tun sich leider noch viel zu viele Organisationen schwer. Scrum Teams werden als „Ausführende“ gesehen und viel zu selten als strategisch Mitwirkende, die wichtige Impulse geben können. Ohnehin ist die oft zu beobachtende strikte Trennung zwischen operativer, taktischer und strategischer Ebene eher kontraproduktiv. Das ist übrigens auch ein Grund, warum ich mich viel mit Obeya beschäftige. Die Vernetzung der Ebenen und der beteiligten Akteure ermöglicht es, gute Entscheidungen zu treffen. Den Artikel von Stephan Wolpers habe ich in zwei Versionen, deutsch und englisch, verlinkt:
Englisch: https://www.scrum.org/resources/blog/agile-teams-investors
Deutsch: https://www.scrum.org/resources/blog/agile-teams-als-investoren
Reviews | Gute Praxis als Anregung
Ein richtig gutes Sprint Review ist Gold wert. Und doch liegt genau da die Krux. Ein gutes Sprint Review ist Arbeit und vielen Faktoren abhängig. Und nein, Folienschlachten in denen Teams in 20 Minuten herunterreißen, was sie im Sprint gemacht haben, sind keine gute Reviews. Leider viel zu oft der Fall und nicht immer gelingt es die Beteiligten davon zu überzeugen, etwas daran zu ändern. Die Produktwerker zeigen mit Praxisbeispielen wie es besser geht.
Effektivität | Mehr Effektivität im Team
Viel zu oft steht die Effizienz im Vordergrund, ohne die Effektivität zu berücksichtigen. Und genau diese sollten wir im Auge behalten. Gerade im agilen Kontext resultiert die gerne angestrebte „Effizienz“ aus der hohen Effektivität der Teams. Und genau dieser Effekt wird von vielen Entscheidern immer noch übersehen. Ich kann hocheffizient in die völlig falsche Richtung fahren. Lokale „Totoptimierung“ durch „Effizienzeurose“ führt wie bei einem falsch verstandenen „Lean“ dazu, dass am Ende das große Ganze nicht zusammenpasst. Auch das ist etwas, was ich viel zu oft erlebe und was mich immer öfter an den Entscheidungsträgern in manchen Unternehmen zweifeln lässt. Dieses Problem können wir leider nicht lösen. Aber wir können dafür sorgen, dass unsere Teams ihren Kompass besser ausrichten können und zumindest dazu beitragen, dass es besser läuft. Piyush Rahate hat sich dazu einige Gedanken gemacht, die ich sehr gut finde.
https://www.scrum.org/resources/blog/tips-improving-effectiveness-scrum-teams
Scrum und Qualitätsmanagement | Wie sich schlechte Produktqualität vermeiden lässt
Als alter Kaizen-Fan springe ich natürlich sofort an, wenn ich einen Titel wie diesen von Marc Löffler lese: „Wie gehe ich mit schlechter Produktqualität um?“ Nun, die Antworten in seiner Podcastfolge helfen Entwicklerteams definitiv weiter. Gerade die Definition of Done ist ein guter Hebel, der hier wirken kann. Und noch etwas halte ich für zentral. Regelmäßige Reflexion, auch im Kleinen. Lasst euch doch mal auf das Experiment ein, jeden Tag im Daily über kleine Verbesserungen im Arbeitsalltag zu sprechen. 5 Minuten reichen.
https://marcloeffler.eu/2024/07/09/wie-gehe-ich-mit-schlechter-produktqualitaet-um/
Product Owner | Wenn der/die Product Owner:in nicht verfügbar ist …
Ein absolutes No-Go in einem Scrum Team ist ein nicht anwesender Product Owner. Hier muss dringend gegengesteuert werden. Glücklicherweise habe ich solche Situationen sehr selten erlebt und in wenigen Fällen sofort mit vereinten Kräften gegengesteuert, das Gespräch gesucht und mit dem Product Owner erfolgreich an den Ursachen gearbeitet. Der Ansatz von Simon Flossmann mit den fünf Schritten ähnelt meiner Vorgehensweise in diesen Fällen, wobei ich versucht habe, in den Gesprächen immer die Wirkung in den Vordergrund zu stellen und dabei immer wieder feststellen durfte, dass fast alle Product Owner selbst mit der Situation unzufrieden waren.
Gute Praxis | Der dreiteilige Vermerk als Hilfestellung
Als jemand, der nicht nur Verwaltungswissenschaftler studiert hat, sondern selbst viele Jahre in der öffentlichen Verwaltung tätig war und auch heute noch ein großes Herz für die Kommunalverwaltung hat, kann ich aus praktischer Erfahrung nur immer wieder betonen, dass wir von der oft gescholtenen öffentlichen Verwaltung sehr viel lernen können. Gerade mit Blick auf die großen Konzerne werde ich nicht müde zu erklären, dass manche Verwaltung viel agiler ist als eben jene Konzernbürokratie. Umso mehr freue ich mich, wenn ich nicht der Einzige bin, der in der Verwaltung gute Beispiele entdeckt, die übernommen werden können. Wie hier Felix Stein. Ein Ansatz, der mich übrigens auch an „5S im Kopf“ erinnert.
https://www.lean-agility.de/2024/07/der-dreiteilige-vermerk.html
Toms Gedankenblog 