schmonz.com is a Fediverse instance that uses the ActivityPub protocol. In other words, users at this host can communicate with people that use software like Mastodon, Pleroma, Friendica, etc. all around the world.
This server runs the snac software and there is no automatic sign-up process.
Nimm eure letzten drei Retros. Zähl die Maßnahmen, die tatsächlich umgesetzt wurden.
Meistens ist die Antwort eine. Oft keine.
Das ist kein Motivationsproblem. Ihr erkennt die Probleme sauber, ihr könnt sie nur nicht schnell genug in veränderte Arbeit übersetzen. Feedback läuft schnell, die Arbeit langsam. Dieser Zustand hat einen Namen.
https://no-bullshit-agile.de/wfl/?mtm_campaign=mastodon#zwei-geschwindigkeiten-zustände-des-systems
@midzer schrieb, Scrum sei ein brutaler Scam, erfunden von Krawatten.
Ich halte den Satz für falsch. Die Wut dahinter für berechtigt.
Die meisten Devs, die agiles Arbeiten hassen, haben es nie erlebt. Sie kennen das Daily als Statusreport für den Chef und die Schätzung, aus der eine Deadline wird.
Ich hab fünf Jahre Scrum nach Lehrbuch gemacht und es sein lassen. Warum es trotzdem nicht an dir liegt:
https://no-bullshit-agile.de/es-liegt-nicht-an-dir-agiles-arbeiten-devs.html?mtm_campaign=mastodon
I'm speaking at KanDDDinsky 2026 in Berlin this October.
KanDDDinsky is one of the few conferences where the hallway conversations are as good as the ones on stage. That isn't an accident. The whole thing is set up so practitioners learn from each other rather than sit and listen. Working software, real problems, no vendor pitches.
A lot of this year's programme deals with AI in business software: what it actually gives us, and what it costs us. Both parts matter and both get discussed honestly. If you build business software for a living, this is your crowd.
14-15 October, Park Inn at Alexanderplatz. Early-bird tickets are 800 EUR until this Friday, 31 July. After that they go up to 950 EUR.
kandddinsky.com/
His tags: #infosec, #agile, #systemsthinking
Thank you very much for your work as a volunteer and your support in organizing the Open Security conference
What I’ve been reading (and watching) week ending 26 July 2026 https://jchyip.medium.com/what-ive-been-reading-and-watching-week-ending-26-july-2026-9c11a433eabc #politics #AI #SystemsThinking #economics #Lean #SoftwareEngineering
From the Leanpub Blog: Leanpub Book LAUNCH 🚀 Systems Thinking for Agentic AI: A Software Architect’s Guide to Building Reliable LLM and Agent Systems by Ediz Najim
#books #leanpublishing #selfpublishing #AgenticAI #LLMArchitecture #SystemsThinking #RAG #SoftwareArchitecture
NEW! Leanpub Book LAUNCH 🚀 Systems Thinking for Agentic AI: A Software Architect’s Guide to Building Reliable LLM and Agent Systems by Ediz Najim
#books #leanpublishing #selfpublishing #AgenticAI #LLMArchitecture #SystemsThinking #RAG #SoftwareArchitecture
From the Leanpub Blog: The Leanpub Podcast 🎙 Feat. Russ Miles, Author of The Sovereign Engineer: AI Literacy for Software Professionals
https://leanpub.com/blog/the-leanpub-podcast-feat-russ-miles-author-of-the-sovereign-engineer/
#books #leanpublishing #selfpublishing #ArtificialIntelligence #SoftwareEngineering #AILiteracy #LLMs #AgenticAI #SoftwareArchitecture #TDD #EngineeringLeadership #SystemsThinking #Leanpub
NEW! The Leanpub Podcast 🎙 Feat. Russ Miles, Author of The Sovereign Engineer: AI Literacy for Software Professionals
#books #leanpublishing #selfpublishing #ArtificialIntelligence #SoftwareEngineering #AILiteracy #LLMs #AgenticAI #SoftwareArchitecture #TDD #EngineeringLeadership #SystemsThinking #Leanpub
Every time I struggle with something difficult and big, I rediscover the usefulness of #SystemsThinking 💎 and specifically causal-loop diagrams 🔄 and systems archetypes. Such a great tool.
From the Leanpub Blog: Leanpub Book LAUNCH 🚀 Thirst for Reality: How to see the task, find strong solutions, and act without self-deception by Anton Minin Baranovskii
#books #leanpublishing #selfpublishing #TRIZ #problemsolving #systemsthinking #inventivethinking #decisionmaking
NEW! Leanpub Book LAUNCH 🚀 Thirst for Reality: How to see the task, find strong solutions, and act without self-deception by Anton Minin Baranovskii
#books #leanpublishing #selfpublishing #TRIZ #problemsolving #systemsthinking #inventivethinking #decisionmaking
One person’s solution is another person’s problem.
That’s not a bug. It’s how requirements move through organizations.
Every layer solves a problem and creates a new one for the next layer.
#AI is accelerating this process dramatically.
#AgileCheese embraces it. We don’t optimize solutions. We optimize problem propagation.
The fastest way to solve a problem is to make it somebody else’s problem.
That’s why #agile scales so well.
And that’s where the #cheese comes from. 🧀🔥 #SystemsThinking
Is Conway's Law just a hunch? Or is it a law? Conway didn't include a proof in 1968.
However, decades later, research from the automotive/aerospace industries and the software industry tells a different story.
If organisations are misaligned with the product architecture, they will have quality problems and decision latency.
Part 2 of "Beyond the Shades of Conway's Law" is out now:
Validation: The Research and Reality Check
https://thinkinglabs.io/articles/2026/06/20/beyond-shades-of-conways-law-validation.html
RE: https://mastodon.social/@art3starr/116757210750373518
You should read this! And the paper linked from the article! For the content, but also for the meta-level thoughts:
“There is a way in which metaphors create a thinking scaffold that constrains the ways in which we can see. With a metaphor like “debt” that is a noun, we automatically focus on the objects and try to make sense of our world through the metaphor. […] The metaphor creates a nounification of our world as a way of seeing.
What we miss when we see through a lens made of nouns, are the processes, the verbs, what is happening over time, and more precisely, what is going wrong when the system is moving.”
#softwarearchitecture #systemsthinking #softwaredevelopment #softwareengineering
💡 Supporting the Moment: Seeing Software As Activity Instead of Artifact
I’m excited to share a recent blog article I wrote that extends the 𝐓𝐫𝐢𝐩𝐥𝐞 𝐃𝐞𝐛𝐭 𝐌𝐨𝐝𝐞𝐥 by @mastorey re-examining the idea of “debt” from an activity-centric lens, and splitting apart the two embedded triangles as two separate models, one for the relationships and interactions, the other for the three types of knowledge characterized by the three debts.
Organisational Dysfunction of the Day
Doing the wrong thing right
Context: The organisation is focused on improvement. There are efficiency drives, process optimisations, restructuring programmes, and culture initiatives. Each quarter brings a new priority. The internal machinery is constantly being tuned. Meanwhile, the environment is changing. A new technology is reshaping customer expectations. A regulatory shift is coming. A competitor is doing something nobody has quite figured out yet. The people closest to these signals mention them in meetings, raise them in retrospectives, and flag them in Slack. The organisation processes them slowly, if at all. The improvement programmes continue. The internal machinery gets more refined. The gap between the organisation and its environment quietly widens.
OST explains: Open systems theory makes a distinction that most management frameworks miss. The health of a system depends not only on its internal functioning but on the quality of its relationship with its environment. An organisation can be internally coherent, well-managed, and efficiently run while simultaneously drifting away from the environment it depends on. Emery and Trist's turbulent fields insight is relevant here: in a Type IV environment, the environment itself is in motion. An organisation that looks inward while the field moves becomes misaligned, not through any internal failure but simply through the passage of time. DP1 (bureaucracy) accelerates this, concentrating perception and decision-making at the top, seeing the environment through a narrow aperture. DP2 distributes that perceptual capacity across the whole system. Every group at the boundary imports a signal. All hands on deck. The organisation stays coupled to its environment not through a strategy process but through its structure. Peter Drucker distinguished between efficiency and effectiveness: there is nothing so useless as doing efficiently that which should not be done at all. Most improvement programmes are efficiency projects. OST asks the effectiveness question first. You cannot tune your way into relevance. The environment does not wait.
#OpenSystemsTheory #SocioTechnical #OrgDesign #SystemsThinking
Organisational Dysfunction of the Day
The collaboration that isn't
Context: Two teams decide to work together. A shared initiative, a joint project, a problem neither can solve alone. There is enthusiasm on both sides, and a genuine excitement about what they might build together. Everyone has a picture in their head of what that looks like and what they want to get out of it, and everyone assumes the others have the same one. Who owns what, and what success looks like for each of them, is left open. Good intentions and regular syncs will be enough. For a while, they are. Then something goes wrong. Credit lands unevenly. Decisions get made by the louder team. One side feels their contribution has been absorbed rather than shared. Trust erodes quietly. The collaboration continues in name but not in spirit.
OST explains: Two teams are two social systems, each with its own purpose, its own design principle, its own internal logic. The shared purpose is assumed rather than agreed upon. There are two clean ways to work across that boundary. A clear transactional relationship: a contract, explicit deliverables, arm's length. Or deliberately create a new, shared system with a common purpose both sides have actually agreed to, a structure for how the collaboration works and is coordinated, and a design principle governing the joint work. What tends to happen instead is neither. The teams proceed as if goodwill substitutes for structure. The result is laissez-faire more often than not. No clear location of responsibility, no purpose anyone has committed to, no shared system. DP1 (bureaucracy) fills the vacuum, as it always does: the team with more power, more visibility, or a stronger brand quietly starts setting the terms. The other finds itself inside someone else's system without ever agreeing to join it. The same dynamic plays out between companies, just with invoices adding a harder edge to the same underlying confusion. The collaboration was real. The shared system never was.
#OpenSystemsTheory #SocioTechnical #OrgDesign #systemsThinking