35 years ago, Eliyahu Goldratt introduced the Theory of Constraints (ToC) in his seminal book "The Goal" as a new management paradigm for manufacturing plants, struggling with excess inventory, late deliveries, poor quality. The ToC solved this through five focusing steps - a guideline to systematic improvement and continuous learning.

Today, the ToC is one of the pillars of the DevOps movement. This talk will present its principles, and how it applies to the software industry, through a mix of theory, stories and experiences, and practical advice.

Target Audience: Architects, Developers, Project Leaders, Managers, Decision Makers
Prerequisites: Some previous knowledge of software delivery is helpful, but not required
Level: Basic

This talk will provide insights for a successful integration of lean-quality management to scaled agile projects. We will show based on our project experience that by improving process quality, higher product quality is achieved, resulting in significantly increased customer satisfaction. We will share how the lean principles and an easy-to-use toolkit helped us to tackle complex problems by providing a proven and scalable approach for continuous improvement and boost business agility at the same time.

Target Audience: Quality & Test Engineers, Agile Coaches, Project Managers, Quality Managers
Prerequisites: Solid agile knowledge, basic lean understanding, basic understanding of quality assurance
Level: Advanced

This workshop gives a short introduction to BOSSA nova (Beyond Budgeting, Open Space, Sociocracy and Agile combined to support company-wide agility), but is mainly very interactive, supported by various 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 a probe that they can start with when back in office.

A practical workshop for probe-sense-responding.

Target Audience: No exclusions, everyone can make a small step
Prerequisites: None
Level: Basic

If you’re not making mistakes, you have no chance to learn enough! This is especially true in complex situations, where, more often than not, the difference between a success and a failure can only be seen in hindsight. Which is why it pays off to dare new things, even if that might mean you can go wrong–as long as you don’t make the same mistake twice!

In this interactive talk we will explore how psychological safety, creativity, complexity and motivation are connected. And we will exercise our “No Blame – More Flame” mentality.

Target Audience: Testers, Developers, Leaders, Managers, Teamplayers
Prerequisites: Curiosity and willingness to challenge one's own habits
Level: Basic

Extended Abstract:
Let’s remember, that in the beginning of IT and software development there was no chartered territory. There was no right or wrong path – great minds dared to venture on into new lands. And sometimes they failed. Spectacularly or subtle, with a chance of correction or at huge (monetary) sunk costs. But always with great learnings, albeit not always good documentation.

Yet in school and in life we often get punished for failures. And as a result, we learn that pointing the blame away from ourselves pays off. This is not only bad for the climate and culture in a team or in an organization, it is also detrimental when it comes to our ability to learn. Especially in uncertain and complex contexts, where this ability is crucial to survive and thrive. When we block our learning capabilities, we lose our powers to deal with the unknown, to adapt to new and emerging information, to explore solutions. This inhibits progress and kills motivation.

While most of the above facts are common sense or even common knowledge, it is quite hard to break the mental and behavioral habits we were taught throughout education and our work-lives.

In this talk I will summarize the concept of psychological safety and the effects of a psychologically safe culture on creativity and solution focus in teams. I will introduce a “tool” to adopt a more open-minded and learning focused mindset. The participants will get the opportunity to discuss how the tool can be applied in their individual contexts. Also, I will let the participants exercise a method which helps to change the interpretation of mistakes as something dangerous and evil to something viewed as valuable and helpful. The method uses failures as steppingstones to come up with improved solutions, which not only enhances the results but also lets us question our mistake-habits. Finally, I will wrap things up by speaking about how handling errors affects motivation.

When facilitating retrospectives, there is often a focus on the agenda, the activities and the experiments you take away from the retrospective. Also, there might be a technical theme for the retrospective, but the people and the process for cooperation and communication is often what you end up discussing.

I will provide you with tips and tricks for how to avoid neglecting the human aspect of your retrospectives; the trust, the different personality types, the feeling of safety, and what you can pick up from the body language.

Target Audience: Facilitators, project leaders, managers, coaches, team leaders, Scrum Masters
Prerequisites: Have facilitated retrospectives or wants to facilitate them in the future
Level: Advanced

The growth of Kafka inside an organization sometimes follows the development of the broader Kafka ecosystem over its lifetime. The initial use case may be something conceptually simple, like mainframe offload or point-to-point integration, evoking the simple Large Pipe architectures of Kafka’s infancy. Then those newly populated streams of events present themselves as fertile grounds for real-time analytics, as stream processing applications grow up around them to perform analysis event-by-event, leaving behind legacy ETL processes and their long batch times. Finally, a rich set of event streams gradually comes to describe more and more of the evolving state of the business, forming the substrate on which an ecosystem of event-driven microservices can thrive.This growth in architectural sophistication of an organization’s Kafka usage mirrors the development of those same concepts in the Kafka community over the past decade. In many cases, the process can be played forward at an accelerated rate as leaders draw on lessons learned and concepts developed by the community. This talk traces this development, ending with a comprehensive vision of an event-driven architecture suitable for the next generation of information technology deployments. You’ll leave knowing where you need to go and how this new architectural paradigm will help you get there.

How much can you separate what you are building from how you are building it? This becomes an increasingly relevant question with IT moving from building systems to cultivating ecosystems. At the enterprise architecture level, one of the challenges nowadays is to decide which constraints to put in place to get a robust and evolvable landscape of interacting components, while at the same time it is important to minimize these constraints so that teams and units have some autonomy, and that the overall architecture can evolve continuously.

