Themen auf der ALM

Was erwartet Dich bei uns?

Agilität steht nicht nur für den Einsatz von Methoden im Projektmanagement oder Softwareentwicklung. Vielmehr bietet eine agile Grundhaltung Unternehmen eine einzigartige Möglichkeit. Basierend auf Werten wie Transparenz, Mut, Respekt, Feedback und Einfachheit gestalten sie dabei eine Arbeitsumgebung, die engagierte Mitarbeiter:innen langfristig an ihr Unternehmen bindet. Für diese entsteht dabei eine Umgebung, in der sie sich angstfrei entwickeln können, für das Unternehmen entsteht ein langfristiger Wettbewerbsvorteil.

Wir veranstalten die ALM, um Menschen von dieser Idee zu überzeugen. Dabei können Unternehmen sowohl von oben als auch von unten verändert werden. Im Vordergrund steht bei uns immer die Idee der Augenhöhe. Durch den Austausch aus völlig unterschiedlichen Perspektiven möchten wir eine Veranstaltung schaffen, in der alle Teilnehmenden positive Impulse ins Unternehmen mitnehmen kann und die Idee der Agilität damit verbreitet.

Du kannst einfach Deine Themen oder Fragen zur ALM mitbringen und Dich mit den anderen Teilnehmer:innen austauschen.

Wenn Du schon vorab ein Thema weißt, welches Du besprechen möchtest, dann kannst Du uns auch vorab Infos dazu an

alm@colenet.de
schicken, die wir dann gerne unten veröffentlichen – das ist aber keine Pflicht!

Du hast Fragen? Schau einfach mal in unsere Fragen & Antworten oder kontaktiere die Organisatoren.

Themen

Handwerk im Burnout

Fabian Biebl

Handwerksbetriebe sind überlastet wie nie zuvor. Unzählige Auftragsanfragen überfordern bisherige Arbeitsweisen und führen zu Stress und Burnout.
Im Praxisbericht wird eine Kombination aus Coaching und Kanban vorgestellt, die über Selbsterkenntnis und Transparenz dem Betrieb Mechanismen zur Regelung der Auftragslast und der eigenen Arbeitsweise zur Verfügung stellt, um mit diesem Ansturm fertig zu werden.
In einer Betriebskultur, in der die Digitalisierung häufig noch nicht angekommen ist, wird die Einstiegshürde über low-tec und leichte Nachvollziehbarkeit und Sprache genommen.

Kreativität in Retrospektiven – Fluch oder Segen?

Lukas Böhler

Es gibt Scrum Master, die möglichst viel Komplexität reduzieren, um einen sicheren Rahmen zu geben – auch bei der Retrospektive, die dann mit wenigen standardisierten aber eben bekannten Vorlagen durchgeführt wird.
Wieder andere hingegen freuen sich auf ständig neue Methoden, probieren mit den Teams neue Dinge aus und versuchen über Abwechslung Spannung und Motivation zu erzeugen.
Am Ende, wie so oft, geht es aber nicht (nur) um die Kreativität des Scrum Masters, sondern um das Team, welches einen Mehrwert aus einer Retrospektive ziehen sollte.
Doch schließen sich die beiden Ansichten wirklich gegenseitig aus oder lässt sich nicht doch auch etwas kombinieren?
Das würde ich gerne in meiner Session näher beleuchten. 

Die Groan Zone

Simon Flossmann

Die Diskussion im Daily Stand-up dauert schon wieder ewig. Statt miteinander zu reden, reden die Entwickler nur aneinander vorbei. Im Sprint Planning kann sich dein Team einfach nicht auf ein gemeinsames Ziel für den Sprint einigen. Die Diskussionen drehen sich nur mehr im Kreis.

Kommt dir das bekannt vor?

Eigentlich sollte es doch so einfach sein: Das Team kommt zu einem bestimmten Thema zusammen. Jeder bringt sich mit einem Lösungsvorschlag ein. Die unterschiedlichen Ansätze werden vorgestellt, diskutiert, ergänzt und schließlich zu einer Lösung zusammengeführt. Jeder im Team stimmt zu, diesen gemeinsamen Ansatz weiterzuverfolgen und umzusetzen.
Du wirst zustimmen, dass die Wirklichkeit in den seltensten Fällen so aussieht. Was genau ist anders? Die Diskussion im Team steckt in der Groan Zone fest.

In dieser Session möchte ich euch die Groan Zone näher bringen. Und dann mit euch hilfreiche Tipps sammeln, wie wir unseren Teams helfen können, die Groan Zone zu überwinden. Denn das ist es, was erfolgreiche Scrum Master auszeichnet: Wir helfen unseren Teams unterschiedlichen Ansichten und Perspektiven einfließen zu lassen, um innovativ Probleme zu lösen und gleichzeitig auf dasselbe Ziel hinzuarbeiten.

Let’s try (to) unFIX!

Steffen Thols

