Organisational Dysfunction of the Day

The Sunday email

Context: The organisation has a genuine commitment to work-life balance. It is in the values mentioned in onboarding, and comes up regularly in all-hands meetings. Flexible working is encouraged. Mental health is taken seriously. And then the email arrives. Sunday evening, 21:47, from the director. Not urgent. Just something they wanted to get out of their head. No response expected, of course. Nobody says that, though. By Monday morning, three people have replied. Others noticed and said nothing. Over time, the pattern becomes clear. The people who get ahead are the ones who are always available. The policy says one thing. The calendar says another.

OST explains: In the bureaucratic DP1, the person at the top carries personal responsibility for outcomes they do not fully control. The higher the position, the larger the gap between accountability and agency. That gap produces anxiety, and anxiety produces overwork. Not because leaders are workaholics by nature, but because the structure places an unreasonable individual burden at every level of the hierarchy. The Sunday email is not a character flaw. It is a structural symptom. The deeper problem is that modelled behaviour always outcompetes stated values. People read the environment, not the handbook. What the boss does on Sunday communicates more about what is expected than any well-being policy. In DP2, responsibility is distributed across the group. No single person carries the weight of outcomes alone, so the chronic anxiety that drives performative overwork largely disappears. Work-life balance stops being a value that needs defending and becomes a natural consequence of a structure that does not place impossible individual burdens on anyone. The Sunday email stops because nobody needs to send it.

#OpenSystemsTheory #SocioTechnical #OrgDesign #leadership

#Agile #Innovation #MentalModels #FirstPrinciples #ProductDevelopment #AgileHardware #Strategy #LeanStartup #SystemsThinking #Leadership (3/3)

Next time your perfect framework feels like a gag, ask: We traded a thinking tool for a muzzle?

#PsychologicalSafety #TeamDynamics #Leadership #MentalModels #Agile #ThinkingTools #TeamCulture #DecisionMaking #Management #Innovation #OWL (5/5)

The moment you turn toward learning instead of sitting in the sting, you start converting that raw disappointment into something you can actually use.

That's the shift. The obstacle stays exactly where it is, but your relationship to it doesn't have to.

Go forward.

#BusinessStrategy #Leadership #Entrepreneurship #Agile #ContinuousImprovement #LeanStartup #ProfessionalGrowth #BusinessTips #StartupLife #Resilience (3/3)

Measuring the wrong thing

Process improvement requires measurements. How do you know what to improve if you can’t see where things aren’t working, and how do you know you’ve made the right change without seeing those numbers going in the right direction?

But measuring doesn’t mean you’re measuring the right thing, and measuring the wrong thing can lead to the wrong outcomes, and can be very harmful (see Liz Keogh’s talk on perverse incentives )

The key to the success of any metric is that it is owned by the team so they have complete control over the changes needed to affect it, so they feel ownership, and that improving the metric has a useful business outcome.

Metrics that I’ve found useful in the past include:

Number of bugs introduced by a release.

This is a tricky one to work with because it can easily be a perverse incentive, and the feedback cycle can be slow, especially with the usual 6-12 month release cadence. However, on one waterfall project I took over there was a strong negative perception of the quality of the code, and big count was a useful proxy as the customer had access to JIRA so the big list was already visible. Reducing this number was a combined effort where testers and developers had to approve requirements, developers and testers invested in automated testing at all levels, and testers joined the developer daily stand-up in order to catch bugs before they were released “have you checked that page in Welsh?“, “We found problems on that page last time because IE was too slow“.

Number of releases per month.

On an agile project we noticed that releases were getting held up because testing was slow and produced a lot of rework, which were then tested against more features that had been pulled from the backlog, increasing testing time. Each release also took half a day, so we had to schedule them carefully.

So we set a goal of focusing on releases for a month and measuring how many we did. There were other measures within that, such as monitoring work in progress on the testers, time taken to do a release, and cycle time from start of development to live release, but they all drove the big number, visible to the whole company, of more quality releases.

Questions answered per day.

This can be a very useful metric for research projects, especially when following a fail fast approach, when you want to prove something can’t be done before you invest in doing it. In order to do that, you need lots of questions with quick answers, to accelerate learning. Any answer, positive or negative, is progress. It means we have learned something.

