Same Symptom, Different Diagnoses.

If two teams are both missing their dates, do they have the same problem?

I've led organizations where the symptom looked identical: delivery kept falling short of what leadership expected. The talent and the effort were there in all of them. Each time, I used the House of Software Value Delivery to diagnose what was getting in the way.

In one, the diagnosis was Coherence and Accountability. There was no shared language for what kind of date a timeline was: a Forecast, a Plan, or a Commitment. And when a Commitment slipped, it got treated like a Forecast that had simply moved. Sprint goals, execution reviews, and a shared vocabulary across functions changed that.

In another, it was Communication and Prioritization. A shared backend team set the priorities for several frontend teams, and the frontend teams kept building features that would never get the backend support they needed. Cross-functional prioritization up front, with no frontend work starting until the backend had committed to it, got the teams planning together.

In a third, larger organization, it was Transparency, Alignment, and Focus, and they turned out to be a chain. Focus depended on Alignment, and Alignment depended on Transparency. A diagnosis works like an inquiry: you pull a thread and see what's attached.

Same symptom, different diagnoses, different repairs.

I created the House of Software Value Delivery to visualize the health of a software development organization. It starts with Attributes: the qualities you want your software and your delivery ecosystem to have. The diagnosis finds which ones have the most room to improve, before anyone reaches for a fix.

A diagnostic that returned the same answer every time wouldn't be diagnosing anything.

Next
Next

Change the Tool, Measure the Attribute