Software is written to perform some business function, and lately it has largely been about automating tasks that have been typically done manually by people. Teams of business analysts, managers, and engineers are brought together to design and build the software. In the early days of software engineering, software would get released in weeks, months, or years, but now companies will release software every single day, if not multiple times a day. This rapid development is helping companies deliver value to their customers faster, and that is generally a good thing.

Customers aren’t always getting value though. Facebook continues to upgrade and improve their user interface, but sometimes their users don’t want the changes that have been made. In fact, it can often alienate customers to have to continually adapt to changing interfaces. Some people love trying to do things in new ways and provide feedback on what they like and don’t like. Other people need time to learn how to use software, and when these changes roll out, they have to start over again.

As an engineer, I can tell you that we often feel like our jobs are never done. We may have delivered a solution that works, but we also feel like there are better, more efficient ways of doing things. We try to do things in different ways to differentiate ourselves from our competition. We try to add more and more features to keep customers excited about what we are offering. A lot of companies will push products that don’t even have a customer base yet, but if they push hard enough and market it as if the product is something that everyone needs, some customers will buy into that illusion.

All of this comes at a cost, however. A lot of projects are eagerly launched that eventually are delayed, shelved, or cancelled entirely. When you spend dollars on development efforts that don’t result in a product that goes out the door, you are wasting more than time – you are losing potential revenue because you could have been spending that time on other efforts that could have been generating revenue.

There are two really good books about this topic. The first is called The Goal, and is about a man who is given a short amount of time to make a plant become profitable or the plant will be closed. What he realizes is that it isn’t about cutting costs – which unfortunately is how a lot of companies address issues with their bottom line. Instead, the real problem is the complicated processes that prevent finished products from getting out the door, often leaving heavy inventories sitting around idle. As he streamlines the processes and gets the products moving out the door, the increased sales more than compensate for the increased costs, and the plant becomes one of the most profitable in the entire business.

The other book to read is called The Phoenix Project. It is similar to The Goal, but is about software development. The process of software development can often be like a factory that is trying to build things. When parts of the solution get bogged down in the process, it can have effects down the line. There are many things companies can do to improve these processes, but the most important one is to adopt DevOps strategies so that code is continually being built, tested, and made available for release as soon as possible. You can only realize the value of your work when it goes out the door, and you may have to make quick adjustments if you deliver something that doesn’t actually give your customers value.

The real challenge is correctly identifying what it is that will give your customers value. If you aren’t doing this correctly, you can have the most efficient delivery process in the world and still not be profitable. A lot of companies fail simply because they spend time building products that really don’t bring value to customers. Large companies like Apple, Microsoft, and Google can afford to experiment and take these risks, but a lot of companies really can’t afford to do so.

Getting feedback from customers early can be vital to successful projects, and this is largely why Agile has been so successful. Companies are able to produce small pieces of functionality and make quick adjustments if they determine that they are going in the wrong direction. They can cancel projects sooner if they realize that the product they were developing would not actually succeed with customers. Users get to see small incremental changes and give feedback rather than being blindsided with large changes that may make them go to other solutions. Companies can also quickly change direction if other needs are prioritized (and this happens a lot), so it makes it much easier to address issues in a timely fashion.

You don’t have to do Agile the way other companies do it, and in fact there are many different types of processes that are often labeled as Agile but are actually different. You may have to try a few different ways to find the right one for your teams. The important thing is that you keep product flowing out the door rapidly so that your customers can quickly tell you if you are going in the right direction or not. If you don’t know where you are going, how do you ever expect to get there?