“I cheerily assured him that we had learned something.
For we had learned for a certainty that the thing couldn’t be done
that way, and that we would have to try some other way.” – Thomas Edison

Age of Pull Requests

Successful agile projects rely on peer review, either via pairing, or a formal review process such as git PRs (and I won’t discuss that in this post). However, when we started working with these on one project, we discovered that we were building up a large debt of Work In Progress because the team wasn’t incentivised to review each other’s code, so one of the developers set up a nag bot for any PR older than 4 days. It lasted 2 weeks before it was no longer needed.

What about you?

What metrics have you used to incentivise the team? What problem were you trying to solve, and did the metric work?

Your team has 4 certified Scrum Masters, a SAFe implementation, and a Jira board with 200 columns.

But nobody dares to say "I made a mistake" in the Daily.

Allen Holub nailed it: "Without psychological safety, respect, and trust — none of what follows is possible."

No framework will save a team that's afraid to speak up. Fix the culture first. The process is secondary.

#agile #leadership

Alt...

NO FRAMEWORK SAVES A TEAM THAT'S AFRAID TO SPEAK UP.

When team members understand that their success is tied to the team’s performance, collaboration improves, and ego-driven disruptions diminish.

Read more 👉 https://lttr.ai/ArazN

#ExtremeProgramming #Leadership #BusinessOwnership

Becoming a technical lead: Trust your team

When I first became a technical lead, one of my biggest challenges was giving up control. It wasn’t a matter of not trusting my team technically but I didn’t want to overload them, so I took on all the planning, all the customer interaction, and all the other jobs that I felt had distracted me from the job of writing code.

I was wrong.

I needed to let my team in, because they had ideas that I didn’t, they had capacity whereas I was a bottleneck. I was holding up my team.

But I needed to be sure that coding standards were followed and quality was maintained. You know who else cares about that? My team. I made it their responsibility to ensure that the code met standards, and pushed out code reviews. I put internal documents at the same level as code. Anyone can edit, but everyone can review, or veto.

I asked for honest feedback in retrospectives, and implemented changes, so they could trust that I was looking out for them, and I set them goals to improve, alongside the feature work : “can we release twice a week?” (challenge – automate the pain points); “can we halve the bugs found in testing” (challenge – better unit tests)

And the more I trusted them, with support, and understanding their limits, the better they performed. I’ve also worked with managers who don’t trust their teams. Those teams don’t work so well.

If you don’t trust your team, they’re not your team. They’re just people who work beside you. What are you doing today to foster trust?

Your 5-Minute Win: Right now, grab a pen. Write one sentence about something you built today. Not what went wrong. What you made. Even if it's small. A line of code. A clean desk. A kind word. Write it down. Keep it where you see it.

Go Forward: You chose to create instead of complain. That's the shift. #BusinessStrategy #Leadership #Entrepreneurship #ContinuousImprovement #Agile #LeanStartup #ProfessionalGrowth #Productivity #StartupLife #TechBusiness (2/2)

A CPO told me: "I don't care if your standup takes 10 or 20 minutes. I care if you learn from what went wrong."
Meanwhile, middle management is obsessing over story points, sprint velocity, and whether the Daily started on time.

The C-Level wants outcomes. Your process police wants compliance.
Stop reporting rituals. Start reporting what you learned and what you'll do differently.

#agile #leadership

Alt...

THE C-LEVEL WANTS OUTCOMES. YOUR PROCESS POLICE WANTS COMPLIANCE.

Honored that @UCSanDiego features my "Phases of Team Development" on teamwork tradecraft in course curriculum.

See https://scottgraffius.com/blog/files/ucsd-2024.html for details

The 2026 edition of my work is here: https://doi.org/10.13140/RG.2.2.18184.89601

#UCSD #Agile #ProjectManagement #Teamwork #Leadership #UCSanDiego #PhasesOfTeamDevelopment #TeamworkTradecraft

Technical leadership at scale requires a different orientation: creating the conditions for others to do great work, rather than doing the great work yourself.

Read more 👉 https://lttr.ai/ArKX1

#SelfLeadership #Leadership #TechnicalLeadership

You don't need to fix everything today. You just need to stop fighting ghosts. #BusinessStrategy #Leadership #Entrepreneurship #Agile #ContinuousImprovement #LeanStartup #ProfessionalGrowth #BusinessTips #StartupLife #Productivity (4/4)

