Interesting view on agile development and how LLMs are changing it.

https://lewiscampbell.tech/blog/260414.html

I specifically liked this:

«One unambiguously positive development that's followed is that software professionals are writing specs again. [...] Agile told us "Working software over comprehensive documentation". Spec-Driven Development is telling us "Comprehensive documentation creates working software"»

#softwareDevelopment #agile

Ah, the grand #farewell to #Agile, the mystical #buzzword everyone loved to misunderstand. 🌊 Like a diet where the only rule is "eat food," #Agile swept through, leaving us with endless debates on what True Agile™️ actually meant. #RIP Agile, we'll miss your cryptic wisdom and #daily #circle time. 😏
https://lewiscampbell.tech/blog/260414.html #Misunderstood #HackerNews #ngated

Ретро без гадания: собрали техники в одном месте!

Запускаем раздел «Техники» на RetroPoint — коротко и по делу: что за формат, кому он подходит и какие колонки появятся на доске.

Двенадцать проверенных сеток — от классики вроде Start / Stop / Continue и What Went Well до Sailboat, хронологии спринта и «трёх поросят». Можно просто почитать. А если пора провести ретро — создайте доску по выбранному шаблону в пару кликов, в том числе прямо со страницы техники, без ручной настройки колонок.

Смотреть и выбирать: retropoint.ru/techniques — заходите на следующую ретроспективу чуть увереннее.

#retrospective #ретроспектива #agile #scrum #kanban #teamlead #it #itleads #retropoint #teamleasthings #команда #RetroPoint

If urgent work keeps appearing, it's not a developer problem.

It's a prioritisation and leadership problem.
#Software #Dev #Agile #Smells #Heroics

ueberleg mir grad nen halbtagsworkshop:

• 15min Ankommen und erster Austausch (impromptu networking)
• 30min humorvolle Zerstoerung (TRIZ)
• 16min durchatmen / pause
• 60min What I need from You (winfy)
• 30min shift&share oder troika consulting (je nach dem, was mir dann passt)
• 15min 15% solutions

was meint ihr, is "was wuerde es noch schlimmer machen" triz aktion vor einem winfy hilfreich?

@agile
#agile #scrum #retro #liberatingstructures

»Interview Red Flags for the Scrum Master« https://www.scrum.org/resources/blog/interview-red-flags-scrum-master #Agilist.in #Agile #Change #Lean #Kanban #Scrum

hab den #scrumday2026 gebucht. kommt noch wer mit? ;)

@agile
#agileparty #scrum #agile

»Why You Can Still Get Lost With A Stakeholder Map« https://www.scrum.org/resources/blog/why-you-can-still-get-lost-stakeholder-map #Agilist.in #Agile #Change #Lean #Kanban #Scrum

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.

#OpenSystemsTheory #SocioTechnical #OrgDesign #agile

»Como descomponer bien épicas en historias de usuario« https://www.scrum.org/resources/blog/como-descomponer-bien-epicas-en-historias-de-usuario #Agilist.in #Agile #Change #Lean #Kanban #Scrum

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)

»How to Run the Sprint Retrospective When Half of your Team is AI Agents« https://www.scrum.org/resources/blog/how-run-sprint-retrospective-when-half-your-team-ai-agents #Agilist.in #Agile #Change #Lean #Kanban #Scrum

A good rule for engineering teams:

“We can work faster temporarily.

But we cannot work faster forever.”
#Software #Dev #Agile #Smells #Heroics

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

#scrum #agile

RetroPoint — инструмент для проведения ретроспектив команды.

Это простой и понятный сервис с канбан-досками, голосованием, опросами и таймером — всем, что нужно, чтобы ретро не превращались в формальность, а реально помогали улучшать работу команды.

Особенно полезен:
— тимлидам и руководителям команд
— тем, кто только начинает управлять людьми и выстраивать процессы
— распределённым командам

Планируем постепенно расширять функциональность — добавлять новые инструменты, которые помогут тимлидам и руководителям эффективнее работать с командой.