Target Audience: Interest in enterprise & software architecture and in digital transformation
Prerequisites: None
Level: Advanced

Extended Abstract:
In this presentation, we look at this interesting challenge from the standpoint of APIs, and how they can help to reduce the constraints to the necessary ones, while still resulting in an effective architecture.

One of the main challenges of enterprise architecture and software architecture today is to move from building systems to cultivating ecosystems. With business and IT moving closer together, and the demands on businesses to become better at changing and adapting, this introduces new constraints into architecture that looked different when the main goals were mostly centered around being secure, robust, and efficient.

Ecosystems exhibit different qualities from systems in the sense that they afford more autonomy to components, while at the same time introducing models of fitness and continuous change. With today's demand on business and IT to become faster and more effective at changing, the question is how to reflect those demands in new practices and models for architecting. We argue that one way of doing this is to focus on constraints, and to also focus on minimizing the constraints so that components can adapt and evolve as freely as possible.

We present a model of how to address API issues in the four areas of strategy, program, platform, and products. The goal of this model is to have as much coordination and alignment between these areas as necessary. The way this is done is by having clearly structured guidelines that represent and communicate the constraints, and that always clearly explain the rationale, the constraint itself, as well as possible ways how to comply with the constraint and how to test for compliance. The goal of this is to create loose coupling while still having a structure that allows governance. While in practice it would be ideal to fully automate all tests so that governance can be done in a full self-service model, so far we have concluded that automated testing is a good goal to have, but that some constraints still need a process of human review and approval.

The Extended Business Model Canvas (EBMC) links Lean Portfolio Management, System Thinking, Lean Product development, and agile development in a way suitable for established enterprises, not just startups.

Two additional components, the "Contribution to Strategy" and "Technical Debt," apply now to both operational and development values. Those components are supported by two special lenses that help agile teams to connect better, align, and achieve more business agility.

Target Audience: Architects, Business Owners, Portfolio Managers, Product Managers, POs, SMs, Agile Teams
Prerequisites: Scaled Agile Frameworks
Level: Advanced

Extended Abstract:
The business model canvas (BMC) developed by Osterwalder and Pigneur explains "how value is created, delivered and captured from an organizational perspective." The BMC excels through the addition of the simple yet effective Value Proposition Canvas (VPC). The BMC combined with the VPC unfolds the driving powers and key pivot points along the operational value stream. It is a valuable Business Agility artifact increasing transparency along the operational value stream.

To link development value streams to operational value streams, it is helpful to abandon the greenfield approach and extend the BMC by to additional components.

The two extensions are "Contribution to the Strategy" and "Technical Debt." Nearly every epic has to legitimate its strategic fit for purpose in a more transparent way. Technical debt is also a matter that has to be dealt with transparently, as it seldom will disappear in the short term.

In this interactive presentation, the participants will learn how the EBMC can be used to help our clients to thrive in the digital age. Depending on the level of audience participation, this will range from a presentation based on the Corona-Warn-App as a use case to an audience-specific workshop.

The secret sauce is: how do we break down Strategy and Technical debt. The presentation shows how these two components can be examined generically to increase transparency.

We do this in three steps:

#1
Recap the application of the BMC and VPC. Let us lookout for some pitfalls when dealing with a more complex intake when there is some ambiguity between the operational and development value stream and the mapping of funding to ARTs. We usually see this when there is a complex mashup between value streams, reverse demand, and regular business, BAU IT-demand, and multiple ARTs.

#2
We add "Contribution to the Strategy" to the BMC to map the complex intake described in #1 and link the greenfield BMC with strategic themes and the portfolio level to integrate the various usually concurring stakeholders.

#3
We add "Technical Debt" to enable the program layer to better participate in environments with complex interwoven system landscapes and numerous different components and platforms.

80% of machine learning is said to be data wrangling. Is all this wasted effort? Hardly - often the journey really is its own reward.

In this talk, we'll briefly describe a machine learning project that predicts the outcome of test cases in a large-scale software development cycle. We'll then show what we gained from collecting the necessary data and how these insights can have lasting impact on the day-to-day work of developers, testers and architects. This includes a quick answer to the well-known question: Whose defect is it anyway?

Target Audience: Developers, Testers, Architects
Prerequisites: Basic knowledge of software development and testing and an interest in data analytics
Level: Basic

Extended Abstract:
Data science folk wisdom holds that at least 80% of machine learning consists of data wrangling, i.e. finding, integrating, annotating, and cleaning the necessary data.

While sometimes viewed as less "glorious" than the deployment of powerful models, this journey has its own rewards as well.

Benefits may sometimes be somewhat expectable, if still non-trivial, like data cleaning potentially exposing errors in underlying data bases.

In other cases, though, there may be some low-hanging fruit a casual glance might miss even though they are indeed rewarding.

Data integration often reveals opportunities for statistical analyses that are relatively simple, but may still have high impact.

In this talk, we'll start at the destination: the result of a machine learning project where we successfully predicted test results from code changes.

A necessary task was the integration of several data sources from the full software development cycle - from code to testing to release in a large industry project with more than 500 developers.
Naturally, this required all typical steps in the data science cycle: building up domain knowledge and problem understanding, both semantic and technical data integration, data base architecture and administration, machine learning feature design, model training and evaluation, and communicating results to stakeholders.

These steps yielded several benefits, on which we will focus in our talk.

Among others these include data quality insights (e.g. about actual "back to the future" timestamps), and new analyses which were made possible by a unified view of the data (e.g. survival analysis of defects).

