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

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.

Sich rasch wandelnde Märkte und Business-Modelle stärken den Ruf nach Flexibilität. Reaktionsfähigkeit soll Unternehmen auszeichnen. Wie genau kann Enterprise-Architektur (EA) hier unterstützen? Können langfristige Planung, Enterprise Repositories, Standardisierung und Governance im agilen Kontext tatsächlich nützen?

Diese Session zeigt, welche Ziele sich EA im agilen Kontext stecken sollte. Mit Erfahrungen aus der Praxis untermauert, werden wichtige Zusammenhänge illustriert und Tipps aus kleinen und großen Erfolgen abgeleitet.

Zielpublikum: Solution-, Enterprise-Architekt:innen, CTOs, interessierte Manager:innen
Voraussetzungen: Erfahrung in der Entwicklung größerer Systeme und Systemlandschaften
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Sich rasch wandelnde Märkte und Business-Modelle stärken den Ruf nach Flexibilität. Reaktionsfähigkeit soll Unternehmen auszeichnen, sich bietende Möglichkeiten wollen rasch genutzt werden. Wie genau kann Enterprise-Architektur (EA) hier unterstützen? Können langfristige Planung, Enterprise Repositories, Standardisierung und Governance im agilen Kontext tatsächlich nützen?

Diese Session zeigt, welche Ziele sich EA im agilen Kontext stecken sollte. Dazu werden organisatorische, methodisch/agile und technische Trends der IT-Industrie eingeordnet. Es entstehen sechs Themenblöcke, mit denen sich wandelnde Unternehmen in den letzten Jahren viel beschäftigt haben. Experimentierkultur und empirische Prozesse zu stärken, technisches und organisatorisches Feedback auf allen Ebenen zu fördern, oder auch gut gelebte Transparenz und die Öffnung von einst etwas "elitären" Architekturdiskussionen sind einige Beispiele, die ich diskutieren werde.

Mit Erfahrungen aus der Praxis untermauert, werden wichtige Zusammenhänge illustriert und Tipps aus kleinen und großen Erfolgen der eigenen Arbeit abgeleitet. Ein paar Mythen der EA-Disziplin könnten am Weg leiden.

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.

Es erwartet Sie ein lebendiger Bericht über die agile Transition bei Siemens Healthineers. Wir bieten Einblicke in die von uns gewählten Ansätze zum Portfoliomanagement und teilen unsere Erfahrungen auf dem Weg zur agilen Entwicklung komplexer Produkte (>300 Personen, SAFe). Wir beschreiben die ersten Schritte in eine Verbreitung von Agilität in die Gesamtorganisation (Personal, Marketing). Anhand von Beispielen zeigen wir gelungene und nicht gelungene Ansätze zur Gestaltung eines Kulturwandels.

Zielpublikum: Agile Change Agents, Manager:innen, Entscheider:innen, Architekt:innen
Voraussetzungen: Grundverständnis von Agilität
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Die ersten agilen Schritte wurden bei Siemens Healthineers bereits 2008 mit der Einführung von Scrum getan. Seit 2017 wird nun konzernweit die agile Transition vorangetrieben. Das Transition Team stellt seine gemachten Erfahrungen vor, insbesondere auch nicht erwartungsgemäße Ergebnisse und die Lehren daraus. Es werden beispielsweise die Themen Changemanagement, Scrum / agile Teams, Team of Teams, Portfolio sowie Management Support analysiert. Der Vortrag ist keine reine Frontalveranstaltung, sondern bietet dem Publikum auch Gelegenheit, sich aktiv einzubringen.

Ein halbes Jahrhundert der Software-Entwicklung ist von einem überraschenden Phänomen geprägt: Wir, die Entwickler:innen + Architekt:innen, haben nicht nur immer wieder neue Technologien und Architekturansätze geschaffen, sondern auch Methoden entwickelt, die über die reine Programmierung hinausgehen. Projektleiter, Anwender, Betrieb und Tester haben von unseren Innovationen profitiert. Dieser Vortrag berichtet über die erstaunlichen Beiträge, die unsere Disziplin konzipiert und entwickelt hat, und wagt einen Blick in die Zukunft unserer Disziplin.

Zielpublikum: Alle
Voraussetzungen: Keine
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Nach diesem Vortrag werden die Teilnehmenden voller Motivation ihre Reise durch die OOP antreten.

Neben dem Blick in die Vergangenheit wird die Zukunft unserer Disziplin den Schwerpunkt dieses Vortrags bilden.

Unter „Resilienz“ versteht man die Fähigkeit von Systemen, auch unter massiven Störungen von außen ihre Funktionsfähigkeit zu erhalten. Die Coronakrise mit ihren massiven Einschnitten und Opfern hat uns vor Augen geführt, dass Resilienz von Unternehmen entscheidend sein kann für das weitere Überleben. In diesem Vortrag betrachten wir Situationen, in denen Resilienz von besonderer Bedeutung ist, und leiten daraus ab, welche Voraussetzungen Unternehmen erfüllen müssen, um Resilienz zu zeigen. Spoiler: Auch Agilität spielt dabei eine Rolle ...