https://www.europesays.com/britain/43664/ We’re becoming a simple and more agile bank | HSBC news #agile #ai #Bloomberg #CEO #customers #elhedery #francine #FrancineLacqua #georges #GeorgesElhedery #GroupCeo #HSBC #HsbcNews #Interview #lacqua #Leader #Leadership #Podcast #Tariffs #Trade #transformation

Alt...

We’re becoming a simple and more agile bank | HSBC news

New post: Scrum is Dead

“We tried Scrum.”

A few meetings.
Some tickets.
New role names.

Everything looked familiar.
Nothing actually changed.

#Agile #Scrum #RealityCheck #SoftwareDevelopment #Leadership

https://agile-is-a-state-of-mind.com/scrum-is-dead/

Micro Habits for better Teamwork: Psychological Hacks with Great Impact by Dr. Denniz Dönmez & Dr. Rafael Huber is the featured book 📖 on Leanpub!

Link: https://leanpub.com/microhabits

#leadership #teamwork #organizational_psychology

Just a friendly reminder on my blog this week that Terror is not a helpful strategy for conducting business.

https://www.edyouragilecoach.com/why-copying-corporate-terror-fails/

🏴‍☠️ 🐻

#leadership #GhostGang #business #agile #blogging

@albertocblanco

Concluding Thought:
Resistance fades when people see real results, so start small, learn fast, and let the work speak for itself.

#Agile #XP #StakeholderManagement #Education #B2B #ProcessChange #Leadership #FeedbackLoops #SME #Innovation (12/12)

Lean Agile Predictability Bundle by Daniel S. Vacanti is the featured bundle of ebooks 📚 on Leanpub!

Link: https://leanpub.com/b/leanagilepredictabilitybundle

#business_and_management #agile #leadership_agile #agile_business_leadership #lean #leadership #project_management #product_management

Maybe the best thing your retrospective can produce isn't an action item. Maybe it's the moment someone feels safe enough to tell the truth. If your mental model can't hold that, it's not a thinking tool. It's a avoidance strategy with a fancy name.

#Agile #Retrospective #MentalModels #TeamCulture #Leadership #AgileCoaching #PsychologicalSafety #Retail #ContinuousImprovement #EmotionalIntelligence (6/6)

Join us May 26, 18:00 CET for a Lunch & Learn on the invisible barrier that slows Data & AI teams: **the Silo Mindset**. Two similar projects, two wildly different outcomes—same tech, same talent, different approach. Case study + Q&A. Register: https://luma.com/ft2xweur #DataAI #Collaboration #Leadership #Agile #Teams
https://www.datentreiber.com/blog/reminder-lunch-learn-breaking-silo-mindset/

The Constant Gardener : Knowing your team

One of the most interesting challenges in becoming a lead is understanding your team, and balancing project tasks between them. Whilst experience, both technical and domain, is a valuable indicator of how to assign tasks, there’s a few other things to take into account.

Having worked with a few people over the years, I can see 2 main types of developers. Managers may be asking which of the 16 Myers-Briggs personality types these represent, but I’m trying to give a persona sketch rather than a detailed breakdown.

Innovators are the ones I see most often – developers who want to work on the hot new thing, keep seeking out new ideas, and often like to throw things out and start again. They can pick up new projects quickly, by focussing on certain areas but are likely to get bored if they stay on one project for too long and may sometimes miss the bigger picture. That’s great for learning, and pushing forward the boundaries, but may not provide the stability that some projects need, and may need closer code reviews to ensure they maintain the house style for the project. If you’ve ever needed a white knight on your project, they’ll probably be an innovator.

Gardeners will take longer to get up to speed with a new project, because they prefer to dig in and find out how everything works, and build a detailed knowledge of the system before making changes. They will tend to evolve systems over extended periods. If you get someone like that on your project, you’ll want to keep them for several months, as their value to the project increases over time. Long lived projects with several maintenance releases benefit most from this type of individual. You may well find that they know the business domain better than the customer.

I think everyone I have worked with has qualities of both, but there are individuals who are clearly more innovators, and others that are clearly more gardeners. A good project should have both, with innovators pushing ideas and bringing new technologies to the tables, and the gardeners bringing the domain knowledge to make sure the right changes are made for the long-term health of the project. As a lead, your job should be to understand the way your team things, so that you can take the right ideas on board at the right time, and bring your team along with you. And, most importantly, know yourself. The most important thing the others on the team bring is knowledge of things you don’t know, or at least questions that force you to think about them. Embrace it. Inspire your innovators and nurture your gardeners.

