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.
Wird das Agile doch wieder in Prozessen ertränkt? (Prof. Dr. Gunter Dueck)
https://youtube.com/watch?v=uO8nEd4CY2s&is=8w2mvN7Dfr7co0kz
#agilebarcamp #agileleipzig #Agilität #gunterdueck #GuntherDueck #agile
Next Barcamp am 8. Und 9. OKTOBER 2026 IN Leipzig
Habr » 🤖 🌐
@habr@zhub.link
«У вас не Agile» — сказал agile-коуч
У вас идёт цифровая трансформация? К вам пришёл Agile-коуч и рассказывает, как вам правильно работать? Вы разработчик и считаете Agile бредом, который придумали менеджеры? Тогда добро пожаловать под кат.
https://habr.com/ru/articles/1088350/
#agile #трансфорация #agileманифест #agile_development #agile_manifesto #agile_manufacturing #thoughtworks #extreme_programming
Explore https://scottgraffius.com for unique resources and actionable insights on #technology and #business, including #AI, #Agile, #ProjectManagement, #Teamwork, #Leadership, and more. Here's an example:
🔗 Strategic alignment talk at PMI Silicon Valley: https://scottgraffius.com/blog/files/scott-m-graffius-speaking-at-pmi-silicon-valley.html
Photo by Pixabay on Pexels.com
Politik muss agiler werden. Sie sollte iterativ und inkrementell arbeiten – sowohl in der operativen als auch in der strategischen Umsetzung. Stellt euch vor, Gesetze würden wie Software-Updates in kleinen Schritten getestet und angepasst. Wobei geprüft wird, ob die Erwartungen und Annahmen mit der tatsächlichen Wirkung überprüft werden.
Dafür gibt es eine Unmenge an methodischen Ansätzen, die sich adaptieren lassen. Ich habe mir dazu schon in der Vergangenheit immer wieder Gedanken gemacht, auch im Blog des Forums Agile Verwaltung z. B. in einer Kombination aus Scrum mit Bürgerräten oder dem Einsatz von OKRs in der strategischen Steuerung. Gerade denke ich darüber nach, wie auch Obeya in diesem Kontext sinnvoll Verwendung finden könnte.
Es ist fast schon schade, dass diese Ideen außerhalb der agilen Blase in der Politik kaum Fuß gefasst haben. Das ist sicherlich auch – nicht nur – den Mechanismen des Parteienwettbewerbs und der Aufmerksamkeitsökonomie geschuldet.
Ich finde das persönlich sehr schade. Ich würde mir mehr Austausch wünschen. Vielleicht liest der eine oder andere politische Entscheidungsträger, wie beispielsweise Gemeinderäte, Landtags- oder Bundestagsabgeordnete, sogar Abgeordnete im Europäischen Parlament, hier in Toms Gedankenblog mit und fühlt sich angesprochen. Das würde mich freuen. Ich bin offen für einen Gedankenaustausch.
#Agile #Bundestag #Europaparlament #Gemeinderat #Landtag #Politik #ScrumI blog from time to time and hope people find them useful. Watch this link https://www.linkedin.com/in/trondhjort/recent-activity/posts/ or this space for posts on #socioTechnical, #OpenSystems, #DDDesign, #SOA, #agile, #entArch, #softArch and such. ☺️
Toyota’s material and information flow logic is a masterclass in seeing the system. This piece explores how AI-powered "Digital Brains" now reveal the invisible bottlenecks that workshops miss. Crucial for scaling Lean thinking.
Connect the dots here: https://nigelthurlow.com/ai-workflow-bottlenecks-toyota/
Top Links
AG-UI Protocol now has a first-class .NET SDK (Daniel Roth)
Syncfusion Releases First Set of Open-Source Blazor Controls (Syncfusion Team)
GitHub Copilot app for Beginners: How to build custom workflows with canvases (Kayla Cinnamon)
Introducing the new Copilot with Hom…
THE ART OF STRATEGY by Erik Schön is on sale on Leanpub! Its suggested price is $13.95; get it for $9.95 with this coupon: https://leanpub.com/TheArtOfStrategy/c/LeanpubWeeklySale20260922 #leadership #enterprise_management #agile #business_and_management #strategy
Eines der großen Probleme, mit denen wir alle ständig zu kämpfen haben, ist die Versuchung, andere zu „bewerten”. Wir interpretieren ständig mögliche Motivlagen, Gründe und Ursachen, wobei wir uns meist auf extrem dünne Informationen stützen. Dabei laufen wir, wie Dan Rockwell es beschreibt, Gefahr, es auf uns oder andere Personen zu beziehen. Das ist keine gute Idee, weil wir so sehr schnell zu Trugschlüssen gelangen können. Dan Rockwells Idee ist es, dem entgegenzuwirken, indem man die offenkundigen Stärken der Person als „Linse“ nutzt und die Interpretationsspielräume auf diese Art und Weise einschränkt. Ob es funktioniert, muss ich erst einmal ausprobieren.
https://leadershipfreak.blog/2026/09/21/judgment-based-on-fabrications/
Ich ziehe den Hut vor Menschen, die selbst unter großer Unsicherheit klare Haltung zeigen. Nicht im Form von Sturrheit, sondern bewusst und reflektiert. Sie nehmen eine klare Position ein, vertreten diese – sind gleichzeitig offen genug diese zu hinterfragen und an neue Erkenntnisse anzupassen. Unter Unsicherheit erlebt man leider oft zwei Extreme: Starres beharren ohne Anpassung an neue Erkenntisse oder eben extrem Unsicherheit, die dazu führt, dass gar keine Entscheidungen getroffen werden. Beides nicht wirklich ideal. Aber genau diese Extreme lassen sich oft bebachten. Wer klare eine Hypothese vertritt, sie auf Basis neuer Erkenntisse anpasst und seine Entscheidungen ggf. ehrlich korrigiert agiert in diesem Sinne adaptiv. Eigentlich nichts weltbewegendes und doch immer wieder ein Thema. Dan Rockwell überträgt das in seinem Beitrag hier auf unser Verhalten als Individuum, was dem manchen vielleicht sogar aus dem Kontext von agilen Methoden bekannt vor kommen mag.
https://leadershipfreak.blog/2026/09/22/adaptive-confidence
In der aktuellen Podcast-Folge spricht Ivan Blatter über „Nicht-Ziele” als Zeitmanagement-Strategie, die dabei hilft, das „Schiff nicht zu überladen”. Es gibt immer wieder viele Ideen, Ansätze und Initiativen, die spannend und verfolgenswert sind, die wir im Augenblick aber nicht leisten können oder bei denen wir im Augenblick nicht absehen können, ob wir diese tatsächlich leisten können. Genau hier greift das Nicht-Ziel als reflektierte Entscheidung darüber, was in den nächsten Monaten nicht stattfinden soll. Damit schließen wir nicht aus, diese Dinge später aufzugreifen. Die Idee ist spannend. Ich muss sagen, dass ich bisher nicht mit Nicht-Zielen gearbeitet habe. Dabei habe ich in anderen Kontexten bereits gute Erfahrungen mit der negativen Abgrenzung, also der Frage, was wir nicht tun wollen, gesammelt.
https://share.transistor.fm/s/02aa2674
Einen sehr spannenden Beitrag hat mir Houssam Hamade zugeschickt. Es geht um eine Gesprächstechnik. Das Zwiegespräch. Das Sprechen über Gleichzeitigkeiten. Allein schon sich bewusst zu machen, dass Mensch „gleichzeitig“ zwei vermeintlich konträre Positionen einnehmen kann. Dieses sich bewussst machen, führt dazu, dass wir hoffentlich offenen miteinander in Dialog treten. Polarlisieren, dass wir doch alle so oft wahrnehmen und als störend empfinden, lässt sich dadurch aufbrechen, vorausgesetzt dass die jeweilgen Dialogpartner auch offen und bereit dazu sind, sich auch das Zwiegespräch einzulassen, weil dabei durch die Gleichzeitigkeiten bewusst wird, dass man sich in vielen Dingen doch näher steht als man denkt.
https://houssamhamade.net/2026/07/31/der-trick-mit-den-gleichzeitigkeiten/
Im Lean-Kontext bedeutet Poka Yoke, Fehler gar nicht erst entstehen zu lassen, indem Prozesse und Abläufe so gestaltet werden, dass Fehler gar nicht erst entstehen können. Das ist per se eine gute Idee, die aber im Extremfall einen Haken hat, auf den Götz Müller hinweist. Nämlich dann, wenn der Mensch zur Störgröße wird und zum reinen Bediener, der am Ende gar nicht mehr versteht, was da gerade passiert. Ein Schelm, wer dabei nicht sofort an die KI-Debatte denkt. Pardon, ich kann nicht anders.
https://www.geemco.de/artikel/wenn-poka-yoke-menschen-ersetzt/
Bei der Podcastfolge von Marc Löffler zum Thema „Impact” musste ich an die 14 Prinzipien des „Toyota Weges” nach Liker denken. Das Buch dazu ist mir vor Kurzem wieder in die Hände gefallen, als ich in meinem Buchregal gestöbert habe. Erstaunlich, was man so alles im Laufe der Jahre zusammenträgt. Aber das ist ein anderes Thema. Zurück zum Podcast von Marc Löffler. Es geht um Wirksamkeit. Wirksamkeit, die wir als Organisation erzielen. Er fasst fünf Dinge zusammen, die seiner Meinung nach echten Impact erzeugen, und erklärt, wie man diese in der eigenen Organisation erkennen kann. Ich bin persönlich der Meinung, dass sich alle fünf von Marc benannten Punkte tatsächlich in den bereits erwähnten 14 Prinzipien des Toyota-Weges wiederfinden, die vor über 20 Jahren definiert wurden. Spannend. Allerdings bin ich der Meinung, dass Liker sogar noch ein paar weitere Dinge im Blick hat, die nicht minder wichtig sind.
https://passionateteams.com/e/funf-dinge-die-unternehmen-mit-echtem-impact-ausmachen
Woran scheitern viele Scrum-Implementierungen? Ralph Jocham bietet mit seiner Unterscheidung nach „Protokoll” und „Agenda” eine gute Erklärung hierfür. Oft wird das Scrum-Protokoll implementiert, während die „Agenda” nahezu komplett vernachlässigt wird. Mit anderen Worten: Es steht Scrum drauf, weil es Sprints, Retrospektiven, Reviews usw. gibt, aber die Idee, Mehrwert zu erzeugen, also echte Ergebnisse, die tatsächlich auch kritisch überprüft werden, findet nicht wirklich statt. Das empirische Prüfen der Hypothese jedes Sprints findet nicht statt. Damit gibt es auch kein organisationelles Lernen. Weshalb ist das so? Der Scrum-Leitfaden ist relativ leichtgewichtig und das Protokoll lässt sich leicht kopieren. Die Idee dahinter jedoch nicht. Und genau da liegt ein Missverständnis, dass leider zu oft auftritt: Protokoll und Agenda kann man nicht trennen.
https://www.scrum.org/resources/blog/scrums-protocol-easy-copy-its-agenda-not
Ich durfte Olaf Hinz vor vielen Jahren kennen und schätzen lernen. Schade, dass es das PMCamp Dornbirn nicht mehr gibt. Dort habe ich viele spannende Menschen wie Olaf Hinz persönlich getroffen und so manche Erkenntnis im Austausch mitgenommen. Olaf ist einer der ersten Menschen, die mir zum Thema Change Management einfallen. Daher war ich natürlich neugierig, was er im Interview mit Bernd Geropp über das Scheitern von Transformationsprojekten erzählt. Für mich immer wieder ein interessantes Thema. Spannend ist, dass wir immer wieder die gleichen Themen wälzen. Change Management oder Transformationen sind eben nicht zweckrational, sondern hoch komplex und damit immer wieder herausfordernd.
https://www.mehr-fuehren.de/warum-transformationen-scheitern/
Jede Entscheidung hat Konsequenzen. In irgendeiner Form. Die Frage ist, wer die Konsequenzen in der Organisation spürt. Diejenigen, die sie getroffen haben, oder jemand anderes? Und darin liegt die Krux. Wenn die Konsequenzen nicht dort spürbar sind, wo die Entscheidung getroffen wurde, funktioniert die Rückkopplungsschleife nicht. Das klingt trivial, ist aber ein Kernproblem in fast jeder Organisation, die ich kenne. Wenn Entscheidungen nicht spürbar werden – und zwar bei den Personen, die sie treffen –, unterbleibt das „Adaptieren und Anpassen“ im Sinne des Lernens, wie man die Dinge besser macht. Das lässt sich auch an einem anderen Beispiel gut zeigen. Wenn wir einen Standard definieren, diesen aber beständig ignorieren und das Abweichen vom Standard nicht reflektieren, wird der Standard niemals weiterentwickelt. Es hat ja keine Konsequenzen. Daniel Dubbel reflektiert das Thema etwas ausführlicher als ich es hier tue und kommt zu dem Schluss, dass eine Entscheidung, die keine spürbaren Folgen hat, den ersten Test nicht bestanden hat.
https://www.lean-agility.de/2026/09/einbetonieren-von-veranderungen.html
Jede Entscheidung hat Konsquenzen. In irgendeiner Form. Die Frage ist, wer spürt die Konsquenzen in der Organisation? Diejenigen, die sie getroffen haben oder jemand anders. Und da liegt die die Krux. Wenn die Konsequenzen, nicht dort spürbar sind, wo die Entscheidung getroffen wurde, funktioniert die Rückkopplungsschleife nicht wirklich. Klingt trivial, ist aber ein Kernproblem in fast jeder Organisation, die ich kenne und erlebt habe. Wenn Entscheidungen nicht spürbar werden und zwar bei den Personen, die sie treffen, unterbleibt das „adaptieren und anpassen“ im Sinne eines Lernens, wie man die Dinge besser macht. Das lässt sich auch an einem anderen Beispiel gut zeigen. Wenn wir einen Standard definieren, diesen Standard beständig ignorieren, aber das Reflektieren des Abweichens vom Standard unterbleibt, wird der Standard niemals weiterentwickelt. Es hat ja keine Konsquenzen. Daniel Dubbel reflektiert das Thema etwas ausführlicher als ich hier und stellt fest, wenn eine Entscheidung keine spürbaren Folgen hat (also Konsequenzen nach sich zieht), hat sie den den ersten Test schon nicht bestanden.
https://www.inspectandadapt.de/das-muss-konsequenzen-haben/
#Agile #Leadership #Lean #Management #Produktivität@barryovereem in regular visited teams i like to participate myself. i got always interesting insights that the people gifted to me
Content from my "Agile Scrum: Your Quick Start Guide with Step-by-Step Instructions" book heads up the Agile Innovation section of Harold Kerzner’s "Innovation Project Management" book.
Ansible for DevOps by Jeff Geerling is on sale on Leanpub! Its suggested price is $9.99; get it for $6.99 with this coupon: https://leanpub.com/ansible-for-devops/c/LeanPublishingDaily20260923 #agile #software #startups #ansible #devops #cloud_computing
RE: https://hachyderm.io/@mlevison/117333314839731639
For the same reasons I have problems with usual test management by case numbers.
I prefer this dashboard instead. It's based on assessments by skilled people.
https://www.developsense.com/resource/ReportingExamples/dashboard.pdf
#Testing #Softwaretesting #agile #scrum #kanban
🚦 Red-Yellow-Green status reports are so far removed from the original data that they hide everything.
A team's Task Board or Portfolio Kanban Wall is a first-order model of reality. Not a perfect mirror, but fairly close. A Burndown, Burnup or Cumulative Flow Diagram is a second-order model: it summarizes what's on those boards. Red-Yellow-Green reports are models of the other charts, in that they summarize the already summarized information, hiding almost all details.
Green means we're on track both with time and budget. But missing is important context. A project might be "green" if it's within 5% of budget. That tells you nothing about the quality of the work. Yellow means there are scope or time problems but, with sufficient re-planning, we can come back to target. Red indicates serious issues but doesn't give details, what the issues are, or how they happened.
RYG reports have many shortcomings, but the biggest is that they assume that a plan's scope, budget, and time are fixed and unchanging. This approach might be adequate in a world where these are true, but in the Agile world where change is accepted as the norm, colour-coded, highly abstract reports are dangerous.
Since RYG reports usually have "green" as a default state, often there are too few questions asked about possible issues until it's too late. I do not recommend using RYG reports at all.
the agile way (Lao Tzu Refactored) by Peter Merel is on sale on Leanpub! Its suggested price is $19.95; get it for $9.98 with this coupon: https://leanpub.com/sh/3OjTyqhZ #Agile #Engineering #BusinessAndManagement #Philosophy #Poetry #SystemsEngineering #HumanitiesHistory
Habr » 🤖 🌐
@habr@zhub.link
«Я думал, вы уже начали» — почему задачи зависают между «готово» и «взял»
11:07 — разработчик пишет: «Готово, можно смотреть». 11:10 — менеджер уверен, что задача уже ушла в тестирование. 13:00 — выясняется, что проверка на стороне тестирования не начиналась. Никто не забыл про задачу и не нарушил процесс. Она просто зависла между «готово» и «взял». Такие паузы редко выглядят критичными, но именно из них складываются задержки релизов, сорванные сроки и ощущение, что все постоянно заняты, а работа движется медленнее, чем должна. Я работаю QA-инженером в Ozon Tech и часто вижу, как задачи переходят между разработкой, тестированием, менеджерами и другими командами. Статус в тикете может быть обновлён, договорённость в чате зафиксирована, но ни то ни другое не гарантирует, что следующий шаг кто-то действительно принял. В статье разберу несколько типичных ситуаций, в которых происходят паузы и теряется следующий шаг, и покажу, как их распознавать. В конце соберу короткий чек-лист передачи задачи и формулировки, которые можно использовать в чатах и таск-трекере.
https://habr.com/ru/companies/ozontech/articles/1078568/
#handoff #передача #управление_разработкой #коммуникация_в_команде #jira #софтскиллы #softskills #джира #agile #процессы_в_it
Hey #agile #scrum #kanban,
angenommen (oder vielleicht auch tatsächlich) ihr habt kein Daily (oder es kann nicht immer jeder dabei sein), wie würdet dafür sorgen, dass das Team sich synched? Jeder über den aktuellen Stand Bescheid weiß.
Muss das überhaupt sein? Kommt ihr ohne Daily klar? Wie macht ihr es dann?
Viele Grüße
Top Links
Changes to Microsoft Learn’s public documentation repositories (Martin Ekuan)
Microsoft is updating its author-signing certificate starting September 23, 2026 (NuGet Team)
Claude Opus 5.5 comes to Microsoft Foundry for long-running coding and knowledge work (Amar Badal)…
@barryovereem @christiaanverwijs
its so cool to see the research of @karen to develop and put into practice.
was already very helpful for me many times to put some facts into mindset discussions.
What actually creates an Agile Mindset?
@christiaanverwijs and @karen developed the Agile Mindset Model based on data from real teams.
The model shows that an Agile Mindset doesn’t appear out of nowhere. It is shaped by the environment around teams, particularly, knowledge impulses, work design, and leadership.
The model moves the conversation away from “Do people have an Agile Mindset?” toward “What conditions are we creating for one to emerge?”
Top Links
Creating a memory dump in C# and Today I will… debug a production crash (Aaron Powell)
GPT-6 Astra, Sol, and Luna for production AI agents in Microsoft Foundry (Naomi Moneypenny)
Developer Deep Dive | Build native Windows apps faster with agents (Nikola Metulev)
Foundry…
Photo by Pixabay on Pexels.com
Ein Credo von mir: Wer Agile wirklich verstehen will, sollte sich mit Lean intensiver beschäftigen. Da steckt unglaublich viel drin, was das Verständnis von Agile vertieft und erweitert.
Nehmen wir die Null-Fehler-Politik in der Produktion – ohne sie läuft Kanban nicht rund. Ein defektes Teil? Das wandert nicht weiter. Übertragen auf agile Teams – egal ob Scrum oder Kanban – wird klar, wie wichtig die Definition of Done (DoD) ist. Sie sorgt dafür, dass die Arbeit reibungslos durch den Workflow fließt. An den Übergabepunkten kann nahtlos weitergearbeitet werden – weil alles Notwendige erledigt ist und alle Infos vorliegen.
Prozesse von rechts nach links betrachten – also vom Ergebnis aus – macht extrem Sinn. So sieht man, wo und wie Übergänge zwischen den Schritten reibungsfrei, einfach und effektiv klappen.
Ein weiterer zentraler Punkt ist die Vermeidung von Muda – also nicht-wertschöpfender Arbeit. Im Toyota-Production-System geht es nicht darum, dass einzelne Teile des Systems möglichst kosteneffizient arbeiten, sondern das Gesamtsystem im Blick zu haben. Im Fokus steht, was echten Mehrwert für das Ergebnis liefert. Alles, was nicht dazu beiträgt, versucht man zu vermeiden.
Lean bedeutet hier nicht, dass es keinerlei Reserven gibt, sondern dass Prozesse und Abläufe schlank, aber robust sind. Gesund gestaltet heißt: Alles, was nicht zum Ergebnis beiträgt, wird reduziert – ohne die Fähigkeit zu verlieren, sich anzupassen oder zu verbessern. Noch genug Spielraum für Kaizen– die beständige, evolutionäre Verbesserung – bleibt, und auf Unvorhergesehenes kann reagiert werden.
Habr » 🤖 🌐
@habr@zhub.link
Почему разработка постоянно выходит за сроки и как исправить это с помощью Shape Up
Команды часто пытаются ускорить разработку через новые оценки, больше контроля и подробные планы, но задачи всё равно растут, сроки сдвигаются, а бэклог превращается в список невыполненных обещаний. Shape Up предлагает другой взгляд на планирование: вместо оценки объёма вводится «аппетит» — ограниченный бюджет времени, под который команда адаптирует решение. Разберём, как работает этот подход, из каких этапов состоит цикл и почему правило «проект закрывают через шесть недель» помогает принимать более жёсткие решения. Читать разбор
https://habr.com/ru/companies/otus/articles/1081850/
#Shape_Up #управление_разработкой #продуктовая_разработка #гибкие_методологии #Agile #планирование_проектов #управление_задачами #приоритизация #командная_работа #процессы_разработки
Habr » 🤖 🌐
@habr@zhub.link
Почему гибкие подходы не дают ожидаемой скорости. Серия 2. «Пингвин в пустыне»
Ранее в сериале: в первой серии аналитик Марк Воронов расследует причины провала попыток внедрения модных практик в компании. Погружаясь в работу отделов, он обнаруживает размытую ответственность и накопившийся техдолг, а в финале получает таинственное анонимное послание о необходимости перестройки всей системы.
https://habr.com/ru/companies/T1Holding/articles/1084682/
#кино #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.
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.
AI might lower the cost of a single feature, but production-quality product remains hard. Teresa Torres and Petra Wille debunk the "free delivery" myth, exposing the risks of feature bloat and technical debt. Discover why the last 30% is where the real work happens: https://www.producttalk.org/delivery-isnt-free-all-things-product-podcast-with-teresa-torres-petra-wille/ #ProductManagement #Agile