Agile Pitfalls and HSD Patterns: A Path to Greater Impact

Agile frameworks promise transformation, but why do they so often fall short?

Agile values, principles, and frameworks are designed to act as scaffolding, creating patterns that lead to better outcomes. However, these frameworks can’t succeed on their own; they require a deeper change in the underlying behaviors and patterns of the people within the system. That is what people call being Agile - adopting the mindset and values - versus doing Agile, where teams follow frameworks superficially without systemic changes.

This is where the praxis of Complex Systems from Human Systems Dynamics (HSD) comes in. By offering tools like the CDE Model - Containers, Differences, and Exchanges - HSD provides a way to understand the systems behind frameworks and ensure Agile methodologies are used effectively. Containers define the boundaries - or shared similarities - of a system, Differences highlight the diversity and potential for action within those boundaries, and Exchanges represent the interactions that enable the flow of information, energy, and resources. These elements are essential for understanding the conditions that shape the effectiveness of Agile practices.

To see how the CDE Model can clarify and address common challenges in Agile, let’s examine some concrete examples, starting with Scrum.

Scrum and the Problem of Containers

One of the most common misuses of Agile methodologies is treating them as isolated practices within a single department - like software development - while leaving the rest of the organization unchanged. In this case, the Container is too small.

Take Scrum, where the role of the Product Owner (PO) is central to the framework. The Scrum Guide specifically states "For Product Owners to succeed, the entire organization must respect their decisions." and "Those wanting to change the Product Backlog can do so by trying to convince the Product Owner."

These statements make it clear that Scrum intends to give the PO very broad authority over the Product. The Scrum Team’s container must therefore extend beyond technology to include all aspects of product management, reflecting the Product Owner’s broad authority over the product. When this larger container isn’t in place, Scrum often devolves into delivering a pre-defined waterfall plan in smaller iterations. While this approach may work for some, it misses out on the transformative potential of Scrum.

Kanban, Misaligned Exchanges, and Small Containers (again)

Another example of Agile misuse is found in Kanban, where the Exchanges between different parts of the system are often overlooked. Done correctly, Kanban forces focus on value delivery by limiting work in progress (WiP) and ensuring smooth flow through the value stream.

However, when exchanges between different parts of the value stream are not optimized, it can lead to local optimizations at the expense of the broader system. For instance:

If the organization doesn’t enforce a disciplined pull system, they risk teams being overwhelmed by work being pushed into their backlog. Without tightly managed exchanges, Kanban loses its ability to deliver flow and focus.

When these exchanges are optimized and pull systems are enforced, Kanban excels at creating a steady flow of value across the organization, minimizing queueing times, increasing responsiveness to change, and fostering collaboration and alignment across the entire value stream.

Similarly, Containers play a role here too. For example, a team that implements WiP limits on user stories but ignores limits on epics or initiatives risks losing focus. This can slow the movement of epics, delay value delivery, and undermine Kanban’s strengths.

Extreme Programming (XP) and the Role of Differences and Exchanges

XP emphasizes collaboration within development teams, but a common pitfall is neglecting exchanges with stakeholders outside the team, such as business leaders or customers. The On-Site Customer, a role similar to the Scrum Product Owner, must balance being present for the team with spending time off-site to engage directly with real customers.

This balance is crucial. By staying connected to the market, the On-Site Customer can bring fresh perspectives - what HSD refers to as differences - back to the team. At the same time, their presence ensures that developers receive timely guidance, preventing delays caused by unclear priorities or lack of feedback.

When exchanges with external stakeholders are weak, the team risks focusing on technically sound features that fail to align with customer needs or business goals, ultimately diminishing the product’s impact.

The Bigger Picture: Patterns and Possibilities

HSD can help us see these challenges for what they are: patterns of interaction within a system. By using tools like the CDE Model, Agile practitioners can move beyond frameworks to address the root causes of dysfunction.

When we focus on changing patterns rather than prescribing solutions, we open the door to sustainable change. HSD reminds us that in complex systems, outcomes are emergent and cannot be fully predicted - but they can be influenced by understanding and shifting the conditions that shape them.

A Call to Action

Agile and HSD are natural partners in navigating complexity. By integrating the two, we can create systems that are both adaptable and resilient - capable of thriving in the face of uncertainty.

If this resonates with you, I invite you to explore HSD and join its amazing community. Maybe it can transform the way you approach Agile challenges, like it is doing for me. Start by visiting the Human Systems Dynamics Plaza on LinkedIn.