Managing a DevOps Transition
It's a cultural and organizational change that presents management with special challenges.
To quote the widely used acronym “CALMS,” DevOps is a combination of culture, automation, lean flow, measurement and feedback, and sharing and learning. It is about using thinking systems to improve the flow of value. Those who use DevOps to refer only to release engineering don’t really understand the concept.
Therefore DevOps is very much a transformation of the organization, a new way of working. When an organization goes through a transformation of culture, behaviors and system, there will always be significant management implications.
The Human Rate of Change
Patience is essential. The human rate of change is measured in years. Remember the Normal Distribution of human behavior—the “bell curve.”
Innovators and early adopters will be harnessed quickly to establish some proof points, but the early majority and late majority will take their time to come on board. The tail of the Normal Distribution is often called the “laggards,” but a less pejorative name is “conservative.” People have a right to be conservative in their thinking, and some of them need to be around as dampers on the system.
One of the most wonderful aspects of a DevOps transformation is that so many people blossom when they are empowered, trusted and put into a healthy system.
— Rob England, The IT Skeptic
Evolution Not Revolution
It is important to allow people time to come on the journey. The probability of success of “big bang” cultural and organizational change is low. Everyone has negative experiences of organizations that tried to change too much too fast: Team dynamics get disrupted, morale is shaken and processes have to form again. It is not unusual for the baby to be thrown out with the bath water. It can’t be done right in one rush; organizations need to evolve and explore.
Don’t Rush to Reorganize
Changing the organizational structure of a business can have a negative impact, especially if it is not well-thought-out, well-informed on how things work and carefully introduced.
The ability to reorganize an organizational structure wisely is an outcome of developing sufficient maturity in the new way of working to be able to identify effective reorganization ideas. In other words, organizations shouldn’t rush into reorganization, and they especially shouldn’t start with it. There is some argument for early establishment of standing teams to do work, but even then it is better to create virtual teams without disrupting formal organizational structures until owners are fairly confident of a stable organizational configuration.
Flip the Hierarchy
If an organization draws the management hierarchy above the value stream map in a rising pyramid of bosses, then they need to “flip the hierarchy.” Management should be considered as some of the necessary non-value “servant leaders.” Don’t tell people what to do; instead, allow the people doing the work to make the decisions, and then support them by removing obstacles and getting resources.
Waterfall development was abandoned because of its failed assumption that development teams can perfectly describe in advance that which they are going to build. Likewise, it must be understood that when implementing a new culture and approach such as DevOps, teams will need to iterate and explore. Such early experiments almost always lead to failure, but failure must be welcomed as an opportunity to learn and to add to the organization’s knowledge base.
Dr. Sidney Dekker (The Field Guide to Human Error) says you should thank those who break systems: thank them for finding the weakness in your system so that you can prevent it from happening again.
Victims of the System
One of the most wonderful aspects of a DevOps transformation is that so many people blossom when they are empowered, trusted and put into a healthy system. Often, people exhibit negative behaviors and become blockers because of the position they are forced into by a dysfunctional system: They are “victims of the system.” The classic example of this is change or release management, which often becomes the last line of defense for production if the system is producing poor quality.
Fix the system: “Shift left” so that quality and compliance are ensured earlier in the flow, then Change and Release people will start to behave in quite a different way. As the system improves, expect better of everyone.
Create a Learning Organization
The object of DevOps is to produce work both faster and of higher quality. A system can only go faster with better feedback to keep it stable, and improvement only happens when there is feedback.
An organization must treat continual improvement as foundational, not just as some housekeeping process happening in the background. Continual improvement is not a thing that one does; it is how one does everything.
Capture data and learnings, feed them back to the appropriate recipients quickly and measure improvement.
Ultimately, DevOps is about starting from an assumption of human goodness. Expect the best of people and empower them accordingly. Knowledge workers must be treated differently than clerical workers. Decision-making must be distributed to the front line, and managers must act as servant leaders. The professional is honored. People are treated with respect and trust.
This is difficult for a management culture accustomed to a command-control hierarchy, and systems based on distrust and tight governance. DevOps implies as much transformation of management and governance as it does of systems and working. Managers need to change radically.