The Funnel effect of DevSecOps
Like many endeavors, it often begins with trying to sift or parse through a lot of raw material before you can use it effectively. When trying to optimize a team or a project’s efforts this remains true. In my specific case, I like to evaluate the state of their DevOps or SecDevops optimization. It is not because you were not thinking of becoming more aligned with a DevOps culture, that your efforts have not, or are not pertinent as far I am concerned. There are a series of initiatives you can take that will allow you to continually improve your processes or keep using better tools. But in any case, an objective way to measure improvement and qualify it will absolutely be necessary.
While beginning a decided effort toward becoming more effective more productive, usually, is a good idea to situate where we are. It is using a map. It is very difficult to get to where you want to go, without knowing where you are first.
The learning curve of DevOps
One of the things I like to remind people starting on their DevOps journey, is that the first steps are going to be the ones with the most impact. If you remember that we are working to organize a lot of raw material, the first fork in the road will split it in two. Dramatic changes will be felt. As such I like to express the first few steps as a meteoric rise in performance. And as time increases, gains in performance reduce.
It is roughly like the function:
Roughly your reach an asymptote at “5” but the gains are huge out of the gate. (I’m sorry if my math isn’t perfect, it’s only to illustrate a point)
One of the finer lessons you get from starting a Devops journey isn’t completely dissimilar as getting Agileified. Though negotiating a contract between your team and the customer might seem obvious enough, some of the finer points on how to agree effectively as a team, within team members isn’t so easy. As an example, if you take a dozen creative people and ask them to come up with a name for their team, the exercise can take over an hour. Not that the exercise itself is difficult but working out a protocol to decide “how to decide” isn’t going to be agreed quickly. Hence, it is the first step in our Journey.
The majority is not always right
Contrary to what you might expect, just because a majority of the team members agree on a principle, it doesn’t mean it’s a good idea. You must consider that disregarding an opinion because it is unpopular can disenfranchise an important member of the team. If they become a detractor, your whole effort may be for naught. You must weight your decisions and agreements within the team, with this in mind. It is somewhat revelatory for my clients when they discover this within their teams. An expert in the matter of Security can trump all kinds of idealistic goals.
Where are we going
As I explained before DevOps is not a fixed scientific methodology. So consequently, what it means for the team I am working with will also have to be defined and this definition must be clear enough that any nuances in the future must be understood and agreed upon. This flavour of DevOps is entirely dependent on the composition of the team. And it is one of my favourite things to help people discover. Soon after, we will have concrete milestones to help us see that we are heading in the direction we want.
SecDevOps Roadmap Workshops
Soon after having decided, what is our trajectory for our DevOps journey is, we are going to find a way to keep refining and aiming to a more precise or adequate destination. Please understand, this is metaphoric. Since we are trying to develop a method to improve efficiency, velocity, and quality, we are going to need to try and see what are the techniques that will help us get there. I establish working sessions where some key “universal” concepts are acquired by all team members.
They are called such for two reasons. The first being because they are Transversal. We want people that are aware of the needs and challenges that are being imposed on their teammates. In a pinch you should even be able to rely on a replacement to be easily available because of this proximity. The second, because the letter “T” illustrates the quality of what is being sought: someone with a strong base in a particular skill and the ability to “horizontally” cover a broad spectrum of other competencies if required. It may seem idealistic, but people grow when given space and the opportunity. It’s finding the right kind of opportunities that will benefit the team and the project that becomes tricky.
The competency Matrix
If you know what your strengths and your weaknesses are then you can document them and try to fill the gaps. It sounds simple enough but documenting them clearly enough to be able to exploit them adequately is another challenge. Remember that we have a sub-goal to ensure our entire team is on board with not only developing a clever technological solution, but taking responsibility of its operation, availability, and security. Making sure that everyone is aligned and able to bring this to fruition is yet another challenge I face.
Our next steps in our SecDevOps journey
The list of workshops available is far from being exhaustive here, but is should suffice to say, once we’ve established where we want to be it becomes easier getting there. We spoke of the team “will” so far, but in our next article we will talk about our “ways” or our means, with which we are going to get moving.
We will learn about how work, in progress, unplanned work and constraints all can be leveraged to improve our delivery. How visibility and transparency, some of our favorite corporate values at Emyode can benefit the DevSecOps journey.