Your 5-Minute Win: Right now, in this public space, pull out your phone or a notebook. Set a timer for five minutes. Write one raw, unpolished paragraph about where you want to be in one year. Don't edit. Don't judge it. Just let it flow. This isn't a plan. It's a creative act. That's the point.

Go Forward: You just did something. That counts. #BusinessStrategy #Innovation #Leadership #Agile #Scrum #LeanStartup #ProfessionalGrowth #BusinessTips #StartupLife #Entrepreneurship (3/3)

Amazing CTO by Stephan Schmidt is on sale on Leanpub! Its suggested price is $30.00; get it for $22.50 with this coupon: https://leanpub.com/amazingcto/c/LeanPublishingDaily20260514 #executive_coaching #software_engineering #engineering_management #startups #leadership

You can't mandate a mindset. You can only model it.

Be that one person who just does things differently: ships smaller, asks better questions, admits mistakes first. That's the flywheel. Not a workshop. Not a framework rollout.

Change spreads through behavior, not through slides.

#agile #leadership

Alt...

THE FLYWHEEL IS BEHAVIOR, NOT SLIDES

From the Leanpub Blog: The Leanpub Podcast 🎙 Feat. Org Topologies, Author of 10X ORG – Powered by Org Topologies: A Manager's Guide to Elevating Business Performance with People and AI

https://leanpub.com/blog/the-leanpub-podcast-feat-alexey-krivitsky-co-author-of-10x-org-a-managers-guide-to-elevating-business-performance-with-people-and-ai

#books #leanpublishing #selfpublishing #FutureOfWork #OrganizationalDesign #BusinessTransformation #Management #Leadership #TeamTopologies #LeanpubPodcast #DigitalTransformation

NEW! The Leanpub Podcast 🎙 Feat. Alexey Krivitsky, co-author of 10X ORG: A Manager's Guide to Elevating Business Performance with People and AI

https://youtu.be/HlOK0JZxBAM

#books #leanpublishing #selfpublishing #FutureOfWork #OrganizationalDesign #BusinessTransformation #Management #Leadership #TeamTopologies #LeanpubPodcast #DigitalTransformation

Hiring an Agile Coach won't make your company agile. Neither will a mandate from the CEO. It can help though if you also remember the following.

Agility spreads through a small group of people who actually understand it and who are given the space to prove it works.

No role, no title, no framework will do that job for you.

#agile #leadership

Alt...

Agile Coach won't save you

Every company claims to have a "culture of learning from mistakes."

Then something goes wrong and the first question is: "Who did this?"

You don't have a failure culture. You have a blame culture with better marketing.

#agile #leadership

Alt...

FAILURE CULTURE WITH BETTER MARKETING

Micro Habits for better Teamwork: Psychological Hacks with Great Impact by Dr. Denniz Dönmez & Dr. Rafael Huber is a new release on Leanpub!

Link: https://leanpub.com/microhabits

#books #ebooks #newreleases #leanpublishing #selfpublishing #leadership #teamwork #organizational_psychology

The leaders I've watched plateau aren't the ones who lacked talent. They're the ones who kept waiting for someone else to guide their growth. The ones who keep moving treat their development like a line item they control. You don't need your organization's permission to read, reflect, or ask hard questions. That part is yours.

https://www.congruentchange.com/first-lead-yourself/

#Leadership #ContinuousLearning #SelfLeadership #ProfessionalDevelopment

Stop trying to reach consensus in your team. You'll get silence, dominant voices, or fake agreement.

Try consent instead: "Does anyone have a serious objection?" No objection = we move forward. You can always revisit.

Faster decisions. More voices heard. Less theater.

#agile #leadership

Alt...

CONSENSUS IS A TRAP

Organisational Dysfunction of the Day

Involvement theatre

