PRODUKTIVITÄT
Not-To-Do-List für MS Teams | 8 schlechte Ideen für die Arbeit mit Micosoftteams
Microsoft Teams ist eine der am weitesten verbreiteten Kommunikationslösungen in Unternehmen. Ein Multitalent, das in der Breite vieles kann, in der Tiefe aber leider einiges vermissen lässt. Ein weiteres Problem von Multitalenten ist, dass man sich leicht verzettelt. Hier hilft vielleicht die Not-To-Do-Liste von Sigrid Hess ein wenig weiter, um so manche Lernkurve etwas schneller ansteigen zu lassen und das eine oder andere Thema gar nicht erst aufkommen zu lassen.
https://www.teamworkblog.de/2025/03/die-microsoft-teams-not-to-do-liste.html
Um Rat fragen | Rat einholen ohne „doof“ zu wirken
Wie frage ich um Rat, ohne den Eindruck zu erwecken, „zu dumm“ zu sein? Gute Frage. Ich habe oft eine Idee oder einen Gedanken zur Lösung eines Problems im Kopf, möchte diese aber erst mit jemandem besprechen, weil ich mir noch nicht sicher bin, ob ich alle Aspekte ausreichend erfasst habe. Was mir dann ab und zu passiert, ist, dass mein Gegenüber mir Ratschläge geben will, die ich gar nicht suche, und meint, mein Problem lösen zu müssen. Die Erkenntnis, die dann bei mir gereift ist, liegt in der Art und Weise, wie ich um Unterstützung gebeten habe. Dazu passt dann auch der Artikel von Dan Rockwell, der versucht, genau dafür eine Anleitung zu geben. Auf der einen Seite geht es darum, den Kontext zu liefern, auf der anderen Seite den Korridor abzustecken, dass der Fokus erhalten bleibt. Guter Ansatz, der – wie immer, wenn es um Kommunikation geht – etwas Hirnschmalz erfordert.
https://leadershipfreak.blog/2025/03/06/the-leaderly-pursuit-of-advice/
Obsidian | Exportfunktion für das Notizsystem
Bisher habe ich die Möglichkeit, Notizen aus Obisidian zu exportieren, nicht vermisst. Copy & Paste reicht mir in der Regel völlig aus. Allerdings bin ich im Blog von Thomas Mathoi auf das Pandoc-Plugin als Lösung gestoßen. Die Installation des Plugins erscheint mir recht aufwendig und im Beitrag wird die Variante für Mac vorgestellt. Ich selbst bin (noch) Windows-Benutzer (überlege auf Linux umzusteigen) und habe es noch nicht ausprobiert, da ich zu viele andere Bälle in der Luft habe. Ich bin sicher, dass es für den einen oder anderen interessant sein könnte.
https://www.mathoi.at/2025/03/03/das-pandoc-plugin-fuer-obsidian/
AGILE
Sprintziele | 3 Erkenntnisse aus langjähriger Arbeit mit Sprintzielen
Der Beitrag von Simon Flossmann hat mich schon wegen des Titels angesprochen. Wer gibt schon gerne zu, dass er fast 10 Jahre gebraucht hat, um ein Thema vollständig zu durchdringen. Da ist es wieder: Ein Meister fällt nicht vom Himmel. Wer Meister werden will, braucht Zeit. Viel Zeit für ständiges Lernen und Entwickeln. Und zur Meisterschaft kommt man nur mit viel Geduld. Übrigens, wer es zur Meisterschaft gebracht hat, ist auch ein beständiger Lerner. Das ist für mich wahre Meisterschaft. Das Wissen um die eigene Unfehlbarkeit, das mit jeder neuen Erkenntnis wächst. Ich muss aufpassen, dass ich jetzt nicht ins Philosophieren abdrifte. In diesem Beitrag geht es eigentlich um Sprintziele und die Erkenntnisse aus vielen Jahren Praxis mit ihnen. Eigentlich sind es nur drei. Ich bin bei allen drei Punkten dabei. Gerade den zweiten Punkt, die Nutzerzentrierung, empfinde ich derzeit in vielen Teams als besonders herausfordernd. Vor allem dann, wenn die Distanz zu den Nutzern besonders groß ist.
Stakeholder | Wenn die Stakeholder nicht wirklich mitziehen wollen …
Was tun, wenn die Anspruchsberechtigten nicht mitspielen wollen? Seien wir ehrlich, jeder, aber auch wirklich jeder, hat das schon erlebt. Die Stakeholder interessieren sich wenig dafür, dass das Team ein Review macht und am Ende des Sprints Sprintergebnisse präsentieren will. Oder das Feedback kommt einfach nicht schnell genug, so dass man nicht weiterarbeiten kann. Auch ein Klassiker, es wird nicht verstanden, warum man in Iterationen arbeitet und warum z.B. der Sprint geschützt ist und das Team erst im nächsten Sprint neue Anforderungen aufnimmt. Das ist in der Regel nicht böse gemeint. Genau um solche Situationen geht es in der Podcast Episode von No Agile Bullhsit, die ich unten verlinkt habe. Das Schöne daran ist, dass mein Namensvetter von seinen Erfahrungen berichtet und welche Strategien hier geholfen haben, die „Blockaden“ aufzulösen.
https://no-bullshit-agile.de/nba56-agilitaet-trifft-realitaet-stakeholder.html
Backlog-Management | Upstream-Kanban für die Organisation des Backlogs
Ich bin ein großer Fan von Kanban, auch wenn ich für „Neuentwicklungen“ in der Regel Scrum bevorzuge. Dennoch bediene ich mich auch hier gerne und immer wieder – je nach Kontext – aus der „Kanban-Trickkiste“. Zum Beispiel für das Backlog Management bietet sich Upstream Kanban an, wie es hier von Pawel Rola angeteasert wird. Der Begriff Upstream deutet es bereits an. Es geht um den „Workflow“ vor dem eigentlichen „Commit“ (Sprint). Mit Kanban lässt sich die schrittweise Verfeinerung des Backlogs von der ersten Idee bis zur Übernahme in den Sprint sehr gut darstellen.
https://www.scrum.org/resources/blog/product-backlog-management-upstream-kanban-chaos-clarity
Facilitation I | Effektive Facilitation-Techniken für den Arbeitsalltag
Für Freunde von Liberating Structures, Art of Hosting u.a. sind die 7 Facilitation-Techniken im Blog von Fadi Stephan wahrscheinlich wenig überraschend. Trotzdem finde ich die Zusammenstellung sehr spannend. Als kleiner schneller Spickzettel für die Workshop-Vorbereitung auf jeden Fall interessant. Unter den Tipps ist übrigens auch der „Redestab“ – ich habe kürzlich ein Videokonferenz-Tool ausprobiert, das einen virtuellen Redestab integriert hat. Etwas, das ich in dieser Form z.B. bei MS Teams oder Zoom noch nicht gesehen habe. Leider hat das Tool seine Macken, was das Teilen des Bildschirms angeht, weshalb ich es im Moment nicht wirklich empfehlen möchte. Der Rest ist recht unspektakulär und lässt sich sowohl remote als auch in Präsenz wunderbar integrieren und nutzen.
https://www.kaizenko.com/7-alternative-facilitation-techniques-to-open-discussions/
Facilitation II | Methoden fürs Workshops
Simon Flossmann stellt im folgenden Beitrag ebenfalls Facilitation-Techniken vor. Bei ihm steht jedoch der Lernaspekt im Vordergrund. Ich persönlich würde aber auch sagen, dass die meisten Techniken auch in anderen Workshops gut eingesetzt werden können. Auch wenn man selten „Trainings“ durchführt, können die Techniken interessant und hilfreich sein. Ein Blick lohnt sich.
Engpässe | Woher kommen Abhängigkeiten in Teams?
Gleich zu Beginn – bitte gewöhnt Euch möglichst die „5 Warum“ an, wenn Ihr auf Ursachenforschung geht. Ich habe es schon oft erlebt, dass nicht tief genug gegraben wurde, um an die Wurzel der Ursache zu gelangen. Oft genug wurde nur ein Schuldiger gesucht und das Problem blieb ungelöst. Das ist keine gute Idee. Da man irgendwo anfangen muss, braucht man zuerst eine Idee für mögliche Ursachen. Gerade beim Thema Abhängigkeiten in Teams kann es sehr viele Ursachen geben. Angefangen von technisch bedingten Gründen, Abhängigkeiten von Dritten, unklaren Entscheidungskorridoren bis hin zu fehlenden Kompetenzen in Teams. Hinter all diesen möglichen Gründen verbergen sich oft tiefer liegende, manchmal auch systembedingte Ursachen, die, wenn sie nicht wirklich angegangen werden, immer wieder zum Problem werden können. In die Tiefe zu gehen kann arbeitsintensiv und mühsam sein, zahlt sich aber in der Regel langfristig aus. Was Lavaneesh Gautam im Folgenden beschreibt, ist daher für mich der Einstieg in eine tiefer gehende Analyse.
https://www.scrum.org/resources/blog/behind-bottlenecks-root-causes-dependencies-teams
Ideales agiles Projekt | Was macht ein ideals agiles Projekt aus?
Was macht ein ideales (agiles) Projekt aus? Wenn ich meinen Namensvetter Thomas in der verlinkten Episode des No Bullshit Agile Podcasts richtig verstehe, sieht er das ähnlich wie ich: Ob agil oder nicht, spielt eine untergeordnete Rolle. Was zählt, ist die Zusammenarbeit und die Kommunikation. Das ist auch etwas, was ich vor vielen Jahren aus Projekten im Umfeld des bürgerschaftlichen Engagements mitgenommen habe. Kommunikation, Transparenz, Kooperation mit allen Beteiligten ist das, was das Projekt sinnvoll vorantreibt. Wie ich das methodisch unterfüttere, ist nicht so entscheidend. Methoden unterstützen das Ganze, sind aber nicht der Schlüssel. Wir sind ohnehin zu sehr auf Methoden fixiert, die in meinen Augen Hilfsmittel sind, aber nicht der eigentliche „Motor“. Am Ende zählt sowieso nur das Ergebnis.
https://no-bullshit-agile.de/nba57-ideales-agiles-projekt.html
LEADERSHIP UND MANAGEMENT
Führung und Authentizität | Führung trägt mehrere Hütte, die nicht immer zusammenpassen wollen
Der folgende Beitrag von Daniel Dubbel lässt mich etwas zwiespältig zurück. Mein Bauch sagt mir, dass authentisches Auftreten oberste Priorität hat. Mein Kopf sagt, dass es Situationen gibt, in denen die Führung nach außen eine Rolle „spielen“ muss, um ihrer Aufgabe gerecht zu werden. Da muss die Authentizität zum Schutz aller Beteiligten zurückstehen. Im Prinzip hat Dubbel das richtig erkannt: Wir haben – mir gefällt die Wortwahl besser als Maske – immer verschiedene Hüte auf. Auch als Führungskraft. Mal tragen wir den Hut „Kolleg:in“, mal den Hut „Chef:in“, dann den Hut „Manager:in“ usw. usf. Sich dessen bewusst zu sein, ist mitunter schwierig und doch sehr wichtig. Gerade in kritischen Situationen, wie z.B. bei unangenehmen Personalentscheidungen, ist mir das schon mehrfach schmerzhaft bewusst geworden. Zwischenmenschlich mag mir die Entscheidung nicht gefallen, aber zum Wohle der Organisation muss ich eine unangenehme Entscheidung treffen. In anderen Situationen – ich lege großen Wert auf Transparenz – muss ich Informationen vorübergehend zurückhalten, um keine Verwirrung zu stiften – auch wenn mir das nicht gefällt – und so tun, als wäre alles in Ordnung, obwohl ich selbst mehr Fragen als Antworten habe. Dieses bewusste und reflektierte Wahrnehmen der verschiedenen Hüte, die wir tragen, ist wichtig. Wie ich finde, übrigens auch auf der anderen Seite, der der Geführten. Aber das ist ein anderes Thema.
https://www.inspectandadapt.de/warum-gute-fuehrungskraefte-manchmal-clowns-sind/