Why is DevOps important for business managers?

As a business manager you spend the working day focusing on everything from sales figures and customer satisfaction to employee experience and product range. You’re probably also keeping a close eye on the online sales conversion rate, delivery process, and accompanying marketing costs. But, are you taking enough interest in the value, quality and development of digital services? 

There are many different types of quality: speed, reliability, flawlessness and scalability for different devices. Is quality the sole responsibility of the IT or marketing department? It really should not be, especially when we discuss online sales. And what sales or purchasing process does not begin with an online channel these days? Potential customers go through their decision making process as they get to know the service providers. For this reason the development of digital services becomes particularly important when the product itself is a digital service.

DevOps is intended to automate IT service functions related to software development, testing and maintenance. It is important to note, however, that automation does not mean that costs are automatically reduced. The DevOps model enables two things that are crucial to a business manager: quality improvements and fast value delivery, also known as Zero Day Delivery.

Including test automation in the software delivery process is crucial; software is tested frequently, ie. systematically, and regression or new failures caused by changes to the code base are captured by the automated tests.Test automation and Robotic Process Automation (RPA) can be implemented in most software projects, but they need the input of team members with high-level knowledge of automation possibilities. Well-designed test automation goes beyond checking critical components and basic functionality. It should understand that a product or service is usable and works as designed within unusual situations.

With DevOps practices the process linking the development environment to the production environment can be automated. That said, the organization's culture may still want to add manual steps to the delivery process. Ideally, used services are integrated and insights of changes and their effects are traceable and everything can be rolled back, although it's better to go forward and fix the challenges. The main challenge is to agree with the business on how to verify a change automatically, using a well designed delivery pipeline, so that everyone has confidence in the software quality.

If everything is automated doesn't that reduce costs? Yes, in the long run. Developing automation takes time and money, but as manual work is automated the re-loops of various activities become cheaper.

The role of the tester starts tending towards automation, but unfortunately manual testers rarely develop into automation testers. Nevertheless, there should be skills, or at least interest, in coding or scripting and manual testers will be good at defining how the system should work from a workflow perspective. Team members agree on development practicalities that support best development practices and that decreases manual work.

The customer starts to benefit from automation as the project becomes more transparent, changes are deployed to the production, and it is known which features are being used by the end users. The development team can focus on their work, challenges can be fixed quickly, and releasing a fixed version does not require additional work.

Improving predictability and transparency

Wouldn't it be great to know in advance when a desired feature is creating value for your customers and, consequently, for your business? DevOps improves predictability from both a technical and non-technical point of view. As described earlier, new features are verified automatically, installations are not error-prone to human interaction, and activities are logged. It is also important to maintain transparency over the future development activities. Maintaining the backlog, prioritizing it efficiently, and recording all activities helps to predict the project's future as well as enabling retrospectives. Requirements are defined by someone and they have criteria. The criteria of a change should be clear to everyone participating in the development activities. 

I'll now focus on the decision-making part of the process. One commonly used method is to divide the things to be developed into four levels. For example:

Theme: Business-oriented goal for the product. The business owner owns and prioritizes the theme with the product owner

Epic: Large chunk of work that enables the feasibility (S-XL) and viability (business value) of a clearly defined value generating functionality to be evaluated. The product owner owns and prioritizes the epic with the business owner

Story: Something a user can accomplish with clearly defined “Definition of done” (DoD) and effort (story points). The product owner owns and prioritizes the story with the development team

Task: A single milestone in getting the story done with time as an estimate. The task is owned and prioritized by the development team according to agreed methodology within the team.

These categorizations relate to the decision-making process because they give the business owner oversight of what the development team is doing. This means they can prioritize the development theme and the epics beneath it while retaining the freedom to quickly change direction if required. If development starts heading in the wrong direction wasteful tasks and stories can be easily abandoned and work reprioritized. 

It is also good for the development team's motivation that random issues do not appear in the sprint backlog. There should also need to be some space reserved for critical work or tasks that should be implemented immediately. Randomly appearing tasks are seldom of any true value. They are often poorly prepared and result in wasted time and money. Systematic development takes time and if preparation is not prioritized by the relevant stakeholders the outcome will be inevitably poor.  

DevOps also allows a certain degree of transparency in costs. The best work focuses on maximizing customer value and automating unnecessary manual tasks, which relate to improving business results. In this case the business owner and the product owner spend money wisely and the results matter. Measuring customer value is difficult, but it is easy, for example, to look at inbound money and conversions in an e-commerce store and mirror them in the amount of money spent on development.

Changing culture

The change will not be managed. The change will be made. One of the barriers to successful transformation comes when top management entrusts a single person with the task of changing the way the organization does things. The management itself then follows the change through steering group meetings, management group meetings, and powerpoint presentations. This approach will probably not lead to best success.

Instead, management should use sprints in their own work. This would give them first-hand experience of working in the newly adapted ways. It would clarify in their own minds what is being asked of the organization as a whole and provide them with direct experience of the benefits of a systematic, goal-oriented, and structured way of working. Of course, it's not realistic that all senior management jobs are planned for a week or two, but some are and can be treated as sprints.

Using tools without understanding the value they provide will not lead to success either. For example, Lean often goes wrong if the focus is on tools and methods rather than Lean values. SAFe is applied to some parts of the organization because of its trendiness in the software market.

One form of cultural change is early failure. It's the best way to save a lot of money on development. When concepts are validated often and at an early stage only valued features are brought up to the development backlog. However, people often rely too much on their own ideas and insights and are unwilling to show unfinished solutions to end users, even though it would be beneficial and effective. At this stage, the lowest-cost development ideas and the service to be developed are truly relevant to the customer's needs.

DevOps and Agile development

Often, DevOps is thought of as a variety of tools and practices, such as test automation, release pipe optimization, and making the deployment status visible to developers through monitoring. That’s all true, but these are not one-time development activities. Instead they should be constantly under development and optimized according to the changing needs. 

A good approach would be to have an occasional, dedicated "technical sprint" whenever there’s a focus on technical improvements and tool fixes, etc. It may not be possible for the entire development team to be involved, but it should be a team activity, ie. relevant experts are brought in when needed to solve issues that others can't solve efficiently. However, it is important to include "maintenance" tasks in your sprint design so that you can be prepared for any interruption in the use of your tools, and show the entire team at a glance what changes have occurred.

DevOps enables Agile development. Full time, continuous value creation can only be achieved when time and energy is not wasted on manual work steps or on problems with tooling. And to fully realize that idea the management needs to lead from the front, and practice what they preach. To find out more, read this blog "Agile vs. DevOps: the grand debate."