Bringing DevSecOps transformations to maturity with team dynamics
Companies are going through a digital transformation. Most enterprises have already moved to become ‘Agile Enterprises.’ The logical next step is the DevSecOps transformation where the focus is on optimizing development, operations, and consequently security, in order to reduce the time it takes to get to the market. The DevSecOps transformation, however, has its own complexity.
Fortune 500 companies have a huge number of applications in their portfolio. I would assume close to 1200 applications is a common number. Changing the operating model to DevSecOps for the most critical business applications seems to be a valid idea. Taking a closer look at these applications, the teams supporting them, and the existing processes, shows a diverse landscape. It reveals different team maturity levels in knowledge of DevSecOps skills, used pipeline stack and adopted DevSecOps capabilities for modern software development. For example, some might have already started using Continuous Integration, some are running automated tests, some not even have a single Unit Test.
In Agile Enterprises and with DevSecOps transformations we want to emphasize diversity
Moving such a portfolio into a new, aligned DevSecOps operating model has different challenges:
Different technologies: Not all technology stacks are the same, different pipelines and varieties are necessary
Diverse value in capabilities: Adopting capabilities unfold high value for some teams - but for others not, for example if a change budget for an application is small, high automated test coverage is challenging
Different mindsets: Some teams are already on their way to DevSecOps, breath Lean IT and live continuous optimization, others are still “under the waterfall”
Change takes time: Adopting a new process can be done quickly, but having the right number of automated test cases takes time
Normally we would design a plan; a detailed, structured approach to move all of the selected applications into the new operating model. Plan, execute, measure. But one plan doesn’t fit all and we would leave behind flexibility for individual teams and the freedom to define what's best in their specific scenario. This starts with the simple question, do all teams have to use Jenkins to orchestrate the pipeline? Or do all have to practice agile ceremonies or use GitHub? Shaping a transformation plan for DevSecOps is a huge responsibility, because it changes the way many people are working rapidly. A bad plan can lead to frustration, burnout and blame. To force highly paid experts to rollout on a predefined company standard guarantees frustration and resistance. But for large enterprises a high standardized approach is the obvious approach.
The solution is to define desired capabilities and a maturity model at the team level
The transformation to DevSecOps has two reasons: a shorter time to market for changes in software and higher stability for that software. Keeping this in mind, a list of capabilities are made: continuous integration, pair programming, test driven development, application monitoring, unit testing … just to name some of them.
The second step is to define a maturity model, with loosely defined capabilities assigned to it. The entry point to this maturity model is the minimum of what is defined as a pipeline, the minimum of capabilities and mindset. For example the use of GitHub, Maven, Jenkins, etc., practicing Continuous Integration, trunk-based branching, X% code coverage with automated unit tests and all team members having accomplished the ‘start-with-DevSecOps’ virtual training.
This minimum starting point is the bronze standard. If a team has this maturity, we can say: “they are DevSecOps”. Next is to define the silver and gold standards. Here, the capabilities are loosely coupled. The initially created list shows all the capabilities. Now it's easy to say, “teams which are practicing X capabilities are on silver level.” The number of capabilities can be balanced with more tangible facts; automated test case coverage, reaching of DevSecOps KPIs and accomplished trainings.
A maturity model combined with peer learning accelerates the DevSecOps transformation
The maturity model with loosely coupled capabilities has three main benefits:
Each team can drive at their own pace and activate the capability that generates the most value in relation to the effort to activate the capability
The DevSecOps adoption is transparent on a portfolio level.
A clearly defined start and high guidance for teams that have just joined, high flexibility for mature teams
Two aspects show the beauty of the maturity model approach. By defining DevSecOps KPIs, teams can see how activating more capabilities has a positive impact on the KPIs. The KPIs have to be tied to the reason for the DevSecOps transformation and can be changing lead time, deployment frequency, mean time to recover, change failure rate (compare Accelerate by Forsgren, Humble, Kim). This motivates the teams by realizing that their accomplishments have a positive impact, that’s directly perceived self-efficacy.
The second aspect is that this model makes it easy to leverage gamification. Game elements like points, leadership boards, avatars, and performance graphs can be used. The points can lead to higher maturity; extra points are given for mentoring a team in their onboarding process or in sharing the latest learnings with the other teams. The leadership board shows also which teams can be contacted to answer some challenging questions with their own pipeline.
This approach generates a team dynamic when teams start with cross-team learnings. It has its own atmosphere, when junior teams are listening to experienced gold level teams, when they share how they overcome their struggle. It's great to see how teams pin their earned silver badge on the door. It's fulfilling to see the faces when we name teams and members which have accomplished a new stage in our town hall meetings.
How do you manage your DevSecOps transformation? What do you think is the best approach?