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.

Balanced Loop

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

An example radar below

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

We are authorised Training providers for the following courses

  • ICAgile Systemic Coaching

  • Certified LeSS Pracitioner

  • Certified LeSS Executives

  • Systems Thinking for Leaders

Copyright (C) 2025 The Empirical Coach Pty Ltd. All rights reserved.
You are receiving this email because you have opted during one of the LeSS events or requested in relation with any of the trainings conducted by the Empirical Coacht Pty ltd

Our mailing address is:
The Empirical Coach Pty Ltd
High Street Road
Glen Waverley, VIC 3150
Australia