I have been in many rooms, and at many conferences, where vendors are selling perfect software. No matter the problem, there’s a piece of software you can buy that solves it. I’ve heard hundreds of similar experiences over more than a decade in IT. After all that time I can safely say, there’s no silver bullet. Solving problems is hard. Understanding their causes is harder.
Many consulting conversations start with a customer asking for a solution to a particular problem. Good consulting is understanding that while the customer wants this problem solved, they may not have the tools to identify the underlying cause. Sometimes a problem is pretty straight-forward (e.g. “We’re going live in 2 weeks and our system doesn’t perform as well as we need it to.”). Other times, however, there are unseen and unspoken causes that lead to the request (e.g. “Automate our deployment pipeline” is sometimes an attempt to address Development, Operations, and the Business not communicating effectively). In order for the problem to go away over the long term, the underlying problem needs to be addressed – brought into the open, explored, and resolved. This can be difficult, as some customers don’t want to talk about anything other than the superficial engagement. Other times, it can be difficult because responsibility for the problem lies, at least in part, outside the sphere of influence of the customer. It would be remiss, however, to not raise any deeper issues discovered during exploration phases, if they impact on the problem being solved.
Customers ask for automation, continuous delivery, and DevOps practices. But without addressing the underlying problems, we make poor use of tools, or apply them to the wrong problems, which ultimately codifies and automates failure. Most of the challenges aren’t in poor tools, but in systemic challenges. Addressing these issues is a key component of organisational success.
Deming told us that 95% of individual performance is determined by the system (e.g. Red Bead Experiment). Most of what we do, most of what the people we work with do, and most of the results, are determined by how the system has been built and maintained. And management creates the system. Both management and front-line staff are trapped by the system, but only management has the ability to change it significantly.
We perpetuate the systems in which we find ourselves. Prevailing management theory (i.e. Taylorism and its descendents) focuses on optimizing individuals – individual actors, individual teams/silos. The assumption is that by getting individuals to do their best, the entire system does its best. This is demonstrably false (see The Goal for clear demonstrations of when and how this fails).
DevOps, and Agile before it, attempts to change this narrative. Instead of talking about using processes to get the most from individuals, it talks about flow. Instead of units of work, it talks about customers and collaboration. It puts focus not on optimising the things each person does best, but on how information (in the form of code, much of the time) flows through the system. A good DevOps implementation will change how teams work. It will cause realignment that helps Operations and Development work together, with the result being shared responsibility and ownership of performance. This works brilliantly inside a team, or small group of teams. And it often finds a champion in management, who can help perpetuate it throughout the rest of the technical teams.
Now that information is flowing well, it’s an excellent time to introduce tools that complement the process. The best part is that with Development, Operations, and the rest of the business communicating effectively, it’s easier to see where automation and speed will help.
Each organisation is different, but tools that can be used to visualise work (physical cardwalls, Trello, Jira) are very good for reinforcing collaboration. Predictable deployments are more likely when the deployment pipeline and testing have been automated. And communication usually remains good when teams that work on the same functionality all sit together in one place.
How you fit these ideas and processes into your organisation depends on how your organisation works. Before bringing them in, make sure it functions the way you want it to.