Am 21.+22. Februar 2018 fanden an der Goethe-Universität Frankfurt die Frankfurter Entwicklertage statt. Wie ein roter Faden zog sich die Frage durch die Vorträge, wie Softwareentwicklung in Zeiten der agilen Transformation das Arbeitsleben der Entwickler verändert.

Im Vortrag "Agile Architekturen" von Sippach und Maier wurden sehr strenge und gar nicht leichtgewichtige Verfahren empfohlen, mit denen sich selbst organisierende Teams angeblich die besten Architekturen entwickeln:

• Ausformulierung der aktuellen und möglichen zukünftigen Anforderungen an Funktionalität und Qualität (Performance, Benutzerfreundlichkeit und Wartbarkeit) prüfbar als Szenarien,
• der systematische Vergleich zweier denkbarer Architekturen bezüglich der Anzahl der Komponenten und dem Aufwand, die Anforderungen umzusetzen,
• Architekturdokumentation,
• Code-Reviews und automatisierte Architektur-Checks.

Frau Dr. Porschen-Hueck berichtete aus einer wissenschaftlichen Studie zum Thema "Agilität als Gesundheitsrisiko". Eigentlich versprechen die Grundideen der Agilität eine Entlastung für die Mitarbeiter/innen: Komplexitätsreduktion, schnelle Erfolge, den Sprint als Schutzraum, gegenseitige Unterstützung, sustainable pace statt Meilensteinstress. In der Praxis ist aber die agile Arbeit geprägt von ständigem Zeitdruck, Ressourcenknappheit, Optionsstress, Kooperationsbelastungen, Leistungsverdichtung und Verlust von Kohärenzsinn. In einem Beispiel war ein funktionierendes Team zerbrochen, weil nicht alle Mitglieder bei dem hohen Tempo des schnellsten Programmierers mithalten konnten.

Im Vortrag "Erfolgreich Teams bilden durch Self-Selection" von Diefenthäler und Brandt wurde von einer Erfahrung berichtet, bei der sich in einem eintägigen Workshop die Mitarbeiter selbst zu Teams zusammenfanden und in einem Hackathon erste gemeinsame Erfahrungen machten. So entstanden stabile Teams.

Zuletzt schärfte Doc Norton in seinem Key Note Vortrag den Programmierern ein: "Bitte niemals um Erlaubnis, Deinen Job richtig zu machen!" Es ging um technische Schulden und deren Vermeidung ("The Technical Debt Trap"). Oft entstehen technische Schulden durch strategische Entwurfsentscheidungen, die darauf abzielen, eine schnelle Lieferung und frühes Feedback zu erreichen. Der Begriff "technische Schulden" legt nahe, dass man diese Schulden später zurück bezahlen kann. Diese Vorstellung ist jedoch falsch. Man sollte bei der Arbeit niemals absichtlich Unordnung anrichten, sondern eher nach der Boy Scout Rule (Pfadfinderregel) handeln: "Verlasse den Code sauberer als Du ihn vorgefunden hast." Der Entwickler ist nicht nur dafür verantwortlich, dass die Software ihren Zweck erfüllt, sondern auch für deren Qualität. Für Clean Coding braucht es keine Sondergenehmigung!