Historically speaking, IT has been composed of silos. This has worked out rather well over the last half century or so, as one team developed systems, another kept them running, another handled security and yet another managed the infrastructure. But it was never nirvana. Working well is not the same as cannot be improved.

It was the best coach I’ve ever had!

The Growth of DevOps Into this static hierarchy of work-performed silos came agile development. Agile addressed shortcomings in traditional development methodologies by breaking problems into smaller pieces and implementing those small pieces quickly. It allowed for a faster check on quality/completeness of those smaller pieces, and tracking the smaller pieces allowed for better prediction of timelines. Soon, automated testing was thrown into the mix with agile, so developers could receive faster feedback on their changes and address any issues turned up by automated testing while the chunk of code was fresh in their minds. This lead to teams building more and more of the build/test/deploy process into a system that became known as DevOps. As the change from Agile to DevOps occurred, it became more and more important for communications to happen between teams —Development, Ops and Test—not only to get automation into place, but also to keep things flowing smoothly. Which brings us to today. Today we have tools to automate just about the entire application life cycle. And while you were reading that sentence, a new tool was released.

DevOps Culture Definition The problem with this plethora of tools is not that they’re useless—some of them are downright astounding in how they help us develop and deploy software faster, and some increase the quality of the code we are shipping while not increasing timelines. The problem is that in the old, siloed world, these tools are never enough—problems that occur often have Douglas Adams’s famous SEP (Somebody Else’s Problem) field wrapped around them. This is where DevOps culture comes in. Martin Fowler has a good discussion of culture on his blog, it’s worth a read if you haven’t seen it before. Whether an organization sets out to change its culture or sets out to automate with DevOps tools, a certain amount of culture change is going to happen. That is because lines get blurred relatively quickly if the focus is on turning out high-quality software at velocity.

DevOps culture is teams working together to achieve the goal of delivery in ways that they would not have a decade ago. Communication is king, and is usually the start of culture change. Operations providing immediate feedback when development makes a dependency assumption might be a starting point, then Development starts including Operations in decisions to build in dependencies. Eventually, whether by design or need, teams become reorganized based on the application or application portfolio they are supporting, and the lines between Development and Operations blur into DevOps, where everyone on a team is working closely to achieve the goal of rapid development and deployment of software.

Culture change can take the form of operational changes, wherein team members start to work more closely together in the absence of major restructuring with the goal of making software manufacturing and deployment better. Culture change also can be formalized, with reorgs of IT to put together teams that will manage an application for the entirety of its life cycle, and Dev/Ops/Security/Infrastructure members are all working together, not as worried about boundaries as in a traditional IT organization. Both are DevOps culture change, though most who specialize in DevOps think the first form is just the early stages, and the second is inevitable in a DevOps shop.

The long goal of DevOps is to increase the rate of new feature development, reduce the rate of bugs and improve response time to serious issues. Culture change is the vehicle that drives these changes. Automation tools can do some, but increased collaboration means increased response rates to all of the above issues, and that’s where true improvements start to show. More advanced DevOps implementations include business unit owners in the feedback loop, giving them instant access to information about the state of the applications they are responsible for and allowing them to adjust as market conditions change. This is another increase in the mostly communications front that provides customers with more reactive/adaptive solutions.