Skip to main content

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

Andrew Fuqua
Reading: 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.

Next Does Your Agile Lead to Agility?

@AndrewMFuqua is a founding member of XP-Atlanta in 2001. Currently an Enterprise Transformation Consultant, Andrew has previously held positions in management, product management and software development at companies like Internet Security Systems, Allure Global, and IBM. Andrew earned a BS and MS in computer science and has an MBA from Duke University.

Comment (1)

  1. Dave Nicolette

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

    I suspect that can happen only if the people in the organization connect the dots between customer value and technical practices. Otherwise, it might not occur to them that technical practices have anything to do with their ability to deliver customer value.

    “Better technical practices—even if it’s little more than getting the wrong stuff out there faster—should, in theory, lead to faster learning.”

    I suspect that can happen only if people in the organization connect the dots between technical practices and customer value. Otherwise, it might not occur to them that they’re delivering the “wrong” things.

    Ultimately, then, I agree with your conclusion: It’s best to tackle improvement in a holistic way with a focus on removing the largest constraint. Doing so will almost certain involve mindful, deliberate, and coordinated improvement in all areas.


Leave a comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Congruence Between Agile Process and Ecosystem

In a recent SoundNotes Q&A with Mike Cottmeyer, our Fearless Leader fielded questions on a range of topics related to organizational Transformation and Agility. One key point he made was that any process or method, such as Scrum, LeSS, SAFe, etc., is designed to operate under certain conditions. Each process or method assumes it will […]

Letting Go of the Waterfall, Embracing Agile,
and Mixed Martial Arts
w/ Brandon Dudley

In this episode of SoundNotes, LeadingAgile’s own Brandon Dudley—Senior Consultant—shares his experience making the shift from a Waterfall mindset to a more Agile way of thinking and working. Brandon got his start in traditional, PMI-centric, project management working in the auto industry in Detroit. His introduction to Agile didn’t involve the hard break that many […]

Completeness & Correctness = Predictability

Completeness & Correctness = Predictability Video Transcript: When we think about organizations, one of the challenges for us as a consulting organization is when we engage with any particular company, we have to identify what that company values and what they’re trying to be, as well as what environment they’re in, because that’s going to […]

Questioning Agile Dogma

When I first learned about Agile methods in 2002, the principles seemed to offer an ideal solution to many organizational issues common at the time. When I applied those principles in real-world situations, they worked remarkably well. Today, some of the same principles seem to present impediments or unnecessary challenges for many teams and organizations. […]