Planning your team vision is difficult. Add in mature DevOps practices, and your organization can look very different from how you planned it even a few weeks ago. The very nature of DevOps creates challenging and fast-moving environments. DevOps done right lets us reap the benefits of this environment, and the results can be fascinating for everyone involved, especially for end consumers of your product.
Why DevOps?
As in many cases, a simple internet search of a term will get you lots of varied definitions, DevOps is no exception to this. We see varied opinions on what DevOps means, what is involved in making it work, and how to make it work. One of the best summaries of DevOps, from Microsoft's Donovan Brown, which I believe gets to the heart of DevOps, is that “DevOps is the union of people, process, and products to enable continuous delivery of value to our end users.”
DevOps is about fixing things that are fundamentally broken. It takes into consideration the quality of software releases, software development processes, and operations. If these are questionable and operations teams cannot support software being developed, it can make for grim reading, ultimately affecting the longevity and brand of your company.
Concepts like test-driven development, Agile, Kanban and Scrum have all fundamentally changed how software is developed, enabling teams to add value very quickly. Many teams struggle to deliver that value to their users, taking the output and deploying that output is a challenge many organizations still face, leaving the value of the developed software stuck in non-production environments.
To this day, the biggest challenge I always see for any organization on their DevOps transformation is the change in culture. Process and tooling are two things which can easily be sorted, what is much harder is the cultural changes, this is what requires the most investment and is the critical cog in making the transformation to DevOps a success.
Why is it hard to scope a DevOps project?
So what is a DevOps project, and can you even have a DevOps project? When we discuss the implementation of DevOps within organizations, that is not a project. It's important to understand that you should be learning and considering feedback from your processes and teams continuously so that you can improve your organization and deliver better value.
DevOps is like an assembly line, something drops on it, and you work on it until it’s no longer a problem. From very early in my career, I was taught to fix what hurts you the most, pain points. Then the next thing will drop, and you need to work on that.
If you are talking about organizations working together to deliver something tangible then fundamentally the biggest difference between DevOps and traditional projects will be how you write the contracts which depend on the scope of work. Remember that DevOps has no start or end, deliverables at the start of the contract are likely not well-defined and will evolve in time.
In Agile, we use terminology such as Epics and Features to define larger pieces of work. User stories and tasks define smaller pieces of work. When writing contracts focus on your epics and features which should be fairly well defined without the detail of how you will deliver that work as it’s probably not defined yet.
Value of DevOps
Realize that DevOps is not something you can simply obtain off the shelf. It is not commercially out of the box software you purchase and customize. Your organization doesn’t all of a sudden practice DevOps.
DevOps is much more than just the automation of tasks. It’s also not just about delivering new releases faster. The ultimate goal is value. To quote Donovan Brown once again, “the value we produce must reach our end users”. If we don’t deliver any value, then we still fail as an organization.
The ultimate goal for a leader is to have people leverage automation and tooling to continuously and sustainably deliver value through software to our end users. This is DevOps.
DevOps and Business Continuity Planning
I put up a Tweet asking followers what the biggest changes would be for DevOps in the coming months. An ex-colleague of mine replied broadly with a statement along the lines of what I also believed to be true.
The difference between the organizations that succeed through any crisis versus those that fail is having a business continuity plan (BCP). Those that falter in the face of emergencies and unpredictability lack BCP plans. It’s important to know that disaster recovery (DR) and BCP are two different things. DR does not keep the business running; it enables systems to continue running. If you’d like to learn more about DR planning, see this resource.
Let’s think about BCP in a DevOps context now. Hundreds of agile organizations worldwide have implemented DevOps to unify people, processes, and technology to deliver better value to their end-users. At the end of any crisis, organizations with this in my mind will do better than those who have not. Put simply, organizations that can react to changing conditions and requirements will do better than those who do not.
One pattern to any crisis is a large amount of outsourcing of BCP projects. Money is flying down from boards around the world to put plans in place and ensure the business can better cope with emergency scenarios.
Most BCP providers will likely be large consultancy organizations who cannot be as agile as DevOps based organizations. This, of course, is a problem because it puts organizations-- who have invested huge amounts in delivering more quality and value, against large and monolithic organizations working in waterfall methodologies on a collision course.
If you were ever in doubt about the value of DevOps in your organization, consider times of crisis. It can be chaos localized to your industry or your organization. These times should show you that organizations that can change to meet the demands of the outside world rapidly are the ones who are most likely to succeed and gain a considerable amount of brand reputation because of it.
What does the future hold?
Of course, the real question is, what does the future hold? Organizations that have struggled throughout any crisis should be looking at themselves hard. I know from experience that lots of organizations don’t treat BCP seriously, and this is going to be a real issue for them. In DevOps, we talk about “you build it, you run it,” BCP has to be part of that same ethos for your organization if it isn’t already.
For larger enterprises who may look externally for their BCP, the real challenge is how you get those organizations to consider your DevOps methodologies while adhering to the fundamental principles of DevOps that involve evolution and change. The problem for those BCP outsourcers is how to implement scaled enterprise DevOps to deal with the influx of organizations that are looking for this level of service.
Consider how much time you have spent in building a DevOps culture within your organization. Introducing strategies from a third party organization to implement a BCP may interrupt that culture and cause more problems than it promises to fix. My recommendation is to analyze your BCP strategy and ensure it is in line with your DevOps working practices. When looking for BCP solutions, look to organizations that truly understand DevOps beyond speaking buzz words.
The real test of success is when DevOps and BCP become a requirement for organizations. How these two concepts shape our future will show that we’re on a journey where we need to be thinking next about what the next pain point is and how to address it. Thanks for reading.
