The Diagnostic Coaching Method for Recurring Software Delivery Problems

Problem → Principle → Action

Most recurring delivery problems are not team failures. They are system conditions that have never been properly diagnosed.

PPA is a structured diagnostic coaching method that identifies what is actually driving a recurring problem, which principles are being violated, and what action is realistic within real constraints. It is a way of thinking that engineering and project leaders apply directly to their real delivery situations.

Try the AI Diagnostic Tool (free) | Explore the Principles Library

The Common Path vs. The PPA Path

Most organizations react to symptoms. PPA diagnoses the system condition beneath them.

The common path: symptoms are observed → a symptomatic fix is applied → the system condition remains unchanged → the problem returns. The PPA path: recurring problem → symptoms observed → Unintended System Condition diagnosed → violated principles and constraints identified → deliberate action taken → organizational capability improves.

Most approaches fix the symptom. PPA fixes the system.

Traditional delivery improvement tends to do one of two things: jump straight to solutions, or analyze problems without changing how decisions get made. Both produce the same result — the problem returns.

PPA deliberately connects three things most approaches treat separately: a clear diagnosis of what the system is producing, an understanding of which principles are being violated, and an honest assessment of what constraints make certain actions realistic and others aspirational. Without all three, any action taken is a guess. With all three, the action becomes almost unavoidable.

The goal is not just to fix today's problem. It is to build the organizational judgment to stop producing it.

Problem → Principle → Action

Problem: Understand what the system is actually producing

Most delivery problems are misdiagnosed at the point of entry. The visible symptom is treated as the problem itself. PPA starts beneath the symptom — diagnosing the Unintended System Condition driving it: the underlying state the system has drifted into that makes the outcome predictable, regardless of who is on the team or what was tried before.

Diagnostic question: Where does the system produce this outcome predictably — and what constraint is making the current behavior rational?

Just-in-Time Coaching begins here — at the moment a pattern is recognized as a system condition rather than an incident.

Principle: Identify which cause-and-effect relationship is broken

Behind every recurring delivery problem is one or more principles being violated. When a principle is violated, the resulting behavior is often rational from the perspective of the people involved. That is what makes recurring problems so persistent: everyone is acting sensibly inside a system producing poor outcomes. The Principles Library contains 34 principles mapped to the specific behaviors and conditions they explain.

Diagnostic question: Which principle, if honored, would make the current behavior irrational?

The second coaching moment — when the violated principle is named and the team understands why the current behavior is a rational response to a broken system, not a personal failure.

Action: Act deliberately within real constraints

The Action phase is about choosing the best action available within the constraints that actually exist — structural, incentive-based, regulatory, or political. PPA distinguishes between constraints that are eliminable, mitigable, and manageable. That distinction determines what kind of action is worth taking now, and what would have to change before a different action becomes possible.

Diagnostic question: What action is principle-aligned and honest about the constraints currently in play?

When AI accelerates delivery, undiagnosed conditions scale faster

As AI agents automate more delivery work, the cost of a misdiagnosed problem compounds at machine speed. A solution that reinforces the wrong behavior — deployed through automation — amplifies the condition rather than resolving it.

PPA ensures decisions are principle-aligned before they are automated. The Principles Library includes a dedicated set of principles governing AI-assisted delivery: human accountability, decision authority, observability, and feedback loops that include AI behavior — not just human behavior.

PPA is available in three forms

Deeper questions about PPA

Are these principles universal? Yes — at the system level. The principles used in PPA appear consistently across Agile, Lean, DevOps, Kanban, and systems thinking. They hold true across industries, scales, and organizational models. What varies is which principles matter most in a given context and what action is appropriate.

Can organizations add their own principles? Organizations can define policies, constraints, and guardrails. But principles are discovered, not invented. A useful test: if violating it produces a systemic, repeatable consequence regardless of context, it qualifies as a principle. If the consequence is situational, it is a policy.

Why is PPA a coaching system and not just a diagnostic tool? Because diagnosis without behavior change produces reports, not improvement. PPA is designed to coach how people think — not just what they do. Every recurring problem reveals a leadership assumption and a decision pattern reinforced by the system. PPA surfaces those patterns and turns problems into learning moments.

How is PPA different from root cause analysis? Root cause analysis looks for a single cause to fix. PPA looks for the system condition producing the outcome — which often involves multiple violated principles and real constraints that make the obvious fix either impossible or insufficient. PPA is also designed specifically for recurring problems, not one-time incidents.