Living the Agile Principles: Customer Value

[article]
Summary:
The first principle of the Agile Manifesto states, "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software." Early and frequent delivery gets value to customers quickly and helps you figure out whether you understand what your customers really want. Here are five tips for how you can follow the first agile principle and provide customer value continuously.

Agile Principle #1: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

When I was just starting my career, I worked in a research laboratory inside a large company. All day long I got to play around with new computer equipment and software tools while working to solve difficult software problems.

Our customer for this research was the rest of the company I worked for, and the sales pitch I got when interviewing for the job was that I would get to solve hard software problems that would make our company more competitive and successful. Sounds like a great job, huh?

What I quickly realized is that while we were doing very interesting and cutting-edge research, none of it was being used anywhere else in the company. As hard as I tried, I wasn’t able to get my software used by others. This was partially my fault, as I had no clue how to engage with the rest of the company to even understand what they needed. Instead, my boss told me what problems needed to be solved, and I worked to solve them. Once I had something that management deemed to be useful, we threw the solution over the fence and moved on to other problems.

Never once did I see anything I had worked on appear in any product or service my company sold. Nor did I see any evidence that what I had worked on was increasing the productivity of the company.

While this inability to deliver anything of value troubled me deeply, it didn’t seem to be a problem for many of the scientists around me. They were more than happy to get paid to think deep thoughts and work to solve problems that no customer seemed to have. When I mentioned to others in the lab that I was troubled by this, they would often shrug their shoulders and tell me that the work we were doing was very important and that someday somebody would use it.

After quitting that job to start my first software company, I realized that if we were going to survive, it was all about what value we could provide to customers. There was no time to mess around with new technology or choose the programming language we would use based solely on what I wanted to put on my resume or thought would be most interesting. We need to understand what customers would buy and figure out how to get a solution into their hands as quickly as possible. Otherwise my company wouldn’t be around very long.

Because agile was formalized by software developers seeking ways to improve software development, it should be of no surprise that the first agile principle states that it’s all about the customer. I had a sale executive once that would remind me about this whenever I complained about one of our customers. “Yeah,” he used to say, “wouldn’t business be great without customers?” That usually shut me up pretty quick!

The great thing about this agile principle is that it tells us not only what is most important (satisfying customers), but also how to go about doing it (early and continuous delivery of valuable software).

Unfortunately, there are lots of teams that talk about customer value but then fail to deliver any. Because customers don’t know what they want until they see it, early and frequent delivery gets value to customers quickly and helps you figure out whether you understand what your customers want without spending an inordinate amount of time and money.

Here are five tips for following the first agile principle and providing customer value continuously.

1. Never Skip User Acceptance Testing

Allowing a customer representative to play with your software, or at least see a demonstration of it in action, is an early and ongoing activity that is essential to adding value. Even if your product owner isn’t 100 percent sure what the customer wants, their feedback is valuable in terms of overall direction.

Plus, acceptance testing is the only way you are going to find out whether you and the product owner are on the same page in terms of what each user story actually means. Any disconnect between what the PO was expecting and what you delivered is usually due to ambiguities in user story definition, and you need to recognize this as quickly as possible so it can be corrected.

2. Include End Customers in Some Testing

Nothing beats feedback from actual end customers! Seek to include them in at least some of your user acceptance testing (UAT) to verify what you are building has value to the end user.

Often the business side of your organization will tell you that end customers are too busy to be involved in UAT, but I’ve found that this is usually an excuse. It may be that the product owner is afraid that you will find out they do not really know what customers want if actual customers are involved, or they don’t want others speaking directly to “their” customers.

Seek out users through customer services, marketing focus groups, beta programs, etc., and get them in the loop periodically. Their feedback will be invaluable.

3. Keep Your Sprints Short

The shorter your sprints, the faster you are going to get software in front of your product owner and end customers. Keep your sprints to a maximum of two weeks if at all possible, as this will give you continual feedback.

If you are having trouble getting work done in your sprints, discuss ways to improve your sprint process during retrospectives instead of blindly increasing sprint duration. Usually when teams increase sprint length, it is because it’s easier to do that than deal with the underlying process or team dynamics that are causing work to not get done.

4. Incorporate the Customer’s View in Technology Decisions

Watch for the propensity of some software developers to try to sneak new technology, tools, or programming languages into your process for the wrong reasons. Sometimes developers (like the researchers mentioned above) want to use something new just because it provides them an opportunity to learn, not because it adds any customer value. In fact, learning something brand-new on the fly is risky and should not be undertaken lightly.

Whenever a change is proposed to the tooling being used, make sure the team honestly asks, “Does adopting this tooling create more customer value than the alternatives?”

5. Continuously Deliver

As the phrase “continuous delivery” is part of the first agile principle itself, you wouldn’t think it would be controversial. But even with the current buzz about DevOps, it is very common for organizations to still have six-month deployment cycles into production.

Our goal in agile should be to give the customer value on a continuous basis, and unless we figure out how to reduce deployment cycles, end customers don’t get this value. In addition, releasing new software guarantees we get end customer feedback early. Nothing measures customer value better than market response, and the faster and more frequently, we can get it, the more likely it is we will deliver ongoing value.

User Comments

1 comment

About the author

CMCrossroads is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.