| Lieblingshashtags | #Scrum #Agiltät #AgileManifesto #Agile |
| Webseite | https://scrumschau.wordpress.com/ |
| Account stillgelegt | |
| Agile Themen aus | (DACH) Deutschland, Österreich, Schweiz und etwas englischer Content |
⌨️ 💻 **WIKIPEDIA KANNST DU AUCH** 💻 ⌨️
Wer wie ich schon länger ein #Wikipedia -Konto hat, sich aber noch nicht wirklich zum editieren aufraffen kann: Es gibt drei Veranstaltungen in den nächsten Wochen, in denen wir das lernen und üben können.
WANN?
Mittwoch, 15. April
Dienstag, 05. Mai und
Dienstag, 26. Mai
Jeweils 18:00-19:30 Uhr
WO?
ONLINE!
Infos und kostenlose Anmeldung: https://www.wikimedia.de/veranstaltungen/wikipedia-kannst-du-auch-april/
#LINKSDERWOCHE | 15/2026: Produktivität, Agile, Management und Leadership
PRODUKTIVITÄT
Selbstausbeutung | Wie wir uns selbst „sabotieren“
Gerade als ich die Links der Woche zusammenstelle, stoße ich in meinem RSS-Reader (ja, ich habe tatsächlich einen, der ein wichtiger Teil meines Informationsmanagements ist) auf einen Gastbeitrag von Astrid Kuhlmey bei t2informatik. Ein Blogbeitrag, der mir in weiten Teilen sogar aus der Seele spricht. Sie spricht von „Selbstausbeutung”. Das trifft es ganz gut. Das erinnert ein bisschen an die von mir immer wieder ins Spiel gebrachte „Effizienzneurose”, die zwar auf einer anderen Ebene ansetzt, aber eben auch Teil jener Denkweise ist, die den ganzheitlichen Blick nahezu komplett „ausblendet” und „Upstream-Denken” fast unmöglich macht. Bedauerlicherweise sind wir alle Teil eines Systems und es ist gar nicht so einfach, dieser Entwicklung entgegenzuwirken – selbst wenn man die Erkenntnis hat. Insbesondere nicht, wenn uns ewig gestrige „Entscheidungsträger” erklären, wir müssten mehr arbeiten (trotz Verdichtung der Arbeitsqualität und anderer Faktoren).
https://t2informatik.de/blog/stoppt-die-selbstausbeutung/
Aufgabenmanagement | Aufgaben mit Obsidian ohne Plugins organieren
Ich habe Obsidian – auch durch Thomas Mathoi – schon lange auf dem Schirm. Ich nutze es zwar immer noch zu wenig. Das will ich aber ändern. In seinem folgenden Blogartikel zeigt Thomas Mathoi, was Obsidian allein schon mit Bordmitteln in Sachen Aufgabenorganisation kann, sodass man gut auf Plugins verzichten kann. Das ist sicherlich nicht ganz so schick wie manche anderen Werkzeuge auf dem Markt. Dennoch ist es ausreichend. Hinzu kommt, dass sich Notizen und Aufgabenmanagement gut vereinen lassen.
https://www.mathoi.at/2026/04/06/obsidian-kaizen-aufgabenuebersicht-mit-bordmitteln-selber-bauen/
Zu viele Aufgaben | Rahmen schaffen für Priorisierung
Ich beschäftige mich gefühlt schon ewig mit Produktivität und habe unzählige Methoden, Ideen und Ansätze ausprobiert. Gefühlt hat keine davon das zentrale Problem gelöst, dass es immer mehr zu tun gibt, als ich leisten kann. Je mehr ich von meiner To-do-Liste abarbeite, desto mehr kommt nach. Die Lösung dafür lautet oft: richtig priorisieren, dann wird das schon. So einfach ist es dann eben oft nicht. Meine Erkenntnisse: 1. Es gibt nicht die eine Wunderlösung und Methode. 2. Jeden Tag setze ich alles zurück und plane „frisch”. Ähnlich sieht es bei den Empfehlungen von André Bosse aus. In seinem Beitrag finden sich ein paar gute Ansätze.
https://www.manage-dich-selbst.de/zu-viele-aufgaben/
Agieren statt Reagieren | Reaktionsmodus im Aufgaben abarbeiten durchbrechen
Zum Thema der endlosen „Aufgabenliste“, das ich bereits angesprochen habe, passt ganz gut der aktuelle Podcast von Ivan Blatter. Er bringt eine spannende Perspektive ins Spiel: Das Abrutschen in den Reaktionsmodus führt dazu, dass wir wieder in die Teufelküche geraten, wenn alles gleich wichtig zu sein scheint und das „Dringende“ das „Wichtige“ in den Hintergrund drängt. Wir arbeiten die Aufgabenliste ab, ohne „Licht am Horizont”, weil ständig neue Aufgaben nachrücken. Wir reagieren statt zu agieren. Ivan Blatter gibt vier Tipps, mit denen wir aus diesem Modus aussteigen können. Und das ist vor allem Arbeit am „System”. Übrigens gibt es auch eine Überschneidung zu den Tipps von André Bosse. 😉
https://share.transistor.fm/s/b4bd36e6
Komfort macht „blöd“ | Und deshalb müssen wir reflektiert aus der Komfortzone regelmäßig raus
Irgendwann habe ich für mich festgestellt, dass die Menschen, die sich immer wieder selbst hinterfragen und versuchen, sich nicht zu wichtig zu nehmen, deutlich spannender sind. Sie sind offen für neue Ideen und Impulse. Außerdem liefern sie mir durch ihre Neugier und ihre Fragen neue Impulse, wie ich meine Ideen weiterentwickeln kann. Sie alle zeichnen sich dadurch aus, dass sie sich nicht in ihrer „Komfortzone” einrichten, sondern sich immer wieder hinauswagen. Nicht hochriskante Geschichten, sondern bewusst und reflektiert. Wenn ich Dan Rockwell folge, würde ich sagen, dass wir auch aktiv dazu beitragen können. So wir wollen. Wie er treffend festhält, führt zu viel Komfort dazu, dass wir „dumm” werden (im Sinne von arrogant). Und wir alle wissen, dass das gefährlich ist.
https://leadershipfreak.blog/2026/04/09/comfort-makes-you-stupid/
AGILE
Kognitive Fallen | Wenn Effizienzdenken die Empirie überlagert
Die wohl wichtigste Frage ist: In welchem Kontext bewege ich mich und was ist in diesem Kontext der passendste Weg? Und genau diese Überlegung wird überraschend selten angestellt. Wenn es dann nicht funktioniert, ist der gewählte Ansatz grundsätzlich „Schrott”. Dabei wird gerne vergessen, dass methodische Ansätze wie Scrum für einen bestimmten Kontext geschaffen wurden. Scrum ist ein Rahmenwerk für die explorative Erforschung komplexer Aufgabenstellungen. In diesem Kontext funktioniert eine Denkweise, die für reproduzierbare und standardisierbare Aufgaben gemacht wurde, nicht. Gleiches gilt, wenn ich auf Kanban setze. Kanban ist in einem explorativen Kontext anders als in einem Kontext von Routinetätigkeiten, weil die Art der Arbeit eine andere ist und andere „Anforderungen” stellt. Es ist also durchaus sinnvoll, sich zu fragen, welche Denkweise für welchen Kontext geeignet ist und wie eine Denkweise aus dem einen Kontext im anderen Kontext zu kognitiven Fallen werden kann. Diese Fallen beschreibt Chuck Suscheck sehr treffend.
https://www.scrum.org/resources/blog/cognitive-trap-efficiency-over-empiricism
ROI von Scrum | Wie Scrum – bei explorativen Aufgaben – Kosten reduziert und Umsatz verbessert
Die Überschrift von Robert Pieper ist ein bisschen reißerisch, denn was er über Scrum schreibt, gilt nur für einen bestimmten Kontext. Jenen Kontext, für den Scrum geschaffen wurde. Nämlich für das explorative Lösen komplexer Problemstellungen. Und genau hier greift die Arbeitsweise von Scrum: Die kurzen Feedbackzyklen führen unter anderem dazu, dass wir schneller auf Fehler und Irrtümer reagieren können (was Zeit und Kosten reduziert) und früher echten Mehrwert liefern können, mit dem sich Umsatz generieren lässt – sofern man am Ende des Sprints tatsächlich ein fertiges, vollverwendbares Teilinkrement liefert. Grundsätzlich bin ich mit ihm einverstanden. Wenn es um „Neuentwicklung” geht. Und genau dafür wurde Scrum geschaffen.
https://www.scrum.org/resources/blog/scrum-roi-how-scrum-reduces-costs-and-drives-revenue-growth
Coaching und Führungsframeworks | 21 „Analyselinsen“ und Perspektiven nicht nur für Scrum Master:innen
Jan Fischbach hat eine echte Fleißarbeit geleistet. Er hat sich die unterschiedlichsten Coaching- und Führungsrahmenwerke sowie die jeweiligen Perspektiven, die sie einnehmen, angesehen. Insgesamt hat er damit „21 Linsen” zusammengetragen. Ich bin mir sicher, dass kein Coach und kein Trainer alle im Tagesgeschäft abdecken kann. Darum geht es meiner Meinung nach auch nicht. Es geht vielmehr darum, uns zu sensibilisieren, dass wir uns nicht auf eine „Perspektive” verlassen dürfen. Wir müssen immer im Hinterkopf behalten, dass es für jedes Thema unterschiedliche Perspektiven gibt, die mitunter auch zu ganz unterschiedlichen Lösungsansätzen führen. Die Welt ist komplex. Daher ist es wichtig, sich bewusst zu machen, dass wir Herausforderungen aus unterschiedlichen Blickwinkeln betrachten sollten. Nicht nur mit den zwei oder drei, die wir persönlich bevorzugen, sondern auch mit der Brille anderer „Denkschulen”. Das macht für mich auch einen guten „Agile Coach” aus.
https://www.teamworkblog.de/2026/04/coaching-und-fuhrungsframeworks-im.html
Analyselinsen für Scrum Master | Drei Analyseperspektiven für den täglichen Arbeitsalltag
Jan Fischbach hat das Thema der „verschiedenen“ Linsen in einem Fortsetzungsbeitrag erneut aufgegriffen und dieses Mal für die Zielgruppe der „Scrum Master“, die ihre Rolle gerade erst übernommen haben, zusammengedampft. Interessant finde ich, dass er drei „Linsen” vorstellt, um am Ende die Prozesslinse als die wichtigste zu benennen. In der Praxis erlebe ich zu oft, dass die „Arbeitsklimalinse” im Fokus steht und die Prozesslinse bzw. die Arbeitsergebnisse hinten runterfallen – nicht nur bei frisch gebackenen Scrum Master:innen. Agilität ist kein Selbstzweck. Sie soll dazu dienen, bessere Arbeitsergebnisse zu erzielen.
https://www.teamworkblog.de/2026/04/neuer-scrum-master-mit-drei-einfachen.html
Produktziel | Weshalb das Produktziel von Bedeutung ist
Ich bin, das ist kein Geheimnis, ein großer Fan der Verbesserungskata und ihrer Bestandteile. Dieses Bild verwende ich auch gerne und oft, da es für mich etwas Entscheidendes verdeutlicht: Es braucht einen „Referenzpunkt”, der für Klarheit sorgt und die Richtung vorgibt. Im Kontext der Produktentwicklung ist das das Produktziel. Was mich ebenso an der Verbesserungskata fasziniert, ist die Idee des „Nordsterns” als „zeitloses”, handlungsleitendes Ziel, das auf die Wirkung abzielt. Diese Idee übertrage ich gerne auf andere Bereiche, da ich denke, dass wir in einer hochkomplexen Welt genau das brauchen, um effektive Entscheidungen treffen zu können, die ausreichend Flexibilität und Handlungsspielräume bieten und gleichzeitig Orientierung geben. Das Ganze – wieder zurück zum Thema Produktziel – wird im Produktwerker-Podcast im Kontext der Produktentwicklung dargestellt.
https://produktwerker.de/das-product-goal-warum-sich-daran-der-wandel-der-po-rolle-zeigt/
LEADERSHIP UND MANAGEMENT
Unsicherheit und Führung | Unsicherheit nicht „ignorieren“, sondern „sichtbar“ machen
Ufz, der Blogartikel von Daniel Dubbel hat es in sich. Er ist lang. Er ist vollgepackt mit Gedanken. Und er hat eine Botschaft, die für den einen oder anderen nicht leicht verdaulich sein dürfte. Es geht um Unsicherheit. Unsicherheit, die wir aktuell alle massiv spüren. Aber sie war schon immer da. Und wird immer da sein. Und ja, es macht keinen Spaß. Mir nicht. Und niemand anderem da draußen. Ambiguitätstoleranz wird oft mit der Einzelperson verknüpft. Und jetzt kommt Daniel Dubbel daher und erklärt, dass eine Organisation und ihre Teile als solche Ambiguitätstoleranz erlernen muss. Mit anderen Worten, er besitzt doch frech die Unverschämtheit, uns zu sagen, wir sollten uns von den einfachen zweckrationalen Modellen verabschieden, in denen wir in unseren Organisationen arbeiten, weil „Komplexität“ nicht beherrschbar machen können. Wir müssen selbst und die Organisationen, in denen wir arbeiten, befähigen mit Unsicherheit umgehen zu können. Und dazu muss Führung selbst umdenken. Und zwar ordentlich.
Mehr vom Guten | Wie man gute Führung „multipliziert“
Gute Führung „multipliziert“ sich, indem sie andere dazu befähigt, selbst zu führen. Eigentlich naheliegend. Wäre da nicht der Faktor Mensch. Aber gut, auf die Ursachen will ich gar nicht eingehen. Dan Rockwell zeigt, wie man als Führungskraft gute Führungskräfte „multipliziert“. Nämlich durch das Befähigen von Menschen, die selbst gewillt sind, andere zu befähigen. Ich kenne nur wenige Organisationen, die diese Kunst wirklich aktiv befördern und als Teil ihrer Kultur verankert haben. Es wäre schön, wenn es Nachahmer gäbe. Aktuell hat man eher das Gefühl, die Uhr dreht sich rückwärts.
https://leadershipfreak.blog/2026/04/10/multiply-or-die/
#Agile #Analyse #Aufgabenmanagement #Coaching #Führung #KognitiveFallen #Management #Obsidian #Priorisierung #Produktivität #ROI #Scrum #ScrumMaster #Unsicherheit #Zeitmanagement
I also added a little AI refusal rationale:
Generative AI is a highly problematic technology for numerous reasons - just to name a few: It uses lots of resources, results are nondeterministic and deceptive, costs are being externalized, knowledge and economic power monopolized and labor rights undermined. By facilitating intellectual laziness, and reinforcing bias, amongst other things, generative AI actively contributes to the rise of fascist politics and the destruction of democracy. 1/2
"When I first wrote about microservice disasters, I thought we'd eventually "solve" them, with better tooling, frameworks, and operational maturity. We didn't. We just learned to live with the chaos. Distributed systems will always surprise you: timeouts, retries, and fallacies don't disappear; they just shift shape. Maybe that's the real lesson: software engineering isn't about eliminating uncertainty, but managing it gracefully." by @joaoqalves
https://world.hey.com/joaoqalves/disasters-i-ve-seen-in-a-microservices-world-part-ii-9e6826bf
When I first wrote about microservice disasters, I thought we'd eventually "solve" them, with better tooling, frameworks, and operational maturity. We didn't. We just learned to live with the chaos. Distributed systems will always surprise you: timeouts, retries, and fallacies don't disappear; they just shift shape. Maybe that's the re...
The point of expressing user needs as stories is:
• Stories are human, and so are we. We relate to stories because we are human and stories are how we are human.
• Stories can be simple, and conceal lots of complexity. “I booked a flight on my phone” is a simple story. Allowing a user to book a flight on their phone is complex.
• The complexity is our problem, not the user’s.
• Our job is to make it simple
https://design.scotentblog.co.uk/a-story-is-the-promise-of-a-conversation/
In agile development the whole point of a story is … well, it’s a story. It illustrates an instance. It illuminates an essence. It tells a story. There is a user. An actual person, who needs to get stuff done. A hero. They probably need to get other stuff done too. This, whatever that is, … Continue reading "A story is the promise of a conversation"
The Vasa sank in 1628 because the people who knew it would sink didn't feel able to say so to the people who could have done something about it.
We wrote up the full case study — Vasa Syndrome, authority gradients, and what the sister ship tells us about organisational learning.
RE: https://social.tchncs.de/@simsus/116378604534153269
Hat jemand Erfahrung mit #plane
weird knock on "agile" here, since keeping technical debt low was a by-product of TDD and Refactoring, and worked in harmony with hardware development by savvy teams.
"This architectural discipline is increasingly rare in modern development. Michael Riley, a team lead at Carnegie Mellon’s Software Engineering Institute who previously collaborated with NASA to adapt risk-assessment tools for the Orion mission, noted that while earlier generations worked within strict hardware constraints, modern mission-critical development is different.
“Modern Agile and DevOps approaches prioritize iteration, which can challenge architectural discipline,” Riley explained. “As a result, technical debt accumulates, and maintainability and system resiliency suffer.”"
Gerald M. Weinberg worked on the NASA "Mercury" software using techniques similar to test-driven-development and pair programming: "Agile' software development before the term "software engineering" had been invented.
#agile
https://cacm.acm.org/news/how-nasa-built-artemis-iis-fault-tolerant-computer/
Romeu Moura
nastja
Toms Gedankenblog
Roberto Hortal
Lucas
M. H. Neifer
David O'Brien
tom_geraghty
Third Foundation