Thema: Agility
- Montag
06.02. - Dienstag
07.02. - Mittwoch
08.02. - Donnerstag
09.02.
Do you like some of what you find in the common scaling frameworks but don't buy-in to everything? Then, go to the essence!
This session will present and share a set of principles for scaling, which you can use to roll-your-own approach or properly contextualise the usage of an existing framework such as LeSS, Scrum@Scale or Nexus.
Unlike other scaling approaches, these guidelines are non-prescriptive and recognise the value of elements in many scaling frameworks.
Target Audience: Managers, Decision Makers, Agile Coaches
Prerequisites: Basic understanding of agile. Having been exposed to agile at scale projects is a plus
Level: Advanced
Extended Abstract:
ScaleAgility is a set of principles to create sound scaled organisations.
Devised by a group of five trainers and coaches with a total of more than 70 years of experience in large-scale agile implementations, these principles aim to expose the tensions inherent in any organisational development initiative and provide guidance to discuss and develop strategies and tactics for transforming a company.
In this workshop we will discuss:
- A set of general principles to consider when creating large-scale agile organisations
- How properly defining products and the way the product definition evolves are fundamental for large-scale agility
- A path for Teams to evolve from localised responsibility to feature Teams
- How the Leadership should accompany the change
Pierluigi Pugliese is active as Agile Coach, Systemic Consultant and Trainer. He has a long experience in various roles in software development organisations and complex international projects. As an expert for Agile and Scrum, he helps clients implement agility in organisations. He strives for sustained improvement in teams and organisations, using the best methods as suggested by his broad experience. His expertise is cross-sector and independent from hierarchical structures, spanning from consulting and coaching at the top management level to single teams and individual developers. He regularly speaks at international conferences on Agile and Scrum, especially focusing on people aspects and team interactions.
He started hacking code so long ago that he cannot remember exactly when anymore. After many years various roles in the mobile telecommunication business, he works as a consultant for software organisations and coach for individuals and teams, focusing on software development and software processes, helping them implementing sound and agile solutions.
Simon Roberts is an agile and leadership coach and Certified Scrum Trainer. He has used lightweight/agile methods since the late 1990s and works with organisations large and small to help them achieve better results by leveraging the power of self-organising teams. He has consulted for and led several large-scale agile transitions at DAX companies in Germany, is the author of several articles and speaks regularly at conferences on the subject of agile leadership. Simon holds an MBA specialising in Creativity, Innovation and Change from the Open University Business School.
Since 2005 Colin Bird is assisting organisations in many sectors to wrestle with the challenges of retaining agility as the scale of the challenge moves beyond a single team.
Vortrag Teilen
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.
Unsere Welt verändert sich rasant, wird immer weniger vorhersagbar, komplexer und widersprüchlicher. Und damit geht auch ein Wandel der traditionellen Rolle der Führungskraft einher. Bisher funktionierende Führungsmethoden, erfolgreiche Verhaltensweisen und ein bewährter Führungsstil stoßen nun an ihre Grenzen.
Es verändert sich etwas im Gefüge zwischen Führungskräften und Mitarbeitern. Eine Antwort darauf kann lean-agile Leadership sein. Die erfordert ein neues Rollenbild und Selbstverständnis von Führung. Doch was bedeutet das?
Zielpublikum: Führungskräfte, Entscheider, "Geführte", Interessierte an Agile Leadership
Voraussetzungen: Erste Führungserfahrungen von Vorteil, aber nicht Bedingung
Schwierigkeitsgrad: Fortgeschritten
Max. Teilnehmendenzahl: 30
Extended Abstract:
Unsere Welt verändert sich rasant, wird immer weniger vorhersagbar, komplexer und widersprüchlicher. Und mit dieser Veränderung geht auch ein Wandel der traditionellen Rolle der Führungskraft einher. Bisher funktionierende Führungsmethoden, erfolgreiche Verhaltensweisen und ein bewährter Führungsstil stoßen nun an ihre Grenzen.
Es verändert sich etwas im Gefüge zwischen Führungskräften und Mitarbeitern. Organisationen und Menschen verlangen nach einem neuen Führungsverhalten. Eine Antwort darauf kann lean-agile Leadership sein. Die erfordert ein neues Rollenbild und Selbstverständnis von Führung. Doch was bedeutet das?
In diesem Spotlight beleuchten wir,
- welche Herausforderungen mit lean-agile Leadership bewältigt werden können,
- welches Mindset und welche Verhaltensweisen der ideale agile Leader mitbringt,
- und was das konkret für die Zusammenarbeit bedeutet.
Wir haben uns die folgenden Lernziele gesetzt:
In diesem 2 1/2-stündigen Workshop lernen die Teilnehmer:innen die Grundlagen von lean-agile Leadership kennen und verstehen, welche Vorteile dieser Führungsstil bringt.
Du erhältst Inspiration für konkrete Umsetzungsmaßnahmen und wendest Tools in praktischen Übungen an. Wir werden viel miteinander diskutieren und von den Erfahrungen der anderen profitieren können.
Themengebiete
- Warum muss Führung agil werden?
- Grundhaltung / Mindset agiler Führungskräfte
- Verhaltensweisen von agilen Führungskräften
- Viele praktische Übungen
Voraussetzungen: Offenheit & Lernbereitschaft
Dieser Kurz-Workshop richtet sich an Führungskräfte im agilen Kontext, Führungskräfte, die vor einer agilen Transition stehen, Agile Coaches, SAFe Programm Consultants, Personalentwickler, Scrum Master sowie an alle Interessierte, die mehr über lean-agile Leadership lernen möchten.
Peter Schnell ist Dipl.-Informatiker und seit 1994 in der IT-Branche tätig. Sein beruflicher Werdegang führte ihn von der IT-Projektleitung einer Versicherung über das Beratungs- und Trainingsgeschäft in die Leitung eines IT-Bereiches. Nun ist er Partner der KEGON AG und als agiler Management-Berater und Coach tätig. Seine Schwerpunkte sind das agile Coaching, agile Transitionen, Management 3.0, Management von klassischen und agilen Projekten im Banken- und Versicherungsbereich, Interims- und Personalmanagement. Er hat seine langjährige Erfahrung in eine Vielzahl von Vorträgen und Publikationen eingebracht.
Susanne Bauer ist Management-Beraterin für die KEGON AG. Sie arbeitet als Systemische Business Coachin und Trainerin im agilen Kontext. Ihr Fokus sind die zwischenmenschlichen Aspekte bei agiler Führungsarbeit, Veränderungsprozessen oder agiler Transformation. Dabei greift sie auf ihre langjährige Erfahrung als Führungskraft im Marketing und Trainingssektor, als Ausbildnerin im Coaching und auf fundierte wirtschaftliche, Coaching- und Change-Management-Ausbildungen zurück.
Vortrag Teilen
Agile Games sind in aller Munde. Viel wird gespielt.
Dass Spielen kein Selbstzweck ist, hat sich herumgesprochen.
Doch was braucht es, um Spiele wirksam zu machen? Und was bedeutet das überhaupt?
Dieser Workshop zeigt auf, was es braucht, um ein Spiel wirksam zu facilitieren.
Dabei durchlaufen die Teilnehmenden ein 4-Schritte-Modell und erfahren interaktiv, welche Schritte notwendig sind, und wenden diese selbst an.
Am Ende des Workshops haben die Teilnehmenden so die Erfahrung gemacht, was es braucht, um Spielen wirksam einzusetzen.
Max. Teilnehmendenzahl: 40
Zielpublikum: Agile Coaches, Entscheider, Projektleiter:innen, Change-Manager, Transformationleads
Voraussetzungen: Neugierde
Schwierigkeitsgrad: Anfänger
Extended Abstract:
Im Rahmen des Workshops benutzen wir das 4-Schritte-Modell als Denkanleitung, um in Kleingruppen das Modell anhand eines Spieles anzuwenden und die Schritte kennenzulernen.
Da das Modell universell ist, können Teilnehmende es anschließend auf eigene Spiele und im eigenen Kontext anwenden.
Bei Interesse kann ggf. ein Spiele-Canvas oder eine Checkliste zur Spielevorbereitung zusätzlich vorgestellt werden.
Am Ende nehmen Teilnehmende eine persönliche (todo-) Liste mit, wie und an welchen Stellen sie Spiele in ihrem eigenen Kontext einsetzen können.
Ihr Motto „You go first! – Nimm dein Leben in die Hand!", steht für ihr Tun: Rein in den nachhaltigen Erfolg durch Eigenverantwortung und Selbstführung.
Anne Hoffmann unterstützt Menschen und Organisationen dabei, erfolgreich ihre Ziele zu erreichen. Als Expertin für Selbstführung und mit ihrem Motto „You go first!“ erinnert sie daran, dass nachhaltiger Erfolg durch hohe Eigenverantwortung insbesondere dann entsteht, wenn diese Selbstführung vorgelebt wird.
Anne benutzt oft Spiele, um Erkenntnisse weiterzugeben.
It is common to consider software architecture as structure, as infrastructure, as code, as technologies, as models, and so on, but what if we consider software architecture as knowledge? The idea that software architecture is the set of significant decisions about a system is not a new one, but those decisions represent knowledge.
When we embrace the idea of knowledge as a first class concept, that has implications for our documentation (such as architecture decisions records), for our code and for our development process.
Target Audience: Developers, Architects, Managers, Coaches, Leaders
Prerequisites: No specific prerequisites
Level: Advanced
Extended Abstract:
It is common to consider software architecture as structure, as infrastructure, as code, as technologies, as models, and so on, but what if we consider software architecture as knowledge? The idea that software architecture is the set of significant decisions about a system is not a new one, but those decisions represent knowledge.
When we embrace the idea of knowledge as a first class concept, that has implications for our documentation (such as architecture decisions records), for our code and for our development process.
This session will explore a number of concepts and practices that relate architecture to existing development practice and agile approaches. It will revisit patterns, explore ADRs, relate architecture to lean thinking, PDSA, hypothesis-driven development, and more.
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.
Immer häufiger werden Anwendungen auf einem Kubernetes-Cluster betrieben. Umso wichtiger ist die Absicherung gegen Angriffe von außen, aber auch innerhalb des Clusters.
Wir demonstrieren anhand von praktischen Beispielen, wie mit wenigen Schritten ein Cluster abgesichert werden kann. Ausreden, warum nicht mehr Sicherheit möglich ist, gibt es dann nicht mehr.
Zielpublikum: Entwickler:innen
Voraussetzungen: Grundkenntnisse in Kubernetes und Security, Projekterfahrung
Schwierigkeitsgrad: Fortgeschritten
Extended Abstract:
In den letzten Jahren hat sich Kubernetes als Plattform für Anwendungen etabliert. Es verspricht, das Deployment deutlich zu vereinfachen, birgt aber auf der anderen Seite eine höhere Komplexität.
Oft wird der Betrieb auf einem Kubernetes-Cluster als zusätzliche Aufgabe auf das Entwicklungsteam übertragen, ohne die entsprechende Expertise aufzubauen. Das Wissen um Kubernetes bleibt dann lückenhaft, das Management des Clusters steht nicht im Fokus. In der Konsequenz stehen viele Kubernetes-Cluster ungeschützt im Netz.
Im Vortrag konzentrieren wir uns auf den Aspekt der Sicherheit eines Kubernetes-Clusters gegen Angriffe von außen, aber auch innerhalb des Clusters. Dabei gehen wir Schritt für Schritt durch die verschiedenen Schichten und zeigen anhand praktischer Beispiele, mit welchen Maßnahmen der Cluster abgesichert werden sollte.
Dehla Sokenou fühlt sich in allen Phasen der Software-Entwicklung zu Hause, besonders im Testen. Bei WPS - Workplace Solutions ist sie als Test- und Qualitätsmanagerin und Software-Architektin tätig.
Mehr Inhalte dieses Speakers? Schaut doch mal bei SIGS.de vorbei: https://www.sigs.de/experten/dehla-sokenou/
Adrian Metzner ist seit 2014 als Software-Entwickler unterwegs. Schwerpunkte sind dabei Sicherheit und DevOps. Bei WPS - Workplace Solutions ist er als Software-Architekt und Trainer für das ISAQB Cloud-Infra Modul tätig.
Ein Erfolgsmuster zur Umsetzung von DevOps ist Site Reliability Engineering (SRE). Sie fördert objektiv die Zusammenarbeit zwischen Teams in einem skalierenden Umfeld. Besonderheit: Die System-Zuverlässigkeit wird zum Nummer 1 Feature! In diesem Vortrag werden die SRE-Prinzipien erläutert und SRE-Praktiken veranschaulicht. Abgerundet wird der Vortrag durch die Veranschaulichung des Aufbaus von Betriebsmodellen mit SRE.
Zielpublikum: Architekt:innen, Entwickler:innen, Projektleiter:innen, Manager, Entscheider
Voraussetzungen: Grundkenntnisse in agilen Methoden und Betriebsmodellen
Schwierigkeitsgrad: Anfänger
Halil Hancioglu ist als Solution Architect für die OPITZ CONSULTING Deutschland GmbH tätig. Er verfügt über langjährige Erfahrung in der Erstellung von individuellen Enterprise-Applikationen und der Einführung von DevOps-Praktiken. Seine Stärken liegen in der Analyse und der Restrukturierung von Abläufen mit besonderem Fokus auf SRE, DevOps, Continuous Delivery und Infra-as-Code.
Vortrag Teilen
Vortrag Teilen
Die Digitalisierung schreitet voran! Geht es den einen zu langsam, gibt es andere, denen es zu schnell geht.
Beiden Parteien gemeinsam ist, dass es das richtige Mindset braucht, um den Herausforderungen der Digitalisierung und der damit einhergehenden Transformation Tempo zu verleihen oder mit ihr Schritt halten zu können.
In dem Vortrag schauen wir uns die unterschiedlichen Dimensionen an, für die ein Umdenken angesagt ist. Dabei spannen wir den Bogen von der Fachlichkeit über die Technologie hin zu den organisatorischen Herausforderungen.
Zielpublikum: Manager, Entscheider, Architekt:innen, Projektleiter:innen
Voraussetzungen: Keine
Schwierigkeitsgrad: Fortgeschritten
Extended Abstract:
Aufseiten der Technologie muss man sich einfach mal die Landkarte der Cloud Native Computing Foundation ansehen, um zu erkennen, dass wir hier vor neuen Herausforderungen stehen. Es müssen geeignete Architekturen entworfen und die Technologien sorgfältig ausgewählt werden.
Damit ist es aber nicht getan, denn wir müssen uns auch überlegen, wie wir Domänen finden und schneiden, wie wir in Zukunft mit unseren Daten umgehen, wie wir die Herausforderungen der KI meistern werden und welche Auswirkungen all diese Themen auf die Organisation und Kultur in den Unternehmen haben.
Bei allen Beteiligten, vom Kunden über den Product Owner zum Software-Engineer bis hin zum Management, kommt es in Zukunft auf das richtige Mindset an, um als Unternehmen oder Institution erfolgreich zu sein und am Markt bzw. bei den Bürgern bestehen zu können.
Dabei klären wir abschließend die Fragen:
• Kann man jetzt noch von "einem" oder dem "richtigen" Mindset sprechen?
• Wenn es das nicht gibt, wie bekommt man mehrere Mindsets unter einen Hut?
Als Software- und IT-Architekt mit über 30 Jahren Berufserfahrung wurde Peter Diefenthäler geprägt durch die Entwicklungen in der IT vom Mainframe bis hin zu modernen Cloud-Plattformen.
Der Wandel von der EDV zur modernen IT ist zu einem seiner Steckenpferde geworden. Es liegt ihm am Herzen, Brücken zwischen Technologie und Organisation zu bauen und sich dafür einzusetzen, dass man alte Zöpfe ein Stück weit abschneidet, um das Maximum aus den heute verfügbaren Möglichkeiten herauszuholen.
In recent decades, our scientific and clinical understanding of how our nervous system works has increased tremendously. I’ve recently completed an education for trauma-informed work (NARM informed professional). It has changed many key aspects of how I teach and coach and will continue to have a large impact.
In this session, I’m presenting those key learnings, connecting them to well-known parts of Agile knowledge and inviting into a discussion of what a more trauma-informed approach to leading people in Agile organisations could look like.
Target Audience: All kinds of Leaders, Product Owners, People Managers, Decision Makers, Coaches, Scrum Masters
Prerequisites: No prerequisites
Level: Advanced
Extended Abstract:
In recent decades, our scientific and clinical understanding of how our nervous system develops and works has increased tremendously. Its implications are so profound, they radiate far beyond the field of psychology. Topics such as trauma-informed law, trauma-informed volleyball coaching, legal counseling, education, social activism have arisen. It is time to think about how it affects leadership.
Your speaker Anton, a Scrum trainer and coach, has recently completed a NARM-informed professional education. It has tremendously changed some key aspects of how he leads, teaches and coaches and will surely continue to have a large impact. In this session, he is presenting those key learning, connects them to well-known parts of Agile knowledge and invites into a discussion of what a more trauma-informed approach to leadership could look like.
In this talk you will:
• experience a more calmer vulnerable space
• learn what developmental trauma is and how it plays out in the workplace
• learn about regulation and states of our nervous systems and its connection to creativity and cognitive capacity
• get a new angle to think and act about topics such as responsibility, clarification of assignments and setting goals, teaching, mentoring and more
• reflect on how these topics affects your own line of work and exchange on ideas
Anton Skornyakov is an Agile Coach and CST® for Scrum Alliance®, an experienced speaker and facilitator at many conferences, user groups for topics around Agile, facilitation, non-violent communication and leadership. Largest spaces were GSG Munic 2016, GSG Vienna 2019, OOP Munic 2019. However, there were many more at local conferences, user groups and meetups.
Most relevant to the topic Anton is speaking about, is his recently finished education as a NARM®-informed professional with the NARM® Training Institute. NeuroAffective Relational Model® (NARM®) is a unique and powerful approach to developmental trauma.
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
Ever wondered why the new buzzword is OKR? What does it bring to your company? Did you already try it? Did it help?
In this talk I'll reflect on some of the current industry issues with this valuable tool. Why its adoption often struggles, what to do about it and how to detect issues early on.
Target Audience: Everyone, actually. Decision Makers, Devs, Architects, Coaches, All sorts of Managers
Prerequisites: None
Level: Basic
Extended Abstract:
We may all have heard of - or even suffered under - the current big buzzword: OKRs. Google does it, so it must be great. However, in many orgs it has turned out to not turn them into Google in an instant. Why is that? What can we learn from how the adoption of Agile currently is? What could orgs do better? Is OKR a valid tool after all or just the new hype that will vanish soon? Will it turn into "Dark OKR" like Scrum probably did?
This session consists of an interactive part, some analysis, lots of storytelling and then some conclusions.
Since selling his first software at the age of 17 Dennis Wagner is all about developing.
In such different roles like software architect, team lead, developer or product manager he has searched for and travelled on different paths to successfully develop software better.
Being open, curious, surely extrovert and agilist by heart since he first discovered XP and Scrum more than a decade ago.
Today he is helping teams and organisations of all sizes as coach to identify and live up to their potential.
Agil(ität) ist in Zeiten der Pandemie, des gesellschaftlichen Wandels und der digitalen Transformation en vogue. Viele Unternehmen geben an, agil zu sein – und Aufträge, Projekte oder Produkte agil umzusetzen. Doch wie viele dieser Unternehmen sind tatsächlich agil, oder sagen dies lediglich (vielleicht ohne zu wissen, dass sie es nicht sind)?
Diese Session liefert einen exemplarischen praktischen Einblick, wie Fujitsu den Herausforderungen der agilen Transformation begegnet, mit Fokus auf den Unterschied zwischen Business- und Teamagilität.
Zielpublikum: Entscheider (Fach- und Linienvorgesetzte), Projektleiter:innen, Agile Köpfe
Voraussetzungen: Grundkenntnisse agile Vorgehensweisen und (agile) Transformation
Schwierigkeitsgrad: Fortgeschritten
Extended Abstract:
Auch ohne Covid-19 waren gesellschaftlicher Wandel und digitale Transformation bereits in vollem Gange, der Blick in eine nachhaltigere Zukunft gerichtet. Die Pandemie schob diesen Wandel noch stärker an. Viele Prozesse in Unternehmen veränderten sich stark, genau wie Bedarfe und Anforderungen der eigenen Belegschaft, von Kunden und Partnern. Verteiltes und mobiles Arbeiten oder verteilte Meetings sind nur einige Schlagworte, die immer mehr in den Fokus rückten, genau wie eine Erweiterung oder Kombination der digitalen Transformation um die Facette Agilität bzw. agiles Arbeiten. Speziell in Verbindung mit dem Thema DevOps erhielt die Agilität einen weiteren Anschub.
Um sich den Herausforderungen dieses gesellschaftlichen (und agilen) Wandels im Zuge der eigenen agilen Transformation zu stellen, startete Fujitsu Deutschland verschiedene Initiativen. Eine davon ist das Agile Pioneer-Programm. Diese berufsbezogene inhaltliche Weiterbildung soll dabei helfen, nachhaltig ein gemeinsames Verständnis von Agilität zu schaffen, und damit einen Mehrwert generieren – sowohl unternehmensintern als auch beim Kundeneinsatz.
Nachhaltigkeit steht dabei nicht allein beim Thema „gemeinsames Verständnis” auf der Agenda, sondern ergibt sich aus den Lehr-Inhalten, die bspw. bei Themen wie verteiltem und hybriden Arbeiten sowie der Vermeidung von Verschwendung stark unterstützen. Diese hauseigene Lösung ist an dem Fujitsu Way of Life sowie der Vision und Kultur des Unternehmens ausgerichtet und bietet einen ganzheitlichen Ansatz bei der Betrachtung von Agilität. Die größte Herausforderung bestand darin, die Frage zu beantworten: „Wie kommen wir von agil ‚sagen‘ via etwas agil ‚machen‘ dazu, tatsächlich agil zu ‚sein‘?“ Schlüsselfaktoren bei der Beantwortung dieser Frage waren Motivation, Mindset, Menschen und Missverständnisse, die in dieser Session genauer unter die Lupe genommen werden.
In dieser interaktiven Session erhalten die Teilnehmer:innen einen Überblick über eine der Facetten der (agilen) Transformation bei Fujitsu. Dabei wird der Unterschied zwischen Business-Agilität und Teamagilität herausgearbeitet. Zudem stehen die Mehrwerte, Stolpersteine und Hindernisse eines internen Weiterbildungsprogramms zur Unterstützung der Transformation im Fokus. Zu all diesen Punkten werden die Teilnehmer:innen in Gruppen gezielte Frage- und Problemstellungen bearbeiten – und so ein tieferes Verständnis bezüglich der möglichen Tragweite und Wirkungskraft des Themas Agilität erfahren.
Sebastian Mühleis - Agile Mind – ist Analyst, Consultant, Coach, Scrum Trainer, Scrum Master (PSM II), Product Owner (PSPO II), Scrum with Kanban (PSK), Professional Agile Leader (PAL I).
Shift Left ist, unterschiedliche Prozesse möglichst frühzeitig und direkt im Rahmen der Software-Entwicklung einzusetzen. Während es aus dem Test-Umfeld kommt, hat es große Auswirkungen auf alle Felder der Produktentwicklung. Product Owner und Unternehmen sind nicht auf diesen Mindset Change vorbereitet.
Alte Prozesse, Big Design upfront, Legacy, mangelnde Kenntnis bei der Produktentwicklung: Mit der ganzheitlichen Shift-Left-Denke gelingt der Turnaround zu äußerst werthaltigen Produkten.
Zielpublikum: Product Owner, Produktverantwortliche, Manager, Projektleiter:innen, Entscheider
Voraussetzungen: Produkt-/Projekt-/Management-Erfahrung, agile Methoden
Schwierigkeitsgrad: Fortgeschritten
Extended Abstract:
Der Vortrag führt in Shift Left ein und erklärt, wie in der Produktentwicklung anders gehandelt werden muss.
Product Owner, Produktverantwortliche und Manager in Organisationen erfahren, welchen Upskill sie benötigen, und wie Rahmenbedingungen zu verändern sind, damit die Benefits dieser Denkweise gehoben werden können.
Björn Schotte ist Geschäftsführer der MAYFLOWER GmbH. Er berät Kunden in Fragen der Digitalen und Agilen Transformation. Die mehr als 100-köpfige Crew der MAYFLOWER realisiert moderne, zukunftsweisende Software-Lösungen in agilen Teams.
Mit Erstaunen und forschender Neugier ist er seit 2005 auf lebenslanger agiler Reise unterwegs. Er ist auf Xing (https://www.xing.com/profile/Bjoern_Schotte), LinkedIn (https://www.linkedin.com/in/bjoernschotte/), Twitter (https://twitter.com/BjoernSchotte) und Slideshare (https://de.slideshare.net/BjoernSchotte) zu finden.
Vortrag Teilen
Discipline, determination, a highly visible area, and a few sticky notes, are all you need to move beyond problems with technical debt.
Target Audience: Developers, Project Leader, Designers, Product Owners, Decision Makers
Prerequisites: Basic Knowledge of Software Development Process
Level: Basic
Extended Abstract:
## Making great software is challenging
It doesn't matter how qualified a team is, it will never be able to produce perfect, flawless, entirely bug-free software.
While teams are discovering how to build the right software in the right way, the environment the team operates in changes.
This results in a constant reorientation of the product, and the corresponding software solution, which will cause gaps between how things work, and how they should work.
Unfortunately, the market won't wait infinitely until teams have addressed these issues in the software, and organizations tend to run out of patience too.
That is why teams often have to move forward with designs and code that are ... let's call them sub-optimal.
These gaps, they are technical debt: a loan against the future, where things will be fixed, at some point ... Hopefully.
According to a global survey performed by Stripe, Inc. amongst software engineers in 2018, researchers found that **engineers estimate to spend 17,3 hours per week on addressing technical debt**.
That same research established that developers work about 41.1 hours per week. With that in mind, addressing technical debt constitutes well over a third of the time a typical engineer spends per week.
**If engineers are spending that much time, how could they better utilize their attention?**
Why do they seem unable to gain control over this metric and push it downwards?
While technical debt sounds nice and predictable: "you just have to pay interest", it really is like a loan with a mobster, and not with a bank.
It will show up unannounced at your doorstep at 3.30 in the morning, demanding that you pay up now!
How can you prevent being surprised by this goon?! And what can you do to leverage the benefits of borrowing against the future?
Because when the conditions are right, taking out a loan and paying it back Tomorrow might just help you ship a better product today.
## Imagine...
- A lightweight process to discover technical debt without a big investment up front
- A data-driven approach to identify the technical debt that needs attention right now
- A system that is easy to introduce, and simple to enforce
- Something that will guide engineers to articulate technical debt in terms of our roadmap
- Which will ultimately improve the flow of work in your organization
## The Wall of Technical Debt™️
A few years ago [Mathias Verraes coined the term "_The Wall of Technical Debt_"][1]. During this presentation Marijn Huizendveld will show you how to institute such a process for managed technical debt. Doing so will provide you with a safety net that allows you to make "naive" design choices every now and again to ship your ideas as fast as possible, without sacrificing sustainable delivery in the long run.
[1]: verraes.net/2020/01/wall-of-technical-debt/
Marijn Huizendveld – In a small backstreet of Tokyo lives a man named Aki, a 78 years old former chef. Aki spent most of his life trying to perfectly cook the rice he buys from his friend Mato. He's been at it for 57 years now, and still searches for ways to improve his cooking methods. There is probably not too much anybody else could tell Aki about cooking this specific type of rice. When it comes to his process, Aki's understanding is unrivaled.
After years of trial and error, Marijn Huizendveld could be called the Aki of Domain-Driven Design, due to his extensive background in both programming and strategy. He uses this experience to show teams and organizations how to recognize and act on problems and opportunities in an autonomous, self-learning fashion.
Even in the time of agile software development and devOps, maintenance and evolution of large-scale software systems remain challenging. This is not only caused by technical debt, but is heavily caused by lost knowledge, high complexity of micro-service architectures, difficult requirements management, not available documentation, and the complexity of communication among and coordination of the many stakeholders. In our session we will talk about the challenges we identified in our study and present new approaches to address these challenges.
Target Audience: Architects, Developers, Project Leader, Manager, Decision Makers
Prerequisites: Project Management Experience, Software Maintenance
Level: Expert
Martin Kropp is professor for Software Engineering at the University of Applied Sciences Northwestern Switzerland. His interest is in everything that makes software development more efficient, build automation, testing, refactoring and development methodologies.
As a software engineer, Janick Rüegger worked in different teams from web development to platform engineering. In his master’s degree, he focuses on the challenges of large-scale software development.
Vortrag Teilen
Dieses Problem kennen wir alle: In Projekten führt eine unzureichende Kommunikation oft dazu, dass die Software am Ende nicht so umgesetzt ist, wie die Auftraggebenden es sich am Anfang vorgestellt hatten.
Behaviour-Driven Development (BDD) setzt von Anfang an darauf, alle Stakeholder an einen Tisch zu holen und ein gemeinsames Verständnis über das gewünschte Verhalten der Software herzustellen. Daraus entsteht eine ausführbare Spezifikation, die zum richtigen Produkt nebenbei noch automatisierte Tests und eine lebendige Dokumentation liefert.
Zielpublikum: Product Owner, Entwickler:innen, Tester, Business-Analysten
Voraussetzungen: Grundkenntnisse in Java
Schwierigkeitsgrad: Anfänger
Extended Abstract:
SZENARIO: OOP Konferenz 2023
ANGENOMMEN DASS du wenig über BDD weißt
WENN du zu diesem Vortrag kommst
DANN lernst du das Grundprinzip kennen
ANGENOMMEN DASS du BDD bisher als Testmethode nutzt
WENN du zu diesem Vortrag kommst
DANN siehst du, dass noch viel mehr dahintersteckt
Behaviour-Driven Development ist ganz sicher keine neue, aber eine häufig missverstandene Methode. In vielen Teams wird BDD nur zum Testen eingesetzt. In diesem Talk gehen wir einmal gemeinsam den Weg von der ersten Beschreibung der Software bis zur Umsetzung im Code, um zu erkennen, dass der Fokus von BDD auf der Kommunikation zwischen allen an der Entwicklung Beteiligten liegt.
Katrin Rabow hat viele Jahre als selbstständige Beraterin kleine Unternehmen in ihrem kaufmännischen Alltag unterstützt, ehe sie sich 2015 für ein Studium der Wirtschaftsinformatik an der TU Darmstadt entschied. Sie sucht immer wieder nach Wegen, „harte“ Themen wie Software-Engineering mit „weichen“ Themen wie der Unternehmenskultur zu verbinden. Seit ihrem Masterabschluss arbeitet sie als IT-Consultant in Frankfurt.
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
In der Produktentwicklung unterscheidet man zwischen Discovery („Identifizieren von Features“) und Delivery („Umsetzen von Features“). Im Gegensatz zum Wasserfall findet die Discovery nicht am Anfang, sondern kontinuierlich statt. Wie wechselt man regelmäßig zwischen Discovery und Delivery und verfällt nicht wieder in den Wasserfall? Ich berichte anhand der Umsetzung der SPIEL.digital aus der Praxis, mit welchen Methoden wir Discovery, Design und Entwicklung verzahnt haben.
Zielpublikum: Product Owner, Entwickler:innen, Projektleiter:innen
Voraussetzungen: Keine
Schwierigkeitsgrad: Fortgeschritten
Extended Abstract:
In der agilen Produktentwicklung unterscheidet man zwischen Discovery („Identifizieren von Features“) und Delivery („Umsetzen von Features“). Im Gegensatz zum Wasserfall findet die Discovery nicht am Anfang, sondern kontinuierlich statt. Wie aber geht man damit um, regelmäßig die Flughöhe zwischen Discovery und Delivery zu wechseln und nicht in dieselben Muster wie in der Analysephase des Wasserfalls zu verfallen? Ich berichte anhand der Umsetzung der SPIEL.digital aus der Praxis, mit welchen Methoden wir Discovery, Design und Entwicklung verzahnt haben. Und das alles bei einem festen Endtermin.
Konstantin Diener ist CTO bei cosee. Er ist leidenschaftlicher Software-Entwickler und brennt für Clean Code und Test-Driven Development. Als CTO kümmert er sich mittlerweile mehr um die Rahmenbedingungen für cross-funktionale Entwicklungsteams. Er spricht regelmäßig auf Konferenzen und war Autor der Kolumne "DevOps Stories" im Java Magazin, die sich mit Agilität, DevOps & New Work befasst.
Vortrag Teilen
Requirements engineering like testing require balance of value and risk. Agile requirements engineering and testing with test-driven requirements engineering (TDRE) balances project risks and cost. Clear advantage: Requirements are understandable, testable, and directly applicable as test case. Lead time and costs in testing are reduced by up to thirty percent.
This presentation at OOP 2023 will practically introduce to agile requirements engineering and test with TDRE. A case study demonstrates an industry use of TDRE.
Target Audience: Project Managers, Architects, Analysts, Requirements Engineers, Product Owners, Software Engineers
Prerequisites: None
Level: Advanced
Extended Abstract:
Requirements engineering like testing require balance. Balance is about balancing value and risk. Requirements must be good enough to mitigate risks but yet not overly specific to contain effort. Same for test, which though never complete needs to address those areas with highest risk.
Requirements engineering and testing belong together. Historically, testers have often only seen the requirements after the system has already been partially implemented. This had two serious disadvantages. On the one hand, insufficient requirements quality came far too late to the table. On the other hand, it was quite a lot of extra work without deriving suitable test cases in the context of requirements definition. A lot of additional work and long correction loops were the result.
Only an agile balance of risk-oriented coverage and testable requirements can improve test effectiveness. Such risk-oriented work also optimizes requirements engineering. Instead of paralysis by analysis in defining numerous requirements, test-driven requirements engineering (TDRE) focusses on specifying what is necessary and of high risk or high value.
TDRE is straight-forward: Test cases are developed in parallel to the requirements. Thus, the feasibility of the requirements is analyzed much faster than in the traditional sequential approach, in which tests are specified relatively late. The test cases are initially described in the same structure as the requirements and as a supplement to the respective requirements. This shifts Test-Driven Development (TDD), which has already proven itself as relevant agile methodology, to the specification level. Regression tests are attributed in order to prepare for later automation. The effort required for testing can be better estimated on this basis, and project and quality risks are thus reduced.
TDRE follows a triple peak model, which is connecting requirements (i.e., needs), design (i.e., solution) and test (i.e., the product).
It intertwines three perspectives:
• Market perspective: “How can I meet customer satisfaction and needs?”
• Design perspective: “How can I implement the solution to meet requirements?”
• Testing perspective: “How can I find a defect and cause the product to fail?”
Here some guidance from our projects, which we will further illustrate in this presentation:
• Every single functional requirement has at least one acceptance check, which is either fulfilled or not fulfilled and serves as the agile DoD (definition of done).
• Each individual quality requirement is described with numerical values that can be measured.
• Business rules are defined so that it can be determined whether they are true or false.
• Business and data objects are defined with all their attributes, types and states so that they can be set and validated at test time.
• System interfaces such as GUIs, reports and service interfaces are included in the requirements document so that values can be assigned to them.
• All use cases have pre- and post-conditions that can be generated and validated.
• All text is marked so that it can be automatically processed to generate test cases.
Agile requirements engineering and testing with test-driven requirements engineering (TDRE) balances project risks and cost. Clear advantage: Requirements are understandable, testable, and directly applicable as test case. Lead time and costs in testing are reduced by up to thirty percent. This presentation at OOP 2023 will practically introduce to agile requirements engineering and test with TDRE. A case study from medical cybersecurity demonstrates an industry use of TDRE.
Christof Ebert is managing director at Vector Consulting Services. He supports clients around the world in agile transformations. Before he had been working for ten years in global senior management positions. A trusted advisor and a member of several of industry boards, he is a professor at the University of Stuttgart and at Sorbonne in Paris. He authored several books including "Requirements Engineering" published by dPunkt and in China by Motor Press. He is serving on the editorial Boards of "IEEE Software" and "Journal of Systems and Software (JSS)".
Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/christof.ebert
One of the fundamental strategies of Agile Modeling is that artifacts, including architecture models, should be just barely good enough (JBGE). Another way of saying this is your models should be sufficient for the task at hand, no more and no less. But sufficiency is contextual in nature, it depends.
In this session we will look at the issue of model sufficiency, exploring the risk factors that motivate us to model more as well as the conditions that enable us to model less.
Target Audience: Software Architects, Software Developers
Prerequisites: Basic knowledge of agile, understanding of software architecture
Level: Advanced
Extended Abstract:
One of the fundamental strategies of Agile Modeling is that artifacts, including architecture models, should be just barely good enough (JBGE). Another way of saying this is your models should be sufficient for the task at hand, no more and no less. But sufficiency is contextual in nature, it depends.
In this session we will look at the issue of model sufficiency, exploring the risk factors that motivate us to model more as well as the conditions that enable us to model less. We model to think things through, to identify potential avenues for moving forward so that we can choose what we believe to be the most likely path for success. But the more effort we spend doing so potentially motivates us to make commitments earlier than we should and to lose time, and value, doing so. Balancing these tensions is how we determine model sufficiency in the context that we face. Proven agile architecture strategies that enable us to invest in less up-front modeling will also be explored. It's never just about modeling.
Agenda:
1. Architecture throughout the agile lifecycle.
2. What is initial architecture modeling?
3. What does it mean to be just barely good enough (JBGE)?
4. What risk factors motivate us to invest in more up-front modeling?
5. What factors enable us to invest in less up-front modeling?
6. What are the development practices that support an agile approach to architecture?
Scott Ambler is the Chief Methodologist of Ambysoft Inc. He is the creator of the Agile Modeling and Agile Data methods, as well as co-creator of PMI's Disciplined Agile tool kit. He has worked with organizations around the world to improve their software development ways of working (WoW). Scott is an award-winning author of 20+ books and an international keynote speaker.
Vortrag Teilen
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
Zu den Aufgaben von Scrum Mastern und Agile Coaches gehören Servant Leadership, Coaching, Facilitation und Removing von Impediments. Damit versuchen wir, die Veränderungen für die gewünschten Ziele zu initiieren.
Bei vielfältigen Begegnungen sind mir Verhaltensweisen aufgefallen, die mich nachdenklich stimmen: Wie ist das mit Walk-Your-Talk? Leben wir Agilisten selbst, was wir anderen zumuten? Wie steht es mit unserem Mut, Commitment, unserer Fähigkeit zur Zusammenarbeit und unserem persönlichen Wachstum? Und wie gehen wir damit um?
Zielpublikum: Scrum Master, Agile Coaches, Manager, Team, Developers, Entscheider, Kund:innen
Voraussetzungen: Keine
Schwierigkeitsgrad: Fortgeschritten
Extended Abstract:
Glaubwürdigkeit von Agilisten oder wie viel Integrität ist nötig?
Die Aufgaben von Scrum Mastern und Agile Coaches sind vielfältig. Darunter fallen Servant Leadership, Coaching der Teams, Facilitation, Removing von Impediments. Mit diesen Tätigkeiten versuchen wir, die Veränderungen zu initiieren und zu begleiten, die für den gewünschten Wandel und Ziele unserer Kunden notwendig sind.
Bei den vielfältigen Begegnungen sind mir an mir selbst und anderen Kollegen immer wieder Verhaltensweisen aufgefallen, die mich nachdenklich stimmen und fragen lassen:
Wie ist das mit Walk-Your-Talk? Leben wir Scrum Master und Coaches eigentlich selbst, was wir anderen zumuten? Wo zeigt sich unser Mut, unser Commitment, unsere Fähigkeit zur Zusammenarbeit und unser persönliches Wachstum? Wo erleben wir Dilemmata? Wo erleben wir unsere eigenen Grenzen? Und wie gehen wir damit um?
In unserer Session werde ich euch eine kleine Geschichte zu meinen Beobachtungen erzählen und euch dann einladen, eure eigenen Beobachtungen zum Thema Integrität und Walk-Your-Talk zu sammeln. Wir werden nach Mustern schauen und Hypothesen bilden. Und daraus wollen wir dann Schritte und Ideen entwickeln, mit welchem Verhalten wir unsere Glaubwürdigkeit stärken können.
Ziel dieser Session ist, dass wir Agilisten Inspirationen mitnehmen, die unsere Glaubwürdigkeit stärken. Kunden und andere Interessierte können Einsichten gewinnen, worauf sie bei der Wahl eines Scrum Masters oder Agile Coaches achten möchten.
Bettina Ruggeri ist zertifizierter Coach und Path-to-CSP Educator (Scrum Alliance). Ihre Schwerpunkte sind die Lernende Organisation, Organisatorische Führung und Kultur. Sie hilft Organisationen, sich in diesen Bereichen weiterzuentwickeln. Sie hat sich weitergebildet in systemischem Coaching, Mediation, Gruppendynamik, Organisationsberatung und ist Trainerin für Gewaltfreie Kommunikation. Sie möchte zu nachhaltigem und freudvollem Wachstum beitragen.
Vortrag Teilen
Der OODA-Cycle (Observe-Orient-Decide-Act) beschreibt, wie sich Menschen, Teams und Unternehmen in ihrer Umwelt orientieren und handeln. Im Wettbewerb in dynamischen Umgebungen gewinnt die Partei, die ihren OODA-Cycle schneller durchläuft; denn sie lernt und reagiert schneller. Die IOHAI-Leadership-Prinzipien beschreiben, wie Leadership dazu beiträgt, in Teams und Organisationen den OODA-Cycle schneller zu durchlaufen.
Der Vortrag führt in die Ideen von OODA und IOHAI ein und erläutert ihre Anwendung für Unternehmen.
Zielpublikum: Manager, Scrum Master, Projektleiter:innen
Voraussetzungen: Berufspraxis in Unternehmen :-)
Schwierigkeitsgrad: Anfänger
Extended Abstract:
Der OODA-Cycle und die IOHAI-Leadership-Prinzipien stammen von Col. John Boyd. Den Ursprung haben die Konzepte im Luftkampf Kampfjet gegen Kampfjet. Sie werden inzwischen aber auch für militärische Konflikte verwendet.
Für Unternehmen sind OODA und IOHAI auf verschiedensten Ebenen nützlich. Sie können auf strategischer Ebene helfen, um einen nachhaltigen Wettbewerbsvorteil zu erlangen. Sie können helfen, bessere KPI-/Metriksysteme zu schaffen. Die können bei agiler Skalierung helfen. Und sie können ganz profan dabei helfen, die Meetingstruktur in Unternehmen aufzuräumen und effektiver zu gestalten.
Stefan Roock (it-agile) hilft Unternehmen, Führungskräften und Teams dabei, ihre Potenziale zu entfalten - hin zu erfolgreichen Unternehmen, die ihre Kunden und Mitarbeiter begeistern. Er ist davon überzeugt, dass dazu strukturelle, personelle und interpersonelle Themen im Zusammenspiel adressiert werden müssen.
Stefan Roock hat seit 1999 agile Ansätze in Deutschland maßgeblich mit verbreitet und weiterentwickelt. Zunächst hat er als Entwickler in agilen Teams, später als Scrum Master/Agile Coach und Product Owner gearbeitet. Heute arbeitet er zusammen mit seinen Kollegen daran, dass Unternehmen langfristig mit agilen Denk- und Arbeitsweisen erfolgreich sind. Dabei fokussiert er auf agile Leadership.
Er ist regelmäßiger Sprecher zu agilen Themen auf Konferenzen, bei User Groups und in Unternehmen. Außerdem schreibt er Bücher und Artikel zu agilen Themen.
Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/stefan.roock
Bei der Umstellung einer Organisation in Richtung Agilität wird die Frage nach der Verortung der personellen Führung meist heftig diskutiert. Das Thema ist hoch-politisch und „Existenz-bedrohend“. Ergebnisse reichen von eher traditionellen Lösungen bis hin zu sehr progressiven.
Der Vortrag stellt vier grundlegende und unterschiedliche Modelle von personeller Führung in einer agilen Umgebung vor. Die vier Varianten decken die heute gängigsten Alternativen ab, von den bekannten agilen bis hin zu einer expliziten personellen Führungsrolle.
Zielpublikum: Manager, Entscheider, Personaler, Agile Coaches, Organisationsentwickler:innen
Voraussetzungen: Grundlegende Kenntnisse agiler Rollen in Teams und in der Skalierung
Schwierigkeitsgrad: Anfänger
Extended Abstract:
Im Vortrag wird anhand eines Kundenbeispiels vorgestellt, wie eine Entscheidungsfindung für eine der vier Varianten anhand eines Anforderungskatalogs ablaufen kann. Das gezeigte Vorgehen ist anhand des Modells bzw. Anpassungen für den eigenen Kontext und den Rahmen des Anforderungskatalogs übertragbar, d.h. es gibt dem Zuhörer ein Schema an die Hand, wie er Lösungsoptionen für seinen eigenen Kontext erarbeiten kann.
Was Zuhörer mitnehmen:
* Kenntnis 4 grundlegender Varianten für personelle Führung in der Praxis
* ein Schema, wie diese Varianten gegen einen individuellen Kontext evaluiert werden können
Alex Birke ist Buchautor, Berater und Coach für Business Agility. Er leitet den agilen Bereich von Accenture, Accenture Business Agility, im deutschsprachigen Raum. Seit 15 Jahren fokussiert er sich auf die Nutzung lean & agiler Methoden bei der Skalierung von Bereichen mit mehreren hundert bis zu mehreren tausend Personen. Er spricht regelmäßig auf Konferenzen und war über 10 Jahre als Lehrbeauftragter an der Universität Passau tätig.
Vortrag Teilen
Du hast das Gefühl, die Entwickler tun nicht das, was du ihnen sagst? Das Team übernimmt keine Verantwortung für das Sprintergebnis? Sie sind viel zu ruhig während des Meetings und freuen sich, wenn sie wieder in Ruhe arbeiten dürfen? Dabei hast du doch extra agile Methode eingeführt, um schnell, transparent und produktzentriert zu arbeiten.
Was läuft also schief? Diese Session liefert dir den notwendigen Rahmen und passende Antworten.
Zielpublikum: Projektleiter:innen, Entscheider, Product Owner, Management, Geschäftsführung
Voraussetzungen: Projekterfahrung
Schwierigkeitsgrad: Anfänger
Extended Abstract:
In dieser Session lernst du:
• Welches Umfeld agiles Arbeiten erfordert.
• Wie du näher an deine Entwickler rückst.
• Wie wichtig Konflikte sind.
• Wie wichtig es ist, dass dein Team wirklich enabled und auch empowered ist.
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".
Vortrag Teilen
In der Entwicklungsabteilung der Carl Zeiss SMT GmbH arbeiten mehr als 30 Scrum-Teams. Für diese wurde ein übergreifendes „QA Manifest“ erstellt, das die grundlegenden Werte für die Qualitätssicherung definiert, Empfehlungen ausspricht sowie Anleitungen und Good Practices beinhaltet.
Im Vortrag werden die Ergebnisse vorgestellt, aber besonders wird auf die Erkenntnisse und Überraschungen eingegangen, die während der Workshops, Interviews und Arbeit mit allen Beteiligten auftauchten.
Zielpublikum: Tester, Entwickler:innen, Projektleiter:innen, Manager, Entscheider,
Voraussetzungen: Fachkenntnisse agile Methoden
Schwierigkeitsgrad: Fortgeschritten
Extended Abstract:
Die Entwicklungsabteilung EMI der ZEISS Semiconductor Manufacturing Technology hat sich in den letzten Monaten erfolgreich einer agilen Transition unterzogen. Es gibt nun mehr als 30 Scrum-Teams, die verschiedene Softwareprodukte entwickeln und anpassen. Im nächsten Schritt sollte ein übergreifendes „QA Manifest“ entstehen, das die grundlegenden Werte für die Qualitätssicherung definiert, Empfehlungen ausspricht sowie Anleitungen und Good Practices beinhaltet.
Dabei wurden umfangreiche agile Workshops durchgeführt, um alle Teams abzuholen, gemeinsam mit dem QualityChapter der EMI ein Vorgehen erarbeitet und die Ergebnisse abschließend verprobt.
Ziel war es, einen einfachen Ansatz zu finden, der die Herausforderungen einer agilen Qualitätssicherung gemeinsam mit den Scrum-Teams angeht und dabei die Anforderungen der Stakeholder im Auge behält sowie die Kommunikation mit allen Beteiligten sicherstellt. Darüber hinaus mussten auch Wege gefunden werden, um Anforderungen der Qualitätssicherung in einem skalierten Umfeld effektiv umzusetzen.
Im Vortrag werden die Ergebnisse vorgestellt, aber besonders wird auf die Erkenntnisse und Überraschungen eingegangen, die während der Workshops, Interviews und Arbeit mit allen Beteiligten auftauchten.
Projected learning outcomes / lessons learned for participant:
* Good Practices und Hinweise für agile Qualitätssicherung im komplexen Umfeld
* Ansätze für kollaborative und verteilte Workshops mit vielen Teilnehmern und vielen Teams
* Vorstellung der Schwerpunkte für spezielles Projekt
* Individuelle Ansätze für agiles Testen im skalierten Umfeld
* Einführung (Vorstellung des Projektes und der Aufgabenstellung)
* Erste Schritte (Schulungen, kollaborative und verteilte Workshops mit 20 Teams zur Aufnahme des IST-Standes)
* Gemeinsame Erarbeitung des Testvorgehens (Vorgaben, Anleitung, Good Practices, Definition von gemeinsamen Arbeitspaketen)
* Umsetzung des Testvorgehens (Coaching der Teams, Erarbeitung der gemeinsamen Arbeitspakete)
* Abschluss (Erkenntnisse und Ausblick)
Kay Grebenstein arbeitet als Head of QA für die Business Line Manufacturing Solutions bei der ZEISS Digital Innovation. In seiner Zeit als Testmanager und agiler QA-Coach hat er in den letzten Jahren in Projekten unterschiedlicher fachlicher Domänen (Industrie, Semiconductor, Energie, …) Qualität gesichert und Software getestet.
Mehr Inhalte dieses Speakers? Schaut doch mal bei sigs.de vorbei: https://www.sigs.de/autor/Kay.Grebenstein
Vortrag Teilen