Context: Some architects, project leads, or managers want to do things properly. They genuinely believe in collaboration and know the teams have valuable knowledge. So they organise workshops, like EventStorming sessions, design sprints, or other types of collaborative design workshops. People are invited, post-its go up, discussions happen, and there is real energy in the room. Then the session ends, the outputs are photographed, the facilitator disappears with the material, and a few weeks later, a design document or architecture proposal lands in the team's inbox. It looks nothing like what people thought they were building together. When questions are raised, the answer is that the workshop inputs were "taken into account." The teams learn quickly that the workshops are not really about designing together. They are about being consulted. Next time, fewer people will engage seriously. The post-its get sparser. The energy in the room is noticeably lower, even hostile.

OST explains: This is one of the most common misapplications of participative techniques in DP1 organisations: design authority is retained above, while the appearance of participation is layered on top to legitimise decisions already made or soon to be made elsewhere. OST explains why it fails on two levels. First, Bion's basic assumptions: the moment a person with authority enters the room, even a well-meaning independent facilitator, people shift into dependency or fight/flight, so the workshop never produces genuine collaborative design, regardless of how it is facilitated. Second, Fred and Merrelyn Emery were explicit that it is only when people design their own work that they develop the motivation, responsibility, and commitment to implement it effectively. A design imposed on a group, even one consulted, will never have the ownership that a design created by the group has. Involvement theatre does not just fail to produce good design; it actively corrodes trust in the collaborative process, making genuine participation harder to achieve each time. As Kurt Lewin warned, people cannot be trained for democracy by autocratic means.

#OpenSystemsTheory #SocioTechnical #OrgDesign #leadership

Silence in a meeting is not agreement. It's fear wearing a mask.

If your team "agrees" in 5 minutes, nobody actually shared what they think. You didn't make a decision but one person did, and the rest let it happen.

#agile #leadership

Alt...

SILENCE IS NOT AGREEMENT

You ran an "agile kickoff workshop." The client nodded along. Three months later: "So when will everything be done?"

That's not a client problem. That's yours. One workshop doesn't create understanding. Continuous alignment does. Stop blaming the customer for not "getting agile."

#agile #projectmanagement #leadership #teamwork

"We're agile, we don't need a plan."

Wrong. Agile means planning *more*, not less. Every sprint, every standup, every retro - that's all planning.

What you actually mean: "I don't want to be held accountable for a plan." That's not agile. That's chaos.

#agile #projectmanagement #scrum #kanban #leadership

#scrum #scrumteam #dev #developer #qa #scrummaster #productowner #leadership #management #executives #aicoding #AI #aicodingtools #aicoding #Meme #memes #Humor #humour

Alt...

Illustration of a gray haired man in a suit (labeled executives) holding a bow and arrow (arrow labeled AI) pointing at a man (labeled dev team) who is grabbing the bow

Organisational Dysfunction of the Day

Professional leadership

Context: The organisation has invested heavily in leadership development. There are programmes, frameworks, coaching, 360-degree feedback, and a clear leadership model on the intranet. The managers are well-intentioned, many of them genuinely skilled, and they take their responsibility seriously. However, the teams below them are still not performing as hoped. Engagement is middling, decisions are slow, and the best people keep leaving. Some even because of their manager. Leadership quality is clearly not the bottleneck, so what is? In many industries, supervisors are expected to know the craft they oversee. Not so in most IT organisations, where the manager's job is people and process, not technology. That gap has been growing.

OST explains: The problem is not the leaders; it is the existence of the role itself. DP1 as bureaucracy requires leaders because control and coordination are handled by a layer above the real productive work, be it managers in the line, project managers, product managers, or even architects. You therefore need good ones, and training them makes sense within that logic. But no amount of leadership quality fixes the structural problem that the people doing the work are not in control of it. In DP2, the need for professional leadership largely disappears because coordination and control are handled by the group itself. The resources currently spent on developing leaders should instead be invested in developing the team's self-managing capacity. That is not a small shift; it is a fundamentally different theory of how organisations work. A DNA swap.

#OpenSystemsTheory #SocioTechnical #OrgDesign #leadership

"Doing Scrum" doesn't make you agile. Neither does Jira, a daily standup, or calling someone "Product Owner."

Agility is a mindset, not a toolbox. If you don't understand why you're doing it, the framework won't save you.

Most teams fail at agile not because they picked the wrong method but because they never understood the foundation.

#agile #scrum #kanban #leadership #agilecoaching

Your annual performance review is useless. Your manager barely knows what you did last month — let alone last year.

Try this instead: let people choose 3 peers to give them feedback every 6 months. No report to management. No grades. Just honest growth conversations in a safe space.

