Erik's Scrum Journey

To be completely honest: I fear it is. I’m running into more and more managers and CxOs who genuinely dream of replacing their human employees with AI agents and LLMs.

The LLM never gets tired

Borrowing from one of the classic German internet memes (der Gerät never gets tired), the corporate appeal is obvious:

• LLMs and their agents are fast and run 24/7—no biological breaks required.
• They don't sip fancy highland espresso or play foosball in the lounge.
• From a purely capitalist standpoint, it sounds heavenly: value creation happens seamlessly while the boss is out on the golf course.

I consider it entirely possible that my boss will succumb to the temptation.
But I also believe companies will eventually be forced to bring coaches and agile team leaders back.

After the meltdown: Someone has to breathe life back into the wreckage

• Senior developers are already suffering a massive drop in motivation. Nobody wants to onboard the LLM that’s explicitly designed to replace them.
• The first wave of companies is already shelling out $400k+ annual salaries for “Community Managers” just to keep human morale alive.
• Tokens and LLM deployments are getting expensive—and the prices keep climbing.
• Enshittification on speed is devouring its early adopters.

These are all signals and omens indicating that people who actually know how to lead and coach human beings will, sooner or later, be desperately needed again.

And until that happens? I'll just tighten my belt and set sail.

Ganz ehrlich: ich befürchte ja.

Ich begegne immer mehr Managern und CxOs, die tatsächlich davion träumen, ihre menschlichen Angestellten zu ersetzen. Von Agenten und LLMs.

Der LLM wird niemals müde

Frei nach einem der ältesten Internet-Memes (der Gerät wird niemals müde), ist das auch sehr attraktiv:

• LLMs und ihre Agenten sind schnell und arbeiten 24/7, ohne biologische Pausen
• Sie trinken keinen teuren Hochlandespresso und kickern nicht
• Aus kapitalistischer Sicht, wäre das himmlisch: Wertschöpfung während der Boss golft

Ich halte es also für möglich, dass mein Boss der Versuchung erliegt.

Aber: ich glaube auch, dass man Coaches und agile Teamleader zurück holt.

Nach dem GAU: Irgendjemand muss dem Scherbenhaufen wieder Leben einhauchen

• Senior Developer verlieren heute schon massiv an Motivation. Keiner will der LLM, die einen ersetzen soll, auch noch zeigen, wie es geht
• Die ersten Unternehmen verpflichten “Community Manager” für 400k plus Jahresgehälter
• Token und der Einsatz von LLMs wird teurer – immer teurer
• Die Enshittification auf Speed frisst ihre Early Adopter

Das sind alles Signale und Omen, die mich erwarten lassen, dass Menschen, die Menschen führen und coachen können, früher oder später gesucht werden.

Sollte das so kommen, schnalle ich den Gürtel enger und gehe segeln.

#Scrum #LLM #ScrumMaster

Why Scrum helps resolve conflicts before they turn into shitstorms

As Scrum Masters, we are constantly moderating conflicts and deliberately bringing them to the fore, because the Scrum framework is designed to promote conflict resolution. Constantly.

If you take a closer look at Scrum events, you'll see that they regularly address all areas of teamwork where conflicts can arise. – negotiating what and how much will be done/achieved (planning); – negotiating what has been achieved and how to move forward (review). – Negotiating how the team will work together (retrospective).

I think this is smart on many levels, but the best thing about it is that teams learn to deal with small issues as they arise, so that at some point there isn't a huge pile of shit in the room that is becoming increasingly difficult to ignore.

#Scrum #ScrumMaster #Conflicts

I just stumbled across the question on LinkedIn:

“How can you tell if your organization is ready for Scrum adoption?”

– and responded, inspired by Jan Fischbach:

Or: When should I seriously consider Scrum?

If any of these problems occur in your company, you should take the agile route: 1. Our company does not understand customer requirements. 2. Errors are found too late in the development process. (Possibly regularly by the customer) 3. Management interferes in operational work. 4. Too many projects at the same time. 5. Employees are burning out. 6. Poor communication.

(“Fun fact”: this is a list of the most important product management problems from 1996)

My collab on LinkedIn 📑 https://lnkd.in/e_GA2Kzr

#Scrum #Company #Management #Agile

TL;DR: It is acceptable, but a poor idea!

Celina, a Scrum Master and Agile Coach, posted on LinkedIn that she would skip the daily stand-up meeting if the team consistently failed to see its value.

'I would even go so far as to cancel the entire series if the team did not see the value of the daily.'

I wouldn't!

In fact, I consider the daily Scrum event to be one of the most important events in Scrum.

It is the central control tool for the development team during the sprint, enabling them to: – communicate their current status; – discuss the day's work; and – most importantly, align with the sprint goal.

Scrum Masters are servant leaders who also hold 'domain leadership', meaning they can – and, in my opinion, should – mark important events in their Scrum domain as mandatory and enforce them.

If absences become the norm, we Scrum Masters must intervene. At the very latest, we must intervene when the team simply stops doing Scrum, despite all the love for self-organisation.

