Making the right things vs. Making things right

Recently, David Anderson wrote of how he disagrees with the idea of focusing more on ‘doing the right thing’ than ‘doing things right’.

…we’ve heard a number of leaders in the Agile community promoting the idea that you should focus on doing the right thing – discovering what customers really want and need – rather than focusing on building and deploying working software

David disagrees because…

“doing things right” creates the circumstances to enable deferred commitment. Deferred commitment enables better predictability and faster delivery and a virtuous cycle ensues. Deferred commitment forces hard selection decisions and creates a focus on how selection is done. Combined with the limited WIP of a kanban system, deferred commitment raises awareness of the scarce resource of engineering capability. This is turn focuses attention on how to best utilize that scarce resource by “doing the right thing.”

There is another reason why focusing on “doing things right” is a good idea. One of the very principles behind many agile/lean approaches is iteration, allowing us to make the wrong thing so we can see it is wrong and more rapidly figure out how to make it right. The ability to do that quickly in an easy to evolve product is a significant aspect of agile approaches. “Doing things right”, as David points out, is the path to making this rapid evolution viable.

One way this is relevant is when we give the customer what they say they want so that they can then see what they really need. The ability to iterate quickly and predictably, as David clarifies, builds trust and leads to getting the right thing faster.

So, I entirely agree with David, however, I would phrase it in a slightly different way. To me, there is a distinction between “doing things” and “making things”.

David is talking more about what I would describe as  “making the right things” vs. “making things right”. I think of “doing” as a layer below this. Where “making things” is more what we do and “doing things” is more how we do it.

doing the right things -> doing things right -> making things right -> making the right things

For example, using TDD might be “doing the right thing” but maybe the practitioner isn’t very experienced in it and is not using many of the techniques that give them the most benefit for the effort they put in. While they might be effective, by “doing the right thing” (TDD in this case), they are not as efficient at it because they’re not yet “doing TDD right”.

So, if you ever hear me talk of “doing the right things” before “doing things right” then it’s because of this distinction in my mind between “doing” and “making”.

Start with “making things right” and you’ll get better at “making the right things”.

To improve at “making things right”…

Start with “doing the right things” and you’ll get better at “doing things right“.


Footnote :

Barry Boehm is the first thinker who I saw use the phrase…”Building the right thing” vs. “Building things right” in his 1981 book Software Engineering Economics. I use the term “making” because it’s a more general term that has fewer implications on “how” we create a product. This is partly because developing software products with agility doesn’t feel like “building” to me.