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.
Wieder mal ein interessanter Artikel von Rudolf Gusy.
#agile #kanban #scrum
https://agilereflection.org/while-wip-roi-0/
A podcast guest told me this once: I've seen teams proudly refuse to "work agile" because every agile transformation they'd been through just added bureaucracy.
Instead they just talked directly, shipped fast, and focused on results.
That IS agile. They just didn't call it that. That's fine!
Продолжаем полировать RetroPoint — без громкого релиза, но с заметной разницей в ежедневной работе.
Что улучшили:
📱 Мобильный интерфейс — профиль (все разделы видны сразу), команды, кабинет 1‑2‑1, OKR и Planning Poker: формы влезают в экран, кнопки не «плывут».
🤝 1‑2‑1 — к приглашению на встречу можно добавить заметки (ссылка на созвон, контекст): они уйдут в письмо, календарь и повестку.
🔐 Вход — меньше ложных «вылетов» из аккаунта при переходах между разделами и после подтверждения email.
Мелочи, которые экономят нервы команде на удалёнке.
Подробности — в новости на сайте: https://retropoint.ru/news/mobile-ui-and-stable-login-may-2026
#RetroPoint #тимлид #1to1 #управлениекомандой #retrospective #ретроспектива #agile #scrum #kanban #teamlead #it #itleads #teamleadthings #команда #retroonline #просторетро #oneonone #one2one #pokerplanning
First Principles in Scrum: OpenClaw Scrum and Scrum@Scale: Create Trust at Machine Speed by Jeff Sutherland is the featured book 📖 on Leanpub!
Link: https://leanpub.com/firstprinciplesinscrumscrumandscrumscaleforopenclaw
#computer_programming #business_and_management #scrum #leadership_agile #agile_enterprise #enterprise_management #scrum_project_management #product_management #teamwork
If you work at an agency and call yourself "Product Owner" — you're not one. You're a proxy.
The real PO is the client. They own the vision, the market, the risk. You sort tickets.
Scrum defined this role for product companies, not for agencies. Stop pretending it fits. I made that error myself and it felt wrong the whole time.
RE: https://norden.social/@AgilePreacher/116572274676273996
Das klingt vielversprechend.
Hamburger Agile Bubble, wo seid ihr?
#Hamburg #Agile #Agilität #ProductOwner #Scrum #ScrumOfScrum #AgileJob
"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.
"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.
PRODUKTIVITÄT
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
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/
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.
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/
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/
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?
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/
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/
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
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/
#Agile #Fortschritt #Gewohnheiten #Komplexität #Leadership #Lean #Management #Metriken #Planung #Produktivität #Projektmanagement #Projektstatus #Scrum #Selbstmanagement #Selbstorganisation #Stakeholder #Systemdenken #Verbesserungen #VersteckteKosten
„Scrum is a team collaboration framework. Kanban is a method to manage work."
Schon die Wikipedia-Definitionen zeigen den fundamentalen Unterschied. Scrum optimiert auf Menschen. Kanban optimiert auf Arbeit.
In Unternehmenssystemen, in denen Arbeit heterogen ist – Support neben Projekten, Kleinstaufgaben neben Epics – bricht das Rückgrat von Scrum (der stabile Sprint) regelmäßig. Flow-Management ist dort die ehrlichere Wahl.
Wir managen die Arbeit, nicht die Menschen.
#agile #scrum #kanban
🎉 В RetroPoint появился модуль 1‑2‑1
От ретро — к управлению командой.
У тимлида в профиле теперь есть личная комната с каждым участником: общая повестка с авторством пунктов, действия с дедлайнами и привязкой к Key Results, лента обратной связи и приватные заметки только для руководителя. Всё в одном продукте — не нужно собирать связку из 5 разных сервисов.
Что внутри:
📅 Встречи с .ics-приглашением в календарь
📝 WYSIWYG-заметки и повестка от обоих участников
✅ Action items на уровне комнаты с фильтрами
💬 Обратная связь по типу praise / development / observation
🔒 Приватные заметки тимлида (видны только вам)
🎖️ Каталог из 30 бейджей признания — от «Шерлока Холмса» до «Древня»
📤 Экспорт всей истории в Markdown и PDF
Подключается пакетом «1‑2‑1 для команды» — 199 ₽/мес или 1 990 ₽/год — на тарифах «Команда», «Направление» и «Бизнес».
Как начать: профиль → команды → вкладка «1‑2‑1».
Подробности — в анонсе на https://retropoint.ru/news/one-on-one-launch 👉
@rf @Russia@3zi.ru @russia@lemmy.ml @russian_mastodon
#RetroPoint #тимлид #1to1 #управлениекомандой #retrospective #ретроспектива #agile #scrum #kanban #teamlead #it #itleads #teamleadthings #команда #retroonline #просторетро #oneonone #one2one
First Principles in Scrum: OpenClaw Scrum and Scrum@Scale by Jeff Sutherland is a new release on Leanpub!
Link: https://leanpub.com/firstprinciplesinscrumscrumandscrumscaleforopenclaw
#books #ebooks #newreleases #leanpublishing #selfpublishing #computer_programming #business_and_management #scrum #leadership_agile #agile_enterprise #enterprise_management #scrum_project_management #product_management #teamwork
@stereo @haufegroup @acccgn @micheal
it was a beautiful experience to learn from others and share from myself.
@luilegeant
@PaddyCorry @pedromosilva @SabineTerwelp @Tapir @DerGuteAlteHerrSchwarz @rueschen @gerhard
Die KI-Ausgabenfalle: Warum Adoption schneller gelingt als belastbare Ergebnisse (von Stefan Wolpers)
Was der Agile-Hype und KI-Hype gemeinsam haben.
#scrumDotOrg #Scrum #StefanWolpers #ScrumMaster #Agile #Agilität
Gefühlt wird die Ausbeute an interessanten Links immer geringer. Hängt das vielleicht mit der KI zusammen? Oder sind überoptimierte Algorithmen das Problem? Zumindest bei LinkedIn und anderen Netzwerken habe ich diesen Eindruck. Es gibt schöne Bildchen, viel Selbstbeweihräucherung und wenig Inhalt. Zum Glück setze ich auf RSS-Feeds für den Informationsüberblick und bin damit zumindest teilweise vor Algorithmen sicher, die Bullshit spucken. Leider nicht ganz vor KI-generiertem Bullshit, der deutlich zunimmt. Ich habe nichts gegen KI-Unterstützung, aber bitte nur als „Unterstützung”. Wenn alles nur noch von anderen abgeschrieben wird, ohne eine eigene Denkleistung einzubringen, dann wird es schnell langweilig. Ein kleines Beispiel: Kürzlich hat es sogar eine vermeintliche Band geschafft, mich kurz auszutricksen. Dieses eine Lied war richtig gut. Ich habe mir weitere Titel angehört, die erstaunlich ähnlich aufgebaut waren. Etwas zu glatt. Zu viel des Guten. Eine kurze Google-Suche hat ergeben, dass die Lieder komplett KI-generiert sind. Zu langweilig. Kein Pfiff. Das ist die schöne neue Welt.
Denjenigen, die sich bereits mit Prokastination beschäftigt haben, bringt der Blogartikel von André Bosse vermutlich keine neuen Erkenntnisse. Die Zusammenfassung finde ich dennoch brauchbar. Viele der Punkte findet man übrigens auch im Podcast von Ivan Blatter, der auch immer wieder in den „Links der Woche” erwähnt wird. Abgesehen davon ist das Aufschieben vermutlich normal. Bis zu einem gewissen Grad ist es sicherlich auch hinnehmbar. Ich lasse zum Beispiel gerne auch mal bewusst Aufgaben liegen, um Gedanken reifen zu lassen oder zu überprüfen, ob sie wirklich wichtig sind. Das fällt nicht unter Prokastinieren, weil es eben bewusst geschieht.
Lässt sich jeder Workflow mittels KI optimieren? Diese Frage habe ich diese Woche in die Runde geworfen und dabei angemerkt, dass auch eine KI nur so gut sein kann, wie die Daten, mit denen sie gefüttert wird. Wer also keine gute Struktur hat, kann auch von einer KI keine Wunder erwarten. Abgesehen davon waren und sind hochstandardisierbare Workflows auch ohne KI automatisierbar. Dumm nur, dass vieles gar nicht so hochstandardisierbar ist. Das ist ein Grund, weshalb ich die Erwartungen an KI für überzogen halte, ebenso wie die Erwartungen an Automatisierung generell. Die Maschine wird manches ermöglichen, aber eben keine Wunder wirken, da bin ich sicherlich mit Jan Fisbach einer Meinung.
https://www.teamworkblog.de/2026/04/workflow-und-ki-andert-sich-etwas.html
Beim Stöbern im Leadershipfreak-Blog von Dan Rockwell bin ich wieder einmal über Ideen gestolpert, die mir seltsam bekannt vorkamen. Das dürfte nicht wundern, denn er verweist tatsächlich auf die Stoiker der Antike. Auch nach so langer Zeit sind sie in vielen Dingen noch immer gut für Ratschläge. Das muss man ihnen einfach neidlos zugestehen. Zu den vielen Ratschlägen der Stoa gehört beispielsweise, nicht der „Schmeichelei” zum Opfer zu fallen. Wie immer sehr lesenswert.
https://leadershipfreak.blog/2026/05/01/escape-the-flattery-trap/
Zum Thema Produktivität gehört für mich die Auszeit im Grünen, zum Beispiel Wandern oder Radtouren. Leider kommt das bei mir etwas zu kurz, da es den Kindern oft zu langweilig ist. Da ich gerne meinen Weg finde, beschäftige ich mich natürlich auch mit geeigneten Hilfsmitteln wie Apps. Google Maps ist dafür nicht wirklich ideal. Die bekannten Apps tun sich nicht gerade durch Datenschutz hervor, wie immer wieder durchsickert. Netzpolitik hat einige Alternativen vorgestellt. OrganicMaps habe ich übrigens schon eine Weile ausprobiert und ganz passable Erfahrungen damit gemacht. Auch als Alternative zu Google Maps für die Navigation im Auto ist es gut geeignet.
https://netzpolitik.org/2026/wandern-radfahren-frei-und-dezentral-ins-gruene/
Das Thema von Lars Richter passt tatsächlich als Querschnittsthema in fast alle Bereiche der „Links der Woche”. Ich ordne es daher hier bei Produktivität ein. Denn es geht um Kreativität. Und kreative Prozesse gelingen meiner Beobachtung nach am besten im Austausch mit anderen Mitmenschen. Da kommt auch keine KI wirklich mit. Auch wenn sie als Unterstützungshilfe Impulse liefern kann. Echte Kreativität entsteht dabei jedoch nicht. Sie ist am Ende aber nicht in der Lage, selbstständig zu denken. Übrigens habe ich auch beobachtet, dass man viele Ideen entwickeln und verwerfen muss, ehe aus diesem Prozess die zündende Idee entsteht. Auch das funktioniert wieder nur im Zusammenspiel mit anderen. Ganz im Sinne von Lars Richter: Kreativität gibt es nur im Plural.
https://scamper.blog/kreativitaet-gibts-nur-im-plural/
Der Job eines Scrum Masters ist anspruchsvoll. Sehr sogar. Vorausgesetzt, man versteht, worum es geht. Sicherlich fällt kein Meister vom Himmel. Gute Scrum Master*innen entwickeln sich daher auch beständig weiter. Die weniger guten bleiben in ihrer Entwicklung hängen. Doch wie erkennt man seine Entwicklungsmöglichkeiten? Eine Möglichkeit ist, sich anzuschauen, was man auf keinen Fall tun sollte. Simon Flossmann zeigt hier fünf Wege, wie man es garantiert an die Wand fährt. Es geht um etwas mehr als nur den Scrum-Leitfaden und seine Regeln, sondern auch um ein tiefergehendes Verständnis des Wesens und der Organisation an sich. Nur um einige Punkte zu nennen.
https://www.scrum.org/resources/blog/5-todsichere-wege-als-scrum-master-miserabel-zu-sei
Scrum Master*innen, die ihr Handwerk verstehen, wissen um die Bedeutung der Produktentwicklung für das Gelingen eines Scrum-Teams. Zur Erinnerung: Scrum ist ein Framework für die Produktentwicklung, also das explorative Erkunden. Neben dem Team gehören auch die Product Owner zu den wichtigen Protagonisten. Auch sie benötigen gelegentlich Unterstützung, um den Rahmen abzustecken und dem Team die notwendige Orientierung zu geben. Ein gutes Zusammenspiel zwischen Product Owner und Scrum Master ist daher unerlässlich. Dies wiederum setzt voraus, dass Scrum Master:innen ein gutes Verständnis von Produktentwicklung haben. Genau darum geht es im Podcast der Produktwerker mit Jan Neudecker.
https://produktwerker.de/was-sollten-scrum-master-ueber-agiles-produktmanagement-wissen/
Ich denke, den Fehler, den Marc Löffler in seinem Podcast anspricht, haben wir alle in der Vergangenheit schon mehr oder weniger gemacht und schmerzhaft gelernt. Bei Veränderungen geht es nicht darum, ein Werkzeug zu implementieren, sondern Ergebnisse zu erzielen. Ergebnisse, die für die Beteiligten greifbar und erlebbar sind und einen Nutzen haben. Nach all den Jahren, in denen ich mich mit Agilität beschäftigt habe, kann ich seine Rückschlüsse auf jeden Fall bestätigen. Agilität ist kein Selbstzweck. Sie ist ein Hilfsmittel, mit dem wir etwas erreichen wollen. Zum Besseren. Damit begeistert man seine Mitmenschen. Übrigens habe ich gelernt, Widerstände als wertvolle Impulsgeber und Indikatoren für Verbesserungspotenziale zu schätzen.
https://marcloeffler.eu/2026/04/28/warum-dein-team-jede-veraenderung-mitmacht-wenn-der-preis-stimmt/
Heute möchte ich etwas „Eigenwerbung” für einen Blogartikel machen, den ich für das Forum Agile Verwaltung geschrieben habe. Es geht um Obeya – oder besser: Was es braucht, um Obeya zu starten. Und hier bin ich, wie bei fast allen Dingen, der festen Überzeugung, dass das „Wozu” der zentrale Kompass und die Gelingensvoraussetzung für einen guten Start ist. Wozu wollen wir etwas tun? Falls sich jemand mehr für das visuelle Management mit Obeya interessiert, stehe ich gerne Rede und Antwort. Wissen vermehrt sich, indem man es teilt.
https://agile-verwaltung.org/2026/04/30/mit-obeya-starten-das-weshalb-als-schluesselfrage/
Joost Minnaar von Corporate Rebels bringt es mit der dramatischen Geschichte des Untergangs der Titanic auf den Punkt: Die Katastrophe hätte verhindert werden können, wenn die organisatorischen Silos an Bord des Schiffs nicht verhindert hätten, dass die Warnungen vor Eisbergen die nötige Dringlichkeit erhielten. Nicht, weil inkompetente Mitarbeitende Mist gebaut haben, sondern weil strukturelle Probleme in Form von lokal optimierten organisatorischen Silos ihren Job ziemlich gut gemacht haben. Aber eben nicht aus einer ganzheitlichen Perspektive. Genau dieses Problem nehme ich in vielen Organisationen wahr. Lokal optimierte Silos, die das große Ganze allerdings gefährden. Die Lösung? Autonome Teams in dezentralen Strukturen, die eigenständig – innerhalb einer gemeinsamen Zielrichtung – reagieren können, sowie kurze Rückkoppelungswege.
https://www.corporate-rebels.com/blog/organizational-silos
In diesem Zusammenhang ist auch die Idee der freien „Vorgesetztenwahl” interessant. Sicherlich ist dies nicht in jedem Kontext und uneingeschränkt möglich, aber seien wir mal ganz ehrlich: Wenn das Vertrauensverhältnis zerrüttet ist, sollte ein Wechsel des „Chefs” möglich sein. Denn nicht immer liegt es an den Mitarbeitenden, wenn es nicht funktioniert. Das ist ein Gedanke, dem ich Felix Stein daher beipflichte und den ich spannend finde. Eine Führungskraft, mit der ich vor ein paar Jahren zusammengearbeitet habe, sagte einmal, dass Menschen Menschen folgen. Dabei schwang eine gewisse Bewunderung mit, wie gut es einem bestimmten Teamleiter gelang, Mitarbeiter nicht nur zu gewinnen, sondern auch deutlich länger zu halten, als es anderen Teamleitern gelang. Ich bin mir sicher, dass manche auch gerne zu diesem Teamleiter gewechselt wären, wenn man ihnen die Wahl gelassen hätte. Nicht, weil er besonders großzügig gewesen wäre, sondern weil er durchaus kritische Dinge auf positiv-menschliche Weise vermitteln konnte und es ihm gelang, Menschen auf authentisch-ehrliche Weise anzusprechen. Das war eine große Stärke.
https://www.lean-agility.de/2026/04/freie-vorgesetzten-wahl.html
KI ist derzeit in aller Munde. Ich bin der Überzeugung, dass die Erwartungen an KI viel zu hoch sind. Dennoch ist sie gekommen, um zu bleiben. Das setzt auch den Aufbau von KI-Kompetenz in Organisationen voraus. Ebenso wie jede andere digitale Kompetenz (in diesem Bereich wurde bereits genug geschlampt). Mit Nadine Pedro bin ich einer Meinung: KI-Kompetenz sollte gezielt entwickelt werden. Und nein, das ist nicht allein Sache der Mitarbeitenden, sondern auch des Unternehmens. Wer aus falsch verstandenem Kostendruck seine Mitarbeitenden nicht bei der Kompetenzentwicklung unterstützt, hat nicht verstanden, wer in Organisationen die Wertschöpfung erzeugt, die die Organisation am Leben erhält.
https://t2informatik.de/blog/foerderung-ki-kompetenzen-unternehmen/
#Agile #KI #Kompetenzaufbau #Kreativität #Leadership #Management #Obeya #Produktivität #Prokastination #Radfahren #Schmeichelei #Scrum #ScrumMaster #Silos #Tools #Tooltipp #Veränderungen #Wandern #Workflow@SabineTerwelp
oh, so cool. warm welcome to our beautiful #fediverse