#feedback #agile #leadership #teamwork #continuousimprovement

The biggest mistake leaders make in 1:1s? Talking.

A one-on-one is not your meeting. It's theirs. Your job is to shut up and listen. No status updates. No "feedback." Just one question: "What are we not talking about that we should be?"

Then wait. Even if it gets uncomfortable.

#leadership #agile #teamwork #feedback #coaching

This week, I am talking about a 2800-year-old story and how it explains the phenomenon of storming.

https://www.edyouragilecoach.com/the-leader-at-the-mast/

🏴‍☠️ 🐻

#leadership #agile #GhostGang #business

The most underrated leadership skill isn't strategy, vision, or decisiveness.

It's shutting up and listening.

In your next 1:1, try this: say less, ask "What else?" and wait. The real information comes after the first pause, not before it.

#leadership #agile #teamwork #feedback #coaching

Bonuses don't motivate people. They destroy motivation.

What actually drives your team: autonomy over their work, mastery in their craft, connection to each other, and purpose in what they build.

Every time you dangle a carrot or threaten a stick, you're replacing intrinsic drive with dependency. Stop it.

#agile #leadership #motivation #teamwork #selforganization

#LINKSDERWOCHE | 19/2025: Produktivität, Agile, Management und LeadershipLINKSDERWOCHE |

PRODUKTIVITÄT

Schlechte Gewohnheiten | So wird es einfach sie wieder los zu werden

Schlechte Gewohnheiten erwirbt man oft unbewusst. Sie schleichen sich ein. Allmählich und hinterhältig. Wie wird man sie wieder los? Wenn man Dan Rockwells Ideen hierzu folgt, wird es etwas einfacher, aber es ist dennoch schwer genug. Ein Grund, das Handtuch zu werfen? Niemals.

https://leadershipfreak.blog/2026/05/08/break-the-habit-of-bad-habits/

PROJEKTMANAGEMENT

Dos und Don’ts | Damit das Projekt gelingt …

Wer es kurz und knackig mag: Ich bin normalerweise kein Freund von KI-Zusammenfassungen, mache hier aber eine Ausnahme, weil sie wirklich gut ist. Hier sind die Dos und Don’ts im Projektmanagement von Bernhard Schloss als grafische Zusammenfassung. Man sollte sie sich ausdrucken und in jeden Projektraum hängen 😉

https://www.bernhardschloss.de/blog/dos-und-donts-im-projektmanagement/

Projektstatusbericht | Wie man ihn besser macht

Ich persönlich würde, wann immer es möglich ist, direkt auf Obeya umsteigen. In einem gut gestalteten Obeya-Raum habe ich alle Schlüsselinformationen auf einen Blick und die Notwendigkeit eines Statusberichts, wie er im Projektmanagement üblich ist, entfällt. Nur leider liegt das nicht immer in meiner Hand und es wird wohl auch weiterhin Projekte geben, in denen jemand einen Statusbericht verlangt. Wenn er gut ist und Nutzen stiftet, ist das durchaus legitim. Leider ist das so eine Sache mit der Qualität. Aus verschiedenen, durchaus nachvollziehbaren Gründen, die auch im Artikel von Andrea Windolph ihren Niederschlag gefunden haben. Spannender sind allerdings die Hinweise, wie man es besser macht. Das lässt sich übrigens auch auf andere Kontexte gut übertragen. Und ja, Kommunikation ist nicht einfach.

https://projekte-leicht-gemacht.de/blog/projektmanagement/klassisch/projektsteuerung/projektstatus-fehler/

LEAN

Versteckte Kosten | Wenn man das System igorniert …

