“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

Shop the Agile Scrum book 👉 https://amzn.to/4uwjZZh

#Agile #Metrics #TechMetrics #MetricsQuote #Book

This week, I am blogging about burn-down charts.

https://www.edyouragilecoach.com/burning-down-the-work/

If used correctly, you can create helpful metrics to improve the team.

🏴‍☠️ 🐻

#Agile #leadership #business #GhostGang

@albertocblanco

The role is really about enabling flow. Helping the team focus, collaborate, and deliver without constant friction. That’s where the impact is. #Scrum #Agile

#SchlePaZ - die schlechtesten Projektanfragen aller Zeiten.

https://www.alles-bekloppte.de/multi-projektmanager-weiterentwicklung-komplexer-infrastruktur-und-monitoringlosungen/

#projekt #scrum #scrummaster #agile

"But we have a deadline."

Good. Deadlines aren't the enemy. Fake deadlines are.

A real deadline means: fixed date, flexible scope. You ship the most valuable increment that's ready by then.

A fake deadline means: fixed date, fixed scope, and a team cutting corners at 2am to hit both.

Agile doesn't mean no deadlines. It means honest planning in small increments, with real data, not wishful thinking.

#agile #softwaredevelopment

Alt...

FIXED DATE, FIXED SCOPE? THAT'S NOT A DEADLINE. IT'S A TRAP.

Project Manager 2026: как AI-инструменты меняют профессию

«Что с проектом, Лебовски?» — этот вопрос съедал у меня по 3-4 часа в день: лички, созвоны, «а ты не знаешь?», «а кто отвечает?». Потом я отдал сбор статусов AI-агенту. Внутри — личный опыт, рабочий промпт (можно копировать), стек на Claude + MCP + Obsidian и честный список того, где такой агент стабильно врёт.

https://habr.com/ru/articles/1039480/

#project_manager #проектный_менеджер #AI #искусственный_интеллект #Claude #MCP #автоматизация #agile #управление_проектами #soft_skills

I have long tried to understand why management insists on fixed-time, cost, and scope when planning software development projects. This article is an attempt to explain why this pattern occurs, and what organizational change may be able to fix it.

While I was experimenting with some audio equipment, it came to me that what we call an impedence mismatch in electrical engineering is actually a common problem in software development, too. Perhaps we can learn about the solution from a domain that has this problem solved?

https://uhlig.it/2026/05/25/agile-impedance-mismatch.html

#agile #impedancemismatch #productowner

Почему российские компании остаются на серой Jira

Джира в России осталась, но в очень нелегальном состоянии. 4 года назад Атлассиан ушёл из РФ, а 30 марта закрыли продажи on-premise версий для дата-центров. В 2029 году снимаются с поддержки все локальные версии. При этом 70% компаний всё ещё сидят на неподдерживаемых версиях Jira, Confluence и Trello. Это не малый бизнес, который не захотел успел разобраться, а гиганты с выручкой от 2 млрд рублей. Люди, которые управляют этими компаниями, прекрасно понимают ситуацию. И всё равно не уходят. Потому что это годами настроенные рабочие процессы, тысячи задач в системе и команды, которые не хотят переучиваться. Больше половины бизнесов оценивают срок миграции в 1—2 года. С таким горизонтом легче решить, что «всё равно пока не горит». А уже горит. С 15 февраля 2024 Jira Server перестала поддерживаться — больше никаких апдейтов безопасности. Если вы пускаете снаружи людей без дополнительной прослойки типа корпоративного тоннеля или NGFW — остаётся спорить, создаёт ли Джира дыру в системе или ей является. Крякнутые версии тоже под вопросом относительно бэкдоров. Atlassian Marketplace заблокирован для РФ — плагины и интеграции с другим софтом отваливаются все эти годы. Для госкомпаний, компаний с госучастием, субъектов КИИ (Критическая информационная инфраструктура) и банков законодательно были чёткие сроки перехода на отечественное ПО. Jira прямо нарушает директивы ФСТЭК, Минцифры и указы Президента РФ. Есть сложности с аудитами и проверками — если планируется сделка или сертификация, проверку получится пройти только с серьёзными замечаниями. Админов по Джире всё меньше, а поддержка по мере разваливания стека всё нужнее.

https://habr.com/ru/companies/kaiten/articles/1038166/

#Atlassian #Jira #Confluence #Agile #миграция_данных #тасктрекеры #корпоративное_ПО #импорт_задач #автоматизация_процессов

In many organisations, status dictates behaviour more than value. Performative "busyness" often replaces genuine impact when quality is hard to measure. We must shift the status economy toward learning and candour to build real psychological safety.

Dive in: https://psychsafety.com/st-r-e-a-m-status-rules-everything-around-me/

#ProductLeadership #Agile

Your developers spend 60% of their week in meetings. Then you wonder why nothing gets shipped.

Here's the test: Does this meeting help us deliver good software faster? If you can't answer that in one sentence, cancel it.

No agenda? Cancel. No decision needed? Send a message. Everyone invited "just in case"? Cut the list in half.

Meetings are work. Bad meetings are waste.

#agile #softwaredevelopment

Alt...

NO AGENDA? CANCEL THE MEETING.

