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.
Organisational Dysfunction of the Day
Analysis paralysis
Context: An agile team is working on a rewrite of an existing legacy solution and feels that its success depends on the function parity it must have with the old one. They therefore end up doing a detailed and extensive analysis to account for as much as possible, even tracking down former developers to get details on some of the more obscure parts. And, even more problematic, they have to figure out which business people own which parts and who all their users are. This drags out in time, and although they have started the work, the extensible analysis prevents them from releasing anything. They are stuck.
OST explains: Agile as a concept is pretty much designed to handle these kinds of situations; at least that is what many may think. It focuses on small increments and puts things in front of the users as soon as possible to tighten the feedback loop, so it makes sense. The thing, though, is that this is not product discovery, as it is an existing product with external product owners and users, both internal and external, and the team has no real product ownership of the app apart from the technical bits. They are not a self-managing product team as a DP2 style should be. Only when they have end-to-end ownership of the whole product, not just a part, can they take full responsibility and accountability so that they can manage it as they please.
Morning Dew by Alvin Ashcraft – Daily links for all developers. » 🌐
@alvinashcraft.com@web.brid.gy
Top Links Why we made Windows Terminal (Kayla Cinnamon) PowerShell MSI package deprecation and preview updates (Jason Helmick) MAUI Sherpa — Your Guide to .NET MAUI Development (Jonathan Dick) GitHub Copilot CLI for Beginners: Getting started with GitHub Copilot CLI (Christopher Harrison) Announcing Azure MCP Server 2.0 Stable Release for Self-Hosted Agentic Cloud Automation (Sandeep … Continue reading Dew Drop – April 13, 2026 (#4645)
Ich habe mal eine ernsthafte Frage an alle, die mit Sprints arbeiten und Cuntinuous Delivery machen (oder zumindest sehr regelmäßig auf Prod deployed): Wie rechtfertigt ihr Sprintziele, wenn eh deployed wird, wenn etwas fertig ist. In meinem Kopf macht es keinen Sinn mich auf ein Sprintziel zu committen, welches zwei Wochen weg ist, wenn es schon früher in Prod sein kann, oder auch erst einen Tag später. Das wirkt so gekünstelt auf mich, ohne Deliverable am Sprintende
Arthur Doler, Jon Graf, Eric Reichwaldt & Amy Norris have Sessions on Career Progression at Nebraska.Code() this July.
https://nebraskacode.amegala.com/
#Development #SoftwareCraftsmanship #UserExperience #DevOps #Midwest #HeartlandDeveloper #Agile #Consulting #Homelabbing #Networking #Security #Automation #OpenSource #Infrastructure #WomenInTechnology #WomenInSTEM #CareerDevelopment
RetroPoint — инструмент для проведения ретроспектив команды.
Это простой и понятный сервис с канбан-досками, голосованием, опросами и таймером — всем, что нужно, чтобы ретро не превращались в формальность, а реально помогали улучшать работу команды.
Особенно полезен:
— тимлидам и руководителям команд
— тем, кто только начинает управлять людьми и выстраивать процессы
— распределённым командам
Планируем постепенно расширять функциональность — добавлять новые инструменты, которые помогут тимлидам и руководителям эффективнее работать с командой.
На сайте также будут публиковаться материалы про управление командами и проведение ретроспектив.
Посмотреть можно здесь:
retropoint.ru/news/publi...
#retrospective #ретроспектива #agile #scrum #kanban #teamlead #it #itleads #retropoint
Habr » 🤖 🌐
@habr@zhub.link
AI убивает Agile
AI убивает Agile. Звучит провокационно, но, кажется, это буквально происходит прямо сейчас Больший сдвиг, который происходит с внедрением AI в разработку, произойдет и в области методологий ведения проектов. Многие компании внедрили гибкие методологии, но AI меняет разные правила, и в том числе он влияет на оргпроцессы внутри разработки. Agile появился как способ справиться со сложной проблемой комплексного планирования систем и низкой скорости разработки, но с проникновением AI эти ограничения уже практически сняты, и вопрос только времени, когда они вообще исчезнут. Есть интересная статья с критикой Agile «Agile Is Dead. AI Killed It. Welcome Back, Waterfall.» Там идеи о том, что новая реальность не нуждается в избыточных ритуалах, которые пришли вместе с Agile, и в процессах, которые были порождены ограниченностью человеческих возможностей. Сейчас, когда мы переключаемся с формулирования задач для прозрачности процессов к формулированию задач для эффективного их решения через AI, нужно уходить и от сложившихся практик, и искать новые или переосмыслять забытые. Kent Beck (один из авторов Agile-манифеста) предполагает, что внедрение AI может столкнуться в организациях с противодействием, потому что не всегда люди заинтересованы в ускорении и удешевлении процессов. Это из разговора Kent Beck и Martin Fowler на Pragmatic Summit. Там же Kent Beck говорит о том, что возвращается тенденция к программистам-интровертам, которые не любят и не хотят частого общения, что было нормой до недавнего времени. Сейчас можно сфокусироваться на нескольких коллегах и нескольких агентах, а задачей компании становится создание безопасной позитивной атмосферы для функционирования таких производственных единиц.
Organisational Dysfunction of the Day
Forming–storming–norming–performing
Context: When putting together a new team or making big changes to an existing one, many recommend using Tuckman's "forming–storming–norming–performing" model to turn the team into a coherent and well-oiled unit. It begins with Forming (orientation), moves to Storming (conflict), progresses to Norming (cohesion), and ends with Performing (high productivity). Leaders are advised to manage this process closely as progress is not linear; teams may slip back to previous stages if new members join or goals shift. And conflict is regarded as necessary, as the "Storming" phase is essential to growth.
OST explains: Tuckman's model only makes sense in an autocratic bureaucracy, especially those of the Theory X type, and aligns with Taylor's view that people must be managed to perform properly. This is classic DP1 thinking, whereas in the DP2 style, McGregor's Theory Y is the model, which assumes employees are self-motivated, enjoy work, and thrive under trust, empowerment, and autonomy. Grouped into self-managing groups that have designed themselves using Participative Design. No need for either storming or norming; the teams jump right to performing after forming.
Gerade als ich die Links der Woche zusammenstelle, stoße ich in meinem RSS-Reader (ja, ich habe tatsächlich einen, der ein wichtiger Teil meines Informationsmanagements ist) auf einen Gastbeitrag von Astrid Kuhlmey bei t2informatik. Ein Blogbeitrag, der mir in weiten Teilen sogar aus der Seele spricht. Sie spricht von „Selbstausbeutung”. Das trifft es ganz gut. Das erinnert ein bisschen an die von mir immer wieder ins Spiel gebrachte „Effizienzneurose”, die zwar auf einer anderen Ebene ansetzt, aber eben auch Teil jener Denkweise ist, die den ganzheitlichen Blick nahezu komplett „ausblendet” und „Upstream-Denken” fast unmöglich macht. Bedauerlicherweise sind wir alle Teil eines Systems und es ist gar nicht so einfach, dieser Entwicklung entgegenzuwirken – selbst wenn man die Erkenntnis hat. Insbesondere nicht, wenn uns ewig gestrige „Entscheidungsträger” erklären, wir müssten mehr arbeiten (trotz Verdichtung der Arbeitsqualität und anderer Faktoren).
https://t2informatik.de/blog/stoppt-die-selbstausbeutung/
Ich habe Obsidian – auch durch Thomas Mathoi – schon lange auf dem Schirm. Ich nutze es zwar immer noch zu wenig. Das will ich aber ändern. In seinem folgenden Blogartikel zeigt Thomas Mathoi, was Obsidian allein schon mit Bordmitteln in Sachen Aufgabenorganisation kann, sodass man gut auf Plugins verzichten kann. Das ist sicherlich nicht ganz so schick wie manche anderen Werkzeuge auf dem Markt. Dennoch ist es ausreichend. Hinzu kommt, dass sich Notizen und Aufgabenmanagement gut vereinen lassen.
https://www.mathoi.at/2026/04/06/obsidian-kaizen-aufgabenuebersicht-mit-bordmitteln-selber-bauen/
Ich beschäftige mich gefühlt schon ewig mit Produktivität und habe unzählige Methoden, Ideen und Ansätze ausprobiert. Gefühlt hat keine davon das zentrale Problem gelöst, dass es immer mehr zu tun gibt, als ich leisten kann. Je mehr ich von meiner To-do-Liste abarbeite, desto mehr kommt nach. Die Lösung dafür lautet oft: richtig priorisieren, dann wird das schon. So einfach ist es dann eben oft nicht. Meine Erkenntnisse: 1. Es gibt nicht die eine Wunderlösung und Methode. 2. Jeden Tag setze ich alles zurück und plane „frisch”. Ähnlich sieht es bei den Empfehlungen von André Bosse aus. In seinem Beitrag finden sich ein paar gute Ansätze.
https://www.manage-dich-selbst.de/zu-viele-aufgaben/
Zum Thema der endlosen „Aufgabenliste“, das ich bereits angesprochen habe, passt ganz gut der aktuelle Podcast von Ivan Blatter. Er bringt eine spannende Perspektive ins Spiel: Das Abrutschen in den Reaktionsmodus führt dazu, dass wir wieder in die Teufelküche geraten, wenn alles gleich wichtig zu sein scheint und das „Dringende“ das „Wichtige“ in den Hintergrund drängt. Wir arbeiten die Aufgabenliste ab, ohne „Licht am Horizont”, weil ständig neue Aufgaben nachrücken. Wir reagieren statt zu agieren. Ivan Blatter gibt vier Tipps, mit denen wir aus diesem Modus aussteigen können. Und das ist vor allem Arbeit am „System”. Übrigens gibt es auch eine Überschneidung zu den Tipps von André Bosse. 😉
https://share.transistor.fm/s/b4bd36e6
Irgendwann habe ich für mich festgestellt, dass die Menschen, die sich immer wieder selbst hinterfragen und versuchen, sich nicht zu wichtig zu nehmen, deutlich spannender sind. Sie sind offen für neue Ideen und Impulse. Außerdem liefern sie mir durch ihre Neugier und ihre Fragen neue Impulse, wie ich meine Ideen weiterentwickeln kann. Sie alle zeichnen sich dadurch aus, dass sie sich nicht in ihrer „Komfortzone” einrichten, sondern sich immer wieder hinauswagen. Nicht hochriskante Geschichten, sondern bewusst und reflektiert. Wenn ich Dan Rockwell folge, würde ich sagen, dass wir auch aktiv dazu beitragen können. So wir wollen. Wie er treffend festhält, führt zu viel Komfort dazu, dass wir „dumm” werden (im Sinne von arrogant). Und wir alle wissen, dass das gefährlich ist.
https://leadershipfreak.blog/2026/04/09/comfort-makes-you-stupid/
Die wohl wichtigste Frage ist: In welchem Kontext bewege ich mich und was ist in diesem Kontext der passendste Weg? Und genau diese Überlegung wird überraschend selten angestellt. Wenn es dann nicht funktioniert, ist der gewählte Ansatz grundsätzlich „Schrott”. Dabei wird gerne vergessen, dass methodische Ansätze wie Scrum für einen bestimmten Kontext geschaffen wurden. Scrum ist ein Rahmenwerk für die explorative Erforschung komplexer Aufgabenstellungen. In diesem Kontext funktioniert eine Denkweise, die für reproduzierbare und standardisierbare Aufgaben gemacht wurde, nicht. Gleiches gilt, wenn ich auf Kanban setze. Kanban ist in einem explorativen Kontext anders als in einem Kontext von Routinetätigkeiten, weil die Art der Arbeit eine andere ist und andere „Anforderungen” stellt. Es ist also durchaus sinnvoll, sich zu fragen, welche Denkweise für welchen Kontext geeignet ist und wie eine Denkweise aus dem einen Kontext im anderen Kontext zu kognitiven Fallen werden kann. Diese Fallen beschreibt Chuck Suscheck sehr treffend.
https://www.scrum.org/resources/blog/cognitive-trap-efficiency-over-empiricism
Die Überschrift von Robert Pieper ist ein bisschen reißerisch, denn was er über Scrum schreibt, gilt nur für einen bestimmten Kontext. Jenen Kontext, für den Scrum geschaffen wurde. Nämlich für das explorative Lösen komplexer Problemstellungen. Und genau hier greift die Arbeitsweise von Scrum: Die kurzen Feedbackzyklen führen unter anderem dazu, dass wir schneller auf Fehler und Irrtümer reagieren können (was Zeit und Kosten reduziert) und früher echten Mehrwert liefern können, mit dem sich Umsatz generieren lässt – sofern man am Ende des Sprints tatsächlich ein fertiges, vollverwendbares Teilinkrement liefert. Grundsätzlich bin ich mit ihm einverstanden. Wenn es um „Neuentwicklung” geht. Und genau dafür wurde Scrum geschaffen.
https://www.scrum.org/resources/blog/scrum-roi-how-scrum-reduces-costs-and-drives-revenue-growth
Jan Fischbach hat eine echte Fleißarbeit geleistet. Er hat sich die unterschiedlichsten Coaching- und Führungsrahmenwerke sowie die jeweiligen Perspektiven, die sie einnehmen, angesehen. Insgesamt hat er damit „21 Linsen” zusammengetragen. Ich bin mir sicher, dass kein Coach und kein Trainer alle im Tagesgeschäft abdecken kann. Darum geht es meiner Meinung nach auch nicht. Es geht vielmehr darum, uns zu sensibilisieren, dass wir uns nicht auf eine „Perspektive” verlassen dürfen. Wir müssen immer im Hinterkopf behalten, dass es für jedes Thema unterschiedliche Perspektiven gibt, die mitunter auch zu ganz unterschiedlichen Lösungsansätzen führen. Die Welt ist komplex. Daher ist es wichtig, sich bewusst zu machen, dass wir Herausforderungen aus unterschiedlichen Blickwinkeln betrachten sollten. Nicht nur mit den zwei oder drei, die wir persönlich bevorzugen, sondern auch mit der Brille anderer „Denkschulen”. Das macht für mich auch einen guten „Agile Coach” aus.
https://www.teamworkblog.de/2026/04/coaching-und-fuhrungsframeworks-im.html
Jan Fischbach hat das Thema der „verschiedenen“ Linsen in einem Fortsetzungsbeitrag erneut aufgegriffen und dieses Mal für die Zielgruppe der „Scrum Master“, die ihre Rolle gerade erst übernommen haben, zusammengedampft. Interessant finde ich, dass er drei „Linsen” vorstellt, um am Ende die Prozesslinse als die wichtigste zu benennen. In der Praxis erlebe ich zu oft, dass die „Arbeitsklimalinse” im Fokus steht und die Prozesslinse bzw. die Arbeitsergebnisse hinten runterfallen – nicht nur bei frisch gebackenen Scrum Master:innen. Agilität ist kein Selbstzweck. Sie soll dazu dienen, bessere Arbeitsergebnisse zu erzielen.
https://www.teamworkblog.de/2026/04/neuer-scrum-master-mit-drei-einfachen.html
Ich bin, das ist kein Geheimnis, ein großer Fan der Verbesserungskata und ihrer Bestandteile. Dieses Bild verwende ich auch gerne und oft, da es für mich etwas Entscheidendes verdeutlicht: Es braucht einen „Referenzpunkt”, der für Klarheit sorgt und die Richtung vorgibt. Im Kontext der Produktentwicklung ist das das Produktziel. Was mich ebenso an der Verbesserungskata fasziniert, ist die Idee des „Nordsterns” als „zeitloses”, handlungsleitendes Ziel, das auf die Wirkung abzielt. Diese Idee übertrage ich gerne auf andere Bereiche, da ich denke, dass wir in einer hochkomplexen Welt genau das brauchen, um effektive Entscheidungen treffen zu können, die ausreichend Flexibilität und Handlungsspielräume bieten und gleichzeitig Orientierung geben. Das Ganze – wieder zurück zum Thema Produktziel – wird im Produktwerker-Podcast im Kontext der Produktentwicklung dargestellt.
https://produktwerker.de/das-product-goal-warum-sich-daran-der-wandel-der-po-rolle-zeigt/
Ufz, der Blogartikel von Daniel Dubbel hat es in sich. Er ist lang. Er ist vollgepackt mit Gedanken. Und er hat eine Botschaft, die für den einen oder anderen nicht leicht verdaulich sein dürfte. Es geht um Unsicherheit. Unsicherheit, die wir aktuell alle massiv spüren. Aber sie war schon immer da. Und wird immer da sein. Und ja, es macht keinen Spaß. Mir nicht. Und niemand anderem da draußen. Ambiguitätstoleranz wird oft mit der Einzelperson verknüpft. Und jetzt kommt Daniel Dubbel daher und erklärt, dass eine Organisation und ihre Teile als solche Ambiguitätstoleranz erlernen muss. Mit anderen Worten, er besitzt doch frech die Unverschämtheit, uns zu sagen, wir sollten uns von den einfachen zweckrationalen Modellen verabschieden, in denen wir in unseren Organisationen arbeiten, weil „Komplexität“ nicht beherrschbar machen können. Wir müssen selbst und die Organisationen, in denen wir arbeiten, befähigen mit Unsicherheit umgehen zu können. Und dazu muss Führung selbst umdenken. Und zwar ordentlich.
Gute Führung „multipliziert“ sich, indem sie andere dazu befähigt, selbst zu führen. Eigentlich naheliegend. Wäre da nicht der Faktor Mensch. Aber gut, auf die Ursachen will ich gar nicht eingehen. Dan Rockwell zeigt, wie man als Führungskraft gute Führungskräfte „multipliziert“. Nämlich durch das Befähigen von Menschen, die selbst gewillt sind, andere zu befähigen. Ich kenne nur wenige Organisationen, die diese Kunst wirklich aktiv befördern und als Teil ihrer Kultur verankert haben. Es wäre schön, wenn es Nachahmer gäbe. Aktuell hat man eher das Gefühl, die Uhr dreht sich rückwärts.
https://leadershipfreak.blog/2026/04/10/multiply-or-die/
#Agile #Analyse #Aufgabenmanagement #Coaching #Führung #KognitiveFallen #Management #Obsidian #Priorisierung #Produktivität #ROI #Scrum #ScrumMaster #Unsicherheit #ZeitmanagementMany view autonomy as a wonder pill, but without alignment, it often leads to silos and conflict. True autonomy isn't independence; it requires shared constraints like vision and strategy to flourish in a team environment. https://mdalmijn.com/p/autonomy-is-overrated-why-alignment #ProductManagement #Agile
Reddit ist eine Quelle der Freude, wenn man in den tiefen Abgrund der Missinterpretation von #Agile schauen möchte. Sub-Task Zeitschätzungen in Tagen und Story Points je Dev auf einem Dashboard - very well!
Agile isn't dead, but our hunger for shared learning may be. Allan Kelly argues that by stopping experimentation and post-work meetups, we let Agility stagnate. We must revive that curiosity to thrive in the AI era. https://www.allankelly.net/archives/10705/agile-is-dead-assisted-suicide-can-you-revive-it/ #Agile #ProductManagement
Needed to look something up for a discussion about agile. Still love the Work-Feedback Loop document I wrote. Give clarity to what #agile is about without thinking about a method. WFL > Method. At least for me.
Bureaucracy Is Not a Scaffold, It Is a Cage, by (not on Mastodon or Bluesky):
https://www.scrum.org/resources/blog/bureaucracy-not-scaffold-it-cage
When CPO/CTO alignment is fake, teams pay the price in mixed signals and fake work. CPTO is best. If you must keep the roles separate, real partnership is the ability to disagree productively behind closed doors. Stop paying the Alignment Tax.
https://insideproductorg.substack.com/p/the-alignment-tax-what-a-real-cto
#ProductLeadership #Agile
Morning Dew by Alvin Ashcraft – Daily links for all developers. » 🌐
@alvinashcraft.com@web.brid.gy
Top Links Running Multiple Instances of an Aspire AppHost Without Port Conflicts (James Newton-King) Why .NET MAUI Popups Lag and How to Fix Performance Issues (Kompelli Sravan Kumar Kompelli Lakshman) What’s new in Microsoft Foundry | March 2026 (Nick Brady) Expanding the MCP Maintainer Team (David Soria Parra) Visual Studio Code 1.116 Release (Visual Studio … Continue reading Dew Drop – April 10, 2026 (#4644)
Practical Ways to Lead and Serve (Manage) Others by Johanna Rothman is on sale on Leanpub! Its suggested price is $9.99; get it for $7.99 with this coupon: https://leanpub.com/manageothers/c/LeanpubWeeklySale20260407 johannarothman@mastodon.sdf.org #Agile #BusinessAndManagement
Dynamic Reteaming by Heidi Helfand is on sale on Leanpub! Its suggested price is $30.00; get it for $16.00 with this coupon: https://leanpub.com/dynamicreteaming/c/LeanpubWeeklySale20260407 heidihelfand@mastodon.social #Agile #Startups #Teamwork #ProjectManagement
This isn't your typical Agile transformation book. It's a fast-moving story packed with drama, humor, and practical insights. See "Agile Protocol" on Amazon 👉 https://amzn.to/4bVpiJI | #Agile #Scrum #AgileTransformation #ScrumMaster #ProductOwner #AgileProjectManagement #Book
Product teams often suffer from a 'perspective problem'. While leadership tracks market trends, teams focus on specific users. To build great products, we must translate between three layers. Misalignment is usually a lens issue: https://eleganthack.com/everyone-on-your-team-is-right-and-thats-the-problem/ #ProductManagement #Agile