... or the other way around: If your code and architecture aren't designed for testability, there easily might arise problems in your agile, continuous workflow. So it might help to know some patterns and anti-patterns regarding testability, even as someone who isn't deeply into coding – you will be able to ask your teams suitable questions to help them find better testable implementations.

So much for the TL'DR, here's the longer story:

Some software development teams are more agile than others, for a number of reasons. While working with many teams during the last decade, I observed a recurring pattern: Teams (and products) with good, fast testautomation often deliver better solutions sooner, while keeping a better team spirit – a combination that many agile coaches wish for their teams. But how do some teams achieve good testautomation, while others struggle for years?

In my experience, this depends on if the code is easily testable or not. You might know programming practices like test-driven development (TDD) which yield better designed - testable - code. But there are some architectural patterns as well that support easier testing with fast-feedback loops.

We'll have a look at what it means to separate business logic from integration code and what different architectural styles and patterns exist to reach this goal - and why this enables smaller and faster automated tests. To keep this broad topic as comprehensible as possible, you'll see simplified visualizations of the different architectural styles and code designs.

The goal of this session is that you get a basic understanding what distinguishes testable architectures and code designs from less testable ones. And why testability is a fundamental building block that enables true - continuous - agility.