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.
"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
“If you don’t collect any metrics, you’re flying blind. If you collect and focus on too many, they may be obstructing your field of view.”
— Scott M. Graffius, Agile Scrum: Your Quick Start Guide with Step-by-Step Instructions
#Agile #AgileAnalytics #AgileBook #AgileProjectManagement #AgileQuote #AgileScrumGuide #Analytics #Data #DataQuote #Innovation #Metrics #MetricsQuote #ProjectManagement #ProjectManagementQuote #Quote #QuoteOnMetrics #Scrum #ScrumBook #ScrumQuote #Software
„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
Habr » 🤖 🌐
@habr@zhub.link
Как устроена разработка ПО: разбираем Waterfall и Agile
Почему Agile‑команды скатываются в неконтролируемый хаос, а проекты на Waterfall годами пилят никому не нужный продукт? Спойлер: проблема не в методологиях, а в нас самих. Вы узнаете, как сильные команды совмещают лучшие практики обоих миров, почему Contract‑First и Trunk‑based Development спасают даже в Agile.
https://habr.com/ru/companies/otus/articles/1022180/
#Waterfall #Agile #Scrum #методологии_разработки #процесс_разработки_ПО #системный_анализ #требования #проектирование #обратная_связь #гибридный_подход
Habr » 🤖 🌐
@habr@zhub.link
Коэффициент токсичности задачи: как одна метрика снизила текучку в команде до 10%
Из моего отдела ушел ключевой специалист. Унес три года контекста. Я начал разбираться и обнаружил, что инструментов для измерения человеческой стоимости задачи не существует. Пришлось делать свой. Через полгода текучесть в команде упала до 10%.
https://habr.com/ru/articles/1032000/
#управление_проектами #agile #scrum #бэклог #выгорание #метрики #уточнение_задач #планирование_итерации #требования #команда
Habr » 🤖 🌐
@habr@zhub.link
Культура инженерии: Почему главные инсайты рождаются не на сцене, а в метро и барах
Я долго думал, что главное в IT — это спринты, доски задач и код без лишних встреч. Но после Techday 2026 понял: настоящие решения рождаются не в Jira, а в кулуарах, в метро и за кофе. Делюсь своим опытом — как офлайн-мероприятия меняют связи между командами и экономят энергию Забрать опыт
https://habr.com/ru/companies/astralinux/articles/1014554/
#культура_компании #корпоративная_культура #командная_работа #взаимодействие_с_командой #itкоманды #agile #scrum #кросскомандная_разработка #soft_skills #митапы
Habr » 🤖 🌐
@habr@zhub.link
Проектный менеджмент умер: почему проекты больше не ведут, а только синхронизируют)
Если открыть любой рабочий мессенджер, создаётся ощущение высокой вовлечённости: обсуждения не прекращаются, апдейты приходят постоянно, команда «на связи» и все задачи «в работе». Я как Project Manager стриминга кино viju.ru сама в этом варюсь каждый день — десятки тредов, уточнений, синхронизаций, но в какой-то момент ловишь себя на мысли: чем больше коммуникации, тем меньше реального движения задач. Это не просто ощущение. По данным Microsoft, у перегруженных специалистов переключение внимания происходит каждые две минуты, а 60% встреч — внеплановые. Atlassian дополняет: 65% сотрудников считают важнее быстро ответить на сообщение, чем продвинуться по задаче. В сумме это приводит к довольно неприятному выводу: проектное управление постепенно умирает.
https://habr.com/ru/companies/viju/articles/1031294/
#project_management #управление_проектами #agile #scrum #коммуникации_в_команде #управление_задачами #рискменеджмент #принятие_решений #эффективность_команды #backlog
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 #WorkflowSustainable teams over individual heroics
https://doi.org/10.13140/RG.2.2.12459.91681
#Agile #AgileLeadership #AgileProjectManagement #AgileScrumGuide #AgileTeams #Collaboration #ContinuousImprovement #Innovation #Leadership #ProjectManagement #Scrum #SustainableTeams #TeamDynamics #Teamwork #WorkCulture #SustainableTeamsOverIndividualHeroics #HeroesInAgile
@SabineTerwelp
oh, so cool. warm welcome to our beautiful #fediverse
Thank you to Gartner for the shout-out!
EDIT: Originally from 2019, but worth revisiting.
#Agile #Scrum #AgileScrumGuide #AgileProjectManagement #ProjectManagement #ScrumMaster #ProductOwner #Book #Gartner #Tech #Metrics #Quote #MetricsQuote
🖥 Как провести онлайн-ретроспективу и не потерять команду в видеозвонке
Ретро на удалёнке — другая встреча. Мимика в плитке 5×5 см считывается хуже, половина камер выключена, а молчание в экран давит сильнее, чем в переговорке.
Написали пошаговый гайд на 60 минут:
🔧 Как подготовить инфраструктуру — доска, видеосвязь, таймер
✍️ Что делать на каждом этапе — от сбора стикеров до голосования
🎯 Как закрыть встречу действиями, которые команда реально выполнит
⏱ Почему тайм-бокс спасает от «ну, у кого ещё что-нибудь?»
Внутри — конкретные приёмы: почему все пишут одновременно, а не по очереди, зачем звать по имени и как не дать ретро превратиться в монолог фасилитатора.
Подходит scrum-мастерам, тимлидам и всем, кто ведёт ретро на удалёнке 👇
https://retropoint.ru/news/online-retrospective-guide
#retrospective #ретроспектива #agile #scrum #kanban #teamlead #it #itleads #teamleasthings #команда #RetroPoint #retroonline #просторетро
oh, only two times sleeping ;) @agile
just collecting attendees from the @haufegroup to invite them to our digital twin rooms in #matrix
Habr » 🤖 🌐
@habr@zhub.link
Ремонт в квартире как IT-проект: Scrum, спринты и ежедневные митапы с бригадой
Как связаны ИТ и строительство? Очень тесно — через методологию управления. Несколько лет назад я впервые столкнулся с методологией Scrum. Тогда она произвела на меня колоссальное впечатление. Позже, конечно, я нашёл и негативные стороны этого подхода, и понял, что в разных проектах лучше использовать разные подходы. Благо, что их придумано множество!
https://habr.com/ru/articles/1029136/
#Scrum #Agile #управление_проектами #ремонт_квартиры #daily_standup #проектное_управление #методологии #лидерство #быстрый_ремонт #строительство
Habr » 🤖 🌐
@habr@zhub.link
Story points — прошлый век?
Мнение. Предложение к обсуждению, а не новая догма. Story points долго были удобным способом оценивать сложность задач в разработке. Но в 2026 году всё больше работы делается не только инженером, но и в связке с LLM: генерация кода, тестов, документации, рефакторинг, разбор ошибок. Возникает вопрос: может ли рядом со story points появиться новая метрика — neuro points, отражающая AI-итеративность решения задачи? В статье предлагаю этот подход как гипотезу для обсуждения и разбираю, зачем он вообще может понадобиться командам, которые уже активно используют нейросети в рабочих процессах. Обсудить подход
https://habr.com/ru/articles/1028984/
#story_points #neuro_points #agile #scrum #LLM #AI_coding #оценка_задач #нейросети_в_разработке #developer_productivity #engineering_management
Dr. Harold Kerzner's "Innovation Project Management" book features content from my "Agile Scrum: Your Quick Start Guide with Step-by-Step Instructions" book:
https://amzn.to/3LFxFfO
#Agile #Scrum #AgileScrumGuide #ProjectManagement #Innovation #ScrumMaster #ProductOwner #Book
I'm looking for problems by watching you CI server build jobs and telling the devs if a build breaks. (Don't asks about the broken e-mail notification)
I don't call it #QualityEngineering or similar. Just plain / upland #Testing .
#RapidSoftwareTesting goes beyond the execution of predefined scripts and also doesn't reinvent the wheel.
Good, deep testing is doable.
#quality #softwaredevelopment #softwaretesting #agile #kanban #scrum
If you're interested in Agile, check out my 3 books
◾️ Agile Scrum: A Quick Start... [non-fiction] https://amzn.to/42sjFyH
◾️ Agile Transformation: A Brief Story... [non-fiction] https://amzn.to/42RVome
◾️ Agile Protocol: The Transformation... [fiction] https://amzn.to/4pScdal
#Agile #Scrum #AgileProjectManager #AgileProjectManagement #Books #AgileBooks #ScrumBooks
🎯 В RetroPoint появился модуль OKR!
Теперь квартальные цели команды живут прямо рядом с ретро — не в Notion, не в таблицах, а в профиле команды.
Что внутри:
📌 Циклы OKR с датами и статусами — Черновик → Активен → Закрыт
📊 Objectives и Key Results с автоматическим прогресс-баром по формуле
✅ Еженедельный чек-ин — текущее значение, уверенность (В норме / Под риском / Отстаём), заметка
📈 Спарклайн и таймлайн за весь квартал — видно, равномерно ли движется работа или всё сдвинулось в конец
🔗 Прямая связь с ретро Sprint Goal — создаёте ретро-доску из KR, и данные возвращаются в OKR прямо с доски, без переключений
Модуль доступен на тарифах «Команда» и выше с пакетом «OKR для команды».
Попробовать → https://retropoint.ru/modules/okr
@rf @Russia@3zi.ru @russia@lemmy.ml @russian_mastodon
#retrospective #ретроспектива #agile #scrum #kanban #teamlead #it #itleads #teamleasthings #команда #RetroPoint #OKR