DevOps for Agility
There are 2 points from the 12 Agile Principles that construct what we see in DevOps today. They are about iteration with frequent delivery, and technical excellence. What we know from iteration is that the agile team needs to deliver in a short-time manner, a working product, for every iteration. But how does it affect the development team? In fact, the effect is kind of huge.
When you do the waterfall methodologies, you don’t really care about the delivery part on the beginning of the project. You will not show anything to anyone, anyway. The team will only need to do deployment to few environments manually at the end of the project. But with Agile, everything changed. With iteration, it means that you will need to show your working product to the stakeholders in a relatively short-time manner. When you need to do everything manually like what we did in waterfall, it will consume a lot of time and it will make the delivery of the backlogs compromised with this ‘routine’ works. It then, relates with the second points from the Agile principles: technical excellence. Why? Because when you spend a lot of time for delivery (build-test-deployment), you don’t have enough time to deliver what matters the most: the product.
DevOps is exactly addressing that issue. We can see a lot of definitions for DevOps in the internet. But the essence for me is always the one and only: Continuous Integration — Continuous Delivery, or what we know as CI/CD. Basically, CI/CD will handle the most time consuming routine tasks of a software development: Build-Test-Merge-Release-Deploy. When a project team can automate this part, then the developers, the one who matter the most for delivering the product, can concentrate on creating the product with the highest quality of code they can do, with less distractions!
Of course DevOps is not only about CI/CD. Remember, that is the essence. In fact, to construct a strong DevOps implementation, we should automate more. Remember, we are doing this inside an iteration, it means, you will always go back to the start line (not with the same backlogs though). The CI/CD part will take care about this direction: from development team to the customer/stakeholder, to deliver the working solution. After that, we will definitely have comments, feedback, bugs, re-prioritization, new requirements from our customer/stakeholders. To complement that input, we will also need to monitor our product, and to see what kind of improvement can be made for the next iteration. That is why, in DevOps, we are also addressing monitoring part of the solution. We will need some statistic to back every comments/feedback/requests from our customer/stakeholders, to make sure we are not going the wrong way. In this part, the monitoring is holding a strong role within the iteration. You would want to know everything happened with your deployed solution as soon as you can, to be able to handle them as soon as possible.
The next step of DevOps is actually the transformation of it: DevSecOps. Yes, they put the new guy in the middle: Security. Usually in the organization, security is seen as a constraint for innovation. It usually blocks the creativity, blocks the flexibility, preventing you to try something new in order to secure the organization’s assets. For me, it’s not right, ok I compromise a bit, it’s not always right. I believe part of this perspective was built because of a silo between the security department with the project team. We don’t really know what kind of measurement defined as security standard for the organization. What we used to know is, when our project is being scanned for security (in waterfall usually it happens when your project almost reaching the end), you will find some loopholes that might need a major changes to your product to fix those and comply with the security standard. So that’s why security is introduced as part of DevOps, to be able to address it as early as possible, and to automate it as much as possible.
What are the goal of DevOps? In principal, DevOps is created to improve speed, agility, innovation, and quality, while (as much as possible) reducing cost. Especially in this difficult situation triggered by pandemic, I believe every organizations are in favor of cost reduction, in any way. With DevOps, we can accelerate the development, less time will be consumed, which automatically will lead to less cost generated, without compromising quality. But this is the good part of the things that almost everyone wants to hear, the advantage of it. To reach that maturity in DevOps, of course organization has to spend time and effort to build the framework, everything in place. It will relates with the culture, the tools, the roles of people in the organization landscape. So that’s why you may hear that DevOps is also a culture, not merely a methodology. It is a culture that needs to be built in alignment of Agile mindset in the organization. DevOps is part of Agile, I believe it needs to be built in sync of the effort for the organization to become Agile.
For an organization, what it means to have a mature DevOps (or DevSecOps) framework, is to be able to provide a standard way of implementing CI/CD, monitoring, and security for most of the projects (of course we will still have technical constraints that may prevent us to implement this for every project), and all of these are aligned with the organization landscape. In the long term, the organization will not be suffering because of conflicts and redundancies which may lead to (again) uncontrollable cost generated.
My takeaway from this is DevOps is definitely part of Agile, and it has a strong role in making sure that the Agile Principles are addressed. Have you start defining DevOps in your organization? How well has it been received so far? Let’s discuss!
Originally published at https://www.linkedin.com.