Change the Tool, Measure the Attribute

Nobody has ever made their software more Functional by just deciding to.

Functional is an Attribute: the software does what it's supposed to do, and bugs don't get in the way of your users' workflows. If your organization talks about Quality, as in Quality Assurance, Functional is the Attribute behind it.

In the House of Software Value Delivery, Attributes are the characteristics you want your software and your delivery ecosystem to have. On the software side, that might be Timely, Secure, or Intuitive; in the ecosystem underneath it, Collaboration or Learning & Growth.

You can measure an Attribute. Functional, for example, shows up in your escaped bug rate. But if your measurements reflect a problem, it's not something you can act on directly. There's no dial to make software more Functional.

You act on Tools: the technologies, rituals, culture, and practices your organization uses to build software and work together. Code review practices. Architectural standards. How you prioritize technical debt. How leaders meet and how planning runs.

So if defects keep reaching your users, you pick a Tool you expect to move Functional, like how your teams review code or how they write automated tests, and you change that. Then you measure again and see whether your escaped bug rate moved.

When I use the House, the order is always the same: name the Attribute, measure its baseline, change a Tool, measure the Attribute again. The Attribute tells you where you are and where you want to be. The Tool gets you there.

I created the House of Software Value Delivery around that distinction.