Please note:
On this page you will only see the English-language presentations of the conference. You can find all conference sessions, including the German speaking ones, here.
The times given in the conference program of OOP 2023 Munich correspond to Central European Time (CET).
By clicking on "VORTRAG MERKEN" within the lecture descriptions you can arrange your own schedule. You can view your schedule at any time using the icon in the upper right corner.
- Montag
03.07. - Dienstag
04.07. - Mittwoch
05.07.
More information about the keynote will follow shortly.
The story of a small Python script I wrote to automate a repetitive step in my testing, and what happened when it became a key part of pipelines for teams around the company.
Target Audience: Architects, Developers, DevOps
Prerequisites: No prerequisites, some Python and low-code knowledge wouldn't hurt
Level: Advanced
Extended Abstract:
Driven to madness by the normal workflow for testing my application, I wrote a small Python script in a couple of days. It called some APIs to build the app and deploy it to a hosted environment. It ran in my terminal, printing output often enough that I wouldn't get distracted. It solved my immediate problem.
But that wasn't the only problem it solved. It replaced a manual piece of our release process with an automated step, allowing my team to automate our pipeline. Then other teams copied us. Soon, a dozen teams in three units were trying to add and request features so that my personal pet project could become part of their merge request and release pipelines too. As more ideas needed to urgently serve the needs of teams in release time crunches, I merged code I didn't agree with in to keep everyone unblocked. The code base became something I dreaded, and I stopped maintaining it.
The next time a merge request came in, I was able to pay it the time and attention it deserved. I worked with the code submitter to improve usability. Another dev forked the code to build a UI component, serving a completely different purpose. Seeing how many individuals and teams used this code reignited my interest in maintaining it. I wrote tests for the repository, allowing me to finally refactor away the changes I'd dreaded. And the next contributor to the code base added a test without being asked. I no longer dread my little Python script. I support and maintain a critical piece of infrastructure, and I'm excited to do it.
Elizabeth Zagroba is Quality Lead at Mendix in The Netherlands. She sets out to prove that when “it should just work” it actually does. She's the go-to person for thinking critically about what’s being built, creating a common understanding, and writing API tests and English effectively. Her goal is to build enough skills in individuals and teams to make herself redundant.
Everything has to get faster and terms like “Continuous Everything” and “Shift Left” receive a lot of attention.
These trends are also followed in regulated environments like healthcare but are these approaches beneficial? Do they bring any value or is it more costly than helpful to introduce them? Is there any ROI? Is it measurable?
To answer these questions, we will show some approaches applied at Siemens Healthineers and how they influenced the release cycles and quality of the software.
Target Audience: Architects, Developers, Manager, Testers, Project Leader
Prerequisites: Basic Software Development Practices and Methods, Agile Methodologies
Level: Advanced
Extended Abstract:
Nowadays, everything has to get faster, as evidenced by the attention that buzz-words like “Continuous Everything”, “Shift Left” and similar receive.
These trends are also followed in heavily regulated environments like healthcare, even though these domains tend to stick to what they do for decades.
But are these approaches beneficial at all, especially in big organizations with several hundred developers? Do they bring any value or is it more costly than helpful to introduce them? Is there any ROI? Is it measurable? Or is it possibly better to stick with the established processes for development and testing, and focus on being agile?
To answer these questions, we will demonstrate some approaches that the Syngo business line of Siemens Healthineers implemented in the past few years and how they influenced the release cycles and quality of the delivered software. This will show if the juice is now better than before. We will also give a short overview of future “squeezes” that are being implemented at the moment.
Marco Achtziger is a Test Architect working for Siemens Healthcare GmbH in Forchheim. He has several qualifications from iSTQB and iSQI and is a certified Software Architect by Siemens AG.
Gregor Endler holds a doctor's degree in Computer Science for his thesis on completeness estimation of timestamped data. His work at Codemanufaktur GmbH deals with Machine Learning and Data Analysis.
With ca. 400 million search results on Google, psychological safety (PS) has become one of the biggest buzzwords in recent years. Unfortunately, most of the people writing and talking about PS are not psychologists. Although they are for the most part well-meaning, this has led to spread of misinformation about what PS is and how it can be fostered in teams.
This talk addresses some misconceptions about PS, presents techniques used by psychologists to analyse PS, and asks the question whether PS is all that's needed for high-performing teams.
Target Audience: Managers, Coaches, Scrum Masters
Prerequisites: None
Level: Basic
A quiet and reserved researcher and practitioner with over 25 years experience, Joseph Pelrine is considered by cognoscenti to be one of the pioneers and top experts on Agile methods. As a psychologist, his focus on people and his experience in applying leading-edge techniques from social complexity and psychology to process optimisation goes far beyond the domain of software development, and extends to the whole organisation.
Resilient software design is around for a while. Still, there is a mismatch between popularity and progress – while patterns and libraries are quite well known and microservices are still popular, only little progress in terms of creating better robust applications seems to be made.
In this session we will examine the probably biggest obstacles and pitfalls on our way towards creating resilient systems. You will learn what they are, how you identify them and what you can do about it.
Get ready to create more resilient applications.
Target Audience: Architect, Lead Developer, Project Lead, Manager, Decision Maker
Prerequisites: The desire to create more robust applications
Level: Advanced
Uwe Friedrichsen travels the IT world for many years, always in search of innovative ideas and concepts. His current focus areas are system design, resilience, sustainability and making IT a (bit) better place. Often, you can find him on conferences sharing his ideas, or as author of articles, blog posts, tweets and more.
What do the 640K memory limitation and the overlay technology from the 1980s have to do with today's software development? At first glance, nothing at all. Back then, both topics were answers to technical constraints that made developing hardware and software challenging. At a second glance, however, there is very much a connection. We still have many challenges. The numbers and drivers may have changed, but we still have boundaries to confront and overcome. This keynote reflects in an anecdotal and personal way on the journey that software development has been on over the past decades and the lessons learned along the way: from programming paradigms and languages to software architecture and agility to technologies like the cloud and the edge to topics like business agility and sustainability. There and back again.
Frank Buschmann is a Senior Principal Engineer at Siemens Technology in Munich. His interests are in modern software architecture and development approaches for industrial digitization.
Kevlin Henney is an independent consultant, speaker, writer and trainer. His development interests are in programming, practice and people. He is co-author of two volumes in the ”Pattern-Oriented Software Architecture” series, and editor and contributor for multiple books in the ”97 Things” series. He lives in Bristol and online.
For many people, refactoring is a simple code transformation they click on in a context menu or via a keyboard shortcut. The widespread availability of automated refactoring should have made oversized classes and long-winded functions a thing of the past. But it hasn't.
Having a tool is only part of the solution: knowing what to do with it and how to use it well matters. In this talk, we'll revisit what refactoring is (and isn't) and emphasise the idea that refactoring should be considered a design process and not just a clean-up click.
Target Audience: Developers, Architects, Tech Leads
Prerequisites: Programming experience
Level: Advanced
Extended Abstract:
For many people, refactoring is a simple code transformation they click on in a context menu or via a keyboard shortcut. They can extract, inline, replace, move, rename, etc. at will. The widespread availability of automated refactoring should have made oversized classes and long-winded functions a thing of the past. But it hasn't.
Having a tool is only part of the solution: knowing what to do with it and how to use it well is what makes the bigger difference. Refactoring is often mentioned in the context of agile development, test-driven development and legacy code, but beyond saying that it should happen, there is often not much focus on how and why.
In this talk, we'll revisit what refactoring is (and isn't), examine what practical and social obstacles refactoring faces, explore the idea that refactoring should be considered a design process and not just a clean-up click, and that most interesting refactorings are not necessarily automated.
Kevlin Henney is an independent consultant, speaker, writer and trainer. His development interests are in programming, practice and people. He is co-author of two volumes in the ”Pattern-Oriented Software Architecture” series, and editor and contributor for multiple books in the ”97 Things” series. He lives in Bristol and online.
"The Leader must be [X]" is one of the most common sentences we read about leadership. But not all leaders are the same and when working with people context is king!
In this session we will instead analyse the metaphor of Host Leadership: a context-friendly and non-prescriptive way to frame how leadership in an organisation could work. It reuses many of the cultural elements of hosting, thus making it very intuitive and generative!
We will also look at and experiment with practical applications of the idea!
Target Audience: Manager, Leaders, Scrum Master, Agile Coaches
Prerequisites: Experience in a leadership role is a plus, though not required
Level: Basic
Additional Information:
Host Leadership is an idea by Mark McKergow, who analysed the tension between heroic and servant leadership and proposed that an actual effective leadership has elements of both: sometimes hero and sometimes servant. And always adapting according to the context.
Pierluigi Pugliese is active as Agile Coach, Systemic Consultant and Trainer. He has a long experience in various roles in software development organisations and complex international projects. As an expert for Agile and Scrum, he helps clients implement agility in organisations. He strives for sustained improvement in teams and organisations, using the best methods as suggested by his broad experience. His expertise is cross-sector and independent from hierarchical structures, spanning from consulting and coaching at the top management level to single teams and individual developers. He regularly speaks at international conferences on Agile and Scrum, especially focusing on people aspects and team interactions.
He started hacking code so long ago that he cannot remember exactly when anymore. After many years various roles in the mobile telecommunication business, he works as a consultant for software organisations and coach for individuals and teams, focusing on software development and software processes, helping them implementing sound and agile solutions.
When the Agile movement began, it started with the term “lightweight processes”. Lean was closely interwoven with some of the approaches and very often referred to in the general discussion – nowadays you hardly ever read about it.
If you really want to use “Agile” approaches for more than just pushing notes over the wall, or holding meetings as ceremonies, a look at Lean is not only helpful, but actually inevitable which we will present in this talk. We’ll also put them in the context of currently fashionable approaches.
Target Audience: All kinds of change agents – either by choice or by chance.
Prerequisites: Some working knowledge of agile software development techniques and practices
Level: Advanced
Extended Abstract:
When the Agile movement began, it started with the term “lightweight processes”. Lean was closely interwoven with some of the approaches and very often referred to in the general discussion – nowadays you hardly ever read about it.
If you really want to use “Agile” approaches for more than just pushing notes over the wall, or holding meetings as ceremonies, a look at Lean is not only helpful, but actually inevitable. Straight from “ Lean“ come many approaches that are helpful in the agile realm like:
- Visual Management (as an approach to empowerment),
- the Improvement Kata (as a leadership method),
- the Jidoka concept (as an approach to deal with automation),
- and many other ideas for change and organization,
which we will present in this talk. We’ll also put them in the context of currently fashionable approaches (like the Kanban method, Scrum, SAFe, etc.).
Michael Mahlberg is a method-agnostic method consultant since the 1980s – In the beginning more in the areas of analysis, design and architecture, nowadays more in the area of processes and change. Mantra: Accept Reality.
A recipe for collaborative product ownership: Finding solutions to business problems that are feasible and sustainable.
Target Audience: Product Owners, Manager, Project Leader, Architects
Prerequisites: None
Level: Basic
Extended Abstract:
How do you translate Objectives and key results (OKR) back to a hypothesis that can be challenged by the various roles within a team? How do you ensure that the communication around initiatives is not hindered by conflicting terminology or by misinterpretation? In what ways can you involve business stakeholders in finding solutions that will help them understand the technical constraints that a team has to take into account? And how do you prevent tech teams building the wrong thing the right way?
**Imagine:**
- a way to visualize and clarify to the relationships between OKRs, hypothesis and the underlying technical constraints within the technical real-estate;
- a clear path from "user need" to the responsible "components";
- having a common language to talk about problems in context, removing ambiguity and confusion in the process;
- and finally, a way to collaboratively dive into the nitty gritty detail of the current landscape and the proposed solution;
In this session Marijn Huizendveld will take you through the process of leveraging your existing OKRs to clarify what needs to be done to all stakeholders and members of a team.
Marijn Huizendveld – In a small backstreet of Tokyo lives a man named Aki, a 78 years old former chef. Aki spent most of his life trying to perfectly cook the rice he buys from his friend Mato. He's been at it for 57 years now, and still searches for ways to improve his cooking methods. There is probably not too much anybody else could tell Aki about cooking this specific type of rice. When it comes to his process, Aki's understanding is unrivaled.
After years of trial and error, Marijn Huizendveld could be called the Aki of Domain-Driven Design, due to his extensive background in both programming and strategy. He uses this experience to show teams and organizations how to recognize and act on problems and opportunities in an autonomous, self-learning fashion.
Alignment ist der aktuelle Hype. Alle sollen an einem Strang ziehen. So wichtig das Thema ist, so oberflächlich und voller Plattitüden wird es diskutiert.
Den Beteiligten muss klar sein, was erreicht werden soll. Das und wie man das tut, ist seit mindestens 1954 bekannt. Allerdings entsteht das Alignment, das wir meinen, nur, wenn die Menschen im Unternehmen wissen, was sie tun müssen, ohne ständig alles Mögliche abstimmen und koordinieren zu müssen.
Mission Command und OKRs sind Ansätze, um genau das zu erreichen.
Zielpublikum: Manager, Entscheider:innen, Product Owner, Scrum Master, Projektleiter:innen
Voraussetzungen: Grundkenntnisse Agilität
Schwierigkeitsgrad: Anfänger
Extended Abstract:
Alignment ist der aktuelle Hype. Alle sollen an einem Strang ziehen. So wichtig das Thema ist, so oberflächlich und voller Plattitüden wird es diskutiert.
Offensichtlich muss den Beteiligten klar sein, was erreicht werden soll. Das und wie man das tut, ist seit mindestens 1954 bekannt. Es reicht offensichtlich nicht aus. Schließlich entsteht das Alignment, das wir meinen, nur, wenn die Menschen im Unternehmen wissen, was sie tun müssen, ohne ständig alles Mögliche mit allen möglichen Leuten abstimmen und koordinieren zu müssen.
Die Alignment-Mechanismen reichen von der Rücknahme agiler Arbeitsweisen über OKRs (Objectives and Key Results) bis hin zu Anleihen aus der Militärtaktik wie z. B. Mission Command. Der Vortrag betrachtet verschiedene Methoden in der historischen Entwicklung und vergleicht einzelne Ansätze kritisch bzgl. ihrer Eignung.
Anschließend stellt er wiederkehrende Muster für die erfolgreiche Umsetzung in der Praxis vor.
Nach dem Vortrag kennen die Teilnehmenden die wichtigsten Konzepte zum Thema Alignment & Autonomie und können so fundiert entscheiden, welcher Ansatz in ihrem Kontext besonders nützlich sein kann.
Urs Reupke ist Berater, Trainer und Coach für Agilität bei it-agile.
In fast 15 Jahren Erfahrung mit Agilität hat er gelernt, dass Miteinander, Prozess und Technik Hand in Hand gehen müssen, damit das Ergebnis stimmt.
Heute gibt er diese Erfahrung weiter und hilft Unternehmen aller Größen, elegante Lösungen für ihre strukturellen Probleme zu finden.
Stefan Roock (it-agile) hilft Unternehmen, Führungskräften und Teams dabei, ihre Potenziale zu entfalten - hin zu erfolgreichen Unternehmen, die ihre Kunden und Mitarbeiter begeistern. Er ist davon überzeugt, dass dazu strukturelle, personelle und interpersonelle Themen im Zusammenspiel adressiert werden müssen.
Stefan Roock hat seit 1999 agile Ansätze in Deutschland maßgeblich mit verbreitet und weiterentwickelt. Zunächst hat er als Entwickler in agilen Teams, später als Scrum Master/Agile Coach und Product Owner gearbeitet. Heute arbeitet er zusammen mit seinen Kollegen daran, dass Unternehmen langfristig mit agilen Denk- und Arbeitsweisen erfolgreich sind. Dabei fokussiert er auf agile Leadership.
Er ist regelmäßiger Sprecher zu agilen Themen auf Konferenzen, bei User Groups und in Unternehmen. Außerdem schreibt er Bücher und Artikel zu agilen Themen.
AI is being used every day to power sustainability efforts. We will look at a few areas where we have direct experience working with agriculture, oil and gas, and transportation companies to reduce their carbon footprint and their energy consumption, as well as their risk of systemic failure. We will also talk about the inherent risks of using AI in the sustainability domain, where human-machine interactions are the strongest. We will review some Responsible AI best practices that we have used.
Target Audience: Architects, Developers, Project Leader, Manager, Decision Makers
Prerequisites: None
Level: Advanced
Zorina Alliata is a Sr. Machine Learning Strategist at Amazon, working with global customers to find solutions that speed up operations and enhance processes using Artificial Intelligence and Machine Learning. Zorina helps companies across several industries identify strategies and tactical execution plans for their ML use cases, platforms, and ML at scale implementations.
Vortrag Teilen
Agility is vital for any organization that doesn’t want just to adopt the Agile terminology but start changing itself, its core, and its way of thinking and operating.
With our thinking tool, the Adaptivity Map, we have discovered different topologies of organizational design. The org topologies are created in the context of a perfection goal of full adaptivity. By doing this, we discovered the organizational changes and paradigm shifts required to move from one type to another.
Target Audience: CEO, Agile Coaches, Project Leader, Manager, Decision Makers
Prerequisites: Basic knowledge of agile frameworks
Level: Advanced
Extended Abstract:
Many organizations struggle to adopt "agile" in a way that delivers on its promise to make the company fast, flexible and efficient. Global consultancy firms have great pitches on how to adopt different so-called “Agile frameworks”. The marketing is great, but are the results too? We see how our clients get stuck in adopting a framework – forming “agile teams”, appointing “product owners” and then clustering all this into “tribes”. Thus creating robust structures that make further organizational improvements and adaptability difficult, slow, and expensive.
For more details visit www.orgtopologies.com
Key Outcome:
In this session, the participants will receive a hands-on thinking tool – Adaptivity Map, that allows participants to design a tailored, long-lasting roadmap to grow their organization's adaptivity towards perfection.
Description:
We believe that every organization needs to discover its own Agile adoption goal, and then lay down a path to it. Agility is vital for any organization that doesn’t want just to adopt the Agile terminology but start changing itself, its core, and its way of thinking and operating.
With our thinking tool, the Adaptivity Map, we have discovered different topologies of organizational design. The org topologies are created in the context of a perfection goal of full adaptivity. By doing this, we discovered the organizational changes and paradigm shifts required to move from one type to another.
This session:
In this session, we propose a context-driven approach to find the level of adaptivity that fits in your organization. You will learn a new way of looking at organizational transformation towards high adaptivity. We will offer a realistic palette of corporate transformation strategies using archetypical organization topologies.
Decision-makers attending this session will get familiar with this model and will be able to evaluate their ongoing Agile adoption (if any). They will be able to see their next horizon, and understand what options are available and what difficulties need to be overcome. Attendees will be able to assess their Agile transformation roadmap.
Participants of this session will learn:
- Understand how Agile adoptions are a journey and the adoption of any scaling framework is not an end-state.
- Understand the prevalent org topologies (archetypes of Agile organization design) and what a starting point of minimal agility is.
- Identify which org topology matches their current Agile adoption.
- Learn how to navigate Agile transformations using the Adaptivity Map to improve the Agile adoption journey.
- Learn to see the organizational changes and paradigm shifts that are required to navigate towards a more adaptive organization.
Roland Flemm worked for more than 20 years as an engineer in IT and has built 10 years of experience as Professional Scrum Trainer (PST) and Agile transformation design consultant in corporate environments.
https://www.linkedin.com/in/rolandflemm/
Alexey Krivitsky has been a developer, scrum master, conference producer, and speaker since 2004. He has written several books and is the inventor of lego4scrum. He is a Certified Scrum Trainer (CST) and works as an organization agility coach.
https://www.linkedin.com/in/alexeykrivitsky/
Can you relate to that ambiguous desire to “actually DO something” while – at the very same time – feeling an irresistible urge to “just hide under a blanket until 'this' all is over”?
I can!
In uncertainty, we humans all too often oscillate somewhere between ‘numbing’ and ‘over-action’. Yet, crises always bear something new, something that wants to be uncovered and tended – besides all the easily visible “unwanted” things.
Join us, in (my) search of sustain-ability.
But: be prepared to be surprised.
Target Audience: All curious human beings (including Developers, Architects, Managers, Project Leads)
Prerequisites: Curiosity and openness for different ways of thinking (and behaviour)
Level: Advanced
Extended Abstract:
Oh crap! Another crisis!
Or at least: another challenging, changing situation.
What can I do? What can WE do – as change supporters, as leaders, as human beings in business?
"What can I do?" is one question I asked myself A LOT of times “just for work” with teams in organisations. Now in times of pandemic, wars & climate change this question got a whole different scope and magnitude for many of us beyond work contexts.
I will take you on a little journey, sharing some of my own experiences… what worked, what didn’t… and most important: what I learned in times of crises.
You will leave that session with digestible psychological science (around Relational Frame Theory (RFT), S. Hayes et al) and most important: with tangible tools to try out yourself. At work and beyond.
Cosima Laube is an independent agile coach, leader & consultant with experience in a variety of industries (automotive, finance, healthcare, travel, public sector).
Having a strong background as developer and people lead in IT engineering, over the last decade Cosima enhanced her portfolio with solid coaching skills (ICF-PCC) and university studies focused on I/O- and Health Psychology. Besides work, you likely find her running or on a bike. Her credo at work and in life is: Achieving MORE - together!
More information about the keynote will follow shortly.
This talk is inspired by the BOSSA nova book from Jutta Eckstein and John Buck on company-wide agility, based on Beyond Budgeting, Open Space, Sociocracy and Agile.
This workshop gives a short introduction to BOSSA nova, but is mainly very interactive, supported by Liberating Structures. It helps the participants to identify and refine their biggest challenges in the agile transformation in their organization and provides a structure in which they can create and improve an experiment that they can start with when back in office.
Target Audience: Agile Coaches, Scrum Masters, Leaders, Managers
Prerequisites: None
Level: Advanced
Extended Abstract:
In the VUCA world that we are in, companies are expected to be flexible and both rapidly responsive and resilient to change, which basically asks them to be agile.
But, the agile toolbox is not enough to cover all aspects that create a true agile organization.
We do a brief overview of the additional principles and practices of Beyond Budgeting, Open Space and Sociocracy that Jutta Eckstein and John Buck added to Agile in their book BOSSA nova on company-wide agility. What is it, why is it needed and how it does fit in.
Participants will be engaged and supported to identify their biggest impediments in their agile transformation. From there participants will learn how to cope with these impediments by setting up an experiment to validate a small change, inspired by the BOSSA nova toolbox.
Participants will help each other to refine and improve their safe to fail experiment that they can start running when back in office.
Edwin Burgers is working as an independent agile consultant, working in IT for more than 25 years and in agile roles since 2009. He supported many teams and organisations to improve value delivery.
Mike Pruis
Linkedin: Practice lead & (agile) transformation coach at Ordina
Is your organization perfect? Or do you wish some things could be different? You may be stuck – so you scratch your head, brainstorm a bit, and grumble a bit more. This session will help you get unstuck. You will be introduced to Fearless Change strategies and participate in a Fearless Journey game that can help you and your team begin to move from the present situation to where you want to be. Get ready for some fun and you'll take away some strategies you can start to use on Monday morning!
Target Audience: Anyone who sees problems in their organization and would like to help make change happen
Prerequisites: A desire to learn (and have some fun while you do)
Level: Basic
Extended Abstract:
This tutorial is for anyone who wants to learn how to start to make change happen. Attendees will:
- Discuss their problems and the changes they would like to make on their team or in their organization
- Learn some strategies they can use to begin to get people so interested and involved that they want to change
- Participate in a "game" that will help them begin to get from the present situation to where they want to be
- Take away change leadership strategies they can begin to use right away
Mary Lynn Manns, PhD, is the co-author of two books with Linda Rising, "Fearless Change: Patterns for Introducing New Ideas" and "More Fearless Change: Strategies for Making Your Ideas Happen". She has led numerous presentations and workshops on the topic of change throughout the world at conferences and in organizations that include Microsoft, amazon.com, Apple, Procter & Gamble, and Avon.
More information about the keynote will follow shortly.
Many have suggested using DDD to help define the functional scope of microservices. But how to apply this idea in practice is not clear to everyone. This talk will cover basic DDD concepts, and we'll discuss why and how DDD can help to create microservices with better autonomy, scalability, and reliability. Using examples, we'll navigate from a domain model to the design of both synchronous (REST-based) and asynchronous (reactive) microservices.
Target Audience: Architects, Developers, PM's, QA
Prerequisites: Understanding of Microservices and DDD is useful
Level: Advanced
Extended Abstract:
Many have suggested that DDD modeling techniques can help define the functional scope of microservices. But how to apply this idea *in practice* is not clear to everyone. DDD is NOT an approach to microservice design. However, DDD can help with some aspects of microservice design. DDD has had a resurgence with the advent of Microservices, specifically as it can help you design the right-sized microservices modeled around the domain.
This talk will examine how to take the results of domain modeling (specifically Domain-Driven Design) and map them to a microservices implementation for systems with better availability, scalability, reliability, and modifiability. This will include examples for the design of both synchronous (REST-based) and asynchronous (reactive) microservices. I will also explore various microservice design scenarios around DDD concepts such as aggregates (with entities and value objects), bounded contexts, domain events, anti-corruption layer, and various strategies for Bounded Context interactions.
Joseph (Joe) Yoder is president of the Hillside Group and principal of The Refactory. He is best known as an author of the Big Ball of Mud pattern, illuminating fallacies in software architecture. Joe teaches and mentors developers on agile and lean practices, architecture, flexible systems, clean design, patterns, refactoring, and testing. Joe has presented many tutorials and talks, arranged workshops, given keynotes, and help organized leading international agile and technical conferences.
At a big town hall, a manager mentions DevOps, how that can help our company, and that it is necessary to switch to DevOps as our leading culture/process. Simple, yes? But what often gets forgotten is what needs to be changed to succeed in that culture switch and the expectation that it is a journey. I will show you two teams in the same company with the same presentation and how they went completely different directions. What we have learned from that and what I can give you as advice.
Target Audience: Developers, Managers, Team Leads, Ops, Decision Makers, Project Leader
Prerequisites: Basic knowledge of what DevOps is about
Level: Advanced
Extended Abstract:
Why is it so hard to move to a DevOps culture? This a common question from managers as they already talked about the advantages and got positive feedback from the team. On the other hand, developers now think they must be full-stack developers and ops specialists but still earn a developer salary. Then there is the Ops team, who struggles with the outcome of the development teams and their new role in the process. Everybody else is confused by the word DevOps and starts to think it is a new position in the company (well, you find DevOps team leads and specialists on job platforms).
Changing a company to follow a DevOps-oriented culture is a big project and should be planned accordingly. You will have setbacks; the bigger the company, the longer it will take. If you understand that this is a journey and that you cannot simply copy another company's culture, then you are at the right starting point.
Whenever Sanjit Roopra could automate items and gets his hands on Ops-related topics, he would do that as he found it essential to bridge the two worlds. He was not that experienced or successful in the big company he worked for, so he switched to a Startup. There everything changed as he saw the possibilities of what DevOps could be – going back to a big company, he wanted to bring that knowledge back and underestimated the cultural aspect when many more people were involved.
Misunderstandings between developers and the business are a plague. Bad communication makes projects fail. This talk presents a remedy (including a practical demonstration with auditorium participation).
Domain Storytelling is a technique to transform domain knowledge into effective business software. It brings together domain experts and development teams.
We let domain experts tell us stories about their tasks. While listening, we record the stories using an easy-to-understand pictographic language.
Target Audience: Everyone involved or interested in software development, including non-technical people
Prerequisites: Curiosity
Level: Basic
Extended Abstract:
Misunderstandings between developers and the business are a plague. Bad communication makes projects fail. This talk presents a remedy (including a practical demonstration with auditorium participation).
Domain Storytelling is a technique to transform domain knowledge into effective business software. It brings together domain experts and development teams to: (a) understand the domain of a software system, (b) find microservices boundaries, and (c) talk about requirements.
We let domain experts tell us stories about their tasks. While listening, we record the stories using an easy-to-understand pictographic language.
The domain experts can see immediately whether we understand their story correctly. After very few stories, we are able to talk about the people, processes, and events in that domain.
The talk is aimed at everyone involved or interested in software development, including non-technical people.
Henning Schwentner loves programming in high quality. He lives this passion as coder, coach, and consultant at WPS – Workplace Solutions in Hamburg, Germany. There he helps teams to structure their monoliths or to build new systems from the beginning with a sustainable architecture. Microservices or self-contained systems are often the result. Henning is author of “Domain Storytelling – A Collaborative Modeling Method” and the www.LeasingNinja.io as well as translator of “Domain-Driven Design kompakt”.
In large organizations, creating value through IT often involves multiple teams, domains and systems. Join this talk to hear experience reports from a large Nordic Bank, about how domain-driven architecture can help tackle sociotechnical complexity at different scales. Concepts such as coherence, correspondence, recommoning and boundary-driven architecture will be contextualized with examples. The talk will also share a personal story of evolving the architect role from being a “maker” of good solutions to a “multiplier” of good conditions.
Target Audience: Architects, Developers, Product Owners, Agile Coaches, Decision Makers at all levels
Prerequisites: Understanding of agile, architecture, domain-driven design
Level: Expert
Extended Abstract:
At Danske Bank, we’re dealing with cross-team, cross-domain, cross-system change initiatives. It’s a complex sociotechnical environment, and we need large-scale structures to understand the big picture.
How can we scale these models to give direction and set boundaries, while leaving room for local design autonomy? How can we disseminate multiple models at multiple scales? How do we keep them supple enough to bend at places that need bending? And how can we help teams navigate the mess between the strategy floor and the engine room?
We made a lot of headway bringing strategy closer to the engine room. But not everyone of every team can be part of ideation, strategy, and design. Many developers who write customer-facing production code will not receive the “why” firsthand.
We set up collaborative experiments to facilitate decision understanding, decision feedback, and decision re-making. We probed architectural models at scale with minimal conceptual contours, capable of being fleshed out by decentralized design decisions. To deal with constant change, we looked for opportunities to refactor at the architectural level.
The talk will share field examples of practising domain-driven architecture. It illustrates how domain-driven architecture can be cross-pollinated by inspirations from product management, UX design, complexity, and organization theories.
It’s a call to action for architects and systems thinkers to become acute listeners of languages in contexts and deliberate feedback loop designers, to interact with complexity for sensing and understanding, to play with safe-to-fail experiments, and to embrace the learning and growth that only happens outside our comfort zone.
Xin Yao is a sociotechnical architect at Danske Bank. She believes that a product, domain, and team-oriented architecture is the super glue to bind multiple agile teams navigating toward a common horizon. In her organization’s recently Spotified landscape where a team’s cognitive capacity is under constant stress, she practices domain-driven design and facilitates collaborative modeling to help teams make sense, make decisions, and make intuitive business software.
EasyJet Test Manager Laveena Ramchandani as she shares the skills and strategies needed to be successful in Test/QA leadership. Drawing from her own experiences and from those with varying backgrounds, she offers actionable guidance for those aiming to become, or just starting to work as, a Test Manager.
Explore how to choose and deploy the right processes, tools, and team members to meet your quality mandate. Learn how to create a culture that values feedback. Understand why growing and retaining your best people is critical in uncertain economic times.
Target Audience: All
Prerequisites: None
Level: Advanced
Extended Abstract:
EasyJet Test Manager Laveena Ramchandani as she shares the skills and strategies needed to be successful in Test/QA leadership. Drawing from her own experiences and from those with varying backgrounds, she offers actionable guidance for those aiming to become, or just starting to work as, a Test Manager.
Explore how to choose and deploy the right processes, tools, and team members to meet your quality mandate. Learn how to create a culture that values feedback. Understand why growing and retaining your best people is critical in uncertain economic times
Key takeaways:
- Traits to cultivate
- Being a people manager
- Tools and techniques: How to choose what’s best for your team
- Giving and receiving feedback
- Working smart
Laveena Ramchandani is an experienced Testing Consultant with a comprehensive understanding of tools available for software testing and analysis. She aims to provide valuable insights that have high technical aptitude and hopes to inspire others in the world through her work. Laveena holds a degree in Business Computing from Queen Mary University of London and regularly speaks at events on data science models and other topics.
The Tech world is ever growing, and Laveena Ramchandani has been working in Tech for 10 years now. She works in testing and quality assurance, a good mix of technical and business awareness role. Laveena has learned a lot through her career and looks forward to gaining more knowledge and at the same time inspires and spreads more Testing eminence around the world.