DevOps as an IT consultant

This post was first published on Øysteins private blog blixhavn.dev

After learning about Domain Driven Design, DevOps, Lean work or Agile methodologies, it's easy as an IT consultant to be eager about introducing these concepts at your workplace. You might notice a lot of different practices which are not optimal, or directly in contrast with what is suggested by these approaches.

The problem however, is that you don't see a simple way of introducing these. You might mention some suggestions, but you're often met with resistance and questions rather than enthusiasm. This might feel frustrating, but it is important to remember that your job is usually to fit in with the existing developers, and work efficient in this team - not to bash in doors and disrupt the working dynamics with your god-given knowledge.

It is also worth noting that DevOps is more than a way of organizing your development team.

In its full form, it spans the culture of the entire company, requiring buy-in from both management, customer relations, development, product management and support. Therefore, be humble in your ambitions, and acknowledge that transforming a company to "be agile", or do DevOps thoroughly, is a huge undertaking.

Still though, it is possible to get started on the ground work for introducing a more productive development environment. The first step is to create an understanding of how there are shortcomings with the current state of development. Try to visualize "waste" in the Lean sense, and maybe suggest some small improvements that might move things in the right direction:

• Waiting - for external input, for input or work from other developers. This often leads to multitasking, which introduces an unnecessary cognitive load to the developers. If your planning board has a lot of work items in progress, this might indicate a problem with waiting. See if your development workflow contains unnecessary wait periods, or bottlenecks that could be alleviated.
• Partially done work - related to the above point, a suboptimal workflow between team members and the product owner/QA team or other parts of the team might lead to a lot of work items staying partially done for a long time. Are feature branches being left to stale before being merged? Free up your teams mental shelf space by suggesting to streamline delivery processes to avoid stagnant, partially done work.
• Defects - bugs and poorly written code require bugfixing, rework and refactoring, which is obvious waste: if the code was better, the time could be spent producing value. Suggest concepts like code review, pair programming and required tests to increase the quality of committed code.
• Task Switching - if your work day is fragmented - often the result of waiting as described above - you might lose as much as 40% of your productivity. See what steps you can take to decrease the multitasking being done in your team.
• Over Production - This is often understood as "extra features" in the software version of Lean. However, I also see this as premature optimization, which as computer scientist legend Donald Knuth stated, is "the root of all evil". It is incredibly easy to get lost in optimizing and generalizing your code and components too early - something that in many cases will prove useless and even harmful in the end. Question the reasoning for such optimizations, and maybe remind the team of what the immediate goal of the work is.
  Another point that should go into this category, and which is more coupled with "extra features", is long feedback loops. If the actual users of your software are involved too late, you risk having to redo a lot of features, and even scrap some altogether. Advocate tightening feedback loops, getting user input as soon as possible.

If you can incorporate some of these visualizations in the day-to-day work of the team, eventually it might seep in how some changes might be beneficial, and with this traction, more "radical" ideas could take hold.

In the end, what you want to do is to lay the groundwork for a more generative work culture, where pursuing knowledge becomes the first instinct in the face of failure or problems. Your objective is to convince your team of the benefits this provides. If the company you work at tries to introduce Agile methodologies company wide at a later point, you and your team are prepared!