Thema: Collaboration
- Montag
06.02. - Dienstag
07.02. - Mittwoch
08.02. - Donnerstag
09.02.
Koordination von mehreren agilen Teams im skalierten Produktentwicklungsumfeld ist nicht selten eine Herausforderung: Konflikte zwischen Teams treten auf, Entscheidungsfindung dauert lange oder führt zu Unzufriedenheit, Verantwortung wird hin- und hergeschoben. Die Dynamik zwischen diesen Teams unterscheidet sich wesentlich von der innerhalb eines einzelnen Teams. Das führt zu Spannungsfeldern.
In diesem Workshop nehmen wir eine systemische und organisationsdynamische Perspektive ein, um Konflikte besser zu verstehen und adäquat damit umzugehen.
Zielpublikum: Agile Coaches, Organisationsentwickler:innen, Scrum Master, Prozessverantwortliche
Voraussetzungen: Basiskenntnisse von agilen Arbeitsweisen und skalierter Produktentwicklung
Schwierigkeitsgrad: Fortgeschritten
Extended Abstract:
Bei der Zusammenarbeit von mehreren Entwicklungsteams in skalierten Scrum-Umfeldern entsteht immer wieder die Frage, wie teamübergreifend Entscheidungen getroffen werden und Verantwortung über Teamgrenzen hinweg verteilt wird. Dabei entstehen strukturelle Konflikte, die in ihrer Dynamik verstanden werden sollten, um konstruktiv genutzt werden zu können.
Gerade bei Fragen zu Softwarearchitektur, Technologiestandards und Umgang mit Bugs braucht es Abstimmung. Will man hier nicht zentralistisch vorgehen – d. h. eine Person entscheidet für alle – braucht es Mechanismen und Strukturen, die selbstorganisierte Zusammenarbeit ermöglichen.
Nun ist die Schwierigkeit, dass es kaum möglich ist, Konsens über viele Teams hinweg herzustellen. Dabei spielt es eine untergeordnete Rolle, ob LeSS, SAFe, Nexus oder andere Ansätze verwendet werden.
Die Teilnehmenden können im Workshop anhand von Übungen, Fallbeispielen und Diskurs lernen, welche strukturellen Konflikte zwischen Teams in skalierten Umfeldern auftreten können (bei denen die beteiligten Akteure austauschbar sind), welche Arten der Entscheidungsfindung in skalierten Umfeldern möglich und welche sinnvoll sind und wie Selbstorganisation mit mehreren Teams praktisch umsetzbar ist.
Joris Wachter ist als Agile Coach bei andrena in München tätig und beschäftigt sich dabei mit Team- und Organisationsentwicklung sowie Gruppen- und Organisationsdynamik in sozialen Systemen. Als Psychologe, Informatiker und Gruppendynamiker (öggo) unternimmt er gerne Perspektivwechsel und analysiert Methoden, Praktiken und Theorien, um sich selbst und andere zum Nachdenken anzuregen.
Nicht nur Teams mit hoher Diversität treffen auf polarisierende Themen und Konflikte, die es scheinbar unmöglich machen, einen Konsens oder gar ein gemeinsames Vorgehen zu finden. Denkmodelle, die auf Argumentation und Objektivität beruhen, scheitern hier oft bereits im Ansatz.
Eine Einführung in die psychologische Forschung erklärt, warum das so ist, und welche Denkmodelle hier weiterhelfen können. Dann sammeln Teilnehmer praktische Erfahrung mit Gesprächsformaten, die helfen, Polarisierung und Konflikte zu behandeln oder zu vermeiden.
Max. Teilnehmendenzahl: 50
Zielpublikum: Team Coaches, Führungskräfte, Entscheider, Projektleiter:innen
Voraussetzungen: Bereitschaft
Schwierigkeitsgrad: Anfänger
Dr. Jörn Redlin arbeitet als Teamentwickler und Coach mit einer methodischen Spannweite von Spezialeinheit bis Doktorhut. Engagiert, dynamisch, kontaktstark, gefühlvoll - für gegenseitiges Verständnis und gemeinsame Weiterentwicklung!
Jutta Eckstein arbeitet weltweit als Business-Coach, Change-Managerin & Beraterin. Ihr Fokus liegt auf unternehmensweiter Agilität in großen & verteilten Organisationen. Sie war von 2003 bis 2007 im Vorstand der AgileAlliance. Sie hat einen M.A. in Business Coaching & Change Management, einen Dipl.-Ing. in Product-Engineering und ist als Immissionsschutzbeauftragte (Umweltschutz) zertifiziert. Jutta wurde 2011 von der Computerwoche in die Top 100 der bedeutendsten Persönlichkeiten der Deutschen IT gewählt.
Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/jutta.eckstein
Alles hat eine API: Wir ITler sind megagut darin, Software-Architekturen zu durchleuchten und neue Integrations-Patterns für technische Komponenten zu entwickeln. Warum wenden wir diese Fähigkeiten nicht auch auf unser Mindset und unsere Teams an?
In diesem Workshop üben wir uns in der Transferleistung: Warum sind unsere Reaktionen oft hard-coded statt loosely-coupled und wie können wir das ändern? Ist meine Gedankenwelt wie ein Monolith aufgebaut, die sich nur mühsam weiterentwickelt oder lässt sie schnelle Updates zu, wie Microservices?
Zielpublikum: Entwickler:innen, Projektleiter:innen, Manager, Entscheider, Architekt:innen
Voraussetzungen: Architekturmuster- und Projekterfahrung ist von Vorteil, aber kein Muss
Schwierigkeitsgrad: Fortgeschritten
Extended Abstract:
Dieser Workshop macht Lust auf Selbstführung. Die Hypothese, zu der dieser Workshop einlädt, ist:
Das Gesetz von Conway gilt nicht nur für Abteilungen, sondern auch für die Teammitglieder: „Organisationen, die Systeme entwerfen, sind gezwungen, Entwürfe zu erstellen, die die Kommunikationsstrukturen dieser Organisationen abbilden.“
Je mehr Dynamik das Umfeld und die Systeme einfordern, desto dynamischer muss mein Mindset im Team sein. Nicht nur, damit die Systeme funktionieren, sondern damit ich in dem Umfeld glücklich sein kann.
So kann ich beispielsweise das ganze Team inklusive mir selbst als Microservice-Architektur betrachten. Ich kann analysieren: welche Schnittstellen biete ich nach außen an, und sind die auch gut dokumentiert? Wissen die Anderen dass die meisten Schnittstellen vor dem ersten Kaffee nicht ansprechbar sind? Welche Reaktionen sind hart-verdrahtet, wo bin ich anfällig für eine Denial-of-Service Attacke, und was kann ich dagegen tun?
Mit interaktiven Übungen finden wir die richtige Balance für die eigene Mindset und Team-Architektur. Am Ende des Workshops haben Sie einige Entwurfsmuster im Gepäck, mit denen Sie die eigene Mindset-Architektur Step by Step refactoren können (wenn Sie das wollen). Und das spannende dabei: Die meisten Tools haben sie schon im Gepäck - Sie haben sie nur noch nicht auf sich selbst angewendet.
IT und Theater: Christoph Diefenthal arbeitet seit mehr als 15 Jahre als Entwickler und IT-Führungskraft - den kreativen Ausgleich fand er im Theater. Als Schauspieler hat er soviel über Perspektiven + Rollenwechsel gelernt, dass ihm irgendwann klar wurde: Das bringe ich in die Firmenwelt - und zwar mit Spaß!
Seit er die Mutual Empowerment GmbH mitgegründet hat, kombiniert er Team- und Führungsworkshops mit Werkzeugen des systemischen Coachings und Übungen aus dem Impro-Theater. Begeisterung zum Mitnehmen!
"If you can't measure it, you can't improve it." Although it is (relatively) easy to measure objectively quantifiable decision criteria such as profit, how does one measure "soft" attributes, such as psychological safety or team dynamics, to judge an intervention's success?
This talk will present insights into the practical application of leading-edge research into what makes intelligent, high-performing teams and organisations, exploring the science behind the current buzzwords of psychological safety, diversity, and empathy.
Target Audience: Managers, Coaches, ScrumMasters
Prerequisites: None
Level: Advanced
Extended Abstract:
"If you can't measure it, you can't improve it." This quote, attributed to Peter Drucker, emphasises that the ability to measure something is essential for seeing changes in it. Although it is (relatively) easy to measure objectively quantifiable decision criteria such as profit, how does one measure "soft" attributes, such as psychological safety or team dynamics, to judge an intervention's success? The problem with most team/organisational assessments is that they say more about the persons who designed the evaluation (and what they want to sell) than about the persons taking it.
This talk will present insights into the practical application of leading-edge research into what makes intelligent, high-performing teams and organisations, exploring the science behind the current buzzwords of psychological safety, diversity, and empathy.
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.
Hoch performante Teams entstehen nicht von selbst – da sind wir (und die Forschung) uns mittlerweile einig. Doch was hilft nun einem Team weiter? Und welche Tools wende ich in welcher Situation an?
Zielpublikum: Führungskräfte, Teamleiter, Scrum Master, Agile Coach, Teammitglieder
Voraussetzungen: Keine
Schwierigkeitsgrad: Fortgeschritten
Extended Abstract:
Nach über zehn Jahren Arbeit in, mit und an verschiedenen Teams quer durch die Industrie haben wir viele Tools und Werkzeuge ausprobiert, einige Mal völlig danebengegriffen, aber auch echte Perlen gefunden. Wir haben acht Erfahrungsräume herausgearbeitet, in denen Teams unterstützt werden dürfen.
Dieser Vortrag bringt Orientierung in den Team-Entwicklungswerkzeug-Dschungel, indem ich dir meine meistgeliebten freien Tools zur Teamentwicklung vorstelle und einordne. Mit der einen oder anderen Geschichte aus dem Alltag und der dazugehörigen Forschung – praxisnah und pragmatisch.
Jasmine Simons-Zahno ist „Agile Psychologin“, die sich leidenschaftlich für die menschliche Seite der Produktentwicklung einsetzt. Ihr Masterstudium in Organisationspsychologie qualifiziert sie auf einzigartige Weise für die Auseinandersetzung mit den Hindernissen und Widerständen, welche entstehen, wenn das agile Paradigma mit traditionellen Organisationsstrukturen kollidiert. Sie hat es sich zum Ziel gesetzt, Unternehmen dabei zu unterstützen, produktive und motivierende Umgebungen zu schaffen, die Mitarbeiter ermutigen und inspirieren, ihre beste Arbeit mit Freude zu leisten.
Eure Domänen sind identifiziert? Event Storming gemacht? Anti-Corruption Layer definiert? Sehr gut, das ist die halbe Miete.
In der Praxis geht es danach um technische Basisplattformen, zentrale Sicherheitskonzepte, UX-Strategien usw., aber auch um die Abbildung dieser Themen auf Teams und deren Zusammenarbeit.
Wir präsentieren Erfahrungen aus echten Projekten und zeigen, wie es nach dem ersten DDD-Aufschlag weitergeht. Wir vertiefen Konzepte wie Team Topologies und streifen Themen wie den Ideal Present Canvas oder soziotechnische Architekturen.
Zielpublikum: Entwickler:innen, Agile Coaches, Management-Rollen
Voraussetzungen: DDD Grundlagen
Schwierigkeitsgrad: Fortgeschritten
Extended Abstract:
Domain-Driven Design und verwandte Techniken eigenen sich sehr gut, um den fachlichen Schnitt einer Anwendung und den Teamschnitt von Produktteams zu definieren bzw. weiterzuentwickeln. Blicken wir auf ganze Entwicklungsvorhaben in der Praxis, gibt es jedoch eine Menge an Themen, die nicht zwangsläufig in Domänenservices landen: Wie gehen wir mit technischen Basisplattformen um? Wo entstehen zentrale Sicherheitskonzepte? Wo UX-Strategien oder Logging und Tracing-Konventionen? Die Abbildung dieser Themen auf Teams und deren Zusammenarbeit ist schwierig zu besprechen.
Team Topologies beinhaltet Konzepte und Prinzipien, aber auch eine Notation, um hier zu helfen. Es spielt gut mit Praktiken aus dem DDD-Bereich zusammen und kann um weitere Werkzeuge (wie den Ideal Present Canvas) ergänzt werden. So wird es möglich, komplexe Softwaresysteme über die fachliche Gliederung hinaus zu besprechen und Teamschnitt sowie Team-Zusammenarbeit explizit weiterzuentwickeln.
Wir haben in mehreren Branchen - wie E-Commerce, E-Mobilität, Logistik und anderen - Erfahrung in der Anwendung gesammelt. In dieser Session präsentieren wir unsere Erkenntnisse aus dieser Praxis, zeigen Beispiele und geben Hinweise zur eigenen Anwendung. Wir sprechen über Minimal Viable Platforms, Interaction Modes für Teams, die Herausforderungen bei Enabling Teams in Ramp-up-Phasen usw. Alles ausgehend von der gängigen DDD-Praxis.
Stefan Toth berät Entwickler, Teams und Unternehmen in Sachen Agilität und Software-Architektur. Fundiert, klar und effektiv. Seine Erfahrungen reichen vom Banken- und Versicherungssektor über sicherheitskritische Branchen bis hin zur Unterstützung von Internet Start-ups. Neben dem breiten technologischen Kontext ist die methodische Erfahrung aus agilen Projekten, Architekturbewertungen und IT-Transformationen sein größtes Kapital.
Peter Götz ist IT Consultant und agiler Coach. Er hat in mehr als 20 Jahren Softwareentwicklung aus verschiedenen Perspektiven und in verschiedenen Rollen begleitet.
Als aktives Mitglied im iSAQB liegen ihm Software-Architektur und die Arbeit als Software-Architekt besonders am Herzen.
Er ist Professional Scrum Trainer der Scrum.org und hat langjährige Erfahrung in agilen Softwareentwicklungsprojekten.
Weitere Informationen zu Peter gibt es unter: https://pgoetz.de/
Vortrag Teilen
"We're looking for passionate programmers!" says the job ad. Passion is used to evoke single-mindedness, drive and intensity. There is more than one kind of passion, and when raw passion is tempered with compassion and dispassion, we start to see a more balanced way of development.
Good development draws on both creativity and rationality, on both experience and experimentation, on both focus and connection, on both individual skill and group intelligence. Let's explore the many passions of programming.
Target Audience: Developers, Architects, Managers, Coaches, Leaders
Prerequisites: No specific prerequisites
Level: Advanced
Extended Abstract:
"We're looking for passionate programmers!" says the job ad. For a love-in or a development role? Passion is used to evoke single-mindedness, drive and intensity, but it also has many other meanings, surely not all of which can be intended. Love aside, passion also spills over into irrationality, aggression — e.g., crimes of passion — and unconditional and unquestioning pursuit of ideas. Our acceptance of this word and this quality should be partial and conditional. But there is more than one kind of passion, and when raw passion is tempered with compassion and dispassion, we start to see a more balanced way of development.
Good development draws on both creativity and rationality, on both experience and experimentation, on both focus and connection, on both individual skill and group intelligence. The dry language of productivity needs to admit the possibility of enjoyment; the culture of burn-out needs to give way to humanity and empathy. Let's explore the many passions of programming.
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.
Vortrag Teilen
IT is always changing ... In this talk I'll do some crystal ball gazing from two perspectives. At heart, I’m a tester. For two years I’ve also been a CEO. I’ll look at what factors are at work and what kinds of effects will they have on how we work and the roles of testers and software professionals.
Alongside musings about the future, I’ll talk about concrete activities on an individual and company level to best prepare ourselves for this nebulous future.
Target Audience: Everyone
Prerequisites: None
Level: Basic
Extended Abstract:
I’m not the first person to notice that the world is constantly changing and that everything is impermanent. Most especially after the last two years, we have really been forced to come to terms with how quickly and drastically things can change. As IT professionals, we are aware of the intrinsic changeability of projects, contexts and our business, but the events of the last couple of years have put this into sharper focus.
But let’s not get too generally philosophical about the whole world. Let’s look at what is in our more immediate context and perhaps even in our sphere of influence. If our future is anything, it’s nebulous (and I don’t just mean the cloud). How will external changes shape our teams and our work, and how can we shape ourselves proactively in order to be able to respond to changes, make changes or our own and even thrive?
In this talk I’d like to do some triangulated crystal ball gazing from two perspectives. At heart, I’m a tester. For two years I’ve also been a CEO. From my passion for testing and my experience of business and people in organisations, I’ll look at what factors are at work now, what known unknowns we have and what kinds of effects will they have on how we work and the roles of testers and software professionals.
Alongside musings about the future, I’ll talk about concrete activities on an individual and company level to best prepare ourselves for this nebulous future.
Alex Schladebeck ist eine Testerin aus Leidenschaft. Ihr Herz schlägt für Qualität, Agilität und ihre Mitmenschen. Sie ist Geschäftsführerin und Leiterin der Qualitätssicherung bei der Bredex GmbH.
In diesen Rollen unterstützt sie Kollegen, Kunden und Teams in ihre Reise, bessere Qualität zu liefern: in Produkten, in Prozessen und in der Kommunikation.
In früheren Rollen war sie für die Befähigung von Teams und qualitativ hochwertige Systeme verantwortlich. Nun befähigt sie andere, genau das zu machen, und sorgt für eine Umgebung in der Firma, wo jede(r) aufblühen kann.
Alex schaut mit neugierigen Tester-Augen auf die Welt und möchte immer dazu lernen. Sie teilt ihr Wissen und ihre Erfahrungen in Workshops, Coachings und als Sprecherin oder Keynote-Sprecherin auf Konferenzen.
Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/alexandra.schladebeck
Vortrag Teilen
This talk explains how Scenario Casting enables agile teams to pull together despite diverse ideas and concerns - in three iterative collaborative steps:
1. Find example scenarios of how ideas and concerns affect the domain - strictly in domain language! This provides an initial Scenario Backlog outlining the problem space.
2. Prioritize the Scenario Backlog and agree on scope.
3. Combine the top scenarios into coherent overarching Orientation Scenarios.
Let the agile teams focus on their parts of the Orientation Scenarios over the next iteration(s).
Target Audience: Stakeholders, Non-IT Domain Experts, BAs, Developers, Architects, QMs, Agilists
Prerequisites: Project experience, basic knowledge of DDD, basic knowledge of agile methods
Level: Advanced
Extended Abstract:
Scenario Casting is a collaborative planning and requirements engineering method that has emerged over the past four years in various Domain-Driven Design projects. It is used intensively with dozens of teams most of them involved in ambitious transformation projects.
Scenario Casting is especially helpful for getting a handle on complex or even overwhelming domains. If your domain feels like this and there are a lot of people involved too, you should give Scenario Casting a try.
Scenario Casting lays the groundwork for focused collaborative modeling sessions using domain storytelling or event storming. It ensures that all relevant points are addressed step by step. Also, it helps to quickly identify your domain's subdomains and determine the people who should be involved.
More relevant scenarios are discovered during collaborative modeling. They all go into the Scenario Backlog and will be considered in future Scenario Castings.
Unlike other concepts that try to scale agile, the Scenario Backlog is strictly limited to DDD's problem space, thus avoiding upfront design and premature planning.
Instead, Scenario Casting sets a common focus in problem space for agile teams by defining Orientation Scenarios. An Orientation Scenario illuminates parts of the problem space very precisely. It defines the actual results that solutions must deliver from a domain perspective - but without prescribing specific solutions. Finding and implementing good solutions remains the responsibility of the individual agile teams!
This talk contains examples from real projects and gives you best practices - so you get a good idea of how to try Scenario Casting yourself!
Jörn Koch is an agile and DDD coach and trainer. He worked many years as a developer and architect. Jörn loves ambitious projects in highly collaborative environments. He has practical experience as an agile coach for 15 years, and as a DDD coach for 6 years.
Vortrag Teilen
Over 95 % of companies in the EU are small businesses with less than 250 employees. Many of them would like to reduce their carbon emissions but very few have the knowledge and time needed to take action.
Reaching a sizable fraction of these companies with actionable information about their carbon footprint has a huge potential for climate impact. But is that possible for an organization with less than 10 employees? While also working at a sustainable pace?
Target Audience: Everybody willing to explore how to build software for our future
Prerequisites: none
Level: Basic
Extended Abstract:
Humanity of today is faced with several very serious challenges: environmental problems such as climate change are changing our conditions for living and producing food, making social problems like poverty and global inequality worse. A good future for our Planet Earth and the humans it supports is possible, but only if we act for it. The aim of this session is to give more people the confidence and tools to get more people to do exactly that: act for a better future.
We’ll spend most of the session exploring the story of GoClimate, a company founded for the sole purpose of stopping climate change. From the example of GoClimate’s journey we’ll extract a toolbox for making an impact on a global problem with a small team. Hopefully you’ll leave this talk convinced that your actions matter and with concrete ideas on how you can act.
Since many years Pia Fåk Sunnanbo is a software engineer with experience from a wide range of languages, environments and domains. She loves deleting code and using the simplest tools possible. Fascinated how humans create technology and technology changes human behavior and lives. She holds a firm belief that software engineering knowledge is a huge power in today's society. It's our responsibility to use it for good. Works full time to stop climate change.
Vortrag Teilen
Weg von “hustle culture”, hin zu einem Tempo, welches langfristig aufrechterhalten werden kann und gesund für alle Beteiligten ist. Klingt gut? Beängstigend? Oder sogar beides?
Das richtige Gleichgewicht, eine “sustainable pace” im Arbeitskontext zu finden, ist weder eine individuelle Aufgabe noch liegt es allein in der Verantwortung eines Teams. Es ist ein Zusammenspiel von beidem – und mehr noch: Führungspersonen spielen hier ebenfalls eine zentrale Rolle.
Gerade sie haben oft (noch) einen größeren organisatorischen Hebel und in jedem Fall eine Vorbildfunktion!
In diesem Vortrag werde ich:
- definieren, was Sustainable Pace ist
- häufige Fallstricke teilen, die ein System aus der Balance bringen können (z.B. ein Team, eine Abteilung, ein ganzes Unternehmen)
- wirkungsvolle Selbstfürsorge-Praktiken für Individuen und Teams anbieten
- fundierte psychologische Hintergründe einweben (z. B. zu Stress und Coping)
Nach der Teilnahme seid Ihr gut gerüstet für weitere Schritte – mit Euch selbst und mit anderen zusammen.
Gemeinsam zu mehr Sustainable Pace!
Zielpublikum: Entwickler:innen, Architekt:innen, alle Arten von Manager:innen,
Menschen :)
Voraussetzungen: Neugierde und Offenheit, Arbeitserfahrung in unterschiedlichen Kontexten
ist hilfreich, aber nicht notwendig
Schwierigkeitsgrad: Anfänger
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!
Product Owner treffen regelmäßig Entscheidungen in der Produktentwicklung, die eine fundierte Kenntnis der Fachdomäne und versteckte Anforderungen an wertstiftende Anwendungsfälle und Features erfordern.
Am Beispiel einer komplexen Softwareentwicklung wird der flexible, zeitsparende Einsatz von Domain Storytelling aufgezeigt, um die Qualität fachlicher Entscheidungen zu verbessern. Dazu gehören u. a. die Problemraumanalyse, SOLL-Szenarios im Lösungsraum, strategisches Design (DDD), Releasemanagement (MVP) und arbeitssparendes Dokumentieren.
Zielpublikum: Product Owner (m/w/d), Business Analysts, Manager, Architekt:innen, Entwickler:innen
Voraussetzungen: Keine
Schwierigkeitsgrad: Anfänger
Extended Abstract:
Was lernt man:
• Eine kurze Einführung in Domain Storytelling
• Konkrete Beispiele zum Einsatz des Werkzeugs in der Anforderungsermittlung und Softwareentwicklung
• Den Einsatz des Open-Source-Tools Domain Story Modeler Egon.io zum Entwickeln von Szenario-Diagrammen
• Den Zusammenhang von Domain Storytelling und Domain-Driven Design in der Aufgabenstellung Strategisches Design
Carsten Lill (WPS – Workplace Solutions GmbH) interessiert sich für alles, was hilft, Projekte von der Vision bis hin zur Anforderung kollaborativ aufzusetzen. Er berät Kunden im Kontext agiles Projekt- und Anforderungsmanagement, arbeitet als Agiler Coach und hat viel Freude daran, seine Erfahrungen als praxisnaher Trainer in Schulungen weiterzugeben.
Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/carsten.lill
Vortrag Teilen
Zur Implementierung einer gemeinsamen Strategie orientieren wir uns in Unternehmen oft an OKRs und KPIs. Bisher wurde jedoch nicht viel getan, um zu messen, wo wir auf unserem Weg zu mehr Nachhaltigkeit stehen und/oder wie wir vorankommen.
In diesem (interaktiven) Vortrag gebe ich einen Überblick darüber, wie man einerseits den Status quo bezüglich Nachhaltigkeit eines agilen Teams oder Unternehmens herausfinden kann und andererseits, wie man diesen dann zur Definition der nächsten Schritte verwendet, um nachhaltiger zu werden.
Zielpublikum: Architekt:innen, Entwickler:innen, Projektleiter:innen, Manager:innen, Entscheider, ...
Voraussetzungen: Keine
Schwierigkeitsgrad: Anfänger
Extended Abstract:
Nachhaltigkeit ist einerseits eine Notwendigkeit in der aktuellen Krise und andererseits muss man Nachhaltigkeit auch zunehmend als Schlüsselfaktor verstehen, der über das Überleben von Unternehmen sowohl bei der Suche nach Talenten als auch nach Kunden und Märkten entscheidet.
Ein datengesteuerter Ansatz für mehr Nachhaltigkeit bedeutet nicht, dass wir alle Antworten haben – aber, dass wir bessere Fragen stellen können. Ein Fokus auf Daten ist besonders in einer volatilen, unsicheren, komplexen und vieldeutigen Umgebung wichtig, um Anhaltspunkte für die gemeinsame Weiterentwicklung zu bieten.
Comparative Agile Sustainability ist ein Ansatz, den wir in einem kleinen Team mit Unterstützung von Data-Analytikern erstellt haben, und das dazu dient, das Bewusstsein von Nachhaltigkeit in einem (agilen) Team und/oder Unternehmen zu verankern und voranzutreiben. Die Evaluierung wurde unter creative commons veröffentlicht und steht somit allen Interessierten frei zur Verfügung. Durch die Nutzung der Ergebnisse dieser validierten Bewertung können agile Teams und Unternehmen besser verstehen, wie sie ihre eigene Wirksamkeit erhöhen und zur Steigerung von Nachhaltigkeit in der gesamten Branche beitragen können.
Jutta Eckstein arbeitet weltweit als Business-Coach, Change-Managerin & Beraterin. Ihr Fokus liegt auf unternehmensweiter Agilität in großen & verteilten Organisationen. Sie war von 2003 bis 2007 im Vorstand der AgileAlliance. Sie hat einen M.A. in Business Coaching & Change Management, einen Dipl.-Ing. in Product-Engineering und ist als Immissionsschutzbeauftragte (Umweltschutz) zertifiziert. Jutta wurde 2011 von der Computerwoche in die Top 100 der bedeutendsten Persönlichkeiten der Deutschen IT gewählt.
Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/jutta.eckstein
Vortrag Teilen
"Wir müssen dringend unser System modernisieren. Das, auf dem unser gesamtes Business beruht. Und wir wollen dabei alte Zöpfe abschneiden und moderne Technologien und Architekturen verwenden. Wir wollen mehr so wie Google werden." Guter Vorsatz, sehr hoher Anspruch. Und dementsprechend gibt es oft massive Probleme in solchen Projekten. Wir waren an einigen repräsentativen Exemplaren als Berater beteiligt und haben dabei beobachtet was schiefgegangen ist und was man besser machen könnte. In dieser Session erzählen wir Euch davon.
Zielpublikum: Architekten und Projektleiter
Voraussetzungen: Keine Spezifischen
Schwierigkeitsgrad: Fortgeschritten
Extended Abstract:
Die Sprecher sind beide auf den Bau von domänenspezifischen Sprachen spezialisiert. In diesem Vortrag spielt dieses Thema aber keine Rolle, außer als Aufhänger für den Modernisierungsanspruch: man will die Fachlichkeit der Domäne per DSL ausdrücken. Um das tun zu können, muss man zunächst sehr genau verstehen, wie die Domäne funktioniert. Man analysiert also sehr präzise. Viele der Systeme unserer Kunden sind schon relativ alt und die Technologien sind entsprechend in die Jahre gekommen. Neben dem Verstehen und "Aufräumen" der Fachlichkeit soll also auch gleich die Architektur und Technologie gewechselt werden.
Diese beiden Dinge zusammengenommen sind wirklich anspruchsvoll. Das Projekt beginnt mit entsprechend viel Hoffnung und hohen Zielen. Im Laufe der (meistens) Jahre wird es aber schwierig. Hier sind einige Themengebiete, wo es oft klemmt:
- Architektur und Hypes
- Die notwendige Prozessanpassungen
- Staffing und Skills im Projekt
- Sinnvolle und der Projektreife angepasste Interpretation von "agil"
- Kommunikation untereinander und Meetingstruktur
- Umgang mit politischem "Störfeuer"
- Führung, Entscheidungsfindung und Produktvision
- Firmenkultur und deren Auswirkungen
Der Vortrag ist kein unkonstruktives Bashing oder Lästern über (anonymisierte) Kunden. Sondern wir greifen repräsentative Situation auf und geben konkrete Ratschläge, wie man die Dinge besser machen könnte. Einige davon sind vielleicht naherliegend und lassen sich mit gesundem Menschenverstand (der ja oft nicht umgesetzt wird) begründen. Andere sind weniger naheliegend und vielleicht auch unkonventionell oder regen zumindest zu Diskussionen an die wir im Rahmen des Vortrags auch gerne führen werden.
Unsere Rolle in diesen Projekten war die eines Beraters rund um DSLs und Domänenanalyse. Die Projekte als Ganzes waren nicht unsere Verantwortung. Aber wir haben natürlich viel mitbekommen, beobachtet, geredet und mit unserer jahrelangen Erfahrung in solchen Projekten abgeglichen. Es wurde auch sehr deutlich, dass bestimmte (angeblich) technische Probleme in Wirklichkeit eine Folge von organisatorischen Problemen waren. Als Folge sind wir dann von unserer Kernaufgabe "DSL-Bau + Domänenanalyse" auch immer mehr in Architektur- und Projektorga-Themen hineingerutscht -- an deren Lösung wir dann auch konstruktiv mitgearbeitet haben.
Unser Vortrag ist anhand dieser Entwicklung strukturiert. Wir beginnen mit Herausforderungen in der Technik, der Architektur und den Entwicklerskills und zoomen dann schrittweise heraus bis wir auf Ebene der Firmenkultur ankommen.
Im Ergebnis werden die Teilnehmer lernen, welche Faktoren den Erfolg eines Modernisierungsprojekte maßgeblich beeinflussen und dass diese in den wenigsten Fällen einzelne große Faktoren sind, sondern die Summe vieler kleiner Probleme – die alle lösbar sind, wenn man nur will.
Markus Völter ist freiberuflicher Berater zu (domänenspezifischen) Sprachen und Entwicklungswerkzeugen sowie den Systemarchitekturen und Prozessanpassungen um sie in Produkte/Projekte zu integrieren.
Kolja Dummann ist Berater und Architekt für domänenspezifische Tools und Sprachen bei der itemis AG mit besonderem Fokus auf Zusammenarbeitsmodelle und Prozesse.
Ursprünglich war agile Entwicklung und allen voran XP für Entwickler:innen gedacht. Inwiefern werden diese heutzutage noch von agilen Vorgehensweisen unterstützt? Diese Frage wird von Erik Dörnenburg mittels "25 Jahre XP: Die Balance zwischen neuen Technologien und bewährten Praktiken" und Ina Einemann durch "Take it Back" untersucht und in einem Panel mit Frank Buschmann diskutiert.
Zielpublikum: Architekt:innen, Entwickler:innen, Projektleiter:innen, Software-Ingenieur:innen
Voraussetzungen: Keine
Schwierigkeitsgrad: Fortgeschritten
Extended Abstract:
Als Kent Beck vor fast 25 Jahren Extreme Programming (XP) beschrieb sah die IT-Industrie noch recht anders aus. Seitdem sind agile Ansätze und die Nutzung von Open Source Software Mainstream geworden, und die Public Cloud Anbieter haben sich und ihre Ökosysteme etabliert. Diese Trends haben unsere Fähigkeiten komplexe Software-Systeme zu entwickeln verbessert. Das eigentliche Handwerk – effektiv in einem Team beständig Software zu schreiben – ist aber genauso wichtig wie immer. In diesem Talk geht es um die Rolle, die XP für die moderne Software-Entwicklung spielt.
Das agile Manifest wurde vor über 20 Jahren von Entwicklern für Entwickler geschrieben. Mittlerweile fühlt es sich aber immer mehr an, als ob die agile Bubble eine eigene Welt ist, die von Scrum Mastern und Agile Coaches übernommen wurde. Developer nehmen eher passiv an den vorgeschriebenen Meetings teil, statt den Prozess aktiv zu gestalten.
Was läuft da schief? Und wie können wir das ändern?
In dieser Session geht es um Motivation, sinnvolle Konflikte und Empowerment.
Erik Dörnenburg ist Software-Engineer und leidenschaftlicher Technologe. Auf seiner inzwischen langen Reise durch die Tech-Branche ist Erik einer Fülle neuer Technologien begegnet. Dabei ist es ihm wichtig deren Potenzial zu bewerten und gleichzeitig bewährte Praktiken für die neuen Technologien zu adaptieren. Als Head of Technology bei Thoughtworks hilft er Kunden, ihre geschäftlichen Herausforderungen mit modernen Technologien, Plattformen und Praktiken zu lösen. Erik ist regelmäßiger Redner auf Konferenzen, hat an einigen Büchern mitgewirkt und unterhält mehrere Open Source Projekte. Er hat einen Abschluss in Informatik der Universität Dortmund und hat Computer Science und Linguistik am University College Dublin studiert.
Ina Einemann ist als Agile Coach bei der Open Knowledge GmbH in Oldenburg tätig. Ihr Tätigkeitsumfeld umfasst neben ihrer Arbeit als Scrum Master auch Aufgaben aus dem Bereich PO und Requirements Engineering. Sie beschäftigt sich mit agilen Methoden und Vorgehensmodellen und berät Teams bei der Umsetzung agiler Praktiken. Sie ist außerdem einer der Hosts des Podcast "Mein Scrum ist kaputt".
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.
Vortrag Teilen
Qualitätsziele helfen uns, Architekturentscheidungen fundierter zu treffen. Die genau richtige Qualität ist jedoch oft subjektiv und ändert sich über die Zeit hinweg. Dies macht das Arbeiten mit und an Qualitätszielen vor allem bei langlebigen Softwaresystemen spannend.
In diesem Vortrag stelle ich eine neue Sicht auf Softwarequalität vor, bei der wir Qualität im evolutionären Kontext betrachten. Als Basis verwende ich das ISO 25010-Qualitätsmodell sowie Wardley Mapping, um die passende Qualität nach Wichtigkeit und Evolutionsstufen zu finden.
Zielpublikum: Software-Architekt:innen, Entwickler:innen
Voraussetzungen: Erfahrung mit optimierungsbedürftigen Softwaresystemen
Schwierigkeitsgrad: Anfänger
Extended Abstract:
Die Balance der passenden Qualitätszielen ist ein herausforderndes Thema. Qualitätsziele sind aber sehr wichtig in der Entwicklung passender Softwaresysteme. Sie helfen uns, Architekturentscheidungen fundierter zu treffen. Die „genau richtige Qualität“ hängt dabei stark vom Betrachtungspunkt verschiedener Stakeholder ab. Zudem ändern sich Ansprüche an die Qualitäten eines Softwaresystems über die Zeit hinweg. Dies macht das Arbeiten mit und an Qualitätszielen vor allem in langlebigen Softwaresystemen immer wieder spannend.
In diesem Vortrag stelle ich eine neue Sicht auf Softwarequalität vor, wo wir Qualität im evolutionären Kontext betrachten. Als Basis verwende ich hierzu das ISO 25010-Qualitätsmodell sowie Wardley Mapping. Damit lassen sich notwendige Qualitäten nach ihrer Wichtigkeit und Evolutionsstufen von Softwaresystemen kommunizieren. Der Vortrag verzahnt die evolutionäre Sicht auf Softwarequalität mit Beispielen aus der Praxis und zeigt, wie sich damit die richtige Balance zwischen zu viel und zu wenig Qualität gestalten lässt.
Markus Harrer arbeitet seit mehreren Jahren in der Softwareentwicklung und ist vor allem in konservativen Branchen tätig. Als Senior Consultant hilft er, Software nachhaltig und wirtschaftlich sinnvoll zu entwickeln und zu verbessern. Er ist aktiver Mitgestalter in Communities zu den Themen Software Analytics, Softwarearchitektur, Softwaresanierung und Java. Zudem ist er akkreditierter Trainer für den iSAQB Foundation Level und dem Advanced-Level-Modul IMPROVE.
Ist uns Softwerkern wirklich klar, was wir meinen, wenn wir von Technischen Schulden sprechen? “Klar”, ist die Antwort. Wirklich? Warum haben wir dann Schwierigkeiten, POs/Projektleiter/Abteilungsleiter vom notwendigen Budget zu überzeugen?
Im Vortrag zeigen wir, wie es datenbasiert besser geht. Wie man für Technische Schulden KPIs erfasst und wie man jeweils Code-, Architektur-, Test-Qualität, Team-Kollaboration mit den KPIs korreliert, um eine Kosten-Nutzen-Analyse durchzuführen. Trotz Microservices und DevOps - die Herausforderungen bleiben.
Zielpublikum: Architekt:innen, Projekt-/Technische Leiter:innen, Key Developer, Manager, Entscheider
Voraussetzungen: Keine
Schwierigkeitsgrad: Fortgeschritten
Extended Abstract:
Ist uns Softwerkern wirklich klar, was wir meinen, wenn wir von Technischen Schulden sprechen? “Klar”, ist die Antwort, “es geht um Smells, Bugs, Bedarf an Refactoring, fehlende Tests …”. Zum Teil können wir deren Umfang und Bedarf sogar messen. Aber wie entscheiden wir, was wir zuerst angehen sollen? Wie und was messen wir, sodass andere Stakeholder uns überhaupt verstehen und wir POs, Projektleiter und Abteilungsleiter vom notwendigen Budget überzeugen können?
Im Vortrag zeigen wir, wie man datenbasiert bessere Antworten findet. Was man mit den Folgen der Technischen Schulden anfängt, Wartungs- und sich verstärkende Mehraufwände in der Entwicklung als KPIs erfasst und deren Hotspots im Code identifiziert. Wie man jeweils Code-, Architektur- und Test-Qualität usw. als Ursachen identifiziert und mit den KPIs korreliert. Und wie man Technische Schulden in der Architektur in Zahlen prognostiziert, um eine Kosten-Nutzen-Analyse durchführen zu können. Und wie sich Team-Kollaboration auch auf Technische Schulden auswirkt.
Diese Herausforderungen sind seit mehreren Jahrzehnten die gleichen. Daran haben auch Microservices nichts geändert.
Die Teilnehmer erhalten Antworten auf folgende Fragen:
• Was sind Technische Schulden genauer?
• Wie misst man die Folgen?
• Wie sieht eine effektive Ursachenanalyse aus?
• Wie überzeuge ich andere Stakeholder von der Notwendigkeit?
• Wie wirkt sich Team-Kollaboration auf Technische Schulden aus?
You have emotions? Congrats, you are a (professional) human being! Now, how can you actually handle your emotions smartly in our still tech- & tool-focused IT world?
In professional situations like:
- dealing with human "legacy experiences"
- integrating "personal silos"
- interacting with ease with other human beings
- tackling stressful situations (e.g. conflicts) within a team
This session offers a set of science-based, pragmatic tools that are (almost) always accessible - like a Swiss Pocket Knife for engineers (and other humans :-)).
Target Audience: Developers, Architects, System Engineers, Managers of all kind, Human Beings :)
Prerequisites: Curiosity and openness for new ways of thinking (and behaviour)
Level: Basic
Extended Abstract:
Oftentimes people think that having emotions or even “being emotional” means being unprofessional, being irrational or even being weak. That is wrong!
Being able to consciously deal with (your) emotions is a (professional) strength that can be learned and practised.
• It contributes to better teamwork.
• It promotes individual health.
• It even is a leadership quality.
Join this session to bridge potential gaps between "tech" and "humans", between "hard" and "soft", between "us" and "them". Join and start right now with finding the 'right' balance...
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!