- LeSS Newsletter
- Posts
- Goal Seeking Loop
Goal Seeking Loop
Causal Loop Modeling
Welcome to Lean, Agile, LeSS and Systems Thinking newsletter
Failure Demand
The term failure demand, coined by systems thinker John Seddon, refers to work caused by not getting things right the first time—like rework, clarifications, or follow-ups.
In Agile teams, this can show up as unclear user stories leading to mid-sprint disruptions, bugs caused by vague acceptance criteria, or repeated demo requests due to misaligned expectations.
Studies in service organizations have shown that failure demand can account for up to 40–60% of all incoming work—effort that doesn’t contribute real value. While numbers in Agile product teams may vary, the impact is still significant: increased cycle time, lower throughput, and team frustration.
To reduce failure demand, teams can:
Invest in better backlog refinement with the whole team
Use examples and testable acceptance criteria in user stories
Engage stakeholders early and often to align on expectations
Encourage cross-functional collaboration to reduce handoffs
Conduct root cause analysis on recurring defects or rework
Reducing failure demand isn’t about working harder—it’s about designing smarter systems that help teams deliver value with fewer avoidable detours.
If you want to learn a bit more and its sources, check this article
Goal Seeking Loop - Causal Loop modeling
If you have attended my LeSS course or Systems Coaching courses, you would have tried the Causal Loop Modeling. Since the trainees numbers are growing for both the courses, I thought of releasing short videos on some of these difficult concepts.
Here is an attempt to explain the Balanced Loop or Goal Seeking Loop example. Please watch and share your feedback. Am keen to improve the newer videos.
Only One Product Backlog - LeSS Experiment
If you haven’t read the Practices for Scaling Lean and Agile Development book, I highly recommend reading it. I am planning to insert LeSS experiments in the newsletter. This week’s experiment about having Only One Product Backlog.
Some “scaling Scrum” descriptions advise that each team have their own Product Backlog. This is not correct. There is only one Product Backlog for the overall product, regardless of the number of teams.
The Scrum Guide explains:
Multiple Scrum Teams often work together on the same product. One Product Backlog is used to describe the upcoming work on the product.
This is necessary for focus on the whole product and to optimize the overall priority of features for the product—to avoid local sub-optimizations by separate teams.
In product groups with many component teams or single-function teams (such as design or testing), these teams do technical tasks— partial work for a feature—rather than a complete feature. Sometimes, rather than transitioning to Scrum feature teams (that do complete features), these existing teams have team-level so-called Product Backlogs that contains these tasks. Avoid that.
Thoughtworks Technology Radar
Many of you might know about the company Thoughtworks. Their technology team regularly shares “Radar” providing their view of the technologies, platforms, methodologies into following categories. I felt it is an interesting view.
Check their complete technology assessment here
Adopt: We feel strongly that the industry should be adopting these items. We use them when appropriate in our projects.
Trial: Worth pursuing. It’s important to understand how to build up this capability. Enterprises can try this technology on a project that can handle the risk.
Assess: Worth exploring with the goal of understanding how it will affect your enterprise.
Hold: Proceed with caution

Upcoming Course Schedule
Certified LeSS Practitioner (Provisional) - July 2025 (dates TBD)
Certified ICAgile Systemic Coaching Profiessional - June 2025 (dates TBD)
If you are keen to join the course, please reach out to me directly
ICAgile Systemic Coaching
Certified LeSS Pracitioner
Certified LeSS Executives
Systems Thinking for Leaders
