Over the years, I have been asked by many organizations to assess their Agile software development. In many cases,...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
the organizations think they are proficient at Agile because they use some associated practices, such as daily stand-up meetings. But such a meeting is not exclusive to Agile development -- I've observed plenty of teams holding daily stand-up meetings that perfectly match their waterfall development process -- nor does it define Agile. Agile is indeed a set of practices, but they are the result of an attitude, culture and philosophy.
There is a risk that we could do the same thing with DevOps adoption: implement a few practices without embracing the whole picture. But what constitutes the DevOps attitude, culture and philosophy?
To answer that question, I prefer to look at what has driven the creation of both Agile and DevOps: the need for business innovation. Over the past 20 years, every single major business innovation -- mobile, social, analytics, collaboration, cognitive systems, cloud, etc. -- has come from technology. And, because business innovation is based in technology, innovation moves and changes at the pace of technology. That pace is fast, and it creates mountains of uncertainty. In my opinion, we use Agile methods to deal with uncertainty and we use DevOps to deal with our need for speed.
Now let’s talk about the underpinnings of DevOps. If we recognize that the goal of DevOps adoption is to increase our speed, we can ask ourselves what must be true -- in our thinking, structures and processes -- to increase our speed. My teams are now reasonably good at DevOps. On our way to increasing speed through understanding the DevOps attitude, culture and philosophy, we discovered seven key tactics other should follow:
Train every team on the basics of Lean. Waste -- which manifests in rework, overprocessing, waiting, etc. -- is a drag on our speed. Lean is the science of identifying and eliminating waste. We have done value stream maps of our deployment, software development and operating processes to find waste so that we can reduce or eliminate it. And we have created and follow checklists (in the language of Lean -- standardized work) to make sure that our processes are complete and accurate.
Train every team on the basics of Agile. Using Agile principles and methods, we do short, time-boxed elements of prioritized work. At the end of each iteration, we demonstrate what we have completed -- not what we have almost completed or are thinking of completing. The fact that we are going to deliver something that works means that we could deploy those results at the end of each iteration -- thus the need for DevOps speed. By training team members on this Agile practice, everyone understands one of the drivers for making the potentially massive changes to our IT operations processes.
Measure and improve time to deploy and quality of deploy. A wise mentor once told me that if you measure it, you can manage and therefore improve it.
Eliminate organizational boundaries and barriers. In our case, we couldn't quite get over the DevOps hump until we put our IT operations and software engineering build teams together. We made decent progress with two separate teams, but the magic happened when we combined them. We now use common tools, approaches and measurements.
Be honest about the areas you want to specialize in and what should be left to others. In our case, we had to get over the idea that we were the world experts in managing hardware. This led us to expand our use of cloud services, which increased our speed. (Why spend the time to acquire and configure hardware when that hardware already exists in some cloud service?)
Make a strong commitment to virtualization, containerization and orchestration. DevOps assumes that we can define and assemble the services we provide into a virtual package that we can then move around, scale up and scale down as needed. This is an area that intersects with Lean; we need to have tight processes if we are going to do DevOps well.
Learn from others. Our teams have become heavily involved in local users groups so that we can learn how others are increasing speed.
Adopting DevOps and getting good at it means that everyone -- me, my staff, IT operations and software engineering -- embraces the goal of getting faster and better. It means that we will make the needed changes in how we think and act so that we can lead our organizations into the technology-driven future. That sounds pretty weighty, but since all business innovation today comes from technology, it is on us to change what we do and how we do it.
More on DevOps adoption strategy:
IT operations contends with DevOps
Container automation, smart monitoring become priorities for DevOps
Are you ready to build in DevOps security?