Technical Practices or Value to Customers:
What to Focus on First

Suppose your organization doesn’t truly know what would be valuable to your customers and you don’t have good technical practices, delivery capability or Agile project management. What would you improve first?

Would a focus on customer value lead to improved technical practices?

Would a reliable delivery process enable the organization to explore and meet customer needs more effectively?

Okay, let me ask you this….Is there any point in a software development team learning to build higher-quality software and learning to do it faster if it doesn’t solve a business problem, remove a constraint, or help meet our business goals?

Focusing on Value to Customers First

If you have a good product idea, good market fit, and good product management practices then you have a shot at success even if development capability needs improvement.

Is the converse true?

If you have a lousy idea, it doesn’t matter how good your software development organization is. So what if you’ve got continuous deployment? If the “what” you’re building is wrong, you’re just auto-deploying code that doesn’t drive any business value.

So that’s a vote for focusing on value to customers first.

Focusing on Technical Practices First

Better technical practices—even if it’s little more than getting the wrong stuff out there faster—should, in theory, lead to faster learning. Faster learning that you’re doing the wrong thing, assuming a minimal level of market/customer awareness.

Improve your delivery capability anyway because doing so will do two things:

1. It prepares you for later
2. It may cause the organization to improve in other areas

If it does, it’s because you’ve created a learning organization. So, change anyway and build the organization’s ability to change—its ability to remake itself.

So that’s a vote for focusing on technical practices first.

Across the Whole Organization

When you begin an improve program, it’s wise to improve technical practices across the whole organization, or at least as far as there are interfaces and dependencies between teams or projects. Failing to move everyone along can frustrate the improved team, living in an organization that can’t consume their work at the rate of production, or can’t feed them inputs or resolve dependencies fast enough.

Parting Thoughts

I’ll leave you with this:

• Improving technical practices throughout an organization takes a long time.
• Learning good product techniques and skills takes months of guided practice.

You should tackle them both.

Attack a few of the biggest constraints that the organization is capable of attacking and do it at the same time.

That is, consider capacity for change. An organization has capacity for only so much change and leadership can manage only so much. But thankfully, the product organization and the technical organization typically have separate leadership and thus distinct capacities for change.

They can change simultaneously.