The Time-To-Market is between two cups of coffee

But how can such a short time-to-market be implemented? How can an idea from the morning already reach the first test customer in the afternoon? Or how can I close a bug in the production system perhaps even within a few minutes?

The requirement for this consists of three essential components:

• high automation
• cross-functional teams and
• a philosophy of learning.

A fast rollout only works if as little manual intervention as possible is required.

Continuous Integration and Continuous Delivery

A first step in this direction is software development based on Continuous Integration (CI): This involves checking in the source code and building it automatically, determining code metrics to determine quality, and running automated unit tests.

A second expansion stage is the automatic rollout, i.e. Continuous Delivery (CD). The built source code is automatically brought to the target environments.

Test automation

The automation of tests is the top priority of the hour: Manual integration tests by clicking on interfaces no longer take place. The role of the classic tester is therefore shifting more towards the test software developer or test scripter.

Even for small projects it is advisable to start directly with test automation: On the one hand to avoid manual steps, on the other hand small projects often become larger than expected - and the later development of test automation can become expensive.

Multi-Environment Deployment

The CD pipeline can span multiple environments. After code checking and successful build, delivery is made to a test environment. There, the CD pipeline then performs automated integration tests. If no problems are encountered, the rollout is carried out directly to production - ideally without human interaction.

Concepts like Canary Deployment help to make new code in production available to a small percentage of users first. If the new feature works, it is gradually made available to more users.

Cross-functional teams bring together colleagues who work together on a topic-related project. The team unites all roles that are needed for the project. Existing silos are broken down: The team of developers, the team of testers, the team of operations - all of these no longer exist in Cross-Functional Teams. Instead, small thematic teams are created that can represent all of these roles.

A basic idea of DevOps is that developers (Devs) and operations staff (Ops) form a joint team and can thus address the problems of the respective work area directly from the start. For example, operations places high demands on the monitoring and logging of an application. In close coordination, these can be taken into account directly by the developers. Operations specialists also know the typical scaling problems that should have an impact on the application architecture.

For technical decisions, the customer or product owner (Biz), bring their expertise to the team. Often forgotten, but equally important, are testers and security experts.

End-2-End Responsibility

This team now works completely autonomously on a thematic area. For example, it develops a decoupled microservice and is able to roll out a new version at any time, ensure testing and operation, and drive forward development based on customer requirements.

Each member of the team still has their core competency. It's not about developers taking over operations in the future. Even if the team structure automatically leads to a better understanding of the previously unfamiliar areas of responsibility. Rather, BizDevOps ensures that interdisciplinary collaboration and communication is improved.

This is also accompanied by a new freedom: The team can organize itself and choose the best way for implementation and operation.

At the same time, responsibility increases: The team is responsible for its service end-2-end. Everyone is called upon, for example, if there are problems on the production environment. There is also a suitable DevOps principle for this: You build it, you run it.

Current organizational forms such as complicated processes or strict division of tasks often consist of fear of making mistakes and a lack of trust in one's own employees.

However, only those who are not afraid to make mistakes have the courage to try out new things and address problems. Innovation needs the support of colleagues and the courage of each individual to want to create something new.

It's not for nothing that one DevOps principle is: fail fast, learn fast.

That's why I advocate establishing an open error culture: Mistakes are allowed to be made. The important thing is that they are communicated so that everyone can learn from them.

In addition to individual mistakes, metrics need to be collected to measure the success of the team's work: Is the new code better than the old code? Do the new features make our customers more productive?

Having an idea at the coffee machine in the morning and the first customers using the feature in the afternoon? For a team with freedom of action, which uses automated processes and is not afraid of making mistakes, this is not utopia.

If we additionally derive from customer behavioral data how we can make life easier for them, the result is a truly innovative product with a short time-to-market. Customers are happy to commit to such a product - one that really aims to help the user.

The three principles presented are a small part of the DevOps culture. For several years now, these principles have been changing not only classic product development, but entire company structures and collaboration concepts.