Mark Graban trifft damit einen Nerv. Viele begehen einen zentralen Fehler, wenn sie versuchen, Kosten zu optimieren. Sie betrachten nicht das Gesamtsystem, sondern nur Teilbereiche. Die Personalkosten stehen oft in der Kritik, weil sie als zu hoch angesehen werden. Was ich an Toyota Production System (TPS) schätze, ist, dass dort eben der ganzheitliche Blick vorherrscht. Dies haben viele bei ihrer Lean-Adaption leider übersehen. Das ist ein Grund, weshalb ich lange mit „Lean” gehadert habe (ich kannte zu dem Zeitpunkt nur die angelsächsische Lean-Variante und noch nicht Monozukuri). „Lokale Optimierung” verschiebt die Folgekosten lediglich und oft genug steigen die „Gesamtkosten” (besonders, wenn man Kunden, Lieferanten usw. mit einbezieht) dadurch deutlich. Als Kunde großer Telekommunikations-, Versicherungs- und Energiekonzerne kann ich darüber mittlerweile mehr als nur ein Lied singen. Daher freut es mich, dass Mark Graban das Thema aufgreift und verdeutlicht, dass man etwas mehr Hirnschmalz investieren muss, wenn man sinnvoll an das Thema „Kosten sparen” herangehen will. Auskömmlichkeit zu verbessern ist halt etwas anderes …

https://www.leanblog.org/2026/05/working-charge-nurse-hidden-cost/

Das System wirkt | Niemand kann einfach aus dem System ausbrechen

Wie oft musste ich schon hören, dass die Menschen schlicht und ergreifend nicht das richtige „Mindset“ haben und es deshalb nicht klappt! Bei näherer Betrachtung lag es jedoch nicht unbedingt an den Menschen und ihrer Haltung, sondern in weiten Teilen am System selbst und seiner Mechanik. Diese lässt sich nicht einfach dadurch ändern, dass man jetzt regelmäßige Retrospektiven durchführt. Götz Müller greift dieses Thema im Zusammenhang mit Lean und Verbesserung auf und verdeutlicht: Oft liegt es nicht an den Menschen, sondern am System.

https://www.geemco.de/artikel/warum-menschen-auf-systeme-reagieren-und-nicht-auf-leitbilder/

Pimär Metrik | Wie Metriken helfen Wirksamkeit von Verbesserungen zu prüfen

In John Knotts Blogartikel geht es um Verbesserung und Metriken. Interessanterweise beobachten wir häufig, was nicht gut läuft. Darauf basieren Annahmen und Hypothesen über die Ursachen und die mögliche Wirkung. Allerdings machen sich nur wenige Gedanken darüber, wie sie diese Vermutungen faktenbasiert, also empirisch, belegen können. Dabei geht es nicht darum, Zahlen zu erzeugen, sondern in erster Linie darum, transparent zu machen: Sind unsere Annahmen korrekt und zeigen unsere Maßnahmen daher Wirkung?

https://blog.gembaacademy.com/2026/05/08/start-every-process-improvement-effort-with-the-primary-metric/

AGILE

Zu viel Planung, zu wenig Fortschritt | Wenn es an der Basis klemmt

Obwohl viele von Agilität reden, kommt mir das, was Merlin Mechler unter dem Stichwort „zu viel Planung, zu wenig Fortschritt” zusammenfasst, doch sehr bekannt vor. Besonders gerne – sorry, ich kann es mir nicht verkneifen – fallen mir dazu Umfelder ein, in denen man sich skalierte Rahmenwerke auf die Fahne schreibt. Die Grundlagenarbeit passt noch nicht. Es fehlt der Fokus auf Wirksamkeit und kurze, echte Feedbackschleifen, die aufzeigen, wo die Probleme liegen. Wenn man das Ganze mit passenden Metriken ergänzt, die auch tatsächlich sinnvolle Veränderungen sichtbar machen und das „Lernen” als Organisation unterstützen, wird es definitiv besser. Aber Achtung: Auch mit Kennzahlen kann man viel Schindluder treiben, und „Controlling” ist kein Selbstzweck. Die Metriken dienen dazu, das Lernen als Organisation zu stärken. Sie sollten daher auch regelmäßig auf den Prüfstand gestellt werden.

https://t2informatik.de/blog/zu-viel-planung-zu-wenig-fortschritt/

Stakeholdermap | Immer noch ein Top-Werkzeug fürs Stakeholdermanagement

Die gute alte Stakeholder-Map ist nach wie vor ein hervorragendes Werkzeug, um den Überblick über die verschiedenen Anspruchsgruppen und ihre Bedürfnisse zu behalten. Leider erlebe ich in der Praxis sehr häufig, dass sie zwar begonnen, aber selten dauerhaft gepflegt wird. Das liegt vermutlich daran, dass sie nicht Teil der „alltäglichen” Arbeit ist und dann gerne mal vergessen wird. Abhilfe schafft hier ein guter Obeya-Raum, in den sie integriert ist, weil sie dann präsent bleibt und bei Bedarf schnell fortgeschrieben werden kann, wenn neue Erkenntnisse hinzukommen. Nur mal so am Rande. Wer jetzt nicht weiß, was ich meine, für den bietet der kleine, aber feine Artikel von Fadi Stephan eine schnelle Zusammenfassung des Werkzeugs Stakeholder-Map.

