PRODUKTIVITÄT
Aufgabenorganisation: Text oder Tabelle?
Bei der Aufgabenorganisation habe ich schon vieles ausprobiert – Methoden und Werkzeuge. Ich bin kein Freund von Listen – egal ob in Textform oder Tabellen. Aber dies hat viel mit meinen persönlichen Vorlieben zu tun. Und ich vertrete die Meinung, dass ein System der Aufgaben auch zum jeweiligen Menschen und seinen Vorlieben passen muss, damit es seine Effektivität und Effizienz ernsthaft entfalten kann. Daher gibt es nicht DAS System, sondern viele – die je nach Kontext und Vorlieben – bei dem einen besser funktionieren, bei dem anderen deutlich schlechter. Die Kartenoptik eines Kanbanboards (mit den entsprechenden visuellen Elementen) hat für mich bisher am besten funktioniert. Andere kommen am besten mit einem Listen-System zu Streich. Wer hier noch auf der Suche, nach einem möglichst einfachen Weg ist und möglichst mit einfachen Werkzeugen arbeiten möchte, dem empfehle ich einen Blick auf den den folgenden Beitrag von Stephan List im Toolblog:
https://toolblog.de/2020/04/16/aufgaben-organisieren-text-oder-tabellen/
Digitale Helfer: Eine kleine Sammlung mit Tipps
Es gibt eine Vielzahl kleiner digitaler Helfer für den Alltag. Von der Terminkoordination über Linkkürzer oder einfach nur Dateiorganisation. Einige davon stellt Stephan List im Toolblog vor, in dem Ihr – nebenbei – öfter mal solche Leckerbissen findet. Darunter auch datenschutzkonforme Alternativen zu Doodle wie Nuudle (übrigens mein persönlicher Favorit):
Konfliktmanagement: Konfliktlandkarte als Podcast
Wenn ich versuche, Konflikten auf die Schliche zu kommen, hilft mir persönlich immer wieder die Konfliktlandkarte, wie sie Andrea Windolph in Ihrem Podcast beschreibt, immer wieder weiter. Sie hilft mir zu Verorten, wer alles beteiligt ist und besser zu verstehen, was mögliche Ursache für den Konflikt sein könnten. Vielleicht ist der Ansatz für Euch auch von Interesse:
https://projekte-leicht-gemacht.de/podcast/plg-039/
Problemlösen: Erst verstehen, dann lösen
Ein Problem zu lösen, bedeutet in aller Regel das Problem erst zu verstehen. Leider passiert – besonders wenn es brennt – genau dies nicht. Unter vermeintlichem Druck beginnen wir sofort zu lösen, statt erst einmal zu verstehen. Beobachten kann man es in der freien Wildbahn oft genug. Bei Manager, Politiker oder – wenn wir selbstreflexiv beobachten – auch oft genug bei uns. In diese Kerbe schlägt Roland Dürre mit einem Artikel, in dem er am Beispiel einer logisch lösbaren Aufgabe aufzeigt, warum wir erst innehalten und verstehen sollten, ehe wir loslegen die Lösung zu erarbeiten:
http://if-blog.de/rd/das-richtige-rangehen-an-probleme/
Fokus: Klarheit und Überblick behalten in Zeiten der Unsicherheit
Es gibt immer Phasen mit mehr und mal weniger Unsicherheit. Das gehört dazu, wenn man bedenkt, dass wir eingebunden sind, in ein kaum zu überschaubares Geflecht von Beziehungen, Einflüssen und Rahmenbedingungen. Die Welt ist komplex. Gerade wenn die Fragezeichen immer größer werden, ist es besonders wichtig, Klarheit darüber zu haben, was uns antreibt und uns wichtig ist. Hier setzt der Artikel von Dan Rockwell an:
AGILE
Veränderungen: Scrum unterstützt, aber löst das Problem nicht
Ich bin am Sonntag auf einen Artikel von Marc Löffler aufmerksam geworden, der ziemlich auf den Punkt bringt, was ich auch immer wieder betone. Viele Organisationen meinen, wenn sie sich für einen methodischen Ansatz wie Scrum entscheiden, würde dies ihre Probleme lösen. Eine Erwartung, die kein noch so innovativer Ansatz, kein noch so bewährter Ansatz erfüllen kann. Viel mehr wird sichtbar, was an Hindernissen und Herausforderungen schlummert, die es zu lösen gilt, um die oft tiefer gehenden Probleme in der Organisation aufzulösen. Die Transparenz wird erhöht, doch die Veränderung selbst muss aber durch die Menschen in der Organisation zu erfolgen.
https://marcloeffler.eu/2017/05/17/scrum-ist-nicht-die-antwort/
Scrum-Mythen: Produkt oder Projekt?
Es gibt keine Lösung für alle Herausforderungen. Das ist ein Credo, dass ich immer wieder von mir gebe und von dem ich fest überzeugt bin, dass dies den Unterschied zwischen einem echten Agilisten und einem Agilologen ausmacht. Daher ist Scrum zwar eines meiner favorisierten Rahmenwerke, aber eben nicht das einzige Werkzeug, dass ich in der Werkzeugkiste habe. Scrum kommt immer dann für mich ins Spiel, wenn ich es mit einem hochkomplexen Projekt (ja, Projekt – nicht Produkt) zu tun habe. Sprich: Es ist unklar, wie genau wir an das Ziel kommen und selbst das Ziel selbst können wir noch nicht exakt erfassen. Dennoch hält sich hartnäckig in vielen Köpfen die Vorstellung, bei Scrum ginge es nicht um Projekte, sondern ausschließlich um Produkt und – das ist das andere Extrem – Scrum passt auf jeden Aufgabenstellung (auf dieses Extrem gehen wir leider heute nicht weiter ein). Mit dem ersteren Mythos räumt der Artikel von Christiaan Verwijs auf:
https://medium.com/the-liberators/myth-you-cant-do-projects-with-scrum-f579accfbefa
Product Owner: Die Führungsrolle des Product Owners
Ich tue mich ein wenig schwer, dem Product Owner als „Leader“ zu bezeichnen, da in einem Scrum-Team, jede der drei Rollen – mit jeweils unterschiedlichem Fokus – die Führung innehat. Und doch hat der Product Owner eine nicht zu unterschätzende Position. Die Rolle ist verantwortlich für das „WAS“, also die Vision und den ökonomischen Mehrwert, der erzeugt werden soll. Damit ist die Rolle natürlich in einer führenden Rolle. Genau diese führende Rolle ist Gegenstand des Produktwerker-Podcasts mit Sohrab Salimi, die Ihr unter dem folgenden Link erreicht:
https://produktwerker.de/product-owner-als-agile-leader/
Product Owner: Worauf liegt der Fokus des POs?
Ich hatte es weiter oben schon erwähnt: In einem Scrum-Team hat jede der drei Rollen innerhalb eines Fokus die Führungsverantwortung. Der Scrum Master hat seinen Fokus auf der Produktivität des Teams, das Entwicklerteam den Fokus auf der Qualität der Ergebnisse und das Wie, der Product Owner den Fokus auf dem Mehrwert/Nutzen und dem Was. Was bedeutet dies jedoch genau? Für den Product Owner beschreibt Magdalena Firlit in einem Blogartikel, was genau mit dem Fokus des Product Owners gemeint ist:
https://www.scrum.org/resources/blog/what-should-be-focus-product-owner
Retrospektive: Vier häufige Stolpersteine und die Lösung
Die Retrospektive ist eines der essenziellen Elemente von Scrum am Ende des Sprints und auch wenn Ihr lieber Kanban den Vorzug gebt, werdet Ihr kaum um die vorausschauende Rückschau einer Retrospektive herum kommen, den auch Kanban setzt klar den Fokus auf die Verbesserung und Weiterentwicklung der Zusammenarbeit. So eine Retrospektive durchzuführen ist nicht immer ganz einfach. Mal fehlt die Vertrauensbasis, mal schleicht mit der Routine die Langeweile ein, mal gelingt es nicht, eine zielführend Retrospektive aufzubauen oder man kämpft mit der Herausforderung der räumlichen Distanz. Diese vier Herausforderungen thematisiert Mike Cohen mit passenden Lösungsoptionen in seinem Blogartikel, den Ihr unter dem folgenden Link findet:
https://www.mountaingoatsoftware.com/blog/overcoming-four-common-problems-with-retrospectives
Retrospektive: Ein Format für den Blick in Umfeld
Es macht durchaus Sinn, bei einer Retrospektive einen bestimmten Blickwinkel in den Fokus zu rücken. Meist wird dabei die Zusammenarbeit im Team betrachtet. Eher selten spielt das Teamumfeld in einer Retrospektive eine herausragende Rolle. Das ist verwundert, wenn man überlegt, dass jedes Team eben auch in ein Umfeld eingebettet ist und die Auswirkungen enorm sein können. Ein passendes Format hierfür bietet Khoa Doan Tien in einem Blogartikel an: die vier „Böden“. Er bedient sich dabei der Metapher der Bodenbeschaffenheit.
https://dzone.com/articles/the-4-soils-sprint-retrospective
Schätzung: Remote mit dem Rapid Estimation Game
Die Schätzung der Komplexität von User Storys ist für mich ein wertvolles Feedback-Werkzeug, um dem Product Owner Rückmeldung zu geben, ob der Zuschnitt seiner User Story für das Team passt und auch eine Gelegenheit im Dialog ein gemeinsames Verständnis zu entwickeln. Remote gibt es dafür viele tolle Werkzeuge, die insbesondere auf Planning Poker setzen. Nachteil bei Planning Poker ist allerdings der hohe Zeitaufwand, um einen großen Backlog durchzuschätzen. Wie bekommt man schnell einen Backlog durchgeschätzt? Noch dazu, wenn man bei den Werkzeugen auf die üblich Verdächtigen verzichten muss, um den Compliance-Regeln zu entsprechen? Hier könnte der Ansatz für das Rapid Estimation Game weiterhelfen, dass ich im TastyCupcakes-Blog gefunden habe. Ist zwar optisch nicht elegant, funktioniert aber sehr gut.
https://www.tastycupcakes.org/2020/04/rapid-estimation-game-for-remote-workers/
LEADERSHIP
Demut und Führung: 6 Aspekte der Demut im Kontext der Führung
Wenn es um gute Führung geht, dann ist Demut eine der häufig genannten Tugenden, die man dieser zuschreibt. Tim McMahon hat dem Thema Demut im Kontext der Führung einen Blogartikel gewidmet, in dem er erläutert, was er unter Demut und Führung versteht. Ein paar interessant Impulse für die eigene Reflexion:
http://www.aleanjourney.com/2020/04/six-leadership-principles-for.html
Toms Gedankenblog 