Last but not least, we demonstrate a simple answer to a well-known question, especially in larger software development contexts: Whose defect is it anyway - how can we avoid assigning defects to teams that have nothing to do with them?

Thanks to the integrated information sources from systems concerned with version control, test result logging, and defect management, we are able to support the claims made in this talk with statistics taken from 6 years of real-world data.

In speaking about better ways of thinking and problem-solving, Linda has introduced Jonathan Haidt's model for the brain. He proposes that the rational, conscious mind is like the rider of an elephant (the emotional, unconscious mind) who directs the animal to follow a path. In Fearless Change, the pattern Easier Path recommends making life easier to encourage reluctant individuals to adopt a new idea. Linda suggests that in conversations with others who see the world differently, we "talk to the elephant" instead of the "rider." That is, don't use logic or facts, but appeal to the emotional brain of the resistor as well as making the path more attractive. There is always the question: What's the best way to talk to the elephant? This presentation will provide some answers. Listeners will learn the best elephant-speak based on the latest research in cognitive neuroscience and also hear suggestions for providing an Easier Path.

SOLID principles are well-known for designing object-oriented systems. But what if you are developing microservices? IDEALS, is yet another silly mnemonic acronym and are the core principles for microservice design. The acronym stands for: Interface segregation, Deployability, Event-driven, Availability over consistency, Low Coupling, and Single responsibility. We will relate these IDEALS to techniques, tools, technologies, and domain modeling principles we use today to develop modern service-based distributed systems (microservices).

Target Audience: English, Developers, Architects, QAs, Testers, Product Owners, Managers
Prerequisites: Basic Understanding of architecture and microservices and familiarity with domain modeling
Level: Advanced

Extended Abstract:

It's been seven years since we've started creating microservices. Practice has shown what design principles give you a sound foundation for a successful microservice architecture. Join us in this session to find out what they are, and how to realize them. For OO systems, Robert Martin compiled the five SOLID principles. For designing microservice-based solutions, we propose developers follow the "IDEALS":  

(I) Interface segregation tells us that different types of clients (e.g., mobile apps, web apps, CLI programs) should be able to interact with services through the contract that best suits their needs. 

(D) Deployability (is on you) acknowledges that in the microservice era, which is also the DevOps era, there are critical design decisions and technology choices developers need to make regarding packaging, deploying and running microservices. 

(E) Event-driven suggests that whenever possible we should model our services to be activated by an asynchronous message or event instead of a synchronous call. 

(A) Availability over consistency reminds us that more often end users value the availability of the system over strong data consistency, and they're okay with eventual consistency. 

(L) Loose-coupling remains an important design concern in the case of microservices, with respect to afferent (incoming) and efferent (outgoing) coupling. 

(S) Single responsibility is the idea that enables modeling microservices that are not too large or too slim because they contain the right amount of cohesive functionality. 

We will relate these IDEALS to techniques, tools, technologies and domain modeling principles we use today to develop modern service-based distributed systems (microservices).

Apache Kafka became the de facto standard for microservice architectures. Decoupled applications and Domain-driven Design (DDD) are key benefits. However, that also introduces new challenges like observability of the whole ecosystem. This session explores the problems of distributed Microservices communication and how Kafka, Kubernetes and a Service Mesh like Istio address them. Learn some approaches for combining them to build a reliable and scalable microservice architecture with decoupled and secure microservices.

Target Audience: Software Architects, Consultants, Developers, Project Leads
Prerequisites: Experience with distributed systems / messaging frameworks is helpful
Level: Advanced

Extended Abstract:
Apache Kafka became the de facto standard for microservice architectures. It goes far beyond reliable and scalable high-volume messaging. In addition, you can leverage Kafka Connect for integration and the Kafka Streams API for building lightweight stream processing microservices in autonomous teams. Decoupled applications and Domain-driven Design (DDD) are key benefits. However, microservices also introduce new challenges like observability of the whole ecosystem.

A Service Mesh technology like Istio (including Envoy) complements the architecture. It describes the network of microservices that make up such applications and the interactions between them. Its requirements can include discovery, load balancing, failure recovery, metrics, and monitoring. A service mesh also often has more complex operational requirements, like A/B testing, canary rollouts, rate limiting, access control, and end-to-end authentication.

This session explores the problems of distributed Microservices communication and how both Apache Kafka and Service Mesh solutions address it together on top of Kubernetes. I cover different approaches for combining both to build a reliable and scalable microservice architecture with decoupled and secure microservices.

Together with 100 IT engineers we have been given the freedom to figure out how to transform from doing traditional IT Operations to being agile.

We use Scrum@Scale and Heart of Agile to remove debt; Organizational Debt in the form of old leadership structures that create unclear mandate for scrum roles and prevents organizing around products; Technical Debt that keeps us busy maintaining old technologies and prevents the creation of relevant cloud infrastructure products.

Our story is about how to fuel change through addressing frustrations.

Target Audience: Managers, Coaches, decision makers, Project Leaders, Practitioners
Prerequisites: Basic understanding of agile frameworks and methodology
Level: Advanced

Extended Abstract:
In 2017, we together with 100 IT engineers in an internal IT function of an old industrial company set out to transform our organization from being traditional and hierarchical to becoming agile. The fundamental premise was that the top management invited us to change and gave us freedom to figure out how we would accomplish this. In this process, we used different ‘compasses’ such as Scrum at Scale and Heart of Agile that on different levels helped us navigate what step to take next to facilitate the change.