Mit unFIX hat Jurgen Appelo ein Modell geschaffen, mit der ein vielseitiges Organisationsdesign abgebildet werden kann. Anders als andere populäre Ansätze wie SAFe, LeSS oder gar „Spotify-Modell” bietet es die Möglichkeit, sehr flexibel aus einer Bibliothek die passenden Bestandteile zusammen zu setzen um den Status Quo und den schrittweisen Wandel einer Organisation darzustellen.

In der Session werden wir uns die in unFIX vorhandenen Team-Typen ansehen und anhand eines (fiktiven) Beispiels gemeinsam eine Organisationsstruktur bauen.

Feedback mit Gewaltfreier Kommunikation

Cosima Jedamczik

Feedback zu geben bedeutet Wertschätzung – Feedback zu erhalten ist eine Chance zu Lernen.

Doch in der Praxis ist das oft gar nicht so einfach. Botschaften werden missverstanden und kommen beim Empfänger ganz anders an als beabsichtigt.

In dieser Session möchte ich mit euch darüber diskutieren, wie uns Marshall B. Rosenbergs Handlungskonzept der Gewaltfreien Kommunikation dabei helfen kann, wertschätzend Feedback zu geben und zu erhalten.

GDD – Gurken Driven Development

Moritz Kohl und Henning Meltz

Habt ihr mal wieder das Gefühl, dass euer Team keine Ahnung hat, was euer Produkt können soll und wie es sich verhalten soll? Seid ihr es leid ewig auf die Abnahme einer Story zu warten? Hast du als Product Owner oder Stakeholder keine Transparenz über die Entwicklung und das Testing eines Features?

Wir sind der Meinung, dass man nur dann ein gutes Inkrement liefern kann, wenn das gesamte Team ein einheitliches Verständnis des Produktes hat, transparent agiert und schnelle Feedbackzyklen einhält.

Wie man genau das mit BDD, Gherkin und weiteren nützlichen Tools erreichen kann, stellen wir euch in dieser Session vor.

Minimum Viable Architecture

Pascal Gugenberger

Kennt ihr das auch: Im ersten Projekt wird die gesamte Architektur aufwändig geplant, voll skalierbar und langfristig tragfähig. Leider kommt das Team kaum voran, vor lauter Software-Schichten, die mit „Durchlauferhitzer-Objekten“ zu befüllen sind. Im nächsten Projekt schwingt das Pendel in die andere Richtung aus. Alle architektur-relevanten Fragen werden verschoben, bis sie sich irgendwie von selbst klären, und bald kommt das Team kaum noch, weil die „Big-Ball-of-Mud“-Architektur für sie so ein Klotz am Bein geworden ist.

In einem interaktiven Workshop möchte ich euch ausgehend von einem Minimum Viable Product das Konzept der Minimum Viable Architecture näher bringen.

Wir werden uns ansehen, was eine Minimum Viable Architecture ausmacht, und wo die Stärken und Grenzen des Ansatzes liegen. Anhand einiger ganz unterschiedlicher MVPs machen wir uns deutlich, was eine Minimum Viable Architecture ausmacht. Dann werden wir gemeinsam Tipps sammeln, die euren Teams helfen können, in unterschiedlichen Situation eure Architektur mehr in Richtung „Minimum Viable“ zu bringen.

Wie stelle ich eigentlich einen guten Pull Request? Und was hat das mit Respekt zu tun?

Johannes Jasper

In den wohl allermeisten Softwareteams werden Codeänderungen in Pull Requests vom restlichen Team begutachtet, fachlich und technisch überprüft und dann genehmigt. Damit wird das 4-Augen Prinzip sichergestellt und Wissen über Codeänderungen sind auf mindestens zwei Teammitglieder verteilt.

Aber das Review von Pull Requests kann eine dröge Angelegenheit werden und nicht selten sind sie der Ausgangspunkt hitziger Debatten.

Was macht also einen wirklich guten Pull Request aus? Wie kommuniziere ich den Kerngedanken meiner Codeänderung am effektivsten? Wie gehe ich respektvoll mit der Zeit meiner Kolleg:innen um und wie vermeide ich, dass Fehler durchrutschen oder sich am Ende doch nur eine Person mit dem Code auskennt?

Welche technischen Fertigkeiten werden dafür benötigt?

In dieser Session möchte ich euch mein Ideal eines guten Pull Requests an einem konkreten Beispiel vorstellen und mit euch diskutieren. Von live Coding bis hin zu Anekdoten aus dem Software-Alltag ist alles willkommen.

Culture eats agility for breakfast*

Lea Schröder

Was hat Agilität mit Kultur zu tun? Wie beeinflussen sie sich gegenseitig? Was braucht es und was darf nicht passieren, damit die Kultur agile Methoden unterstützt? Mit Euren Erfahrungen und ein paar Impulsen von uns werden wir gemeinsam Lösungsideen entwickeln. Breakfast is served 😉