Some thoughts on planning

Anyone working in the IT industry has seen, heard or said this phrase more than once. Unfortunately, if you in operations then someone else's inability to plan more than likely DOES become your emergency.This remains true even in companies preaching DevOps. The larger and more complex the company, the greater the chances that there is a team somewhere, Operations, DevOps, whatever the name, who's workload is driven almost entirely by interrupts.

These teams often adopt Kanban as a means of making the problem visible but Kanban alone won't fix the problem. Kanban highlights the demands being made upon an operations team and can be useful in improving the work flow but the real problem is in planning.

DevOps at its heart is about collaboration between teams, avoiding silos etc. In a few startups DevOps results in single teams made up of developers and operations people who are in on the plan from the beginning and everyone gets to celebrate at the same time due to a common understanding of "done". At its best DevOps encourages an understanding that a feature is only completed when it is running in production and in the hands of the end user.

In far too many cases, however, companies proclaiming they are doing DevOps have not redefined their definition of "done". In these companies, development teams consider work done when the code builds successfully, or when QA has signed off on it. The task of making this run in production is not considered part of the development process, as a result, what is required to make and keep this running in production is often not part of the plan.

The need for planning is certainly understood by software development teams and forms an integral part of agile methodologies such as Scrum. Developers would revolt if they spent four hours in a planning meeting only to be told three days into a two week sprint, "forget the plan, something has come up and we need you to do this instead." Yet it is considered perfectly acceptable to assign tasks to an operations team towards the end of a two sprint for work that could easily have been predicted in planning.

DevOps Planning

Clearly there is a need for better planning. Many organizations seek to integrate operations people into development sprint planning sessions. This can help but too often discussion focuses around feature requirements from a code perspective and doesn't leave room for considerations of infrastructure. It is often discovered late in the sprint that a new feature requires a change to the Load Balancer for example and this becomes an emergency change for the operations team. To allow operations teams to plan and minimize interrupt driven work, it is necessary to ensure that they are involved in the earliest stages of design discussions.

New features need to be considered in their entirety. Design discussions can not be limited to code implementation. How does the new feature integrate into the application as a whole? What configuration changes are required? Are there new ingress/egress points? Can the existing infrastructure serve the new feature and meet performance requirements? These are all questions that need to be considered as early as possible if we are to make our operations teams more proactive than reactive.