What we have come to realize was that it has been our major frustrations that have helped us navigate with these compasses and make decisions, and that many of the sources for our frustrations have been different kinds of ‘debt’. Organizational debt in the form of ‘old’ leadership structures that created unclear mandate for scrum leader roles and prevented teams from organizing around products. Process debt shows itself in an ITIL operating mindset that kept us from reinventing ourselves as a ‘development organization’ with continuous deployment and end user focus. And technical debt kept us busy maintaining old technologies and systems and prevented focus on learning about the brave new world of ‘the cloud’ and creating new, relevant infrastructure products at high speed. So far our efforts have given us an unexpected happy ending, as even if we still have long way to go on to become truly agile, our changes so far prepared the organization for the unforeseeable: Covid-19.

Our talk is a reflecting experience report about the frustrations that we have met and acted on and on frustrations we are currently living with and trying to act on. It is about how we are slowly uncovering how the past is haunting the organization in so many ways – which is also the reason why the only way forward is a step-by-step process that cannot be planned up front.

We will provide examples from our past – where we have failed and succeeded but, most important, learned – and we will look forward at the challenges we have ahead of us in what we expect to be a 10 year journey towards an agile culture.

As architects become more senior, we are expected to contribute to growing the product, the organization, and the people. This session explores three roles of an architect that help them meet these expectations: architect as leader, as mentor, as coach. This session offers practical tools, methods, and frameworks that help both experienced and aspiring architects succeed in each of these roles.

Target Audience: Architects, engineers, developers, managers, senior/principal/distinguished engineers
Prerequisites: Curiosity about how architects can be effective leaders, mentors, and coaches
Level: Advanced

Architecture work is all about trade-offs. We weigh security against ease of use, we balance availability with maintainability and contrast performance with reliability. But how do we evaluate the cost and benefits of change? As architecture is a means to an end, not an end in itself, architectural improvements have to be governed by sound reasoning, and more often than not that has to be based on numbers. Which in turn implies the need for good practices for the financial evaluation of technical decisions. Here we'll explore a dozen of these.

Target Audience: Software architects, developers, managers
Prerequisites: Some experience with real world architectural and design decision (even without putting numbers on them)
Level: Advanced

We took advantage of the COVID digitalization challenge and converted our Design Sprints and UX workshops into a digital format. A dozen customer workshops in a wide variety of contexts (including logistics, public and chemical clients) have demonstrated UX workshops can also work virtualized with some advantages, e.g. being able to integrate participants from remote locations cost-effectively. In this session evaluated tools, techniques, best practices and lessons learned virtualizing UX workshops will be presented and discussed.

Target Audience: UX Practitioners, Business Analysts, Project Leaders, Decision Makers
Prerequisites: Familiarity with regular onsite Design Sprints does help, although I will provide a short recap
Level: Advanced

In an ever increasing need of remote work, we still need to envision new business models, explore our business processes and design our software systems. While nothing can replace the in person collaboration of an EventStorming, remote tools bring their own exciting upsides. During the lock down of the COVID-19 pandemic the DDD community experimented and distilled a collection of remote modelling methods. Let us together dive into some interesting trade-offs and find amazing new tools that carry us into the future.

Target Audience: Senior developers, Software Architects, Facilitators, Consultants, C*Os
Prerequisites: A basic understanding of why we model and how communication influences software would be good
Level: Advanced

Extended Abstract:
We will explore remote EventStorming, remote Context Mapping with Bounded Context Canvas, architecture design and documentation emerging from and integrated into the model and many more.

Do you find yourself, or your team facing unsolvable problems? Problems that start to polarise and get decided by the people with the most rank? Or the majority vote decided and it resolves in a split in the team or in people feeling left out, or excluded? Perhaps you find yourself excluded from a team or company? Polarities cannot be solved, only managed. With polarity mapping we manage that polarity and go from either-or thinking to both-and thinking, and this way includes the entire team in managing that polarity.

Target Audience: Architects, Developers, Decision Makers, CTO, Tech Leads, designers, facilitators
Prerequisites: None
Level: Advanced

Extended Abstract:
Do you find yourself, or your team facing unsolvable problems? Problems that start to polarise and get decided by the people with the most rank? Or the majority vote decided and it resolves in a split in the team or in people feeling left out, or excluded? Perhaps you find yourself excluded from a team or company? And the moment you think you solved it they come back again. The thing is, polarisations like these cannot be solved, like breathing in and breathing out but need to be managed. If we don't, we will make compromises or stay in one polarity and experience the downside of both. To identify and manage polarities, we need to discuss and start using polarity mapping.

In this session, we will interactively expose you to polarity thinking. We will explore how to identify polarities and how we can start managing them with Barry Johnson Polarity Mapping. We will take a common polarity in software design, like too much vs too little upfront design, mob/pair programming vs programming in isolation, and planning vs taking action. By filling in the polarity map together, we show you the power of visualisation to manage the polarity. We will go from either-or thinking to both-and thinking, and this way includes the entire team in managing that polarity.

Languages that raise the level of abstraction closer to the problem domain help improve quality and productivity. This can be best achieved when the language is directly based on the problem domain, not implementation concepts or existing languages. We describe how to create domain-specific languages in tight collaboration with domain expert users: as soon as a language concept is defined it can be immediately applied by users. We demonstrate this with examples from various fields, such as automotive, home electronics and automation systems.

Target Audience: Developers, subject matter/domain experts, managers
Prerequisites: experiences on applying some modeling language
Level: Advanced