Zielpublikum: Manager:innen, Entscheider:innen, Organisations-Entwickler:innen, Coaches
Voraussetzungen: Verständnis über Unternehmenssteuerung und Agilität
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
Roter Faden dieses Talks ist eine Analogie zwischen der Situation, in der sich Unternehmen während der Coronakrise befanden und noch immer befinden, und den (frei interpretierten) Phasen der Behandlung lebensbedrohlicher medizinischer Notfälle, für die sich in den letzten 50 Jahren weltweite Standards etabliert haben (nein, es wird keine Schockfotos geben. Mir geht es um Taktik und Strategie, nicht um Sensationslust).

Für jede der Phasen (unmittelbare Existenzsicherung, Ursachenfindung, Aufbau von Handlungsoptionen, Ausprobieren der Optionen, Einrichten auf die neue Normalität) wird analysiert, welche Eigenschaften und Praktiken Unternehmen dabei unterstützen oder behindern und wie man sie fördern kann. Dass dabei viele Ähnlichkeiten mit agilen Ansätzen aufscheinen, ist nicht überraschend, wichtig sind aber auch die Bereiche, in denen Agilität alleine nicht ausreicht.

Was hat das mit Tintenfischen zu tun? Diese kommen aus einer Analogie der "Supporting Agile Adoption"-Arbeitsgruppe der Agile Alliance, in der Oktopusse als Beispiel für einen völlig anders organisierten Organismus dienen, der dezentral mit neun Gehirnen kognitive Leistungen erbringt, die sich mit intelligenten Säugetieren messen lassen können. Es zeigt sich, dass die Fähigkeit von Organisationen, Entscheidungen verteilt fällen zu können, ihre Resilienz wesentlich verbessern kann.

"Change the system - not the people!" Leichter gesagt, als getan. Um in Organisationen wirkliche Veränderungen hinsichtlich Diversität und Inklusion zu erzielen, müssen wir im Sinne des systemischen Ansatzes ganzheitlich alle Interaktionen zwischen Menschen, Markt und Gesellschaft betrachten. Hierfür zeigen wir eine strukturierte Situationsanalyse der vier systemischen Dimensionen in Organisationen. Mithilfe dieser systemischen Analyse lassen sich schnell und punktgenau Systemverletzungen und Wirkungsgefüge, sowie Lösungswege identifizieren.

Zielpublikum: Führungskräfte, Teamleiter:innen, (agile) Coaches, Scrum Master, Projektleiter:innen, Change Manager
Voraussetzungen: Keine
Schwierigkeitsgrad: Fortgeschritten

Extended Abstract:
"Change the system - not the people!" Leichter gesagt, als getan. Um in Organisationen wirkliche Veränderungen hinsichtlich Diversität und Inklusion zu erzielen, müssen wir im Sinne des systemischen Ansatzes ganzheitlich alle Interaktionen zwischen Führungsebene, Mitarbeitenden, Kolleg:innen, Kunden, Lieferanten, Finanziers, Markt, Gesellschaft, Kultur und Umwelt betrachten.

Hierfür zeigen wir eine strukturierte Situationsanalyse der vier systemischen Dimensionen in Organisationen. Mithilfe dieser systemischen Analyse lassen sich schnell und punktgenau Systemverletzungen und Wirkungsgefüge, sowie Lösungswege identifizieren. Dies tun wir gemeinsam anhand vieler Beispiele und spielerisch interaktiv.

Die Zuhörenden erhalten Einblicke und Perspektiven für einen systemischen Change-Ansatz und Haltung:

• Die systemischen Gesetze in Organisationen und deren Bedeutung im Kontext Veränderung

• Die 4 Grunddimensionen gesunder Organisationen und leistungsstarker Teams

• Auswirkungen von Systemverletzungen

• Wo sind die individuellen Hebel zur Veränderung, und wo herrschen gravierende Systemverletzungen vor?

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.

Führung ist zu wichtig, um sie nur Führungskräften zu überlassen! Darüber hinaus wollten wir bei uns die Führungsarbeit auf mehrere Schultern verteilen, Entscheidungen dezentralisieren und u.a. eine persönliche Weiterentwicklung durch eine vertrauensvolle Feedback- und Lern-Kultur ermöglichen. In diesem interaktiven Vortrag möchten wir in das Thema kollegiale Führung einführen, auf Vor- und Nachteile und Fallstricke bei der Implementierung eingehen und vorstellen, wie und warum wir unser Unternehmen in einer Kreisstruktur organisiert haben.

Zielpublikum: Entscheider:innen, Management, HR, Coaches, alle, die an alternativen Organisationsformen interessiert sind
Voraussetzungen: Grundkenntnisse agiler Methoden von Vorteil, aber nicht Voraussetzung
Schwierigkeitsgrad: Anfänger

