MIC

Etablierte Firma

Alle Videos anzeigen

7 Powerful Questions to ask your Development Teams

Philipp Dressler von MIC spricht in seinem devjobs.at TechTalk über sieben Grundgedanken, anhand welchen ein Team von Developern reibungslos zusammenarbeiten kann.

Beim Videoaufruf stimmst Du der Datenübermittlung an YouTube und der Datenschutzerklärung zu.

Video Zusammenfassung

In 7 Powerful Questions to ask your Development Teams zeigt Philipp Dressler (MIC) praxisnahe Fragen und Ansätze, um Softwareteams zu stärken – von Technical HR Enabling und der Nähe zu Nutzer:innen über konkrete Beispiele bis hin zu Domain-Driven Design mit gemeinsamer Domänensprache. Er erläutert, wie sich Rework und technische Schulden durch Discovery-Workshops, Testgetriebene Entwicklung sowie Pair-/Mob-Programming reduzieren lassen, ergänzt durch die Boy-Scout-Regel, automatisierte Tests und gutes Design, und warum mehr Köpfe selten helfen. Zuschauer:innen können die Fragen direkt nutzen, um das Richtige zu bauen, Feature-Nutzung zu messen, Jira-Ping-Pong zu vermeiden und Teamzufriedenheit zu fördern, die mit Produktivität korreliert.

7 kraftvolle Fragen an eure Entwicklungsteams – Erkenntnisse aus „7 Powerful Questions to ask your Development Teams“ von Philipp Dressler (MIC)

Warum diese sieben Fragen zählen

In seinem Talk „7 Powerful Questions to ask your Development Teams“ führt Speaker Philipp Dressler (MIC) durch Fragen, die in der Praxis überraschend wirksam sind. Sie zielen nicht auf Tools, Dogmen oder Prozesse um ihrer selbst willen, sondern auf die Qualität der Zusammenarbeit und die Fähigkeit eines Teams, das Richtige schnell, sauber und nachhaltig zu bauen. Als DevJobs.at-Redaktion haben wir besonders geschätzt, wie konsequent Dressler technische Praktiken mit Produktfokus und Teamkultur verknüpft.

Die Leitidee zog sich durch alle Abschnitte: Kleine, bewusst gesetzte Interventionen erzeugen große Wirkung – vorausgesetzt, Teams schaffen Raum zum Üben, suchen die Nähe zu echten Nutzer:innen, arbeiten mit konkreten Beispielen statt mit Abstraktionen und verankern saubere technische Praktiken im Alltag. Die folgenden sieben Fragen bilden dabei einen kompakten, sofort nutzbaren Rahmen.

Frage 1: Entwickelt ihr euch selbst?

Viele Teams sprechen über Softwareentwicklung, aber zu selten über das Entwickeln der eigenen Fähigkeiten. Dresslers Einstiegspunkt ist klar: Teams brauchen Orte und Zeitfenster, um Skills zu üben – nicht punktuell, sondern kontinuierlich. Bei MIC setzt man dafür auf „Technical HR Enabling“.

Was „Technical HR Enabling“ laut Talk bedeutet

Technische HR Coaches arbeiten über einen definierten Zeitraum (z. B. drei Monate) eng mit einem Entwicklungsteam zusammen.
Danach wechseln sie zum nächsten Team. Ziel ist, gemeinsam die Art zu verbessern, wie Code entsteht – nicht nur einzelne Personen zu schulen.
Im Kontrast zu isolierten Einzeltrainings ist die kontinuierliche Zusammenarbeit nachhaltiger, weil sie echte Alltagsprobleme aufgreift.

Dressler benennt den Preis und den Nutzen offen:

„You need to slow down to speed up in the future.“

Wer bewusst Tempo herausnimmt, investiert in künftige Geschwindigkeit – durch besseres Design, gemeinsame Standards und wiederholbare Arbeitsweisen. Aus unserer Sicht lohnt es sich, das als Führungskraft sichtbar zu machen: Dieser Raum ist kein Luxus, sondern eine strategische Entscheidung.

Anwendung im Alltag

Schafft feste Übungsphasen (z. B. drei Monate Coaching), in denen an realen Tickets gearbeitet wird – mit Fokus auf Entwicklungspraktiken, nicht nur Feature-Output.
Verabredet Team-standards, die während dieser Phase entstehen und danach verbindlich bleiben (z. B. Definition of Done inkl. Tests, Review-Formate, Pair-Routinen).
Bewertet die Wirkung nicht nur an Velocity, sondern an den Effekten auf Korrekturen, Änderungsaufwände und Rework.