'A line must be drawn here,' to quote Jean-Luc Picard, one of the greatest servant leaders of all time.

#Daily #Scrum #ScrumMaster

What do you do as a Scrum Master when servant leadership no longer gets you anywhere?

There’s a deeply underestimated aspect of the Scrum Master’s role — that of the Domain Leader. Alongside the Servant Leader, it’s one of Scrum’s essential leadership modes — only this one plays offense.

When Servant Leadership Reaches Its Limits

The Domain Leader ensures that the ethical fabric of discussion within — and around — the Scrum Team stays intact.

If, for example, there are recurring problems with disruptive personalities — or even outright saboteurs — this leadership stance steps in. It may mean temporarily excluding people from events or setting clear behavioral conditions that are defined and agreed upon within the team’s domain.

At times, it can even mean removing someone from the team altogether.

As a practical tool, I often use Team Agreements — documents that define shared expectations and, importantly, include the possibility of consequences when those agreements are violated.

Leadership, after all, isn’t just about serving others. Sometimes it’s about protecting the field so the team can grow.

#Scrum #ScrumMaster #Leadership

I often describe the work of a Scrum Master with the image of a gardener—or a farmer. It fits perfectly, really. As with every true leadership role, it’s less about control and more about cultivation.

The Best Leaders Think Like Farmers 👩‍🌾

(7 practices to help you do the same)

1) Don’t yell at the plants → Lead with understanding, not pressure.

2) Don’t blame the plants → Recognize effort and support growth.

3) Don’t pull the plants out by the roots → Be patient. Let progress unfold in its own rhythm.

4) Match the right plants to the right soil → Pair people thoughtfully with challenges, and embrace diversity.

5) Water and nourish → Invest in development, and praise generously.

6) Pull the weeds → Confront negativity—and remove toxicity before it spreads.

7) Remember: there are seasons—good and bad → Anticipate change, and prepare your people for it.

A heartfelt nod to Eric Partaker for these timeless insights.

Start planting the seeds of success today. Leadership may seem complex, but often it’s the simple, steady practices that make all the difference.

(via LinkedIn)

#Leadership #Scrum #ScrumMaster

The 5 Most Important Tips for Building a Thriving Community

Lately, I’ve been meeting more and more managers and marketing professionals who want to build a community around their brand or area of expertise. However, many community projects fail simply because their creators don’t take enough time to define their purpose. This isn’t strictly about Scrum—though agility and community building do share some important principles.

Before launching a community, take a moment to review these tips. They’re based on 30 years of experience in community building.
(Why repeat the same mistakes that I—and many of my clients—have already made?)

Alongside the essential questions of what goals you want to achieve and how you define success for your community, there are five golden rules shared by all successful online communities:

Die 5 wichtigsten Tipps für einen erfolgreichen Community-Aufbau

Ich treffe in letzter Zeit immer wieder Manager und Marketing-Experten, die sich für Ihr Betätigungsfeld oder Ihre Marke eine Community wünschen. Oft scheitern Community-Projekte jedoch daran, dass sich ihre Betreiber nicht sorgfältig genug überlegen, wofür sie eine Community betreiben wollen. Hat nur am Rande etwas mit Scrum zu tun, auch wenn Agilität in Unternehmen grds. viel mit Communitybuidling zu tun hat ...

Vor dem Gründen einer Community bitte diese Tipps beachten; sie speisen sich aus 30 Jahren Erfahrung im Community Building. (Warum solltet ihr dieselben Fehler machen, wie ich und meine Kunden ;)

Neben der essentiellen Frage, welche Ziele ich verfolge, auf die eine Community einzahlen soll und der Kenngröße, wann für mich als Marke eine Community erfolgreich ist, gibt es fünf Grundregeln, die alle funktionierenden Online Communities ausmachen:

1 Eine Community braucht eine Aufgabe 2 Eine Community braucht Aktivität 3 Eine Community braucht nicht nur Lautsprecher 4 Eine Community muss Trollen den Kampf ansagen 5 Eine Community aufzubauen, ist ein Langstreckenrennen**

– wieso Scrum Konflikte lösen hilft, bevor sie zu Scheißhaufen werden

Als Scrum Master moderieren wir permanent Konflikte, holen sie sogar absichtlich auf den Tisch, denn das Scrum Framework ist so aufgebaut, dass es Konfliktlösung fördert. Permanent.

Wenn man sich die Scrum Events einmal genauer anschaut, dann fokussieren sie sich regelmäßig auf alle Aspekte der Teamarbeit, in denen Konflikte entstehen: – Beim Aushandeln, was und wieviel gemacht/ geschafft wird (Planning) – Beim Aushandeln, was das Erreichte wert ist und wie man weiter voran geht (Review) – Beim Aushandeln des Wie der gemeinsamen Team-Arbeit (Retro).

Ich halte das auf vielen Ebenen für smart; das beste daran aber ist, dass Teams in Scrum lernen, die kleinen Haufen zu bearbeiten, damit nicht irgendwann ein Riesenhaufen im Zimmer liegt, der immer weniger gut zu ignorieren ist ;)