DevOps and Company structure, do we need the reorganization?

DevOps has passed the novelty phase and is now being implemented in larger companies than start-ups or web-shops. The concepts of collaboration amongst Developers and Operations open the recurring question: Can we keep our current organization or do we have to reorganize. In my different discussions around this topic with companies of various sizes this is a recurrent theme and the quest to the 'ideal' organization is the new holy grail.

So, let me ask the following: What do you expect the get out of a reorganization?

• Better collaboration?
• Shorter communication lines?
• Better accountability?
• Increased Productivity?

One of the definitions of DevOps I found is 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 on the culture of Collaboration and Improvement.

From the above we can conclude that DevOps hinges on a couple of key thoughts:

- Make work visible

- Automate whatever you can (without excess)

- Collaboration amongst people is the key

Make Work Visible

Allowing teams to have a shared vision of the work that is being executed to bring a new requirement into production goes a long way to a common understanding of the problems and difficulties that lay ahead. Using a development/deployment pipeline built out of tools that allow a shared view/reporting of the flow of work through the pipeline makes the work and the idle time visible. Teams that can compare their pipeline with other team’s pipelines will have an incentive to keep work flowing and to improve their throughput. Interestingly enough these pipelines also create the trust from management and stakeholders as they have an on-demand overview of the amount of work in flight and a better estimation on when a new feature/requirement will become available.

With a Development/Deployment Pipeline we have a coded way to execute work and apply processes. We are now able to treat infrastructure  (compute, storage, network) as code and benefit from the same processes that have been applied to source code for years, such as team collaboration and change management (including traceability, peer reviews, defect management, and automated testing). The deployment pipeline harnesses all the tools in a meaningful and visible way.

Automate whatever you can

Manual work is the enemy of progress in our DevOps world. It hides work, makes problems invisible and most of all, manual work is not necessarily reliable.

A deployment pipeline leads to a process that is not only faster but safer. You’re looking to  automate most but not necessarily all the process. Deployment procedures, controls, tests, triggers, reactions to monitoring alerts—the deployment pipeline structures your process, helps you communicate it, and (most importantly) improve it.

Test Automation is the place where a lot of teams fail, relying on manual testing or on tests that are performed only at specific times/moments in the development/deployment of an application.

Investing time in automating tests is a must to make work and the quality of this work visible.

Automation also provides fast and meaningful feedback to operations and developers alike. A failed test or deployment done by an automated process with adequate monitors is a valuable data point that allows process and tool improvement and over time a great quality improvement of your application and your operations alike.

Collaboration amongst people is the key

To implement DevOps, you need to enable collaboration across functional boundaries.

Here, people are key. Deployment pipelines enable collaboration, continuous improvement, and lower the walls between the boundaries. Everything becomes visible: the changes going through the pipeline, the triggers, the feedbacks, the gates. Deployment pipelines bring people together.

So back to the initial question: Is a reorg necessary?

I would like to say no, collaboration is necessary not a Reorg. Collaboration can be done around Pipelines and can be enhanced by a free access to information on the health of the development/deployment/operation/monitoring tools/pipeline.

Do not rely on e-mail or meetings, set up Chat rooms in an appropriate Chat tool. The free flow discussions in these chat rooms and an intelligent use of robots in these chatrooms does far more to the team collaboration than a reorganization would be able to accomplish in our current enterprise environments.

Reorganization 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 reorganize, 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.

Author Arne Luhrs is one of the very interesting keynote speakers in DEVOPS 2017 line-up. Arne is working as a Team leader and Architect in HPE. Arne is responsible for the transformation to DevOps of the teams that provide services to the HPE Product development and research community. He is driving and implementing the quality management tools and software that is used by over 50.000 employees. We describe Ahrne as a thought leader and brilliant keynote speaker in the area of DevOps.