The pattern is consistent enough to have a name in enterprise transformation work: the exemplar team problem. A DevSecOps programme selects its most capable, most motivated, most technology-advanced product teams for the initial implementation. Those teams succeed. The pilot is declared a success. The programme moves to scale the model to the rest of the organisation. The rest of the organisation does not perform like the exemplar teams.<\/p>\n
The gap is not explained by the less capable teams being unwilling to adopt DevSecOps. It is explained by the programme having been designed for the most capable teams and deployed on the assumption that what works for the most capable teams will work for everyone else. The assumption is wrong, and it is wrong in predictable ways.<\/p>\n
The exemplar teams have characteristics that the general population of product teams in a large enterprise does not: higher average technical capability, greater operational autonomy, better access to platform resources, and leadership that already understands and values integrated security practice. The DevSecOps programme designed for and with these teams has embedded those characteristics as prerequisites, even if they are not explicitly identified as such. When the programme meets teams without those prerequisites, it encounters resistance that looks like cultural pushback but is actually a requirements mismatch.<\/p>\n
Understanding why DevSecOps does not propagate requires distinguishing between the three scaling barriers that most commonly block it, because each requires a different intervention.<\/p>\n
The first is governance model granularity. DevSecOps governance at the team level is typically designed around the delivery patterns of high-performing agile teams: small, autonomous, running frequent deployments with security integrated into the sprint. When this governance model is applied at the programme level across an enterprise with diverse delivery patterns, it fits some teams and breaks others. Teams with longer delivery cycles, more complex dependency management, or regulatory constraints on deployment frequency cannot operate the team-level DevSecOps model without modification. The governance model that scaled from exemplar teams needs to be redesigned at a level of abstraction that accommodates legitimate variations in delivery context before it can be applied across the programme.<\/p>\n
The second barrier is platform tooling applicability. The security tooling that exemplar teams adopt is often greenfield: new services, containerised deployments, modern CI\/CD pipelines, cloud-native infrastructure. When DevSecOps tooling designed for this environment is applied to teams with legacy delivery constraints, the tools may not integrate with the systems those teams use, may produce finding volumes the teams cannot address within their delivery cadence, or may require platform capabilities the teams do not have access to. The platform tooling layer needs to be capable of serving the full range of team contexts, not only the greenfield ones, before the programme can propagate.<\/p>\n
The third barrier is change management approach. The change management for exemplar teams tends to be led by champions within those teams, who drive adoption from the inside. This works for teams whose technical leadership is already aligned with DevSecOps principles. It does not work for teams where the technical leadership is sceptical, where the delivery pressure is high, or where the value proposition of DevSecOps integration is not immediately visible in the team’s daily experience. The change management approach needs to be designed for the sceptic as the target audience, not for the early adopter.<\/p>\n
The framework that moves DevSecOps from exemplar team to organisational practice has three components, each designed to address one of the scaling barriers.<\/p>\n
The governance redesign component creates a tiered governance model that distinguishes between requirements that apply to all teams regardless of context and requirements that scale with the team’s delivery maturity and technical capability. The universal requirements, things like mandatory vulnerability scanning in the CI pipeline and critical finding remediation SLAs, apply to every team from day one of programme onboarding. The advanced requirements, things like automated security policy enforcement in infrastructure provisioning and runtime threat detection integration, apply progressively as teams develop the capability and platform access to support them. This tiered model means the programme does not require every team to be at the same DevSecOps maturity level simultaneously, which is an impossible standard in a large enterprise.<\/p>\n
The platform tooling evolution component addresses the legacy delivery constraint by investing in tooling that can integrate with the diverse delivery environments the enterprise actually operates. The exemplar team’s CI\/CD pipeline is not representative of the enterprise CI\/CD landscape. A programme that can only operate in one pipeline type cannot scale to the organisation. The platform team responsible for DevSecOps tooling needs to treat legacy delivery environment integration as a first-class capability requirement, not a future roadmap item, before the scaling programme begins.<\/p>\n
The change management redesign component shifts the adoption model from champion-led to outcome-led. The argument that moves a sceptical delivery team is not “here is how DevSecOps works” but “here is what integrated security practice delivers for teams operating in your context: fewer late-stage security findings that interrupt releases, faster remediation because security feedback arrives when the engineer still has context, and reduced security incident frequency that affects your team’s on-call burden.” Making the value proposition specific to the team’s experience and concerns, rather than to the programme’s theory of change, is the change management that gets adoption rather than compliance.<\/p>\n
DevSecOps at organisational scale looks different from DevSecOps at team scale in ways that the programme needs to explicitly design for.<\/p>\n
At team scale, success is measured by team-level security metrics: finding severity trends, mean time to remediate, deployment frequency with integrated security checks. At organisational scale, these metrics need to aggregate into a programme-level view that shows security posture improvement across the portfolio, not just in the teams where the programme has been most successfully adopted.<\/p>\n
The programme-level view also needs to show coverage: what proportion of the application portfolio has DevSecOps practices integrated, at what maturity tier, and what the roadmap is for the teams still in the onboarding programme. Coverage gaps are the residual risk in a DevSecOps programme, and they need to be visible to the security leadership managing the programme and to the CISO communicating programme status to the board.<\/p>\n
The programme that achieves full coverage at tier one, and progressive coverage at higher tiers, is a fundamentally different security proposition from the one that achieves exemplar-level success in ten teams and has not reached the other ninety. Both are DevSecOps programmes. One is a security improvement. The other is a security showcase.<\/p>\n","protected":false},"excerpt":{"rendered":"
DevSecOps programmes frequently achieve genuine success at the team level and then fail to propagate that success to the rest of the organisation. This is why, and what the scaling framework looks like.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[4],"tags":[],"class_list":["post-95","post","type-post","status-publish","format-standard","hentry","category-operating-models"],"_links":{"self":[{"href":"https:\/\/baecke.io\/index.php?rest_route=\/wp\/v2\/posts\/95","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/baecke.io\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/baecke.io\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/baecke.io\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/baecke.io\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=95"}],"version-history":[{"count":0,"href":"https:\/\/baecke.io\/index.php?rest_route=\/wp\/v2\/posts\/95\/revisions"}],"wp:attachment":[{"href":"https:\/\/baecke.io\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=95"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/baecke.io\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=95"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/baecke.io\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=95"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}