Frage 2: Könnt ihr mir zeigen, wie eure Nutzer arbeiten?

Dressler fordert Nähe zu Anwender:innen ein. Die zentrale Prüffrage: Können Entwickler:innen ihre eigene Software genauso bedienen wie die Nutzer:innen? Oft ist die ehrliche Antwort: nicht wirklich. Dann verschwimmt das Verständnis für reale Arbeitsabläufe – und Teams bauen Features, die selten oder nie genutzt werden.

Was der Talk betont

Entwickler:innen brauchen Zugang zum Nutzungskontext. Nur so liefern sie passgenaue Lösungen.
Viele Features in der Branche werden gebaut und danach kaum verwendet. Das ist eine Ressourcenfalle.
Wenn ihr Nutzung nicht messen könnt, fragt die Nutzer:innen. Direkte Rückmeldung ist besser als Vermutung.
Vermeidet „Just-in-Case“-Funktionalität – baut, was tatsächlich gebraucht wird.

Wichtig ist außerdem die Unterscheidung zwischen „das Richtige bauen“ und „das Ding richtig bauen“. Dressler mahnt, die erste Frage nicht dem Zufall zu überlassen. Technische Exzellenz ist wertlos, wenn sie am Bedarf vorbeigeht.

Anwendung im Alltag

Richtet regelmäßig Sessions ein, in denen Entwickler:innen reale Nutzerflüsse durchspielen – mit echten Datenpfaden und Werkzeugen.
Messt, was messbar ist (Nutzungsereignisse, Pfadlängen) und ergänzt das Bild durch qualitative Gespräche.
Räumt Features ohne Nutzung gnadenlos auf oder priorisiert sie radikal nach unten. Die frei werdende Zeit fließt in das, was verifizierten Nutzen stiftet.

Frage 3: Könnt ihr mir ein Beispiel geben?

Dressler bezeichnet diese Frage als eine der stärksten in der Softwareentwicklung. Der Grund: Das menschliche Gehirn versteht konkrete Beispiele besser als abstrakte Konzepte. Wer Diskussionen über Annahmen und Definitionen abkürzt, bittet um Beispiele.

Er illustriert das mit einem einfachen Setup aus „blauen“ und „grünen“ Karten: Die blauen Karten stehen für Akzeptanzkriterien, die grünen liefern erläuternde Beispiele. Selbst in einfachen Fällen wird der Unterschied spürbar – das Team findet viel schneller zu einer gemeinsamen Vorstellung.

„Examples make great test cases.“

Formulierte Beispiele sind prädestinierte Testfälle: zuerst manuell zur Validierung, dann automatisiert. Das verschiebt Missverständnisse nach vorn – dorthin, wo sie am billigsten sind.

Anwendung im Alltag

Stoppt abstrakte Debatten, sobald sie festfahren, mit der Aufforderung: „Bitte ein konkretes Beispiel.“
Haltet Beispiele schriftlich fest – so werden sie zu stabilem Projektwissen und zu Testfällen.
Nutzt die Beispiele in Discovery- oder Refinement-Runden (siehe Frage 5), um Anforderungen zu „testen“, bevor eine Zeile Code entsteht.

Frage 4: Sprecht ihr eine gemeinsame Domänensprache?

MIC arbeitet gern mit Domain-Driven Design (DDD). Aus Dresslers Sicht ist das wichtigste Element die gemeinsame Domänensprache. Sie erlaubt, fachliche Präzision in Gespräche und in Code zu übertragen. Die Herausforderung: die richtigen Worte zu finden und „Business“ sprechen zu lernen.

Eine überraschend hilfreiche Quelle ist die Vergangenheit. Dressler schildert, wie das Team in einer historisch gewachsenen Domäne – Zoll und Außenhandel – Begriffe aus früheren Zeiten heranzog, um Prozesse zu begreifen. Das anschauliche Bild einer „Postkutsche“ half, Abläufe zu skizzieren und passende Worte zu finden. Wichtig: Dieses Bild wurde nicht als Domänenkonzept in den Code übernommen, diente aber als Denkwerkzeug.

Anwendung im Alltag