Extended Abstract:
This talk is based on industry experiences on applying domain terminology directly in a modeling language (in its grammar). This way domain experts can apply familiar terminology, and map the specifications directly to code, to other more technical models, or the same set of models are shared by both domain experts and developers. The talk starts with a practical example how domain experts from different fields can collaboratively edit the same specifications each having own background (industry process, software, hardware, communication). Next the talk describes guidelines how such languages can be created: how domain terminology is defined into a language and how such language can be applied. These guidelines are demonstrated with examples from practice, such as how functional safety engineers can collaborate using ISO26262 (functional safety standard) terminology and related them to the technical system development; and how UX and UI persons can define user interfaces and their behavior in a manner allowing developers to join and work with the same models. The talk is concluded with guidelines and hints backed by industry cases from companies like Panasonic and Elektrobit.

Der Vortrag findet in Englisch statt / The lecture will be in English

Per default, the standard library containers allocate their memory with new and release it with delete. These calls
• do not have deterministic execution times
• can lead to memory fragmentation
In many embedded applications this is not tolerable. Therefore, using standard library containers is not allowed.
With the allocators available since C++17 in the std::pmr namespace (polymorphic memory resources) these disadvantages can often be avoided. With the pmr containers, standard library containers can be used for the first time in the history of C++ in many embedded applications.

Zielpublikum: Architects, Developers, Project Leader, Manager, Decision Makers
Voraussetzungen: Basic C++ experience
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Per default, the standard library containers allocate their memory with new and release it with delete. These calls
• do not have deterministic execution times
• can lead to memory fragmentation
In many embedded applications this is not tolerable. AUTOSAR Rule A18-5-requires:
Memory management functions shall ensure the following:
(a) deterministic behavior resulting with the existence of worst-case execution time,
(b) avoiding memory fragmentation,
(c) avoid running out of memory,
(d) avoiding mismatched allocations or deallocations,
(e) no dependence on non-deterministic calls to kernel.
With the allocators available since C++17 in the std::pmr namespace (polymorphic memory resources) these disadvantages can often be avoided. With the pmr containers, standard library containers can be used for the first time in the history of C++ in many embedded applications.

C++20 is more or less out the door. It is probably the biggest change to the language since ever. In this session we will look into some changes that templates received with C++20. The biggest change is the introduction of Concepts.

We don’t stop there. We will also talk about improvements to CTAD and NTTP. Of course, we will also look into how templated lambdas work in C++20.

By the end of the talk you have learned about the newest C++20 template updates and how to apply them.

Target Audience: Developers
Prerequisites: Knowledge about at least C++11
Level: Basic

AI is maybe the most powerful tool our generation has available. Andrew NG called it "the new electricity". But what does it take to build AI enabled products? What are the key elements to achieve production grade AI? How does it impact your development process? How can quality be achieved? These are the questions this talk tries to answer. You will get an idea why the industry is talking about nothing less than a paradigm shift when it comes to developing AI based products.

Target Audience: Everyone interested in the shift from classical software engineering to data driven AI applications
Prerequisites: Interested in AI, how it works and its impact on engineering departments
Level: Advanced

Extended Abstract:
AI is maybe the most powerful tool our generation has available. Andrew NG called it "the new electricity". Most likely you used an AI based product within the last 3 hours, maybe without even noticing it. But what does it take to build AI enabled products? What are the key elements to achieve production grade AI? How does it impact your development process? How can quality be achieved? These are the questions this talk tries to answer. In addition we will look into the different stages of AI development and the tools which can help to make this process more efficient. You will get an idea why the industry is talking about nothing less than a paradigm shift when it comes to developing AI based products.

Whether evolution or revolution, or yet old wine in new skins, for more than 10 years, DevOps is changing how we develop and deliver software. This session looks back on the roots of DevOps, its movement until today, and current as well as possible future directions. This interactive session aims to offer a set of fruitful starting points for reflection and discussions.

Target Audience: Anyone interested in developing and delivering software
Prerequisites: Knowledge in DevOps and agile software development
Level: Advanced

The Test Pyramid is an efficient and effective approach for Software Testing but does not come with any details about concrete test methods or fixtures.

In my talk I will show you how to combine the principles of the Test Pyramid and the C4 Model for Software Architecture to elaborate a specific test strategy for your software product in a simple manner.

Target Audience: Architects, Developers, QA Engineers
Prerequisites: Basic knowledge in Software Architecture and QA Engineering
Level: Advanced

Extended Abstract:
Software tests have to specify the behaviour of your product as extensive and reliable as possible. At the same time their implementation and maintenance costs should be kept at a minimum.

As Kent Beck said before: "I get paid for code that works, not for tests".

The Test Pyramid is a proven approach for this problem but leaves a lot of room for interpretation when elaborating a test strategy for your product.

Furthermore there are a lot of partly contradictory definitions of Unit, Service and Integration Tests and variations like “Test Diamond” and “Test Trophy” make it even more confusing. So, how do we get from the Test Pyramid to a concrete test strategy?

In my talk I will show you how to combine the principles of the Test Pyramid and the C4 Model for Software Architecture to obtain a test concept tailored for your product. Examples taken from a recent project will demonstrate how this approach balances test coverage, maintainability and development costs.

Modern architectures (e.g. event-driven and reactive) will gain more traction as we build more complex systems, connect more distributed components and slice systems into smaller autonomous pieces. Unfortunately, many companies don’t update their business processes to reflect this. I’ll give an example and discuss the consequences, motivating you to advocate for a redesign of your business processes internally. Too much attention gravitates towards the technical side of reactive, without thinking about the user journey or business implications.

