PRODUKTIVITÄT
Ordnung schaffen | Die befreiende Wirkung des Aufräumens
Ich bin kein pedantischer Ordnungsfanatiker, bei dem alles akkurat einsortiert sein muss, doch ich schätze eine gewisse Grundordnung. Hin und wieder kriege ich einen Rappel, und dann bringe ich den Keller, die Abstellkammer oder den Stapel ungelesener Bücher auf Vordermann. Das ist ein befriedigendes Gefühl. Ähnlich mache ich es auch mit meinem persönlichen Backlog, also meiner „To-Do-Liste”. Wenn ich regelmäßig entrümpele, gewinne ich wieder den Überblick, der im täglichen Tun gerne mal verloren geht. Insofern bilde ich mir ein, Anne Koschinski zu verstehen. Auf jeden Fall habe ich den Artikel zum Anlass genommen, zumindest mein Backlog aufzuräumen und meinen Schreibtisch von angefangenen Büchern und Fachzeitschriften zu befreien. Morgen will ich den Stapel der ungelesenen Bücher „ausmisten” und neu priorisieren. 😉
https://anna-livia.de/dinge-in-ordnung-bringen/
FritzNAS | Dateien freigeben mit FritzNAS
Wieder etwas Neues über Fritzbox gelernt. FritzNAS als Freigabefunktion, mit der man seine Fritzbox zum NAS erweitern kann, war mir noch nicht bekannt. Wieder etwas dazu gelernt. Inbesondere, weil ich gerade darüber nachdenke einen NAS ins Heimnetzwerk zu integrieren. Vielen Dank Herbert Hertentramph, der mich über seinen Blog auf die Möglichkeit hingewiesen hat. Was offenbar neu ist, so schreibt er, ist die Freigabefunktion mit der man auch Dateien außerhalb des Heimnetzwerks problemlos teilen kann. Sicherlich auch für den einen oder anderen hilfreich.
https://digital-cleaning.de/index.php/fritznas-neue-freigabefunktion/
Obsidian | Bases für Datenbanken in Obsidian steht in den Startlöchern
Ich nutze Obsidian (noch) nicht so intensiv wie Thomas Mathoi. Ich nutze es bisher nur auf meinem privaten Rechner und bleibe daher noch weit hinter den Möglichkeiten zurück. Auf dem Projektrechner war es leider nicht möglich, da es nicht unter die erlaubte Software fiel. Heute habe ich in seinem Blog gelesen, dass Bases in Kürze an den Start gehen soll. Mit dieser Funktion soll es möglich sein, ohne Plugin und Addon Datenbanken in Obsidian zu bauen. Noch ist das Ganze in der Beta-Phase. Ich bin gespannt, was da kommt. Vermutlich werde ich wieder zu „faul” sein, um tatsächlich eine Bücherdatenbank oder Ähnliches mit Obsidian aufzubauen. Das heißt aber nicht, dass es nicht für jemanden von euch interessant sein könnte. Schaut es euch an und entscheidet selbst.
https://www.mathoi.at/2025/07/24/bases-datenbanken-mit-obsidian/
Irgendwann | Schluss mir irgendwann
Irgendwann mache ich „x” und schreibe es auf eine Liste, in die ich selten bis nie schaue. So war es in der Vergangenheit. Seither gibt es keine „Irgendwann“-Liste mehr. Die Aufgabe landet im persönlichen Backlog. Wenn sie dort länger als drei Monate liegt, fliegt sie bei der nächsten Aufräumaktion raus, denn aus „Irgendwann“ wird nichts. Wenn es wichtig wird, schlägt das Thema wieder auf und dann nehme ich es in Angriff. Dazu habe ich mich entschieden, lange bevor ich den Satire-Podcast von Thomas Speck entdeckt habe. Und doch hat mich seine – hier verlinkte – Podcastfolge genau daran erinnert. Und daran, weshalb ich lieber ein „Nein” von jemandem höre als ein „Vielleicht”. Mit einem „Vielleicht” kann ich nichts anfangen. Es ist unverbindlich und schwammig. Ein klares „Nein” kann ich hingegen nachvollziehen. Eine Zusage ist etwas, auf das ich mich verlassen will und muss. Diese grassierende Unverbindlichkeit in Form von „Ja“, die eher ein „Vielleicht“ ist, macht mir schon genug Arbeit, weil ich permanent nachfragen muss und mich nicht darauf verlassen kann. Das macht keinen Spaß. Leider ist diese „Unverbindlichkeit” eine sich immer weiter ausbreitende „Krankheit” und ein Ärgernis. Nicht nur anderen, sondern auch uns selbst gegenüber. Daher verleihe ich das Prädikat „hörenswert” bereitwillig und gerne an die aktuelle Podcastfolge von Thomas Speck und seinem Satire-Podcast „Der Schalltrichter”.
https://der-schalltrichter.letscast.fm/episode/irgendwann-ganz-bestimmt-vielleicht-sogar-morgen
LEAN
Probleme lösen | Die 8 Disziplinen des Problemlösens vorgestellt
Ich persönlich ziehe den Toyota-Ansatz vor, aber auch die acht Disziplinen des Problemlösens haben ihren Charme. Christoph Roser erläutert sie in einer Blogserie näher. Dabei handelt es sich um neun einzelne Schritte, die als Disziplinen bezeichnet werden. Die Disziplinen D0 und D1 sind Gegenstand des ersten Blogartikels, den ich hier verlinke. Interessant finde ich, dass es zu jedem Schritt auch vertiefende Empfehlungen gibt. Es ist nichts wirklich Überraschendes, dennoch ist jeder Punkt äußerst spannend, auch in anderen Kontexten.
https://www.allaboutlean.com/8d-d0-and-d1/
Fehlersuche | Weshalb es nicht reicht, den faulen Apfel zu entfernen
Götz Müller weist zu Recht darauf hin, dass wir bei der Ursachenforschung nicht den einfachen Weg gehen dürfen, sondern uns immer auch intensiv mit dem Gesamtsystem beschäftigen müssen. Es ist sinnvoll, immer auch in die Tiefe zu bohren. Leider bemühen wir uns oft, ein lokales Problem zu lösen, und meinen, die Ursache gefunden zu haben. Wenig später wundern wir uns dann, weshalb wir weiterhin mit Problemen zu kämpfen haben. Die vermeintliche Ursache liegt oft tiefer im System vergraben, als es den Anschein hat. Daher ist es unerlässlich, Upstream-Ursachen zu beheben, noch bevor sie entstehen.
https://www.geemco.de/artikel/was-aepfel-mit-lean-zu-tun-haben
AGILE
User Stories | Typische Fehler in der Arbeit mit User Stories
Zu Beginn meines letzten Projekts habe ich mein Team kräftig verwirrt, weil ich selten von User Stories, sondern immer von PBI (Product Backlog Items) gesprochen habe. Der Hintergrund ist einer der von den Produktwerkern benannten Fehler beim Thema User Stories. Der verzweifelte Versuch, alles in ein User-Story-Format pressen zu wollen, auch wenn dieses gar nicht passt. Aber auch die anderen vier benannten Aspekte kommen mir regelmäßig unter, und ich kann sogar verstehen, wie es dazu kommt. Besser, als mir manchmal recht ist. Wie heißt es doch so schön: Eine User Story ist eine Einladung zum Dialog. Doch genau das findet viel zu selten statt, weil beispielsweise der Lieferdruck zu hoch ist und ein Team im reaktiven Modus die Menge abarbeitet, anstatt tiefer zu bohren und zu verstehen, was es wirklich braucht. Nur um ein Beispiel zu nennen.
https://produktwerker.de/fehler-bei-der-arbeit-mit-user-stories/
Stakeholdermanagement | Kooperation fördern statt Konfrontation
Worum geht es beim „agilen Arbeiten”? Wir wollen gute Ergebnisse in hoher Qualität unter Bedingungen hoher Komplexität erzielen. Und wie gelingt das am besten? Durch Zusammenarbeit und Kooperation. Mit allen Beteiligten. Damit sind wir bereits bei den Stakeholdern angelangt. Unter den Begriff Stakeholder können viele Gruppen fallen. Auch solche, die auf den ersten Blick aktuell keine große Relevanz für uns haben. Da wir von komplexen Projekten sprechen, wissen wir oft gar nicht, ob Stakeholder, die aktuell keine große Relevanz haben, später wichtig werden könnten. Das kann sich schnell ändern. Allein schon deshalb kann ich jedem nur eine kooperative Strategie im Umgang mit allen Stakeholdern empfehlen. Es mag sich auf den ersten Blick nicht immer lohnen, aber das Leben hat mich gelehrt, dass es sich irgendwann immer auszahlt. Daher klare Empfehlung für den Beitrag von Simon Flossmann.
https://www.scrum.org/resources/blog/stakeholdermanagement-die-beste-strategie
Scrum Master I | Scrum Master:innen sind Führungskräfte
Der Scrum-Leitfaden ist ziemlich eindeutig: „Scrum Master sind echte Führungspersönlichkeiten, die dem Scrum-Team und der Gesamtorganisation dienen.“ Damit müsste eigentlich alles gesagt sein. Pustekuchen! Die grausame Realität ist, dass Scrum Master:innen oft nicht als „Führungspersonen” anerkannt werden. Über die Ursachen will ich mich heute nicht auslassen, das ist ein sicherlich abendfüllendes Thema. Ich möchte mithilfe von Mary Iqbal hervorheben, dass Scrum Master Führungskräfte sind und dass sie in dieser Rolle wichtiger denn je sind – auch wenn immer mehr Unternehmen meinen, auf Scrum Master verzichten zu können. Gute (!) Scrum Master:innen sind wertvoll und hilfreich für die Organisation. Nur sollte man auch dazu sagen, dass es sie nicht im Eilverfahren nach einer zweitägigen Zertifizierung gibt. Das ist allerdings heute nicht das Thema.
https://www.scrum.org/resources/blog/scrum-masters-and-leaders-have-lot-common
Scrum Master II | Fähigkeiten für die Zukunft
Marc Löffler hat eine Podcastfolge zu einem sehr aktuellen Thema bereitgestellt: Der Markt für Scrum Master:innen befindet sich in einer Umbruchsituation. Das merke ich selbst auch – und zwar massiv. Spätestens jetzt sollten viele Kolleg:innen beginnen, sich Gedanken darüber zu machen, welche Fähigkeiten sie weiterentwickeln wollen. Für mich gehören Change Management, Organisationsentwicklung und Ähnliches ohnehin zum Repertoire guter Scrum Master und Kanban Coaches. Allerdings beschäftige ich mich damit auch schon seit meiner Studienzeit, da es Teil meines Studiums war. Dadurch ist mir der Zugang leichter gefallen als Menschen mit ursprünglich technischem Hintergrund. Ob das allerdings ausreicht? Keine Ahnung. Ich persönlich bezeichne mich schon lange nicht mehr als Scrum Master oder Agile Coach. Das sind Rollen, die ich einnehme. Ich verstehe mich eher als Organisationsscout, der dabei hilft, einen Weg zu finden, und dabei unterstützt und begleitet sowie mögliche Pfade aufzeigt. Leider ist diese Bezeichnung nicht immer ganz ausschreibungstauglich 😉
https://passionateteams.com/e/welche-skills-du-dir-als-scrum-master-jetzt-aneignen-solltest/
Vibe Coding und agiles Arbeiten | Welche Auswirkungen könnte Vibe Coding auf agiles Arbeiten haben?
Vibe Coding – ein Begriff, der mir immer öfter begegnet. Damit geht auch die Vorstellung einher, dass man künftig auf DEV-Teams verzichten könnte, da die KI ja alles macht. Ich persönlich bin da etwas skeptisch. Das mag für „standardisierbare” Dinge wunderbar funktionieren, bei komplexen Problem- und Aufgabenstellungen sehe ich das allerdings noch lange nicht. Interessant finde ich allerdings den Ansatz aus dem Podcast „No Bullshit Agile“: Nicht über die technischen Aspekte diskutieren, sondern darüber, wie sich Vibe Coding auf das iterativ-inkrementelle Arbeiten auswirken könnte und was dies möglicherweise bedeutet. Es sind durchaus interessante Gedanken, die hier mitspielen. Hört selbst rein und macht euch eigene Gedanken.
https://no-bullshit-agile.de/nba75-vibe-coding-agiles-arbeiten.html
Toms Gedankenblog 