I can tell your peers about DevOps without scaring them (and so can you)

See: https://www.youtube.com/watch?v=eCv54CqtlfA for recording!

Ask anyone about what DevOps is and likely you'll get response along the lines of "automation, pipelines, scary tech stuff". While yes, you're going to see those concepts (and tech is not so scary, promise!) in a DevOps transformation, DevOps is far more about a culture shift.

A shift in mindset, in behaviour, in making things easier and effectively managing risk while doing so. A shift in putting smiles back on the faces of engineers and anyone they interact with.

In other words: This talk is about the things your developers wished management knew about DevOps.

So let's explore that together, on a journey where we grab concepts like The Three Ways to help craft a strong definition and story to our peers: I can explain DevOps without scaring you, and after this talk, so can you.

Session aimed at non-technical / non-engineering positions, like Scrum Masters, Product Owners, managers and the like, to get a grasp on DevOps. But technical staff can benefit all the same.

Compliance Automation or: How I learned to stop worrying and love IT controls again

See a (phone quality) recording to get an idea of this talk: https://www.youtube.com/watch?v=DbHBbICUGHA&t=7s

Compliancy is a major concern for nearly every company. Especially on the topics of ‘when is good good enough?’ and generating + delivering evidence, development teams might get stuck for weeks on end to prove security & compliancy standards are being met. If they are being met in the first place.

But the other side of the coin (roles like compliance/security officers) run into similar problems. The coordination and performing of controls, activities often done by hand and in appearing as huge, dreaded checklists in Excel, cost huge amounts of time on both sides. We'd rather spend that on further improving our system.

So let's get that toil out of the system using a case study, demonstrating how commonly used tools, techniques and patterns can also be applied to automating COBIT style key controls.


- BDD style testing (‘Given, When, Then’) using Python & behave, to write acceptance tests on whether we are actually compliant

- Setting up a Compliance/Evidence API that can be used to store and tag evidence, with the goal of making the storage behind it a ‘Self Service Evidence Store’

- Building a reactive architecture with tools like Azure Event Grid to respond to actions within your landscape; e.g. provisioning development resources to be compliant-by-design & automatically generating additions to existing resources like self-service access profiles or pipeline building blocks (compliancy does not have to exclude development enablement, after all!)

Speedrunning DevOps Fundamentals

My aim is to provide a speedrun overview of DevOps, taking you through the most important principles and concepts behind the movement, while trying to lift the curtain on some cultural changes that are bound to come your way. I've noticed that a lot of people seek the latest and greatest, cutting edge stuff but have their teams struggle with the fundamentals, hence a talk about those fundamentals.

We'll talk about the Three Ways (from the Phoenix Project) as our base for further techniques & technologies, discuss common misconceptions & challenges you'll face when trying to implement it, and see if we can define some improvements you can start making the next day.

Focus is on (not limited to):
1) Flow. Taking concepts from Lean, reducing batch sizes & handoffs, limiting WIP, gaining knowledge about the flow of info through VSMs.
2) Feedback. Create & amplify loops through many forms of testing, reviewing, collaborating; shifting left cumbersome activities, seeing problems as they occur and building an ever safer system to work in.
3) Continuous Learning & Experimentation. Improving daily work is more important than daily work itself (Toyota), implementing a blameless culture and doing effective post-incident analysis, looking into resilience engineering and more.

Also a bit on the importance of defining DevOps for your own context and why that is necessary (and difficult), and some spicy stories from the field to liven it all up!

Needs very little in terms of setup; slides/projector is optional.
Session takes about 30-45 mins, depending on audience interactivity (and if this is wished in the first place). Can easily extend with a few topics like CI/CD, engineering culture, bit of leadership. Or, if interactivity is key, can also let the audience decide on a few follow-up topics; I want my talks to be very flexible in that regard.

Target audience is anyone in- or outside of IT, that has heard of the term DevOps before but would like a primer on what it's about, without too much company context or 'this is how we do it here'.

The Good, the Bad and the downright Ugly: Stories of (non-)effective culture in a DevOps world

The C in CALMS, the People in PPT, the thing that eats strategy for breakfast.
The concept most people overlook in organizational change in favor of tools and technology, but coincidentally the same thing most companies struggle with in any major change, doubly more so in a 'DevOps transformation'.

Together, let's examine some stories of both effective and....well, very non-effective culture & behavior in a DevOps setting. We'll talk post-incident analysis with SolarWinds, bridging silo's with a Coin Game, see how pair/mob programming isn't just for programmers and how metrics can be fooled time and time again.

You'll walk away with:
- How to handle incident processes in an effective manner
- What steps you can begin with to bring 2 silo's closer together
- Basic patterns for pairing / mobbing regardless of speciality or seniority
- Some fun examples & games you can utilize in your own environment to get the points above across further!

Given multiple times at in-house company conferences around digital transformation, best fits when audience has a (limited/basic) understanding of DevOps principles. Can be varied from short (+-20 mins) to longer (60mins) and adapted to meet event/company needs. I.e.: Incorporating company / event values or mission, utilized frameworks or switching from a GIF showing the Coin Game to actually having attendees PLAY the Coin Game.