Top Links Automatically getting API difference diagrams in your .NET PRs (Morten Nielsen) Automating Intakes to the Awesome Copilot Marketplace (Aaron Powell) Introducing Syncfusion Toolkit for Blazor: Free Open-Source Blazor Components (Saravanan G.) Learn how to host your agents on Microsoft Foundry (Pamela Fox) TechBash CLI – A GitHub Copilot CLI skill that connects your … Continue reading Dew Drop – May 25, 2026 (#4675)

The ideal agile project doesn't start with a framework. It starts with stakeholders who shows up.

Not one who sends requirements and disappears. One who joins planning, gives feedback every iteration, and helps define what's valuable.

We tried both. When stakeholders vanishe, you're guessing. When they're in the room, you're building the right thing.

The biggest risk in any project isn't technical. It's a silent stakeholder.

#agile #softwaredevelopment

Alt...

YOUR BIGGEST PROJECT RISK? A SILENT STAKEHOLDER.

They’re also there to challenge the organisation a bit. Not aggressively, just enough to expose what’s getting in the team’s way. That part can feel a bit uncomfortable. #Scrum #Agile

How can you assess business value when outcomes are uncertain?

Business Value Floor 95 represents the 5th percentile of 100,000 simulated outcomes.

Consider prioritizing utility over profit (dm), leveraging Team Topologies' platform to enable teams, and recognizing the $8.8 trillion in demand-side value of open source.

➡️ https://www.eifel42.dev/post/business-value/

#BusinessValue #ProductOwner #ValueAtRisk #Agile #SoftwareDevelopment #OpenSource

Alt...

Business value distributions for the three feature hypotheses

»Is it possible to be…Too Nice?« https://bobgalen.substack.com/p/is-it-possible-to-betoo-nice #Agilist.in #Agile #Change #Lean #Kanban #Scrum

Nach etwas mehr als 50 Tröts stelle ich mich einmal vor:
Ich bin Peter ('Winni') Winninger aus #Mayen / #RheinlandPfalz und #neuhier. 👋
Beruflich bin ich als Usability and User Experience (#UX) Professional bei einer Softwareschmiede in #Koblenz unterwegs. Wir entwickeln Software für #Kommunalverwaltungen.
Daneben bin ich Co-Founder von #KoblenzDigital, Content-Marketing-Manager, Social-Media-Manager (IHK) und Fan von #barcamp `s , #Agile und #NewWork.

Your backlog has 40 items marked "Priority 1."

That's not a priority. That's a wish list with a label.

Priority only works at a single point in time. Tomorrow your customer calls with something new and the whole spreadsheet is waste.

Stop assigning priorities. Start defining order: What's next? What creates the most value right now? Do that. Then ask again.

#agile #kanban

Alt...

40 ITEMS MARKED PRIO 1. THAT'S NOT A PRIORITY LIST.

Neglecting your backlog graveyard of bugs isn't just a technical risk; it’s a strategic bottleneck. I’ve always believed that stability is a prerequisite for speed. When we treat fixes as a detour, we actually kill our ability to innovate.

Prioritise health here: https://www.prodpad.com/blog/when-stabilization-becomes-strategy/

#ProductStrategy #Agile

#Agile #Scrum #AgileTransformation #HealthcareAgile #SprintVelocity #TeamCollaboration #AgileCoaching #DevAgileLeadership #TrustInTeams #ContinuousImprovement (8/8)

#LINKSDERWOCHE 21/2026 | Produktivität, Lean, Agile, Politik und Gesellschaft

PRODUKTIVITÄT

Digitale Erschöpfung | Wie die künstliche Intelligenz Belastung verstärkt statt zu entlasten

Wer meine Links der Woche und auch Gedankenblitze im Block aufmerksam liest, dem dürfte sicherlich schon mehrfach aufgefallen sein, dass ich die KI-Ephorie nicht teile, sondern eher positiv-verhalten gegenüber der Technik bin. Der Grund ist simple und einfach, ich sehe zwar viele Möglichkeiten, dennoch ist die Erwartungshaltung viel zu hochgeschraubt und ich sehe auch, dass die Produktivitätzuwächs durch die negativen Folgen aufgefressen werden. Daher habe ich Marcus Raitners Blogartikel sehr aufmerksam gelesen. Er ist sehr differenziert und spricht aus meiner Sicht einige kritische Punkte an, die ich sehr ähnlich sehe. Der Einsatz von KI befördert die digitale Erschöpfung. Dazu mehr hier:

https://raitner.de/2026/05/digitale-erschoepfung-wieso-ki-wissensarbeit-intensiviert-statt-uns-zu-entlasten/

Wie KI dazu führt, noch mehr zu tun

Zur Vertiefung des Beitrags von Marcus Rainter bietet sich der etwas längere Artikel von Daniel Dubbel an. Auch er beschäftigt sich mit der Frage der Arbeitsverdichtung durch KI. Sein Fokus liegt jedoch auf einem anderen Aspekt. Er geht der Frage nach, weshalb die möglichen Produktivitätsverbesserungen im System regelrecht verpuffen, und macht die Führung verantwortlich. Daher war ich kurz versucht, den Beitrag unter Leadership und Management einzuordnen. Ich finde jedoch, dass die beiden Beiträge zusammen wahrgenommen werden sollten.

https://www.inspectandadapt.de/niemand-hat-beschlossen-dass-mehr-geht-es-passierte-einfach/

Obsidian | Plugins nutzen

Für Obsidian steht ein riesiges Biotop an möglichen Plug-ins aus der Community zur Verfügung. Ich nutze nur eine Handvoll, die ich mittlerweile sehr gezielt auswähle. Ähnlich der Empfehlung von Daniel Schimpke am Ende seines Artikels, erst zu überlegen, welches Problem man überhaupt lösen möchte. Viele Probleme lassen sich übrigens oft auch ohne Plugin lösen. Das hat den Vorteil, dass die Dinge einfacher gehalten werden. Was ich empfehle. Ich habe nur sieben Erweiterungen im Einsatz, von denen eine sogar gerade auf dem Prüfstand steht. Also tatsächlich eher sechs. Es gibt allerdings eine deutliche Schnittmenge mit den 13 im Artikel genannten Plugins.

https://www.kadaschi.de/13-obsidian-plugins-die-ich-wirklich-nutze/

Obisidan | Community neu aufgestellt

Über Thomas Mathoi habe ich eine Nachricht erhalten. Es gibt eine neue Obsidian-Community. Dort findet man viele Hilfen. Die Community wurde neu organisiert und soll jetzt übersichtlicher sein. Ich hatte noch nicht die Gelegenheit, mir das anzusehen. Allerdings klingt es sehr interessant und ich hoffe, dass ich jetzt schneller passende Lösungen finde, wenn ich eine Herausforderung zu meistern habe.

https://www.mathoi.at/2026/05/21/die-neue-obsidian-community/

Ankommen | Das Gefühl etwas wichtiges zu tun

Ivan Blatter hat wieder einmal eine großartige Folge seines Podcasts veröffentlicht. Diesmal dreht sich die Frage, die er beantworten will, um das „Ankommen“ als Gefühl. „Ankommen” bedeutet in diesem Sinne nicht, fertig zu werden, sondern das Gefühl zu haben, dass das, was wir tun, wichtig ist. Er erklärt dieses Gefühl zu einer Entscheidung. Eine Entscheidung, die wir selbst treffen. Er definiert vier Entscheidungen, die wir treffen müssen:

• Hör auf, fertig werden zu wollen
• Beurteile den Tag nicht nach Quantität
• Entscheide, was nicht auf die Liste kommt
• Baue kurze Boxenstopps ein

https://share.transistor.fm/s/358edb99

Lernfähigkeit | Weshalb sich selbst hinterfragen vorwärts bringt

Mit seinem Beitrag erinnert Dan Rockwell mich daran, dass Lernfähigkeit oft damit beginnt, sich die Frage zu stellen: „Wie kann ich besser werden?” Das wiederum setzt voraus, anzuerkennen, dass man nicht alles weiß. Ganz im Sinne von Sokrates, der sich als Wahrheitssuchender für unwissend hielt. Mit anderen Worten: Das Streben, sich weiterzuentwickeln, beginnt damit, demütig anzuerkennen, dass man – selbst als weiser Mensch – noch mehr lernen und besser machen kann. Wer sich konsequent selbst hinterfragt, entwickelt sich weiter. Irgendwie muss ich jetzt an Kaizen denken.

https://leadershipfreak.blog/2026/05/19/the-best-ability/

LEAN

Kaizen | Weshalb Kaizen mehr als ein Prozess ist und weshalb wir ins schwer damit tun

Tim Themann hat sich daran gewagt, hinter „Kaizen” zu blicken und ideengeschichtlich aufzuarbeiten, weshalb „Kaizen” eine Haltung darstellt und weshalb wir uns in unserem westlich geprägten Kulturkreis mit dieser Haltung so schwer tun. Hut ab! Ich weiß, dass er es sich nicht einfach gemacht hat, denn ich durfte vorab eine erste Fassung lesen und Feedback geben. Für mich war der Artikel sehr spannend und aufschlussreich. Ich hoffe, dass es euch auch so geht.

https://die-computermaler.de/warum-kaizen-eine-haltung-ist-und-kvp-nur-ein-prozess/

Kaizen | Keine Methode, kein Prozess sondern Haltung

Auch Götz Müller greift das Thema Kaizen auf. Er versucht zu erklären, was Kaizen nicht ist. Es ist eine Haltung. Keine Methode. Kein Prozess. Interessant dabei ist, dass er Kaizen als Akronym nutzt. Hinter jedem Buchstaben steht ein Begriff, der die oft gelebte Realität darstellt und im Prinzip verdeutlicht, dass Methoden und Prozesse kein gelebtes Kaizen sind.

https://www.geemco.de/artikel/was-kaizen-nicht-ist-bzw-sein-sollte

Durchschnittswerte | Weshalb sie nicht immer zielführend sind

John Knotts Beitrag beleuchtet eine Thematik rund um Metriken, die sicherlich einigen bekannt vorkommt: Durchschnittswerte sind nicht immer gute Indikatoren und Referenzwerte. Dies gilt insbesondere bei Prozessverbesserungen. Das heißt jedoch nicht, dass wir Durchschnittswerte verteufeln sollen, sondern es gilt wie so oft – nicht nur im Umgang mit Metriken – reflektiert-kritisch hinzuschauen und immer auch zusätzliche Informationen einfließen zu lassen.

https://blog.gembaacademy.com/2026/05/22/the-trouble-with-averages/

AGILE

Product Owner | 10 Warnsignale, bei denen wir genau hinsehen sollten

In seinem folgenden Blogartikel versucht Simon Flossmann, Indikatoren zu nennen, anhand derer sich erkennen lässt, ob die Rolle des Product Owners gut besetzt wurde. Allerdings möchte ich zur Vorsicht raten, hier vorschnell von den Indikatoren auf die betreffende Person zu schließen. Meine Erfahrung hat mich gelehrt, auch auf das „System” zu achten. Denn es sind oft auch die Zwänge des Systems, die zu einigen der „Fehlentwicklungen” führen, die er in seinem Blogartikel thematisiert. Die genannten Indikatoren bedeuten letztendlich, genauer hinzusehen und Ursachenforschung zu betreiben.

https://www.scrum.org/resources/blog/liebe-fuhrungskrafte-10-warnsignale-dass-euer-product-owner-euch-gerade-800000-eur-statt-100000-eur-kostet

Work in Progress | Viele parallele Arbeit bedeutet geringer Return of Invest

Ich weiß nicht, wie oft ich schon skeptisch auf Scrum- und Kanban-Boards geschaut habe. Skeptisch, weil ich sehr viel Arbeit auf den Boards gesehen habe. Arbeit, die aber nicht abgeschlossen war. Arbeit, die parallel stattfand. Fast genauso wie im Blogartikel von Rudolf Gysi. Vielleicht bin ich genau deshalb ein Freund der Begrenzung paralleler Arbeit geworden. Mehr Fokus, erst abschließen, dann das nächste Thema angehen. Einfach auch, weil nur so sichtbar wird, ob und wie wir einen Mehrwert erzeugen.

https://agilereflection.org/while-wip-roi-0/

Story Splitting | Kleine Storys sind besser als große

Ich bevorzuge kleine Anforderungen in Form von User Stories oder Job Stories. Kleine Losgrößen sind schneller abgeschlossen, ermöglichen schnelleres Lernen und liefern früher Nutzen. Die Reflexions- und Lerntaktung wird kürzer, sodass wir früher erkennen, wo Verbesserungspotenziale bestehen oder wo wir uns geirrt haben. Daher sollte man das Story-Splitting nicht unterschätzen. Mike Cohen, ein Urgestein der Agilität, gibt hierzu ein paar brauchbare Tipps aus der Praxis.

https://www.mountaingoatsoftware.com/agile/user-stories/story-splitting-how-to-split-user-stories-so-teams-can-finish

Problem Statement | Die Herausforderung definieren

Ausgangspunkt jeder Analyse ist das Verständnis des Problems. Hier kann das „Problem Statement” aus dem Design Thinking (ich kenne eine ähnliche Methode auch aus anderen Kontexten, beispielsweise dem TPS) Hilfestellung liefern. Dabei geht es darum, zu verstehen, wann und in welchem Kontext ein Problem mit welcher Wirkung entsteht und auftritt. Einfach und effektiv. Aber auch effektiv. Vielen Dank an Lars Richter, der es prägnant zusammengefasst hat.

https://scamper.blog/problem-statement/

POLITIK UND GESELLSCHAFT

77 Jahre GG | Vermächtnis und Verpflichtung

Am 23. Mai 2026 ist das Grundgesetz 77 Jahre alt geworden. Für mich war das ein Grund, am Samstag zu feiern – wie übrigens jedes Jahr zum Geburtstag des GG. Denn ich halte unsere Verfassung nicht nur für ein besonderes Dokument, sondern auch für eine Verpflichtung gegenüber nachfolgenden Generationen in Deutschland, Europa und der Welt. Eine Verpflichtung, die es mit Leben zu füllen gilt und auf die wir auch stolz sein dürfen. Eine Verpflichtung, die bedeutet, dass wir das Vermächtnis in Ehren halten und gegen seine Gegner verteidigen müssen. Alfons Pieper hat es in dem folgenden Artikel, wie ich finde, gut zum Ausdruck gebracht.

https://www.blog-der-republik.de/wehrhafte-demokratie-77-jahre-grundgesetz/

Höchste Zeit | Weshalb demokratische Kräfte geschlossen gegen die AfD stehen sollten

Kleiner Einschub: Sollten sich aktive Befürworter und Anhänger der „Nicht-Alternative” unter meinen Lesern befinden, kann ich gerne auf sie verzichten. Wie übrigens auf alle Gegner der freiheitlich-demokratischen Grundordnung. Wie Christian Wolff bin ich der Meinung, dass es höchste Zeit ist, dass sich alle demokratischen Fraktionen entschieden gegen die Nicht-Alternative stellen. Jetzt und ohne Diskussion. Bevor es zu spät ist. Sonst werden wir bald keinen Geburtstag des Grundgesetzes mehr feiern können.

https://www.blog-der-republik.de/hoechste-zeit/

Schreckenszenario | Wenn die AfD in Sachsen-Anhalt regiert …

Dass die Gefahr derzeit besonders groß ist, die von der Nicht-Alternative ausgeht, wird bei den anstehenden Landtagswahlen in mehreren Bundesländern, wie beispielsweise Sachsen-Anhalt, sichtbar. Die Amadeu-Antonio-Stiftung beschreibt in einer aktuellen Broschüre, die zum Download bereitsteht, sehr eindrücklich das Szenario, das uns sehr wahrscheinlich erwarten wird. Ein Szenario, vor dem selbst die Gewerkschaft der Polizei vor einigen Tagen eindringlich warnte. Die einschlägigen Wahlprogramme deuten darauf hin, dass dieses Szenario mehr als denkbar ist.

https://www.amadeu-antonio-stiftung.de/szenario-zur-schicksalswahl-das-droht-wenn-die-afd-in-sachsen-anhalt-regiert-166419/

تسعى كل من Agile و DevOps لتحسين إنتاجية التطوير، لكنهما يختلفان في نقطة المركز:

🔹 **الهدف** – Agile يركز على التكيف السريع والتواصل داخل الفريق؛
🔹 **العمليات** – DevOps يدمج التطوير والتشغيل لنسخ أسرع وأأمن.

الاختلاط المثالي يخلق دورة إنتاج متكاملة: Agile يحدد الأولويات، وممارسات DevOps تضمن تسليم مستمر.

#تقنية #Agile #DevOps #تطوير_البرمجيات #مستقبل_البرمجة

🔗 https://news.google.com/rss/articles/CBMiekFVX3lxTFBSenh5cVV1TzBOU05zQ015UHdWTjRPeXhOSHV4cHJYRExwbjBpSk54Nk5CTjdYMWl0MGc2S2JKSDAzQm5vckpfNlRoWWN1d3JTSlVKMENpUUZPXzkzYmo0em91UU1abHJ1S0FuTkUxdGxkZlJJa3NMVm9B?oc=5

5 Whys — когда «починили» не помогает 🔍

«Баг вернулся третий спринт», «прод упал в пятницу», «снова не успели в цель» — знакомо? Часто команда чинит симптом, а корень остаётся.

5 Whys (пять «почему?») — метод Тайити Оно из Toyota. От факта «что случилось» через цепочку «почему?» к системной причине, которую можно убрать, а не к «Вася не успел».

В новом материале на RetroPoint:
• чем 5 Whys отличается от обычного ретро на спринт 🎯
• когда формат уместен (инцидент, повторяющаяся проблема)
• как провести расследование за ~45 минут без поиска виноватых 🤝
• типичные ловушки (остановились на 3-м «почему?», ушли в гипотезы)
• пять колонок на доске от «симптома» к «корню» с готовым шаблоном

👉 https://retropoint.ru/news/five-whys-retrospective

Плюс страница техники и создание доски по шаблону: https://retropoint.ru/techniques/5-whys

Если в команде устали от «починили — снова сломалось», то попробуйте на ближайшем инциденте 🚀

#RetroPoint #тимлид #1to1 #управлениекомандой #retrospective #ретроспектива #agile #scrum #kanban #teamlead #it #itleads #teamleadthings #команда #retroonline #просторетро #oneonone #one2one #pokerplanning #ретро #agile #scrum #realtime #swot #okr #5whys

#Agile #Innovation #MentalModels #FirstPrinciples #ProductDevelopment #AgileHardware #Strategy #LeanStartup #SystemsThinking #Leadership (3/3)

"When will the project be done?"

Wrong question. A product is never done, you just stop investing in it.

The real question is: What's the smallest version we can ship that actually works end-to-end?

Not a prototype. Not a mockup. A real thing a real user can use.

Then ship it. Learn. Plan the next version. Repeat until the budget runs out or the market moves on.

#agile #softwaredevelopment

Alt...

WHEN WILL IT BE DONE? WRONG QUESTION.

Estratégias para Aplicações Modernas by Jaime Nagase is free with a Leanpub Reader membership! Or you can buy it for $8.99! https://leanpub.com/modern-applications-strategy-pt-BR #cloud_computing #software_architecture #digital_transformation #amazon_web_services #agile

Почему классическое управление проектами часто не работает в IT-продуктах

За годы работы в project и product management мне довелось работать с проектами самых разных типов: от государственных и образовательных инициатив до сложных IT-продуктов и создания SaaS-платформ. И один из интересных профессиональных выводов, который я сделала за это время, касается выбора подхода к управлению проектами. Waterfall и Agile уже много лет остаются двумя основными методологиями в индустрии. О них написаны сотни книг и статей. Однако на практике вопрос обычно не в том, “какая методология лучше”, а в том, насколько она соответствует типу продукта, уровню неопределенности внутри проекта, задачам бизнеса. Когда Waterfall действительно работает Традиционная Waterfall-модель строится вокруг последовательных этапов: сбор требований → проектирование → разработка → тестирование → внедрение. Такой подход дает бизнесу несколько важных преимуществ:

https://habr.com/ru/articles/1038682/

#waterfall #agile #product_management #project_management #управление_проектами #управление_продуктом #разработка #методологии_разработки #методологии_управления

Das Agile Manifest ist 25 Jahre alt und passt auf eine halbe Seite. Trotzdem kennen es die meisten nicht, die „agil arbeiten". In dieser Folge gehe ich die vier Werte durch und stelle die Frage: Brauchen wir wirklich mehr als das Manifest?

#agile #podcast #agilemanifest

Unpopular opinion: The Agile Manifesto wasn't written so developers could have a nicer work environment.

It was written so customers could survive in a market that the internet had just blown wide open.

17 people met in Utah in 2001 because waterfall couldn't keep up with market speed. The goal was: deliver software that gives customers a competitive edge fast.

Better team culture? That's a side effect. A welcome one. But not the point.

#agile #agilemanifesto

Alt...

THE AGILE MANIFESTO WASN'T WRITTEN FOR YOU.

Next time your perfect framework feels like a gag, ask: We traded a thinking tool for a muzzle?

#PsychologicalSafety #TeamDynamics #Leadership #MentalModels #Agile #ThinkingTools #TeamCulture #DecisionMaking #Management #Innovation #OWL (5/5)

Work–Feedback Loop v2.0 is here.

What changed: Feedback needs a reference point: the guiding intent. Without it, no comparison. Without comparison, no learning.

Also: no more formulas, but a running example throughout. Clearer, more tangible, more consistent.

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

#agile #feedback #organizationaldevelopment #learningability

Work–Feedback Loop v2.0 ist da.

Was sich geändert hat: Feedback braucht einen Referenzpunkt: die Handlungsabsicht. Ohne sie kein Abgleich, ohne Abgleich kein Lernen.

Dazu: keine Formeln mehr, dafür ein durchgängiges Beispiel. Klarer, greifbarer, konsequenter.

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

#agile #feedback #organisationsentwicklung #lernfahigkeit

Roadmaps create certainty illusions—outcomes are unpredictable.

Feature Hypotheses Simulation with Monte Carlo and Jupyter helps product owners estimate value, risk, portfolio balance, and assumption impact.

Not about perfect prediction: focus on discussing uncertainty before investing.

https://eifel42.de/post/feature-hypotheses-simulation/

#ProductOwnership #Agile #RiskManagement #MonteCarlo #JupyterNotebook #Python #SoftwareDevelopment

The moment you turn toward learning instead of sitting in the sting, you start converting that raw disappointment into something you can actually use.

That's the shift. The obstacle stays exactly where it is, but your relationship to it doesn't have to.

Go forward.

#BusinessStrategy #Leadership #Entrepreneurship #Agile #ContinuousImprovement #LeanStartup #ProfessionalGrowth #BusinessTips #StartupLife #Resilience (3/3)

Measuring the wrong thing

Process improvement requires measurements. How do you know what to improve if you can’t see where things aren’t working, and how do you know you’ve made the right change without seeing those numbers going in the right direction?

But measuring doesn’t mean you’re measuring the right thing, and measuring the wrong thing can lead to the wrong outcomes, and can be very harmful (see Liz Keogh’s talk on perverse incentives )

The key to the success of any metric is that it is owned by the team so they have complete control over the changes needed to affect it, so they feel ownership, and that improving the metric has a useful business outcome.

Metrics that I’ve found useful in the past include:

Number of bugs introduced by a release.

This is a tricky one to work with because it can easily be a perverse incentive, and the feedback cycle can be slow, especially with the usual 6-12 month release cadence. However, on one waterfall project I took over there was a strong negative perception of the quality of the code, and big count was a useful proxy as the customer had access to JIRA so the big list was already visible. Reducing this number was a combined effort where testers and developers had to approve requirements, developers and testers invested in automated testing at all levels, and testers joined the developer daily stand-up in order to catch bugs before they were released “have you checked that page in Welsh?“, “We found problems on that page last time because IE was too slow“.

Number of releases per month.

On an agile project we noticed that releases were getting held up because testing was slow and produced a lot of rework, which were then tested against more features that had been pulled from the backlog, increasing testing time. Each release also took half a day, so we had to schedule them carefully.

So we set a goal of focusing on releases for a month and measuring how many we did. There were other measures within that, such as monitoring work in progress on the testers, time taken to do a release, and cycle time from start of development to live release, but they all drove the big number, visible to the whole company, of more quality releases.

Questions answered per day.

This can be a very useful metric for research projects, especially when following a fail fast approach, when you want to prove something can’t be done before you invest in doing it. In order to do that, you need lots of questions with quick answers, to accelerate learning. Any answer, positive or negative, is progress. It means we have learned something.

“I cheerily assured him that we had learned something.
For we had learned for a certainty that the thing couldn’t be done
that way, and that we would have to try some other way.” – Thomas Edison

Age of Pull Requests

Successful agile projects rely on peer review, either via pairing, or a formal review process such as git PRs (and I won’t discuss that in this post). However, when we started working with these on one project, we discovered that we were building up a large debt of Work In Progress because the team wasn’t incentivised to review each other’s code, so one of the developers set up a nag bot for any PR older than 4 days. It lasted 2 weeks before it was no longer needed.

What about you?

What metrics have you used to incentivise the team? What problem were you trying to solve, and did the metric work?

When your sprint goals are pulled by real needs instead of pushed by guesses, your small team stops doing busywork and starts making things that actually matter.

#JustInTime #SprintGoals #Agile #Education #EdTech #SmallTeam #Productivity #Scrum #AgileEducation #ToyotaProduction #LeanThinking (8/8)

Your team has 4 certified Scrum Masters, a SAFe implementation, and a Jira board with 200 columns.

But nobody dares to say "I made a mistake" in the Daily.

Allen Holub nailed it: "Without psychological safety, respect, and trust — none of what follows is possible."

No framework will save a team that's afraid to speak up. Fix the culture first. The process is secondary.

#agile #leadership

Alt...

NO FRAMEWORK SAVES A TEAM THAT'S AFRAID TO SPEAK UP.

Top Links Plan Before You Build: Introducing the Plan agent in Visual Studio (Rachel Kang) Windows App SDK Version 2.1.3 Stable Release Notes and Windows App SDK Version 2.1 Experimental 8 (2.1.4-Experimental8) Release Notes (Microsoft Learn) Announcing Agent Governance Toolkit MCP Extensions for .NET (Jack Batzner) PowerShell is now notarized and hardened for macOS (Jason … Continue reading Dew Drop – May 22, 2026 (#4674)

Reducing waste by making your goals visible

Metrics are good, but they’re not enough. If you want metrics to drive change, they need to be visible. Not just to managers, but to the team. The right metrics, visible to the team, drive improvement. Visible only to management, drive control. Visible to no-one, drive nothing.

Good metrics need to be communicated clearly and persistently. There needs to be a continual focus on whatever the priorities are. If it’s out of sight, it will be out of mind. If it’s digital, rescue it from individual screens that are easily covered up.

It’s why kanban boards can be so effective when used well. It’s easy to see when the team is taking on too much work, or where there’s a queue waiting for tasks to be pulled. The board radiates information to the team, about how much work is in progress, and who is working on what. It becomes the centre of communication about tasks and removing waste. Make it physical, if you like, and the team is co-located. Use Post-its. Let dog ears and grubbiness indicate age. Do your backlog pruning via environmental effects – older & more used notes are more likely to fail behind the radiator and get lost.

Put (work-related) personal tasks on there too. Keep yourself honest. It’s good for the team to know you’re reviewing CVs, or preparing for that strategy meeting, or learning Haskell the hard way.

But keep it clear. Use a Kanban if WIP or queueing are your key metrics. Use Scrum if velocity and deadlines are key. Use a dashboard if that makes your priorities and progress clearer.

And make sure your key priorities (4 or less please) are visible at a glance for the team, and easy for anyone in the team to explain to a passerby. They don’t need detail, but pointing to a big pile of waiting tasks to justify recruiting a new tester is a clear message.

Removing impediments sounds tidy on paper. In reality it’s messy. Sometimes it’s a process thing, sometimes it’s people, sometimes ... it depends. #Scrum #Agile

Agile Is Dead

As a follow up to DDD Scotland 2011, I want to thank everyone who joined in. It’s time to reveal my ulterior motive : I did it all so I could get a blog post 🙂 So thanks to everyone who helped write the Agile Is Dead Mind Map – please feel free to join in the discussion below.

Agile’s been bouncing around in my head for a while given that it’s reached its tenth birthday, and a lot of people are talking Agile, but its not the agile I see in The Agile Manifesto. It’s a silver-bullet snake-oil leech that throws out agile words and terminology but without the guts to actually make agile work. It’s an agile that doesn’t challenge managers or clients, that sticks to deadlines and a list of features, but promises faster, cheaper development.

It doesn’t work.

And don’t call it agile.

Agile works when the customer understands that it’s an interactive process, when there is a functional feedback loop and when the plan is flexible enough to adapt to changes by dropping features or extending deadlines. If you’re not doing that, you’re not agile.

But, you can be successful without being agile, you can do functional testing, you can have a CI server, you can do team priorities, and stand-up meetings. But until you have feedback loops, for each developer, for each feature, and for the project, you’re still playing the old game. It’s an easier route. It’s more comfortable for everyone to have a defined role, for everyone to work from a fixed position. And that’s fine. Just don’t call it agile.

Procedures and tools provide comfort, I know that, you know that. Budgets drive your business, procedures help you budget, and procedures mitigate risk. If it’s signed off, it’s not your fault. But then, someone must have signed off the Ariane 5 too. Would you rather deliver software or paperwork? Is paperwork your protective shield?

If you’re a manager, do you trust your developers? Do you trust them to take decisions, to talk to the client, to deliver professional quality? As a professional developer, that’s the teams I want to work in, and I feel privileged when I get that chance, because those projects always work out smoothest in the end, although they can be the hardest to set up.

If you’ve tried agile and failed, did you really try it? Did you trust the developers to deliver, did you trust your manager to keep things running, did you trust the client to give you the feedback you needed? Did you trust yourself and your team to be honest?

Agile, the word, has been hijacked. It’s dead but still walking. What matters is the philosophy behind it. And it’s not easy. No profession is. Are you a professional or an unskilled cog in an assembly line?

I don’t give easy answers. I wanted to become a developer because the thing that drives me is solving problems. And these aren’t problems that stay solved. HTML 1.0 didn’t solve everything, that’s why we have HTML5. Project management is a problem you need to solve on every project. Every project you’ll learn something new, and you’ll face new challenges. I cannot prescribe a solution, because I don’t know your project, and that’s how agile works. You have to adapt to your surroundings. After all, you’re only human.

If you want to be agile, talk to your team, and don’t let your ego stifle peer reviews, paired programming or feedback sessions. And if anyone does let things get in the way, staple a copy of the Agile Manifesto to their head and blow raspberries at them. Or go and find out about Programmer Anarchy and ask if you or your team could cope with self-directed project management, just like anyone volunteering for open source. If not, why not?

Becoming a technical lead: Trust your team

When I first became a technical lead, one of my biggest challenges was giving up control. It wasn’t a matter of not trusting my team technically but I didn’t want to overload them, so I took on all the planning, all the customer interaction, and all the other jobs that I felt had distracted me from the job of writing code.

I was wrong.

I needed to let my team in, because they had ideas that I didn’t, they had capacity whereas I was a bottleneck. I was holding up my team.

But I needed to be sure that coding standards were followed and quality was maintained. You know who else cares about that? My team. I made it their responsibility to ensure that the code met standards, and pushed out code reviews. I put internal documents at the same level as code. Anyone can edit, but everyone can review, or veto.

I asked for honest feedback in retrospectives, and implemented changes, so they could trust that I was looking out for them, and I set them goals to improve, alongside the feature work : “can we release twice a week?” (challenge – automate the pain points); “can we halve the bugs found in testing” (challenge – better unit tests)

And the more I trusted them, with support, and understanding their limits, the better they performed. I’ve also worked with managers who don’t trust their teams. Those teams don’t work so well.

If you don’t trust your team, they’re not your team. They’re just people who work beside you. What are you doing today to foster trust?

🛠 Доработали доску по вашим заявкам.

Слушаем письма в поддержку и в каждом релизе закрываем сразу пачку накопившихся пунктов.

Что появилось:
— Action items со связкой 1-2-1 ↔ доска: имя ответственного на доске — кликабельный бабл, ведёт в нужную комнату 1-2-1; в 1-2-1 у задачи — обратная ссылка на ретро-доску.
— «Готов» и счётчик N из M в шапке доски: фасилитатор видит, что команда готова двигаться дальше, и может не ждать таймера.
— Скрытие и маскировка карточек по колонкам: оставляем в фокусе одну зону, остальное под blur; чужой текст замаскирован, чтобы не «просвечивал».
— Счётчики комментариев и оставшихся голосов прямо у иконок.
— 🔔 Мелодия таймера на выбор: мягкие сигналы или гонг — отдельная настройка на доске.
— Права гостей на правки чужих карточек, общая сессия между вкладками и аватары через Gravatar.

👉 Подробно: https://retropoint.ru/news/board-workspace-may-2026

#RetroPoint #тимлид #1to1 #управлениекомандой #retrospective #ретроспектива #agile #scrum #kanban #teamlead #it #itleads #teamleadthings #команда #retroonline #просторетро #oneonone #one2one #pokerplanning #ретро #agile #scrum #realtime #swot #okr

Dew Drop Weekly Newsletter 484 - Week Ending May 20, 2026

https://zc.vg/h6WSi?m=0

#dewdrop #newsletter #javascript #aspnetcore #azure #css #cpp #windowsdev #winui #dotnet #csharp #ai #mcp #devops #agile #gamedev #appdev #podcasts #m365 #sqlserver #data #powershell #python

Processes upon processes: the JIRA trap

It is fashionable to hate on JIRA for software developers. Project Management made spaghetti. It has its faults, but the biggest issue is what it allows. It’s not opinionated, so any user can define any process to follow. It’s a perfect machine for generating red tape, or paper clips.

Because every time something goes wrong, the natural instinct is to add a new process, a new safety net, to make sure it doesn’t happen again [see Agile is Dead blog post]. And once added, they’re very difficult to remove.

So we get processes upon processes, the simple rhythm of a ticket lifecycle or of a sprint adorned with Deferents and Epicycles as we try and tame ever-increasing complexity with more text boxes and more statuses.

Complexity cannot fix complexity. But who has time for simplicity? This is the fundamental paradox of enterprise that Agile, and every “new big thing” is meant to resolve: complexity is added to reduce risk, but the complexity itself creates risk, and makes the risk harder to name, harder to spot, and harder to recover from if it is realised.

We have the 5 whys, the blameless retrospectives. And whilst the intention is sound – blame the system, not the individual – the solution is often to add new trinkets around the edges of the system. And reinforce that the system is the only way. They mistakenly put process at the centre, and ask the people to support the process, whereas the process should support the people.

But of course, this creates the shadow IT departments and the “non-compliant” centres. One place I worked had a strict policy that no one has admin rights because that fixed a problem lost to the mists of time. I understand the benefit of the policy, but at the time all our developers were working on IIS and couldn’t develop the websites we were paid for without having admin access on our machines. And so we had dispensations and workarounds until ASP.net core fixed the underlying issue of requiring admin access to serve web content.

Some companies stack procedure on top of procedure because the project is the centre of their universe rather than business value. And every company is in danger of falling into that trap as they treat risk management as risk elimination, instead of mitigation or recovery. They condemn every project to the tarpit of success, sinking below the crushing weight of process where sunlight cannot penetrate.

You will never have a process that prevents the next failure. You need a process to detect and recover, and you need to remove 99% of the “just in case” procedures from your process.

You don’t need to double-check the prime DVD copy before sending it for distribution, because no one has a DVD drive on their servers. You don’t need to change the admin passwords when someone leaves because there should not be an admin account that isn’t attached to a user. Eliminate the process, because every process you have is a process someone can forget. The best process is one you don’t need because the risk it mitigates cannot be represented by the system.

Either accept that you are not the centre of the universe and rewrite your rules to understand that you merely orbit the sun like so many others, or live out the fantasy that you are special, that your problems are unique, and add deferents on top of epicycles when the universe tries to disabuse you of that notion.

You can’t control the universe, only how you react to it. So don’t use JIRA to enforce pi to be 3.2.

Frage an alle, die „agil arbeiten": Wann habt ihr das Agile Manifest das letzte Mal gelesen?

Nicht gehört. Gelesen.

Vier Werte. Eine halbe Seite. 25 Jahre alt. Und die meisten kennen den Scrum Guide besser.

Kein Wunder, dass wir Rituale ohne Seele haben.

Das Manifest reicht. Alles andere sind Implementierungsdetails.

https://no-bullshit-agile.de/nbak02-agiles-manifest-immer-noch-die-basis.html

#Agile #AgileManifesto #NoBullshitAgile #Podcast

Alt...

AGILES MANIFEST IMMER NOCH DIE BASIS

Your 5-Minute Win: Right now, grab a pen. Write one sentence about something you built today. Not what went wrong. What you made. Even if it's small. A line of code. A clean desk. A kind word. Write it down. Keep it where you see it.

Go Forward: You chose to create instead of complain. That's the shift. #BusinessStrategy #Leadership #Entrepreneurship #ContinuousImprovement #Agile #LeanStartup #ProfessionalGrowth #Productivity #StartupLife #TechBusiness (2/2)

"Velocity is a stupid metric" - the best thing I read on LinkedIn for a long time.

#Linkedin #agile #linkedinlunatics #scrum

RE: https://hachyderm.io/@trondhjort/116617159142908240

Entwickelnde Personen MÜSSEN Kontakt mit den nutzenden Personen haben.
Sonst entsteht Verschwendung auf verschiedensten Ebenen.

Scrum Master, die "das Entwicklungsteam" von der "Außenwelt" abschirmen, haben ihren Job nicht verstanden.
Wirklich nicht.

#Scrum #Agile

#agile boosted

Trond Hjorteland » 🌐 2026-05-22 / 2026-05-26
@trondhjort@hachyderm.io

Organisational Dysfunction of the Day

The customer we never met

Context: Context: The team is building a product. They have a backlog, a product owner, and a roadmap. A user story describes what users need. Personas represent who those users are. Analytics track what people do. Every few months, there is a user research report from the UX team. The team works hard, ships regularly, and hits their sprint goals. They have never spoken directly to a customer, though. The product owner does that, and the UX researcher. But the engineers, the people making hundreds of small decisions every day that shape the product, have not. They are building for an abstraction. A persona on a wall, a ticket in Jira, a data point in a dashboard.

OST explains: An open system maintains its health by actively engaging with its environment. For a product team, the primary environment is the people using what they build. The DP1 bureaucracy is a closed system and mediates that relationship through roles: the product owner translates customer needs into requirements, the UX researcher translates behaviour into insights, and the engineer receives the output of both translations. Each translation loses something. The judgment, the context, the friction, the moment when a real person says something that changes how you understand the problem entirely. In DP2, the group owns the whole task, which includes understanding who it is for. Teams with direct customer access make qualitatively different decisions than teams working from second-hand accounts. Not because engineers are better researchers, but because unmediated contact with the environment is not a nice-to-have. For an open system, it is the condition for staying alive.

#OpenSystemsTheory #SocioTechnical #OrgDesign #agile

Organisational Dysfunction of the Day

The customer we never met

Context: Context: The team is building a product. They have a backlog, a product owner, and a roadmap. A user story describes what users need. Personas represent who those users are. Analytics track what people do. Every few months, there is a user research report from the UX team. The team works hard, ships regularly, and hits their sprint goals. They have never spoken directly to a customer, though. The product owner does that, and the UX researcher. But the engineers, the people making hundreds of small decisions every day that shape the product, have not. They are building for an abstraction. A persona on a wall, a ticket in Jira, a data point in a dashboard.

OST explains: An open system maintains its health by actively engaging with its environment. For a product team, the primary environment is the people using what they build. The DP1 bureaucracy is a closed system and mediates that relationship through roles: the product owner translates customer needs into requirements, the UX researcher translates behaviour into insights, and the engineer receives the output of both translations. Each translation loses something. The judgment, the context, the friction, the moment when a real person says something that changes how you understand the problem entirely. In DP2, the group owns the whole task, which includes understanding who it is for. Teams with direct customer access make qualitatively different decisions than teams working from second-hand accounts. Not because engineers are better researchers, but because unmediated contact with the environment is not a nice-to-have. For an open system, it is the condition for staying alive.

#OpenSystemsTheory #SocioTechnical #OrgDesign #agile

A CPO told me: "I don't care if your standup takes 10 or 20 minutes. I care if you learn from what went wrong."
Meanwhile, middle management is obsessing over story points, sprint velocity, and whether the Daily started on time.

The C-Level wants outcomes. Your process police wants compliance.
Stop reporting rituals. Start reporting what you learned and what you'll do differently.

#agile #leadership

Alt...

THE C-LEVEL WANTS OUTCOMES. YOUR PROCESS POLICE WANTS COMPLIANCE.