Track: Trends & Techniques
- Dienstag
07.02. - Mittwoch
08.02. - Donnerstag
09.02.
For a technology company, building a strong engineering culture is essential for long-term success. Today's software industry is growing so fast that a large proportion of developers will inevitably have less than 5 years experience. At the same time, many software systems contain code that is ten, twenty or even thirty years old.
It's a constant challenge to communicate a healthy culture to newcomers and prevent technical debt from getting out of control. Technical coaching is all about tackling those issues: culture and skills.
Target Audience: Developers, Architects
Prerequisites: None
Level: Basic
Extended Abstract:
The Samman method is a concrete coaching method for spreading skills and culture within an engineering organization. There are two main parts to the method:
- Learning Hour
- Ensemble working
In the learning hour the coach uses exercises and active learning techniques to teach the theory and practice of skills like Test-Driven Development and Refactoring. In two-hour Ensemble sessions the whole team collaborates together with the coach in applying agile development techniques in their usual production codebase.
In combination with strong technical leadership, the Samman method can enable the spread of skills and culture to bring a healthy engineering organization to the next level.
Emily Bache is an independent consultant and Technical Coach. She works with developers, training and coaching effective agile practices like Refactoring and Test-Driven Development. Emily has written two books and teaches courses on platforms including Pluralsight and O’Reilly. A frequent conference speaker, Emily has been invited to keynote at prestigious developer events including EuroPython, Craft and ACCU. Recently Emily founded the Samman Technical Coaching Society, a not-for-profit organisation which aims to support and inspire technical coaches around the world.
"Ich hatte keine Zeit, den Zaun zu flicken" - Dieses Zitat kennt wohl jeder, und doch ertappen wir uns selbst, unseren Zaun nicht geflickt, sondern stattdessen die Hühner gesucht zu haben.
Doch wie ändere ich das?
Dieser Vortrag zeigt mit dem Konzept der MLCs ein Tool auf, dieser Falle zu begegnen und sich selbst und andere in den Modus des kontinuierlichen Lernens zu versetzen.
Am Ende haben die Zuhörenden einen ersten MLC durchlaufen und ein Tool erlernt, um sich und anderen den Freiraum zum Lernen zu erschaffen.
Zielpublikum: Coaches, Entscheider, Projektleiter:innen, Transformation Manager, Architekt:innen, Lebenslange Lernende
Voraussetzungen: Keine
Schwierigkeitsgrad: Anfänger
Extended Abstract:
Micro-Learning-Cycles sind kein theoretisches Konstrukt, sie sind tatsächlich aus der Notwendigkeit entstanden, trotz vollem Terminkalender Zeit zum Lernen zu finden.
Neben der Vermittlung und Anwendung von MLC zeigt die Referentin auch aus der Praxis, wo sie MLCs einsetzte, was funktionierte und wo auch Limitierungen sind.
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.
Zero Trust Architecture has become the norm for how to modernize IT security in an age of growing network complexity and fewer ways to define hard network boundaries. Today, APIs are a standard way of how organizations expose both technical and business capabilities. But what does it mean for an API to be "Zero Trust Ready"?
In this presentation we look at some of the general patterns that APIs need to follow for Zero Trust readiness. We also look at some concrete practices for how to follow those patterns in your own APIs and API landscape.
Target Audience: Architects, Developers, API Designers, API Program/Platform Managers, Security Leads
Prerequisites: Basic knowledge of API terminology
Level: Advanced
Liad is a technologist that specialises in digital transformation and innovations.
For years he has been guiding and assisting organisations through their digital transformation journey. Enabling them to make the necessary changes needed when integrating digital technology into all areas of the business, with the goal of driving operational efficiency and value to customers, whilst supporting them through the technological and cultural changes.
With a strong background in networking and cybersecurity, having worked with service providers, Content Delivery Network (CDN) companies and top security vendors.
He has been helping companies, mostly technology startups and FinTechs, to understand the value of their digital assets and then pivot towards a strategy that will best allow them to innovate whilst maintaining security and control over their data. Liad is Vice President Pre-Sales Consulting at Axway.
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.
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).
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
Irgendwann trifft es mal jeden. Anwendungen veralten automatisch, egal, ob ein oder zehn Jahre alt, ob sie "fertig" entwickelt sind oder nicht. Die Gründe sind vielschichtig: Die Programmiersprache entwickelt sich weiter, Bibliotheken brauchen ein Update, Good Practices entwickeln sich weiter. Diese Wartungsarbeiten werden nicht gerne gemacht, da sie scheinbar unnötige Aufwände erzeugen und zum Teil recht stupide sind. Ignoriert die Entwicklerin sie, dann sammelt sie automatisch technische Schulden und die Aufwände sind in der Zukunft höher.
Zielpublikum: Entwickler:innen, Architekt:innen, Entscheider
Voraussetzungen: Allgemeine Entwicklungskenntnisse
Schwierigkeitsgrad: Anfänger
Extended Abstract:
Irgendwann trifft es mal jeden. Anwendungen veralten automatisch, egal, ob ein oder zehn Jahre alt, ob sie "fertig" entwickelt sind oder nicht. Die Gründe sind vielschichtig: Die Programmiersprache entwickelt sich weiter, Bibliotheken brauchen ein Update, Good Practices entwickeln sich weiter. Diese Wartungsarbeiten werden nicht gerne gemacht, da sie scheinbar unnötige Aufwände erzeugen und zum Teil recht stupide sind. Ignoriert die Entwicklerin sie, dann sammelt sie automatisch technische Schulden und die Aufwände sind in der Zukunft höher und bei Sicherheitslücken schmerzhafter.
Dieser Vortrag zeigt, was alles unter Wartungsarbeiten zu verstehen ist und in welche Probleme Unternehmen laufen können, wenn sie es unterlassen. Außerdem stellt es Vorgehensweise und Werkzeuge vor, die bei Wartungsarbeiten helfen können und somit zumindest den stupiden Teil reduzieren.
Sandra Parsick ist Java Champion und arbeitet als freiberufliche Software-Entwicklerin und Consultant im Java-Umfeld. Seit 2008 beschäftigt sie sich mit agiler Softwareentwicklung in verschiedenen Rollen. Ihre Schwerpunkte liegen im Bereich der Java Enterprise-Anwendungen, Cloud, Software Craftsmanship und in der Automatisierung von Softwareentwicklungsprozessen. Darüber schreibt sie gerne Artikel und spricht auf Konferenzen. In ihrer Freizeit engagiert sich Sandra Parsick in verschiedenen Programmkomitees und Community-Gruppen.
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
In der Vorweihnachtszeit 2021 wurden viele IT-Abteilungen von Zero-Day-Sicherheitslücken im weitverbreiteten Java-Logging-Framework Apache Log4j kalt erwischt. Diese Session fasst das Ereignis zusammen und sucht Parallelen zu ähnlichen Zero-Days. Hinweise zu proaktiven Maßnahmen helfen, zukünftig in ähnlichen Situationen schneller reagieren zu können. In diesem Zusammenhang wird u.a. auf Configuration Management und Infrastructure as Code nebst Automation eingegangen, aber auch auf Tools wie Web, DNS und Netzwerk-Firewalls.
Zielpublikum: Architekt:innen, Entscheider, Manager, IT-Sicherheitsbeauftragte
Voraussetzungen: Generelles Verständnis für IT-Sicherheitsherausforderungen bei Web-Anwendungen
Schwierigkeitsgrad: Fortgeschritten
Extended Abstract:
In der Vorweihnachtszeit wurden viele IT-Abteilungen von Sicherheitslücken im weitverbreiteten Java-Logging-Framework Apache Log4j kalt erwischt.
Diese Session fasst das Ereignis zusammen und beantwortet die folgenden Fragen, um zukünftig in ähnlichen Situationen schneller reagieren zu können:
• Welche Möglichkeiten bieten Web, DNS und Netzwerk-Firewalls, um eine Ausnutzung derartiger Lücken zu verhindern?
• Welche Tools kann ich nutzen, um bspw. mithilfe automatisierter Scans und Analysen des Netzwerkverkehrs festzustellen, welche Bestandteile meiner IT-Infrastruktur betroffen sind?
• Wie kann ich mit Legacy-Anwendungen umgehen, die ich nicht aktualisieren kann?
• Wie sollte ich mein Deployment und Betriebsabläufe modernisieren, um Patching zukünftig schneller realisieren zu können?
Automation in Verbindung mit Playbooks und Runbooks ist dabei ein Kernaspekt, um einen Incident Response-Prozess in einer großen IT-Landschaft skalieren zu können.
Dennis Kieselhorst ist Solutions Architect bei Amazon Web Services (AWS). Er hat 15 Jahre Erfahrung mit Java und verteilten, heterogenen Systemlandschaften. Dennis unterstützt verschiedene Open-Source-Projekte und ist Committer/PMC-Mitglied bei der Apache Software Foundation. Er wirkt in den Organisationskomitees der Java User Group (JUG) Bremen-Oldenburg und des Java Forum Nord mit.
Vortrag Teilen
As developers, our job is to deliver working software. With the shift to CI/CD and the move to the cloud, the need to have the right feedback at the right time only increases. There are many ways that testing can help us with that. Not only can testing help us verify our solution and prevent us from breaking things, it can also help us design our software, find flaws in our architecture and come up with better solutions. In this talk I will highlight some of the many ways that testing can help you to develop better software faster.
Target Audience: Developers
Prerequisites: Basic knowledge in Java
Level: Advanced
Extended Abstract:
Testing doesn't always get the attention it deserves in software development. Many developers claim to be bad at it, or are just not that interested. (These may or may not be related.)
As developers, our job is to deliver working software. With the shift to CI/CD and the move to the cloud, the need to have the right feedback at the right time only increases. There are many ways that testing can help us with that. Not only can testing help us verify our solution and prevent us from breaking things, it can also help us design our software, find flaws in our architecture and come up with better solutions.
In this talk I will highlight some of the many ways that testing can help you to develop better software faster.
Marit van Dijk is a software developer with 20 years of experience in different roles and companies. She loves building awesome software with amazing people and has contributed to open source projects like Cucumber and various other projects. She enjoys learning new things, as well as sharing knowledge on programming, test automation, Cucumber/BDD and software engineering. She speaks at international conferences, webinars and podcasts, occasionally writes blog posts and contributed to the book "97 Things Every Java Programmer Should Know" (O’Reilly Media).
In this session I’ll examine some of the things that can go wrong when organisations jump headfirst into micro-service architectures without understanding the potential pitfalls.
I'll explain contract testing from the ground up. You'll learn how it can decouple micro-service dependencies during development, allowing your teams to work effectively. And I'll describe sophisticated, free, open-source tooling that helps integrate contract testing into your software lifecycle, giving you the confidence to release micro-services independently.
Target Audience: Architects, Developers, Decision Makers, Release Managers, DevOps
Prerequisites: English, basic software design/architecture, software lifecycle
Level: Advanced
Seb Rose has been a consultant, coach, designer, analyst and developer for over 40 years. He's now Developer Advocate with SmartBear Advantage, promoting better ways of working to the software development community.
Co-author of the BDD Books series "Discovery” and "Formulation" (Leanpub), lead author of “The Cucumber for Java Book” (Pragmatic Programmers), and contributing author to “97 Things Every Programmer Should Know” (O’Reilly).
Unfortunately, this presentation has to be cancelled at short notice for personal reasons.
This talk covers the fundamentals of diversity, equity, and inclusion (DEI), including key definitions and statistics. Moreover, the link between DEI, sustainability, and innovation will be made, including reflections on the importance but also complexity of finding a balance.
As part of this talk, I will link theory and research to my work as the Global Head of Diversity, Equity, and Inclusion in a fintech company, including giving practical examples of how we are embedding DEI into our organization.
Target Audience: People Leaders, Managers, Decision Makers, C-suite
Prerequisites: Open-mindedness, interest in DEI
Level: Basic
Extended Abstract:
What does diversity, equity, and inclusion have to do with sustainability and this year’s conference focus on “finding the right balance?” Everything.
In this talk, I will cover the basics of D, E, and I including definitions and statistics, including introducing various “diversity dimensions” and the concept of “intersectionality.” Then, I will link the DEI agenda to the people sustainability agenda, including showing how the world is already diverse and if your organization is not: how you are likely missing out on learning, development, innovation, user experience knowledge, and even market share.
In doing so, I will link theory and statistics to my work as Global Head of Diversity, Equity, and Inclusion in a fintech company, including giving practical examples on how we are embedding DEI into processes and policies. Finally, I will give reflections on how DEI is a journey that also must be balanced and prioritized, just as any other business priority, before opening up to audience questions.
Elizabeth Benedict Christensen, Ph.D. has extensive theoretical and practical experience in diversity, equity, and inclusion in the academic and business worlds. Elizabeth has taught at university-level about Diversity, Cultural Analysis, Communication, Research Methods and beyond. She completed a Ph.D. on sense of belonging before returning to the business world in 2017 to bridge theory with practice, including sharing her passion for DEI globally.
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
What should you do if you are promoted or hired to be the first Head of Architecture in a big, international organisation? What should you do to shape the role to deliver value to the organisation and its customers? How do you work with many development teams to shape the current legacy spaghetti mess into a coherent system, without becoming a bottleneck?
In this talk I'll respond to all questions and more, by sharing my experience in becoming the first Head of Architecture in a big international organisation.
Target Audience: Architects, Developers, Senior Managers
Prerequisites: Knowledge of software architecture
Level: Expert
Extended Abstract:
In this talk I'll share my experience in becoming the first Head of Architecture in a big international organisation, and on how I shaped the role to deliver value both to the organisation and its customers. Among other things, I'll share what I did to:
- Work productively with the development teams and be relevant.
- Navigate the political landscape to influence decisions.
- Create an architectural decision process tailored to the needs of the organisation.
- Provide guidelines and constraints to decentralise decision making while avoiding chaos.
The attendees will get a better understanding of what the role encompasses, and future heads of architecture may get a better view of what expects them in this role.
Giovanni Asproni is a co-founder and CTO at Launch Ventures, https://launchventures.co. Before co-founding Launch Ventures he has worked for many years as a developer, architect, and consultant in projects of all sizes.
His expertise ranges from software design and programming to software project management, and agile software development. He has contributed two chapters to the book ’97 Things Every Programmer Should Know’ published by O’Reilly.
Vortrag Teilen