Skip navigation EPAM

DevOps: Why You Need It

Santanu Bhattacharya

Senior Director, Delivery Management, EPAM
Blog

How long can you hold features in your backlog and not deliver them to the customer? It depends on several factors. One such factor is the holding cost, which could come from opportunity cost, competitor threats, time sensitivity of the features, cost of uncertainty, and the whole cost of delay. The greater the holding cost, the more pressure companies face to deliver smaller batches of features to customers more frequently rather than large batches less frequently. Almost every company, because of market needs and the demand for quick feedback from the customer, is looking towards lowering the batch size and increasing the frequency of delivery.

Instead of releasing big sets of features in a large batches, companies are trying to see if small batches of features can be transported to their customers through a series of release trains. A feature that misses a release train doesn’t need to wait for the next big release or, for that matter, the release doesn’t need to get delayed, as that feature can be pushed to the customer in the next release train.

If we look at what it takes to reduce the batch size of features and deliver frequently through a series of release trains, we need to observe the whole value stream of concept to cash. After making a decision about a set of features and what it takes to deliver them to the customer to get feedback and ROI, several elements contribute to the cost and time taken for the release train to travel from concept to the customers. Looking closely, we see several areas that need attention in terms of process rationalization, automation, and the adoption of certain practices that can reduce the time and cost of producing and transporting the features from conceptualization to the customers.

If the production and transportation cost, as well as the time taken, are high, the tendency of increasing the batch size obviously heightens. For example, if I am asked to carry items from one room to another in a different building, I will first pack everything and then put the packs in a vehicle to move to the other building. I will increase the batch size since the transport cost is high, as is the time and effort required; however, if I need to move the items from one room to the adjacent room, I will probably pick them up in small numbers and carry them by hand to the next room, taking multiple trips. What induces a smaller batch size is a set of other factors, like low production cost of individual features, transport, and time taken.

Streamlining this whole value stream from concept to cash, following Lean principles, and eliminating delays and waste is the main goal of DevOps. So why we all don’t have it? Let’s pause for a moment. Reducing the transport cost, as well as the time and cost of developing individual features, requires a considerable investment! It requires an investment in tools, techniques, and knowledge. Additionally, it requires active leadership support for a change of culture and the way people think about software development. It’s not something we buy off the shelves. To reduce the holding cost, the transactional cost must be increased. It is an art to find the balance and decide on the optimal batch size of the features unlike in manufacturing where you can arrive at a definitive number while calculating the economic batch quantity.

A DevOps consultant and a Lean-Agile coach can work together to look at the value stream and identify the areas where investing will make the most impact on the transactional cost of moving the concept to cash. Do your businesspeople need training on how to define and prioritize the epics or features so that they can flow smoothly through the system and quickly reach the customer? Does your development team need to learn and implement certain engineering practices for developing and testing that help in reducing delays and waste? Does your IT operation need to be modernized to reduce the delay and waste it generates? Could customer feedback be collected through usage pattern analysis, audit logs, direct feedback through social media, or even the app store, and then integrated into a flow so that the business, development team, and operation get seamless insight that they can act on as soon as possible? DevOps practices promise a solution for all these areas. BUT there is no silver bullet, and spending money in the wrong areas may not increase the flow from concept to cash. DevOps needs to be planned for the company, as different products may need different DevOps solutions depending on various parameters and people associated with them.

The goal of DevOps is to remove ALL (yes, ALL!) of the walls from concept to cash to enable a smooth flow in a manner that helps in reducing the batch size of features flowing through the lifecycle until reaching the customer.

Through the implementation of Scrum/Kanban/XP and other Agile practices, we removed the walls separating developers, testers and the business in the classical development approach.

Yet in most companies, the IT operation is still working in the ’90s when it comes to its processes, tools, and ways of operating. Even before thinking about implementing DevOps, it is extremely important to consider focusing on creating an IT operation that adopts Lean principles as well as implement the tools and techniques available in today’s world to support business and market needs. This leads to considering the implementation of LeanOps.

Implementing LeanOps requires taking the next step of removing the walls within the operation as well as knocking down the walls that separate the operation from customer application usage and feedback analysis. It also requires adaptive practices that focus on maximizing revenue rather than merely running the business.

This is the pre-stage of implementing DevOps, as DevOps promises the removal of ALL of the walls in the concept to cash value stream and creates a smooth flow of features. If any feature misses a train, it travels on the next release train.

Ultimately, it is important to find the optimal batch size for both a company and a product. Pushing batch size down increases the investment in DevOps, which includes bringing in the right culture across the organization (leadership, stakeholders, business, development teams, operations, and even other departments like HR and finance) as well as investing in learning and tools. If the holding cost is not very high, a larger batch size that doesn’t require frequent delivery to the customer will potentially reduce the cost of DevOps implementation. At the end of the day, the batch size should make sense based on a balanced approach of managing the holding cost, transactional cost, and the ROI that the business is expecting from the software development.

Hello. How Can We Help You?


Our Offices