Extended Abstract:
Führung ist zu wichtig, um sie nur Führungskräften zu überlassen! Darüber hinaus wollten wir bei KEGON die Führungsarbeit auf mehrere Schultern verteilen, Entscheidungen dezentralisieren, eine persönliche Weiterentwicklung durch eine vertrauensvolle Feedback- und Lern-Kultur ermöglichen, sowie den Fortbestand von KEGON im komplexen und dynamischen ökonomischen Umfeld sichern und nicht zuletzt KEGON wachstumsfähig machen.

Wir haben uns im letzten Jahr eine Reihe von Führungs-Modellen angeschaut und uns letztendlich für die kollegiale Führung in einem Kreismodell entschieden.

Kollegiale Führung ist die auf viele Kollegen und Kolleginnen dynamisch und dezentral verteilte Führungsarbeit anstelle von zentralisierter Führung durch einige exklusive Führungskräfte.

Im Januar 2020 sind wir mit einem Self-Selection-Workshop in die kollegiale Führung gestartet und alle Kollegen von KEGON haben in einem Kollegenkreis eine neue Heimat gefunden. Danach haben wir inkrementell daran gearbeitet, das Kreismodell von KEGON weiter auszubauen.

Wenn eine Menge kreativer Menschen sich eine neue Unternehmens- und Führungsstruktur gibt, dann geht das natürlich nicht reibungslos. Wir durften eine Menge Erfahrungen sammeln und lernen auch heute noch jeden Tag dazu.

In diesem interaktiven Vortrag, in dem wir - Mentimeter unterstützt - auch in kleinen Gruppen diskutieren wollen, möchten wir in das Thema kollegiale Führung einführen, auf Vor- und Nachteile und Fallstricke bei der Implementierung eingehen und vorstellen, wie und warum wir unser Unternehmen in einer Kreisstruktur organisiert haben.

Wir möchten unsere Erfahrungen und Lesson Learned mit Euch teilen und diskutieren. Wir möchten auch Lust darauf machen, sich mit kollegialer Führung zu beschäftigen – vielleicht ist das auch eine Organisationsform für Euer Unternehmen?

Unternehmen sitzen auf einem Datenschatz, oft unbeachtet, doch gar nicht so tief versunken! Mithilfe dieser Daten lassen sich Untersuchungen anstellen, Vorhersagen bilden und Experimente zur Verbesserung starten.

In ihrem Talk stellen Markus und Stefan die Geschichte von Peter vor. Einem Projektleiter, der mithilfe von bestehenden Ticketsystem-Daten leichtgewichtige Metriken erstellt und verschiedene Verbesserungspotenziale für sein Umfeld findet.

Zum Abschluss identifizieren sie geeignete Zeitpunkte, um effiziente Verbesserung umzusetzen.

Zielpublikum: Projektleiter:innen, Management, Teamleiter:innen, Scrum Master
Voraussetzungen: Basiswissen Statistik
Schwierigkeitsgrad: Anfänger

Extended Abstract:
Der Talk stellt ein häufig beobachtbares Phänomen vor: Viele Unternehmen sitzen auf einer Menge von (Mess-)Daten über die Durchlaufzeiten von Anforderungen, die ihre Teams fertiggestellt haben. Zu Beginn des Talks sensibilisieren Markus und Stefan die Teilnehmenden auf die Dienstleistungsorientierung jedes Unternehmens. Darauf folgt eine Anleitung zum Datenschatz heben. Wie komme ich an die Daten aus verschiedenen typischen Ticketing-Systemen ran? Wie werden daraus nutzbare Rohdaten, um aus ihnen geeignete Diagramme abzuleiten? Die Teilnehmenden erhalten dabei die Möglichkeit, die vorgestellten Vorgehen selber auszuprobieren, indem sie mithilfe vorbereiteter Übungen sowohl die Daten in geeignete Form bringen, wie auch sinnvolle Diagramme daraus erstellen. Wir verzichten dabei auf die Nutzung von (teuren) Spezialtools, sondern setzen das allseits verfügbare Excel ein.

Als Diagrammtypen wird das Durchlaufzeit-Histogramm intensiv vorgestellt. Zusätzlich werden weitere Metriken und Diagramme angeschnitten, die auf Basis dieser Daten Einblicke gewähren. Zum Beispiel das durchschnittliche Ticketalterdiagramm, das kumulative Flussdiagramm und die Flusseffizienz.

Eingebettet ist der Talk in eine unterhaltsame Projektgeschichte von Peter, der als Projektleiter verschiedenen Herausforderungen gegenüber steht und mithilfe von Diagrammen und Metriken Interventionen startet. Auch dies geschieht im halb-interaktiven Modus mit dem Publikum, dessen Ideen für Verbesserungen entgegengenommen und gemeinsam besprochen werden.

Den Abschluss der Session bilden die Punctuation Points, also Zeitpunkte, an denen verschiedene Verbesserungs-Experimente effektiver Wirkung zeigen können als zu anderen Zeitpunkten.