# Increase the flow of delivery with effective software design and team interactions

Have you ever faced roadblocks in software development stemming from disjointed team structures or interactions? You’re not alone. Misalignment between software and the domain, siloed teams focusing on discrete tasks, or processes dictating software architecture often end up in rigid software that is not coherent with evolving requirements.

Enter Team Topologies, a pattern language, and a set of principles and practices to ensure a steady flow of value while respecting human-centric aspects like trust boundaries and cognitive load. This perspective prompts a burning question: What if we change how teams interact with each other and leverage these interactions to evolve the software? What would such a world look like?

Through real-world use cases, we’ll discuss and understand the implications of applying Team Topologies, Domain-Driven Design, and fast-flow principles. This workshop is not just theory; it’s about practical engagement, discussion, and learning by doing. You will have the opportunity to reflect on your context and discuss it with the other participants.

## What is this workshop about
The software we produce quickly changes the user's needs, which has a ripple effect on the software itself. Requirements change, and people want different things. This is good; people are engaged, and the software's value is sound. But there’s a caveat: how the teams inside the organization interact can be an enabler or blocker to evolving the software services. You probably have experience with how the friction between different people and teams inside a company didn’t yield the desirable results.

This workshop focuses on a different angle. What if we take how teams interact and leverage our native humane capabilities, such as trust and empathy, around a common goal? Rather than starting from the technical angle, we start from the social and humane angle. With this in mind, we use Team Topologies and Domain-Driven Design principles and practices. We design how teams can interact with each other and how to have a sensible software architecture that enables a fast flow of value toward the service users.

You will work in smaller groups around a fiction company example based on real-life use cases. The workshop provides a space to safely experiment with different options and reflect on the trade-offs and implications. There is a strong emphasis on the practical side of things, with short theory blocks to give you the foundation for the exercises. At the end of the workshop, you can apply the principles and practices to your context, improving the flow and business outcomes.

## Learning goals
At the end of this workshop, you’ll be able to:
- Engage in insightful discussions with your team on the core concepts of Team Topologies and Domain-Driven Design.
- Apply learned techniques to explore how your software can evolve and what the implications are.
- Explore and detail the alternatives to your current team setup and how they interact with each other to increase the flow of value and achieve the business goals.

## What do I need to know
If you are not an expert on Team Topologies or Domain-Driven Design, don’t worry. The workshop is designed to explore the concepts hands-on. You will have a workbook to support your journey, and the materials provide a reference so you don’t get lost.

The workshop is designed to improve the flow of teams that create and maintain software services. Anyone with any level of experience is welcome, and you will maximize the workshop results if you are looking for alternative ways of doing things rather than just the next big and shiny framework.

## Audience
Shout out to software engineers, testers, tech leads, architects, product owners, and scrum masters. This workshop is for you, folks who are part of a team, either to design, build, and maintain software or to work in a function that enables good software services, such as product management or Agile roles. It's especially for you if you have influence over or directly can change the software architecture or the way that teams interact with each other.