На сайте также будут публиковаться материалы про управление командами и проведение ретроспектив.

Посмотреть можно здесь:
retropoint.ru/news/publi...

#retrospective #ретроспектива #agile #scrum #kanban #teamlead #it #itleads #retropoint

»Scrum Master interview questions & answers for 2026« https://www.scrum.org/resources/blog/scrum-master-interview-questions-answers-2026 #Agilist.in #Agile #Change #Lean #Kanban #Scrum

»Leading Like a Caregiver« https://bobgalen.substack.com/p/leading-like-a-caregiver #Agilist.in #Agile #Change #Lean #Kanban #Scrum

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.

#OpenSystemsTheory #SocioTechnical #OrgDesign #agile

»How to do Sprint Retrospective when half of your team is AI Agents« https://www.scrum.org/resources/blog/how-do-sprint-retrospective-when-half-your-team-ai-agents #Agilist.in #Agile #Change #Lean #Kanban #Scrum

»8 Reasons That Force You To Learn Scrum« https://www.scrum.org/resources/blog/8-reasons-force-you-learn-scrum #Agilist.in #Agile #Change #Lean #Kanban #Scrum

»Do Balcão ao Backlog: Por que a falta de visão estratégica está matando o seu Produto« https://www.scrum.org/resources/blog/do-balcao-ao-backlog-por-que-falta-de-visao-estrategica-esta-matando-o-seu-produto #Agilist.in #Agile #Change #Lean #Kanban #Scrum

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!

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.

https://no-bullshit-agile.com/wfl/

»10 Scrum Master Interview Questions for the AI Era« https://www.scrum.org/resources/blog/10-scrum-master-interview-questions-ai-era #Agilist.in #Agile #Change #Lean #Kanban #Scrum

Organisational Dysfunction of the Day

The powerless retrospective

Context: You and your team have decided it's time to do a retrospective prescribed by the Agile methodology you are using. You all see the use of it and contribute with a lot of ideas and concerns about your work. You record them all and have a vote on the most important ones, but soon realise almost all of them are outside of your mandate to change. You note them down and hope the department lead can do something about it, but know that probably nothing will change, and the whole exercise feels like a complete waste.

OST explains: The members of the team come into this believing they are self-managing, at least to a level where they are able to adjust the work to make it better. Even the Agile methodology says so by incorporating the retospective as a recommended element. An essential element in learning is both looking back and improving going forward. The issue here is that the team is not self-managing, in a DP2 structure, as they are not able to change what really matters to them. Most likely, they are in an agile setup where the teams have been given some control, but most still reside in management outside, in the existing bureaucratic DP1 organisation. The retrospective and the learning it ought to provide are mostly ineffective.

#OpenSystemsTheory #SocioTechnical #agile

I managed to make a little dent with my series of posts on #SocioTechnical principles of the day, and thought it was due to do something similar, but this time in the context of modern organisations (especially #agile ones) and the modern version of #STS, known as Emery's #OpenSystemsTheory ( #OST). I'll list some systemic problems I have seen in organisations over the years and explain their causes using OST, one each day as I did back then. Probably way too ambitious, but let's see how this goes. Happy to take comments and rebuttals to each one of them, as the point of doing this is to trigger reflections and critical thinking.
Warning: these will probably be a bit more opinionated. 😁

Organisational Dysfunction of the Day

The daily status report

Context: Your team is using Scrum and has been taught how important stand-ups are (daily coordination meeting), but it feels like a drag and a complete waste of time. Feels more like reporting to someone, be it the scrum master or the product owner. And you really do not care about what the others are working on, as it has little to no impact on what you're doing.

OST explains: This team is probably not a team at all; it's more like a group of individuals working on different things. They may contribute to the same delivery but have not been able to take control of the work design and the coordination needed to deliver it. This is not a self-managing team, but rather a delivery group assigned specific tasks by a manager, in charge of splitting the work so that all team members are working as effectively as possible. This is pure DP1 and nowhere close to the self-managing teams in DP2.