Target Audience: Architects, Developers, Business Analysts
Prerequisites: Experiences with software architecture
Level: Advanced

Extended Abstract:
There is a lot of buzz around reactive architectures. Take, for example, event-driven architectures, event-streaming or reactive programming. These architectures will gain more and more traction as we build more complex systems, connect more distributed components and slice systems into smaller autonomous pieces. Unfortunately, I see many companies that don’t update their business processes to reflect this new world. In this talk, I’ll give an example and discuss the consequences, hopefully motivating you to advocate for a redesign of your business processes internally–because too much attention gravitates towards the technical side of reactive, without thinking about the user journey or business implications.

My hope for the future of software development; We learn that we are responsible for so many big and small impacts to society and that we have to take that seriously. We learn that even if software processes are described in great detail, we should not stop questioning whether we are still doing the right thing, the right way. We can bring our whole self to work. But most of all we learn that continuous integration is something you must have, continuous delivery is very nice to have, and continuous deployment is but a lovely dream for most.

Target Audience: Software developers, agile coaches, managers, leaders, and anyone married to a software developer
Prerequisites: Experiences in agile software development
Level: Basic

Extended Abstract:
I have been in software development for 22 years, and I have seen trends come and go like the fascinations of a teenager. I have taught RUP and years later, I have laughed at RUP. On the other hand, I have laughed at Artificial Intelligence, but some years later, AI laughed at me.

This talk will describe how I think the future of software development will look if we reflect now and learn from the past. Learn to bring your whole self to work, and accept that others do the same. Learn that even if software processes can be described in great detail you should not stop questioning whether you are still doing the right thing in the right way. Learn that we are responsible for so many big and small impacts to society and that we have to take that seriously. But most of all learn that continuous integration is something you must have, continuous delivery is very nice to have, and continuous deployment is a lovely dream for most people.

In summary, I will borrow words from Dr Emmett Brown: “Roads? Where We’re Going, We Don’t Need Roads.” Developers will fly over the roadmaps and stage-gate systems and do exactly, no more, no less, what is needed to build wonderful software systems and to stay sane and human in our field.

Are the skills we apply as software developers of general value? Is our activity the collaborative exploration of creative spaces or the solitary application of mathematical techniques? This talk explores what programming can be, and what that means for teaching. Specifically, the prevalent approaches to teaching don't work, with disastrous effects for both inclusion and software quality. What does work is quite surprising. This talk gives a perspective on teaching from over 30 years of experience in schools, university, and industry.

Target Audience: Anyone
Prerequisites: None
Level: Basic

Extended Abstract:
In the past, we've been practicing software development mainly as tinkering, and teaching it as such through examples, and this has mostly been a failure. If the software of the future and its impact on society is to be better than the depressing present, fundamental changes are necessary. The common approach to teaching, example-based teaching, expects knowledge about what we do to propagate via mental osmosis. It doesn't work, and, worse, communicates the wrong things. As software people, we have great potential to demonstrate the value of thorough listening, deep analysis, self-criticism, attention to detail, and systematic abstraction. Moreover, we can show how astounding creativity grows from these tenets. This talk will report on experience from 30 years of teaching software development to people of all ilks, and show you how to apply them to your co-workers, students, children, and maybe even yourself.

This talk will examine principles that assist with successfully evolving from a monolith to Microservices. Deciding what to decouple along with when and how to incrementally evolve a system are the main architectural challenges in this process. It is important to commit to "stop adding to the monolith" - all new code is added as microservices; the "Strangler Pattern". The new features are microservices, occasionally replacing part of the monolith. Also, when writing new microservices code, it is important to avoid dependencies to the monolith.

Target Audience: English, Developers, Architects, QAs, Testers
Prerequisites: Basic Understanding of architecture and microservices and familiarity with domain modeling
Level: Advanced

Extended Abstract:
Being Agile, with its attention to extensive testing, frequent integration, and focusing on important product features, has proven invaluable to many software teams. When building complex systems, focus on features provides a lot of value and starting with a monolith architecture can be advantageous. However, over time, although you might be committed to keeping the code clean, and having lots of tests — the architecture can become harder to evolve. Ultimately technical debt and design problems will creep in until it becomes muddy, making it hard to deliver new features quickly and reliably. Also, evolving the system quickly can become harder. If things are changing quickly with lots of teams, evolving using the microservices architectural style can have many possible benefits.

Many Microservices architectures start from the evolution of a Monolith system by gradually applying the microservices architectural style. There are considerations and principles that assist with successfully evolving from a monolith to Microservices. Deciding what to decouple along with when and how to incrementally evolve a system are the main architectural challenges in this process. There are good principles that help with this evolutionary process. For example, it is important to commit to "stop adding to the monolith" - all new code is added as microservices. This is the core of the "Strangler Pattern". The new features are microservices, occasionally replacing part of the monolith. Also, there might be important pieces of the monolith that are getting hard to maintain and you want to pull these out. When this happens, you find design seams within the monolith, refactoring these out to components, that can ultimately be replaced with microservices. Early on, it is ok to create macro services first and then evolve (refactor) them to microservices. Also, when writing new microservices code, it is important to avoid dependencies to the monolith. Finally, you can use DDD modeling to identify aggregates and bounded contexts to pull them out from the monolith. This talk will examine various patterns when evolving from the monolith to microservices specifically with variations of the Strangler Pattern.

Raiffeisen Bank International (RBI) started in 2017 with “Group Digital Solutions” a journey in order not to oversleep the digitization of the banking industry.

Due to new approaches such as DevSecOps & Continuous Testing, the topic of software tests, whether manual or automated, had to be completely redesigned and implemented.