https://www.kaizenko.com/how-to-manage-stakeholders-using-the-power-interest-matrix/

Planung ist ein „gemeinsames Problem“ | Auch in der Planung gilt: echte Zusammenarbeit ist Trumpf

Ein Klassiker, den ich auch immer wieder erleben durfte: Product Owner:innen und Teams werden bei der Planung gar nicht groß gefragt. Das Management entscheidet irgendwo, wann was fertig zu sein hat, und dann gibt es ein böses Erwachen. Und das, obwohl es mehrfach Hinweise aus dem Team und vom Product Owner gab. Ein solches Projekt durfte ich vor geraumer Zeit als Scrum Master begleiten. Erst als es richtig geknarzt hat und wir kräftig investiert haben, lief es ähnlich wie von Mike Cohn als idealer Zustand beschrieben. Überraschung: Die Planung war nicht nur realistisch, sondern die dabei entstandene Transparenz im Dialog hat auch beim Management zu einem besseren Verständnis der Herausforderungen geführt, die es zu lösen galt. Leider endete kurz darauf meine Zeit in diesem Projekt – wie das bei Externen nun mal so ist. Soweit ich jedoch gehört habe, läuft es jetzt deutlich besser und reibungsfreier. Es lohnt sich wirklich, zusammenzuarbeiten, auch über „Hierarchieebenen” hinweg. Die Fachleute auf der operativen Ebene können dem Management nämlich realistischer zurückspiegeln, was machbar ist und was nicht. Ab und an den Ort des Geschehens zu besuchen, ist durchaus etwas, das man tun sollte. 😉

https://www.mountaingoatsoftware.com/blog/when-planning-should-become-a-shared-problem

MANAGEMENT UND LEADERSHIP

Komplexität | Die 4 Hebel für den Umgang mit Komplexität

In den letzten „Links der Woche” hatte ich bereits auf Daniel Dubbel verwiesen, der zu Recht erklärt hat, dass Komplexität kein neues Phänomen ist. Unabhängig vom Rahmenwerk gibt es einige Dinge, die dabei helfen, die Zusammenarbeit in komplexen Situationen sinnvoll zu gestalten: Vernetzungsgrad gestalten, Abhängigkeiten klären, Transparenz herstellen, Geschwindigkeit takten, Informationsdichte filtern. Dabei ist Visualisierung, wie sich der geneigte Leser sicherlich denken kann, extrem hilfreich. Daniel Dubbel führt das Ganze noch ausführlicher aus, sodass man einen guten Rahmen erhält. Das Ganze gilt es dann auszugestalten. Zu einem Zusammenarbeitssystem, bei dem ein geeignetes Rahmenwerk Hilfe bieten kann – aber nicht muss.

https://www.inspectandadapt.de/komplexer-mythos-hier-sind-4-hebel/

Amazing CTO by Stephan Schmidt is on sale on Leanpub! Its suggested price is $30.00; get it for $22.50 with this coupon: https://leanpub.com/amazingcto/c/LeanPublishingDaily20260506 #executive_coaching #software_engineering #engineering_management #startups #leadership

The Future of Healthcare by Dr. Bertalan Mesko is the featured bundle of ebooks 📚 on Leanpub!

Link: https://leanpub.com/b/thefutureofhealthcare

#medicine #leadership #digital_transformation

The answers I am getting tell me everything about whether the foundation was ever built. Most of the time, it was not.

#ProfitWithoutOppression #KimCrayton #LLMs #OrganizationalStrategy #Leadership

Leanpub Book LAUNCH 🚀 How to Run an eSports (Video Game) Tournament by Marcel Torres!

Watch here: https://youtu.be/WQDLEiB9gKk

#books #leanpublishing #selfpublishing #booklaunch #esports #tournament #leadership #management #videogames

In a PI planning meeting working on story dependencies and I just want to shout into the void

🏴‍☠️🐻

#Agile #leadership #wednesday