Baut ein Glossar der Fachbegriffe auf, das sowohl Produkt als auch Code leitet. Jedes Teammitglied nutzt dieselben Wörter für dieselben Konzepte.
Nutzt historische oder bildhafte Analogien, um Prozesse zu entwirren – aber überführt nur präzise, tragfähige Begriffe in den Code.
Achtet konsequent auf Sprachdisziplin in Tickets, Dailies und Code-Reviews – das schärft Verständnis und reduziert Rework.

Frage 5: Wie viel Rework habt ihr – und wann testet ihr?

Rework gehört zum Handwerk – doch der Zeitpunkt des Testens entscheidet über das Ausmaß. Dressler nennt ein klares Symptom: „Jira-Ping-Pong“. Ein Ticket wandert vom Development zum Test, zurück zu Development, vielleicht weiter zur Produktseite – und verliert unterwegs Zeit und Kontext.

Er skizziert drei Quick Wins, die den Feedbackzyklus dramatisch verkürzen und Rework reduzieren.

1) Discovery-Meetings bzw. Anforderungsworkshops

Bevor ein Ticket in den Sprint gezogen wird, sollte es inhaltlich gründlich besprochen werden – inklusive konkreter Beispiele. Der Effekt: Ihr „testet“ die Anforderung, bevor Code existiert. Das ist die billigste Form des Testens.

Praktische Tipps:

Definiert klare Ziele pro Workshop: Welche Fälle sind verstanden? Welche Beispiele gelten als repräsentativ?
Haltet die Beispiele so fest, dass sie später in Tests überführt werden können.

2) Testgetriebene Entwicklung (TDD)

Dressler ist bekennender Fan. Neben verbesserter Testabdeckung betont er vor allem den Designnutzen: TDD fördert entkoppelte, langlebige Strukturen. Tests werden zum Dialogpartner im Entwurf – das Ergebnis ist nachhaltiger.

Praktische Tipps:

Beginnt mit kleinen Einheiten, um das Team an den Rhythmus (Rot–Grün–Refactor) zu gewöhnen.
Messt nicht nur Coverage, sondern beobachtet Kopplung und Änderbarkeit als Signal.

3) Pair- oder Mob-Programming

„Ich liebe das“, sagt Dressler – und begründet es mit der kürzestmöglichen Feedbackschleife. Zwei (oder mehr) Entwickler:innen denken, schreiben, prüfen gleichzeitig. Viele Reviews entfallen, Tests entstehen näher am Problem, und der Code gehört dem Team, nicht Einzelnen.

Praktische Tipps:

Führt Pairing mit klaren, leichten Regeln ein (Rollen wechseln, Fokuszeiten, kurzer Retro-Slot am Ende).
Nutzt Mob-Sessions für besonders knifflige Refactorings oder für Wissensverteilung.

Frage 6: Ist es leicht, eure Software zu ändern oder zu erweitern? (Technische Schulden)

Technische Schulden sind unvermeidlich und machen Teams langsamer. Dressler verweist auf Studien, die Produktivitätsverluste von 23 % und in anderen Fällen 42 % beschreiben. In vielen Organisationen fühlt sich der Effekt noch größer an – das ist normal. Entscheidend ist, wie Teams darauf reagieren.

Er warnt vor zwei Reflexen:

Mehr Leute ins Team stecken: Das hilft selten. Sein pointierter Vergleich bleibt hängen:

„You can't give birth to a baby in one month with nine mothers.“

Einfach „weiter ackern“ und die Schuld tilgen, während man in gleicher Taktzahl Features liefert: Das führt Teams auf Dauer zum Stillstand. Änderungen werden dann zäh, kleinste Anpassungen dauern ewig. Und Überstunden? Dressler bringt es trocken auf den Punkt – „Working long hours is 1990s.“

Bessere Wege im Umgang mit technischer Schuld

Gute technische Praktiken fest verankern: Refactoring, sauberes Design, klare Architekturentscheidungen.
Die Boy-Scout-Regel leben:

„Always leave the place nicer than you found it.“

Jedes Ticket hinterlässt den Code etwas besser – kleine, stetige Schritte statt heroischer Großsanierungen.

Nachhaltige Softwareentwicklung als Zielbild: Für Dressler bedeutet das automatisierte Tests und gute Designprinzipien. Beides senkt Änderungsangst und macht Tempo dauerhaft möglich.

Anwendung im Alltag