This talk gives insights into the test strategy & the fullstack test automation architecture that were used.

Target audience: testers, developers, architects, managers
Prerequisites: none
Level: Advanced

Extended Abstract:
So that Raiffeisen Bank International can keep up with digitization in the banking sector, the company relies on the use of native apps, microservices and REST APIs in the Amazon cloud when implementing its mobile banking strategy. 

In order to support the DevOps mantra "Automate everything", a full stack test automation strategy was developed that is based on open source tools and takes all components of the system architecture into account.

The independent services of the microservice architecture make additional interfaces visible that are not available in a monolithic architecture. The advantage is that they can be deployed and tested independently of each other.

Testing these systems is much more complex than testing a conventional monolithic application and needs additional demands on test automation, with classic integration tests being even more important for the overall structure. 

These integration tests were usefully supplemented by consumer contract tests. But end-2-end tests should not be missing either, since an effective test strategy must take into account both the isolated testing of individual services and the verification of the overall system behavior.

Aligning test automation with the classic test pyramid is a very useful approach if the individual layers are seen as the basis for “what is being tested” and not as a measure of the number of tests. Because the old wisdom still counts: “Quality over quantity!”.

For this keynote, Intel Software and TNG Technology Consulting go on a journey to some amazing innovations in Artificial Intelligence. Starting with the concept of Intel® oneAPI and introducing software development tools enabling a multi-architecture future, the keynote will travel in real-time to the AI Labs of TNG in Munich where Thomas Endres, Martin Förtsch and Jonas Mayer will take the audience on an exciting Live Innovation Hacking Tour showcasing the latest capabilities of AI at the edge.

Throw a line of code into many codebases and it’s sure to hit one or more testing frameworks. There’s no shortage of frameworks for testing, each with their particular spin and set of conventions and, but that glut is not always matched by a clear vision of how to structure and use tests — a framework is a vehicle, but you still need to know how to drive.

Compared to many languages, C++ has had slower widespread adoption of unit testing. This talk takes a deep dive into the practices and issues, looking at examples and counterexamples in C++.

Target Audience: C++ developers
Prerequisites: C++ programming
Level: Advanced

Looking back, especially now, makes us sad, but Linda will share scientific evidence that remembering the past provides measurable benefits. She'll outline the science and help us remember some of the "good old days" and then we'll all feel better.

Target Audience: Anyone
Prerequisites: None
Level: Basic

Extended Abstract:
Many of us experience nostalgia as a bittersweet emotion. It combines the memory of good times with the ache of loss. You might think that people who are more nostalgic are more prone to sadness and depression. But research shows that nostalgic reflection makes us more optimistic. It reaffirms our social connections. And by remembering important things about the past, it lays out a vision for a hopeful future. To demonstrate this, Linda will take us back to the "good old days" and through her remembrances, lead us all to a better place. This will, hopefully, demonstrate how nostalgia gives us renewed appreciation for the people and places that constitute our lives.

Autonomous and automated systems are increasingly being used in IT such as finance, but also transport, medical surgery and industry automation. Yet, the distrust in their reliability is growing. This presentation introduces the validation of autonomous systems. We evaluate in practical situations such as automatic driving and autonomous robots different validation methods. The conclusion: Classic methods are relevant for coverage in defined situations but must be supplemented with cognitive test methods and scenario-based testing.

Target Audience: Testers, Quality assurance, Architects, Requirements Engineers, Product Owners, Software Engineers
Prerequisites: Testing basic know-how
Level: Advanced

Extended Abstract:
Autonomous and automated systems are increasingly being used in IT such as finance, but also transport, medical surgery and industry automation. Yet, the distrust in their reliability is growing. There are many open questions about the validation of autonomous systems: How to define reliability? How to trace back decision making and judge afterwards about it? How to supervise? Or, how to define liability in the event of failure? The underlying algorithms are difficult to understand and thus intransparent. Traditional validations are complex, expensive and therefore expensive. In addition, no repeatable effective coverage for regression strategies for upgrades and updates is available, thus limiting OTA and continuous deployment.

With artificial intelligence and machine learning, we need to satisfy algorithmic transparency. For instance, what are the rule in an obviously not anymore algorithmically tangible neural network to determine who gets a credit or how an autonomous vehicle might react with several hazards at the same time? Classic traceability and regression testing will certainly not work. Rather, future verification and validation methods and tools will include more intelligence based on big data exploits, business intelligence, and their own learning, to learn and improve about software quality in a dynamic way.

Verification and validation depend on many factors. Every organization implements its own methodology and development environment, based on a combination of several of the tools presented in this presentation. It is however relevant to not only deploy tools, but also build the necessary verification and validation competences. Too often we see solid tool chains, but no tangible test strategy. To mitigate these pure human risks, software must increasingly be capable to automatically detect its own defects and failure points.

Various new intelligent validation methods and tools are evolving which can assist in a smart validation of autonomous systems.

This presentation introduces the validation of autonomous systems. We evaluate in practical situations such as automatic driving and autonomous robots different validation methods. The conclusion: Classic methods are relevant for coverage in defined situations but must be supplemented with cognitive test methods and scenario-based testing.

After years of introducing “CI”/CD-Pipelines, after using Jenkins, CircleCI, Docker and K8s, your teams still don’t deliver software within minutes? And your customers still know about bugs before you do? Well, maybe you’re doing it wrong.

