In a study performed for my colleagues from HPE Software and available at, YouGov interviewed 403 development and IT professionals from 500+ employee companies in all sectors, except ISVs and Education. Their conclusion, the DevOps mindset is more important than formality. Organizations who approach DevOps as an ongoing journey, a series of pilots and experiments, are the most successful. The mindset is more important than the formality. Why is that the case?

Where are we coming from?

What I’m going to describe here is a caricature, but in many organizations it was pretty close to reality some time ago. Or it was at least the feeling many non IT people had of how things worked.

Not that long ago, when the business needed a new function or some changes in the systems supporting them, they had to describe in simple words what they required. This was called the requirements definition. In some companies they got the help of business analysts, people that had the hard job to be interfaces between business and IT. That requirements definition was then handed over to IT. A guy with a ponytail (smile) picked it up and it disappeared in a black box. Nobody really knew what happened to it. And then suddenly, 6, 9 or even 12 months later, something that was supposed to be the answer to the requirements definition was produced and business was told to sign off on the request. Whether it addressed the original demand was one thing, but more importantly, over the waiting period, things had evolved. Due to the lack of visibility and contact in the interim period, that was definitely not taken into account.

If you are in IT, you probably think I’m going over the top here. You might be right, but I can only draw on 37 years of working in a technology company. And I have seen plenty of that happening.

The good news is that things are changing. The need for faster reaction to an ever more digital business, the availability of new technologies such as cloud and the increased availability of IT literate people in the younger generations have undermined the “IT fortress”. One of the phenomena is what is often referred to as “shadow IT”, the utilization of IT services outside the control of the actual IT department.

The introduction of agile development approaches has removed the barriers between the business and IT teams. It has resulted in the business participating with IT in Scrum teams to ensure the functionality developed by the team is aligned with the needs of the business. However, this does not resolve the development/operations cultural differences. Where developers are looking for new technologies, new approaches, creative ways of doing things, the operations teams are all for standardization, consistency and stability.

This is where DevOps plays a role. It consists in having development and operations working together to enable a fast and smooth deployment in production, allowing business requirements to quickly be addressed within the enterprise IT environment.

Automation requires tools

To speed-up the process automation is deployed at all levels in the development, testing and deployment of the applications. Tools are used to support those. Many companies rely on open source tools to support the automation. A large collection of tools exist and new ones are appearing on a regular basis. The actual lifecycle of most tools is short so over the years you will probably change tools. But that is not the most important aspect of DevOps. It’s more about how you get the teams working together and using the tools, than on implementing a collection of tools. As mentioned at the start of this blog entry, experimenting with DevOps brings more benefits rather than rolling out the tools.

A collaborative approach.

DevOps has three main components:

  • Continuous Integration, addressing the automation in the development cycle, covering automated build, deployment on test platforms and execution of a variety of automated tests with the objective to develop high quality code addressing the needs of the business
  • Continuous Deployment, covering the release process and the actual deployment in production. Here is where development and operations actually come together to bring the functionality in production as seamlessly as possible.
  • Continuous Operations, covering the post deployment operations cycle, including the monitoring of the application and its environment to assess the quality of the code developed amongst others.

DevOps builds extensively on the manufacturing heritage and includes a continuous assessment/improvement cycle. It relates very much to Deming’s Plan-do-check-act cycle. Here is where lean and six sigma approaches are taken to constantly assess how the processes above can be improved.

Where traditional approaches build on well-defined processes in which each individual has a specific task to execute, the agile/DevOps approach is built around teamwork, trust and initiative taking. The diagram here under nicely shows the change in culture required to address such approach:

DevOps Culture

One of the definitions of DevOps I found sounds as follows: “DevOps is a culture built on collaboration and communication across all IT professional units and key stakeholders while automating the process of software delivery and infrastructure change”. To me it clearly identifies what DevOps is all about and why implementing it should not be focused on tools. But we need to recognize that this is counter intuitive in large organizations. Having self-organized teams crossing operational boundaries working closely together and taking decisions is not exactly how many large companies are operating. Self-organizing teams lead to multiple variations in processes, to the need of having to trust the team. Many current managers have difficulties with this.

Do we need to re-organize IT?

One of the main questions I get is whether IT needs to be reorganized to work in a DevOps environment. My answer is simply no. Re-organization would ease the work at one moment in time, but as projects evolve, the teams working together are constantly changing, so you would end-up in constant re-organization. So, don’t re-organize, but ensure your management gets conformable with a new way of working and measures their staff according to the value they deliver to the whole organization, not just to their department. And that is the difficult part. Here is where DevOps fails. If top down alignment clashes with bottoms-up self-organization, DevOps will not work.

On the other hand, if management and their staff truly embrace the collaborative approach of DevOps, not only will you have the benefits of DevOps as such, but you will also have a highly motivated staff that wants to work in this environment and attrition will probably be much lower as the staff feels recognized, trusted and rewarded.

How to get there?

The next question you have is probably how to get there. Not to make this blog entry too long, I have addressed that in a second part. Remind yourself that DevOps is not so much about tools than about enabling developers and operational teams to work closely together in an open, communicative and rewarding environment. They have the possibility to change things and make it work.