Schafft sichtbare Kapazität für Refactoring innerhalb regulärer Arbeit. Wenn Designschulden nur „nebenher“ passieren, bleiben sie liegen.
Nutzt Pairing gezielt auf Legacy-Stellen, um Sicherheitsnetze (Tests) zu knüpfen und riskante Kopplungen abzubauen.
Verknüpft Architekturentscheidungen mit Beispielen (siehe Frage 3), damit der Zweck nachvollziehbar bleibt.

Frage 7: Sind eure Teams glücklich?

Zum Schluss lenkt Dressler den Blick auf Zufriedenheit und Wohlbefinden. Er verweist auf Forschung von Nicole Forsgren und betont die Korrelation mit Produktivität. Überraschend ist das nicht – aber es bleibt handlungsleitend: Gute Arbeitsumgebungen sind kein „Nice-to-have“, sondern ein Leistungsfaktor.

Anwendung im Alltag

Gestaltet eine inspirierende Umgebung – was das bedeutet, variiert je nach Kontext. Wichtig ist, dass Teams fokussiert arbeiten, lernen und stolz auf Ergebnisse sein können.
Nutzt die vorangegangenen sechs Fragen als Hebel für Zufriedenheit: Nähe zu Nutzer:innen, klare Sprache, schnelle Feedbackschleifen und gute Praktiken sind starke Motivatoren.

Beobachtungen zur „Architektur“ der Zusammenarbeit

Auch wenn der Talk keine Code-Demos zeigte, war die technische Leitplanke klar: Architektur entsteht aus Praktiken, Sprache und Feedback. Drei Muster stechen hervor:

Kooperative Architekturarbeit: Pair-/Mob-Programming und TDD verlagern Entwurfsentscheidungen in gemeinsames Tun.
Spracharchitektur: Die Domänensprache bildet das tragende Gerüst, an dem sich Code und Konversation ausrichten.
Feedbackarchitektur: Discovery-Workshops, Beispiele und frühe Tests sind strukturelle Bausteine, die Fehlentwicklungen verhindern.

Diese „Architektur der Zusammenarbeit“ macht Systeme änderbar – und genau daran misst Dressler technische Qualität.

Konkrete Schritte für die nächsten 4–6 Wochen

Woche 1–2: Startet mit Discovery-Meetings vor jedem Sprint. Sammelt pro Ticket mindestens drei konkrete Beispiele und haltet sie fest.
Woche 1–4: Führt Pair-Programming mit klaren Leitplanken ein (z. B. 2×2 Stunden pro Tag). Nutzt die Sessions für heikle Stellen.
Woche 2–6: Beginnt TDD auf neuen, kleinen Komponenten. Ziel ist nicht maximale Coverage, sondern besseres Design und Mut zur Änderung.
Fortlaufend: Pflegt ein Domänenglossar, prüft Wortwahl in Tickets/Code und ergänzt Beispiele, wenn Begriffe unklar sind.
Fortlaufend: Praktiziert die Boy-Scout-Regel – kleine Refactorings bei jeder Änderung.

Die wichtigste Lernkurve aus dem Talk

Entwicklungsteams brauchen Übungsraum, nicht nur Feature-Taktung.
Nutzer:innen-Nähe ist das stärkste Mittel gegen nutzlose Features.
Beispiele schlagen Abstraktionen – und werden zu Tests.
Gemeinsame Domänensprache ist der Klebstoff zwischen Business und Code.
Rework sinkt, wenn Feedback früh und gemeinsam passiert (Discovery, TDD, Pair/Mob).
Technische Schuld verlangt disziplinierte Praktiken, nicht mehr Köpfe.
Zufriedenheit und Produktivität gehen Hand in Hand – baut Arbeitsumgebungen, die beides fördern.

Fazit

„7 Powerful Questions to ask your Development Teams“ von Philipp Dressler (MIC) ist kein weiterer Aufruf zu mehr Werkzeugen, sondern ein präziser Rahmen für bessere Softwareentwicklung. Jede Frage zielt auf einen Engpass: Lernzeit, Nutzerverständnis, Klarheit durch Beispiele, gemeinsame Sprache, frühes Testen, Wandelbarkeit unter Schulden und Teamzufriedenheit. Wer diese Hebel konsequent ansetzt, schafft strukturell die Voraussetzungen für Tempo und Qualität – heute wie morgen.

Weitere Tech Talks

Weitere Tech Lead Stories