We’ll share our experiences on how to incrementally get organisations and systems to be able to leverage all the things associated with “continuous everything”. We argue for solutions tailored to individual situations, and more connected to software craftsmanship than to buzzwords and boxed solutions.

Target Audience: Everyone with the challenge to get functionality to customers - quick
Prerequisites: Some knowledge about general software development
Level: Advanced

Extended Abstract:
After years of introducing “CI”/CD-Pipelines, after using Jenkins, CircleCI, Docker and K8s, your teams still don’t deliver software within minutes? And your customers still know about bugs before you do?

Maybe designing the perfect world during your first sprint just doesn’t cut it. The beautiful docker scaling idea just doesn’t work, because the “microservice” can only run in one instance at a time. The testautomation framework the Ops team provided can unfortunately not test your windows application. Your elasticsearch needs more and more space, but none of the developers have removed a single exception notification. The awesome buildpipeline with the included tests has a great dashboard that shows a red build continuously, but no one cares and you still do hotfixes on the production system. And your last major “refactoring” branch has been running green for the last two month, but you just can’t merge it back into your production code without breaking a few minds.

Well, maybe you’re doing it wrong.

Companies that successfully employ continuous delivery usually don’t excel in their tools. They excel in the architecture of their software, they excel in the way the people in the company work together, they excel in the way everyone actually understands what they are doing. In such environments people are not afraid of magic things that might happen in some unknown system, but leverage tools to automate things they themselves know how to do - so good that it gets boring and thus these tasks are better done by tools.

We’ll share our experiences on how to incrementally get organisations and systems to be able to leverage all the things associated with “continuous everything”. We argue for solutions tailored to individual situations, and more connected to software craftsmanship than to buzzwords and boxed solutions.

Over the history of software systems, the way we build such artifacts, the way we design them, the way we express them have evolved in seemingly disruptive ways. Even today, the pendulum swings between low ceremony agile methods to more rigid waterfall-ish ones; from big balls of mud to microservices and then back to big balls of microservices. In this talk, we'll examine the past, the present, and the future of software architecture: the role it plays in software systems, and the timeless fundamentals that remain across the fullness of time.

At the core of agile development are self-organizing cross-functional teams. Yet, this is often understood as e.g. backend & front-end developers working together. If an organization is aiming for company-wide agility, to fully benefit from agility it has to enable teams as value centers that are truly cross-functional by bringing in different perspectives from business, markets, cultures, beliefs etc. This way cross-functional teams overcome not only the limitations of organizational silos but also of a singular view on the market.

Target Audience: Project Leader, Manager, Decision Makers, in general everyone
Prerequisites: None
Level: Advanced

Extended Abstract:
Too many products have been developed that serve one kind of client only. The reason is that the composition of the teams leads (subconsciously) to the development of products that serve only people that resemble the people in the team. One “famous” example is the soap dispenser that only works if your hands are white.

If teams are really cross-functional and are resembling the diversity of the market, the products they’re creating are also better. Thus, if the whole team has the full business expertise, knows the market, reflects the full diversity of the clients, then it can even disrupt the market and isn’t waiting for some person (e.g. the Product Owner) to decide on priorities. With this real cross-functionality the team can fully understand the company’s business and has a holistic view of it, knowing its contribution to the company’s value stream.

Real cross-functional teams are an essential building block for implementing company-wide agility and the organization benefits by creating better and in a way more real products and by having more options when entering the war of talent.

"How is a diary connected with leadership?" and "how can this change our future?" you might be wondering.

In this session you will get some answers. You will benefit from my extensive experience with (business) journaling. And you will be introduced to psychological science that makes written self-reflection so powerful.

So...

- You want live up to YOUR values?

- You want to change habits in your life's "departments"?

- You want to harvest outstanding outcomes - at work and beyond?

YES?

Then join and get ready for leadership in ACTion!

Target Audience: Developers, Architects, System Engineers, Managers of all kind, human beings ;-)
Prerequisites: Curiosity and openness for new ways of thinking
Level: Basic

Extended Abstract:
During my career in IT and people development I had several turning points where I either was made to use journaling techniques or experimented with them myself to successfully tackle the next challenge.

Over the years some turning points "beyond business" in life followed. Also I got serious scientific foundations in my psychological studies. Having both - the science and my experience - I started reflecting why those 'written self-reflection' techniques are so powerful and – at the same time – they are still quite rarely used in the business context.

This session is suitable for all humans: curious journaling newcomers as well as seasoned written-reflection experts as I'll share my story, more than 10 years of experience and actionable tips and techniques.

Sustainability is often defined as the interconnection of: social connection, economic wellbeing, and a healthy environment. The recent corona pandemic has yet again highlighted the potential as well as the necessity of a fundamental technology: the internet. However, to be sustainable, the internet also needs to assess, mitigate, and live up to its responsibilities for a healthy environment – an element of the equation that is too often neglected. What is the internet’s environmental impact and what would it take for it to be sustainable?

Extended Abstract:
Sustainability is often defined as the interconnection of three elements: social connection, economic wellbeing, and a healthy environment. The recent corona pandemic has yet again highlighted the potential as well as the necessity of a fundamental technology: the internet. The internet has become the lifeline for social connection in times of physical distancing. It is also the primary means by which to still conduct business for those of us that are not on the essential frontlines, in terms of working remotely, providing online services, and monetization, hence being a critical vehicle to safeguard some economic wellbeing. However, to be sustainable, the internet also needs to assess, mitigate, and live up to its responsibilities for a healthy environment – an element of the equation that is too often neglected. What is the internet’s environmental impact and what would it take for it to be sustainable?