Ten years after the first DevOpsDays conference in Ghent, the evolution of DevOps and organizations trying to adopt it was at the forefront of the first DevOpsDays conference in Portugal. On the first day of the conference, a mix of local and international speakers addressed the barriers to DevOps adoption, shift left testing, team patterns, and more.

Mirco Hering’s keynote on DevOps transformation set the tone and topic for the first day. Hering characterized the “The DevOps Phase” as the explosion of DevOps practices and tools, and enforced delivery processes. To move to “The Lean Phase”, organizations need to avoid cultural dogmas (e.g. “we must have a DevOps team” when it’s not clear what that means exactly is a common anti-pattern in large organizations with specialized ops needs), and focus instead on culture, people and principles. Hering stressed that instead of focusing on DevOps as an “end state”, organizations need to improve continuously (with a rigorous experimentation approach) and regularly revisit the (largest) bottlenecks in their software delivery value streams.

Allegra Cooper described how Vanguard decided to adopt cross-functional teams to accelerate software delivery back in 2015, but most of the teams still lacked the required test automation skills and this hindered their velocity. By refocusing their QA engineers to become internal testing coaches and trainers (part of a new testing center of excellence), rather than perform QA work in a silo, they were able to help teams upskill and promote a true shift left approach to test automation. To that effect, they regularly carry out initiatives such as testing dojos (immersive training with full time coaching available), brown bag sharing sessions, open office hours, internal open space conferences, and more. Another success factor for teams was the joint creation of a “shift left checklist” including desired outcomes (measured by metrics such as testing cycle time or software quality), clearly identifying what needs to be tested, how much to invest in automation, which specific skills are missing, tooling selection, CI/CD approach, and more.

Manuel Pais mentioned how Vanguard’s testing center of excellence was a clear example of an enabling team (a fundamental topology) helping product-focused teams upskill and achieve the required competences for end-to-end ownership of the products they are responsible for building and operating. Platform teams that provide common lower level services (for example, monitoring or aggregated logging) with a high degree of usability and reliability constitute another topology that helps teams adopt modern practices by avoiding the associated learning curve and cognitive load on the product team. The fourth and last fundamental team topology refers to complicated subsystem teams, but these should only be necessary when said subsystem requires PhD kind of specialized knowledge (for example, a video processing subsystem), said Pais.

Day 1 also showcased talks from local speakers on their DevOps journey, namely Diogo Oliveira detailing the challenges Outsystems faced in their adoption of Continuous Delivery at an enterprise scale, and Hugo Amorim describing the delivery pipeline at Banco BPI, a large Portuguese bank. Both speakers highlighted the need to treat the pipeline as a product, ensuring it is reliable (everything configured as code, avoiding manually created “snow flake” instances of the CI/CD tool), elastic and provides the best possible developer experience (DevEx).

There were also moments of relaxation such as Grace Chang’s self-challenge of 30 days without using Stack Overflow in order to see if their coding habits would change (hint: no conclusion there). Chang explained the need for intentionally distributing knowledge in organizations, for instance via knowledge roadmaps and automation of knowledge sharing mechanisms.

Besides active open space sessions, the first day included several Ignite talks, where Antonio Cobo’s brave karaoke talk (meaning the presenter does not know in advance what slides are going to be displayed) stood out.

Videos of the talks will be published in DevOps Days Portugal YouTube channel. According to the organizers, the next edition of the conference will take place in 2020 in the city of Oporto.

The DevOps Journey Is Rarely Linear

Every organisation approaches DevOps differently, and the path forward is almost never a straight line. There are false starts, stalled initiatives, and cultural friction that can kill early momentum and breed cynicism across teams. Without a clear, prescriptive framework, many organisations find themselves unable to scale DevOps practices beyond a handful of high-performing teams.

That is the central finding of the 2018 State of DevOps Report, co-authored by Puppet and Splunk. The report categorises organisations into three broad maturity tiers—Low, Medium, and High—based on how frequently they apply key DevOps practices. The data reveals a striking distribution: approximately 80 percent of organisations fall into the Medium tier, roughly 11 percent are Low, and fewer than 10 percent qualify as High.

The jump from Low to Medium is achievable for most organisations willing to commit to foundational changes. The leap from Medium to High, however, is significantly harder—and that gap represents a meaningful competitive opportunity for teams that can close it.

The Five Stages of DevOps Evolution

The 2018 report maps organisations along an evolutionary scale built around a core question: how frequently are key DevOps practices actually being used? Organisations that apply all the practices consistently are classified as highly evolved (High). Those applying few practices infrequently are Low. The majority sit in the middle, doing some things sometimes.

