If you’re thinking to embark on the DevOps journey or, may be, you’re already in the middle of one, ask yourself and your organization what the DevOps means to all of you. Your organization needs to decide how it sees DevOps – is it a “function” or a “culture”. 

The original definition of DevOps is well described by it’s second name CALMS (see DevOps Culture Part 1 and Part 2), which stands for:

  • Culture
  • Automation
  • Lean
  • Measurement
  • Sharing

DevOps culture proposes, when the whole organization is interested in success of the product, in order to increase the velocity and shorten the feedback loops, an organization has to break silos and enable development organization to own the whole life-cycle of the product end-to-end. Portion of the breaking silos calls for full integration of functions and responsibilities like Dev, QA, Release Engineering, System Engineering, etc… into a single cohesive development organization.

This part of such culture transformation is least understood and creates, in my opinion, a greatest point of friction with the DevOps denialists. This is happening because the main message from the DevOps industry leaders (like Netflix, Amazon, Etsy, Facebook, Twitter, etc…) is that a real DevOps organization should have engineers owning the product end-to-end starting with the coding, testing, releasing, deployment and operating the product in production. A successful DevOps organization hires and grows engineers to be generalists.

This message gives a great ammunition to the DevOps skeptics and denialists. You can hear their counterargument very loud and clear: “we don’t believe that developers can know everything and, by becoming generalists, they do not provide high quality results”. This drives them to the conclusion that the DevOps should be a function or a team responsible for the part of the release engineering, deployment and system operations. This conclusion denies the idea of the integrated organization and creates yet another functional silo separation.

Between these two sides of the isle the conflict lies is in the definition and the meaning of the following 2 terms: “generalist” and “know everything”. I believe we can resolve this conflict if both of the sides will keep an open mind and establish common grounds through laying a set of commonly agreeable rules, assumptions and standards.

I hope both sides can agree on the following:

  1. Everyone is looking for high quality results. Mediocre people, bad quality and half-finished tasks are not acceptable.
  2. Organizations expect that engineers will continue their education and will continually keep up-to-date with the innovation in the industry around new practices, tools and technologies. Leaders are supporting and encouraging this behavior.
  3. Companies are hiring smart people with great potential and ensure that the teams are growing their experience and expertise. Over time these teams become self-sufficient and self-motivated to see the results of their work in the hands of happy satisfied customers.
  4. The teams are motivated to satisfy business and customers’ needs as fast as possible to keep business afloat and competitive.

These points are ultimate goals and all companies are somewhere on the journey to achieve these goals. Those who will say that all the above is a “wishful thinking” they are still on the journey, but just at the very beginning of one.

These points are dictated by a common sense. Every company is looking for business and customers’ success. So, in order to reduce the company’s reaction time to the changes in the market or customers’ requirements, the company’s organizational structure should be optimized for that specific goal and should employ Agile practices. Such company should look to reduce wasted waiting time and simplify scheduling of the dependencies by analyzing the throughput and efficiency of the delivery process end-to-end and optimize the bottlenecks. This method is well described by the Theory of Constraints introduced by Eliyahu M. Goldratt in his 1984 book titled The Goal.

When an organization employ specialists, who are used to solve specific narrow-focused specialized tasks, the coordination and scheduling becoming a bottleneck on its own. The bigger organization and more complex the system it is building, the harder and more complicated it is to discover, plan and resolve the planning dependencies. In the software world the dependencies are discovered mostly at the last minute. Developers discover that something is missing after they have started to work on a specific feature. The realization of such fact (last minute discoveries) was one of the main reasons the Agile practice was invented. Agile practice tries to reduce the waste and to limit it to the size of an iteration.

The complexity of planning and coordination grows with increase in number of the agile teams. Communication channels are stretching and dependencies are increasing. Teams are starting to wait more and more on each other and more time is wasted within sprints. A whole industry, called Project Management, was invented to relieve the complexity of planning and to resolve dependency conflicts. Project Management helps you so far and, instead of delivering value to your customers, teams will be spending more and more time on planning and coordination. The success of planning is directly dependent on the clarity of the dependencies ahead of the time. This requires more and more research and discovery executed ahead of the time than it is needed. By the time the teams reaching the point in time when such information, in fact, is needed they find it very partial, outdated and not relevant due to the accumulated changes in the environment. This brings us to back to the Waterfall model and goes totally against the Agile approach. This IS a classical waste problem that Agile tries to solve.

So, to simplify the scheduling and to reduce conflicts and time waste, organizations are well off with Agile self-sufficient teams. Such teams should have all the necessary expertise to successfully execute tasks they are responsible for. Agile teams are better off when they are comprised of generalists, generalizing specialists and specializing generalists. All the necessary people that cover all the possible knowledge domains like business, development, testing and operations. Such teams are scalable and can be deployed anywhere at a moment’s notice. (Note: Read more from Disciplined Agile Delivery authors in Five tips for assembling successful Disciplined Agile Delivery teams)

This explains what the DevOps leading companies mean – they are hiring and growing talent to know a lot about a lot of different things. In some areas the engineers will know more and in some areas they’ll be just comfortable with. Over time and with the growing experience the knowledge balance evolves and shifts to different areas (check out Generalizing Specialists: Improving Your IT Career Skills). So no one assumes that everyone can possibly know everything, but prefers talent that knows a lot about a wide variety of topics.

This approach doesn’t deny existence of specialists. Having access to the right top level specialists is very beneficial to any organization. This approach simply tries to treat such specialists as a scarce resource that is, according to any planning theory, should be available for others to tap in at a moment’s notice. This means that the utilization of a “special” resource in day-to-day planning should leave enough capacity for emergency or unplanned work. If some task or project is on fire, you can deploy specialists to mitigate the issue. Hopefully your long-term tactics works to reduce number of fires over time. This gradually increases amount of underutilized time of the specialists. Consequently this is a very good effect – use this spare time of your specialists to introduce training into your organization as well as task them with long-term goals of reducing chances of fire and improvements in the day-to-day processes. This usually leads to development of more sophisticated and simplified automated processes, which, in its own, pays back into the overall velocity of your organization.

To summarize, no one claims that everyone should know everything and no one denies benefits of having specialists. The teams benefit of having generalizing specialists and still need access to the top level domain specialists at the right place and time. Optimize for the overall flow of the value throughout your organization by reducing planning conflicts and unblocking teams by bringing knowledge closer to where it’s constantly needed and used. Beware of the unqualified people and hire the best talent.

So, please, keep an open mind and do not latch to the bare meaning of the words while ignoring the rest of the context. 

Would love to hear what are your opinions and will greatly appreciate to hear your examples and stories.