Delivering Value

By now you’ve probably seen this image, with waterfall on the left, and continuous operations on the right, it’s an evolution.

I’ve always thought that evolution was a great way to describe the software delivery journey of a company or team. Evolution is not about one person, it’s not about the first person being smart enough to discover fire. It’s about continuous improvement.

It’s about values and attitudes, ideas and behaviours. It’s a way of thinking, a way of doing and a way of being. Culture, paradigms and philosophy. Practicing as well as preaching. It’s about taking the best experiences and sharing those with others. That’s how we evolve.

There’s an Indian story about six blindfolded men who are trying to understand what an elephant is. One man just feels the trunk and thinks the elephant is a snake. The rest feel different parts and think that it’s a fan, rope, spear, wall, tree.

The same can be true for us in software engineering. Often we find that we’re talking about the same thing but from a different perspective. Perhaps from a technological point of view (infrastructure, development or testing). Perhaps from a different methodology (Agile, Lean or Continuous Delivery). However they are all talking about the same thing.

The agile manifesto talks about satisfying the customer as the highest priority.

Lean talks about value and perfection.

Continuous delivery talks about quality built-in.

When I first got into software development, I was given a piece of valuable advice.

“Release early. Release often. And listen to your customers”

Release early points to the fact that that until code is in production, no value is actually being generated. It means getting a minimum viable product out to users without compromising on quality. It means that perhaps the customer will be happy with a bike until a car is available.

Release often means that you need practice. If it’s difficult, do it more. Do it until it’s easy. Do it until it’s just one click. Doing a little and often is how you become an expert. How do you eat an elephant? One piece at a time.

Listening to customers means closing the loop, focusing on building a quality product that people want to use. If quality is a top priority then compromise is not an option. We have to put our efforts into understanding the behaviours that are expected by the end user, rather than making assumptions that could be wrong, or worse, take longer to test and resolve later.

It all talks to quality, but quality is not something you can objectify, you can’t point at something and say, “that’s a quality”, there’s no thing that represents quality, like how you could say a compass would represent the word “direction”.

When pushed, we tend to think about quality products, usually high end cars like Porsche, Mercedes or BMW. We think of these as quality products because people are willing to pay large amounts for them. Their customers like the product enough to part with their hard earned cash.

In software, when we talk about quality we’re often talk about testing. But testing is not supposed to be something that is just tacked on at the end, you have to build quality in from the beginning. You have to think about the process and the standards, knowledge and tools we use to improve the process from the beginning.

Quality assurance isn’t just be about testing or processes. It’s not just about making sure we are building the product correctly, it’s about making sure we are building the correct product.

Continuously delivering the correct product and being aligned with the customer is a very powerful motivator.