The five-stage model is designed to give organisations a pragmatic, prescriptive path forward—one that helps them identify where they are today, replicate existing pockets of success across teams, and make measurable forward progress rather than stalling indefinitely at Medium.

The Executive Perception Gap

One of the report’s most important findings concerns the disconnect between leadership and the teams doing the work. For nearly every DevOps practice surveyed, C-suite respondents were more likely to report that the practice was in frequent use than team-level respondents were.

• 44 percent of C-suite respondents believed their organisation automates security policy configurations, compared to 36 percent at the team level.
• 59 percent of C-suite respondents in one question variant reported automated security policy configurations, again versus 36 percent at the team level.
• In the Asia-Pacific and Japan (APJ) region, only 59 percent of respondents felt supported by leadership in their DevOps initiatives, compared to 63 percent in the United States and 60 percent in Europe.

This gap is not simply a communication problem—it is a measurement problem. When executives rely on self-reported or anecdotal signals, they develop an inflated view of organisational maturity. The practical remedy is objective, automated measurement: telemetry and dashboards that surface the actual state of DevOps adoption rather than what teams or leaders believe to be true.

Collaboration Is the Scaling Mechanism

Highly evolved organisations share a defining trait: their teams collaborate to build and share automation rather than hoarding tools and knowledge within siloed groups.

• In APJ, 41 percent of highly evolved teams collaborate to automate services for broad organisational use, compared to only 13 percent of the least evolved teams.
• Best practices and reusable patterns are shared across the organisation in 28 percent of highly evolved teams, versus just 10 percent in the least evolved tier.

The underlying dynamic is straightforward: DevOps empowers individuals to make changes without navigating layers of approvals. That empowerment only becomes an organisational asset when the knowledge and tooling behind those changes is shared. Without deliberate collaboration, DevOps success remains local—a win for one team, invisible to the rest of the business.

Security Automation as a Maturity Indicator

Security policy automation emerges in the report as one of the clearest markers separating highly evolved organisations from the rest. According to the findings, highly evolved organisations are 24 times more likely to always automate security policy configurations compared to the least evolved organisations.

This is significant because it reflects a change in mindset, not just tooling. In low-maturity organisations, security is typically addressed reactively—bolted on before an audit or after an incident. In high-maturity organisations, security policy configuration is treated as an operational concern, automated from the outset and maintained continuously. Teams initially automate security for their own efficiency; over time, that automation matures into a shared organisational capability.

This pattern aligns with the broader DevSecOps trend: the recognition that security cannot be a gate at the end of a deployment pipeline if organisations want to move at DevOps speed.

Key Takeaways for DevOps Practitioners and Leaders

• Audit your actual maturity, not your assumed maturity. The executive perception gap is real and widespread. Use automated measurement and objective metrics to establish a baseline before planning your next phase of adoption.
• Focus on scaling, not just starting. Most organisations have at least one team doing DevOps well. The hard work is replicating that success across departments—and that requires deliberate investment in shared tooling, documentation, and cross-team collaboration.
• Treat security automation as a first-class practice. The 24x gap between high and low maturity organisations on security policy automation is a strong signal. If your security configurations are still manual or audit-driven, closing that gap should be a near-term priority.
• Bridge the leadership gap with data. If executives and teams disagree on how mature DevOps practices are, the answer is not a better presentation—it is better instrumentation. Dashboards, deployment frequency metrics, and change failure rates give everyone the same ground truth.
• Accept that progress is non-linear. Stalls and setbacks are normal. Treating them as signals to refine the approach—rather than evidence that DevOps does not work—is characteristic of organisations that eventually reach High maturity.

Industry Voices

Darryl McKinnon, Vice President and Managing Director for APJ at Puppet, noted at the time of the report’s release: “DevOps practices are becoming well established, yet many organisations continue to struggle to scale the pockets of DevOps success across multiple teams and departments. Whilst more organisations are recognising the opportunity to adopt DevOps, particularly at the leadership level, there are clearly some barriers to success that have to be addressed first. In the face of rapid digitalisation, mapping out the journey and better defining those challenges are a key step in enabling that success.”

Andi Mann, then Chief Technology Advocate at Splunk, added: “This year’s report findings validate that foundational practices have a profound impact on an organisation’s overall DevOps evolutionary journey and are key to scaling successes no matter how mature the DevOps transformation is within the organisation.”

Bottom Line

The 2018 State of DevOps Report offers a sobering but actionable picture. Being stuck at Medium is the norm—not a sign of unique dysfunction. The organisations that break through to High do so not by adopting new tools in isolation, but by embedding collaboration, measurement, and automation (including security automation) into the fabric of how they operate. Understanding which stage you are in, and what practices characterise the next stage, is the most reliable starting point for making real forward progress.