Deadline-Verderben
Unzureichende Tickets gepaart mit geschwindigkeitsbasierten KPIs fördern auch schlechte Gewohnheiten auf technologischer Seite. Ist die Deadline der alleinige Maßstab, haben die Entwickler keine andere Wahl, als Tickets abzuarbeiten - und Abstriche zu machen. Die können sich in schlampiger Kodierung manifestieren, was wiederum zu ausufernden technischen Schulden führt. Letztendlich erschwert die überstürzte Konfiguration des Produkts am Ende nur, neue Funktionen in der Zukunft hinzuzufügen - und der Teufelskreis schließt sich. Aber hey: Die Deadline steht.
Eine Umgebung, in der sich Softwareingenieure:
nonstop mit Zeitdruck konfrontiert sehen,
nicht in der Lage sind, ihre Arbeit richtig zu leisten und
von einer Metrik abhängig sind, die nicht (vollständig) in ihrem Einflussbereich liegt,
ist ein zuverlässiger Weg zu Burnout und Mitarbeiterfluktuation.
Im Interesse unserer Entwicklungsteams und Unternehmen können wir es uns weder aktuell noch in Zukunft leisten, unsere wertvollsten Mitarbeiter zu vergraulen - insbesondere dann nicht, wenn das Endprodukt darunter leidet. Auch Softwareentwicklung ist ein Prozess und eine Kunstform. In diesem Zusammenhang auf eine maschinenähnliche Kadenz zu beharren, verhindert kreatives Denken und iteratives Vorgehen - und somit die Chance, die bestmögliche Lösung zu schaffen. Es kommt manchmal eben vor, dass Ansätze nicht funktionieren - dann ist es nötig, einen anderen Weg auszutesten. Das führt manchmal zu besseren Lösungen, die Mehrwert schaffen, auch wenn das ein wenig länger dauert. Was es braucht, ist Spielraum.
Vielleicht noch wichtiger ist jedoch, dass Produkt- und Development-Teams sowohl während des Entwicklungsprozesses als auch in Retrospektiven enger zusammenarbeiten, um positive Ergebnisse und kontinuierliche Verbesserungen zu erzielen. Mehr Kommunikation im Vorfeld kann auf lange Sicht viel Zeit sparen, weil so beide Teams die Möglichkeit bekommen, den Übergang von den funktionalen Anforderungen zur kodierten Realität zu meistern.
Und vergessen wir nicht die Grundprinzipien des "Blameless" Postmortem: Ohne gemeinsame Verantwortlichkeit sind Unternehmen nicht in der Lage, ein differenziertes Verständnis darüber zu entwickeln, was während eines bestimmten Sprints schiefgelaufen ist. In einer Kultur ohne Schuldzuweisung arbeiten beide Teams zusammen, um die Gründe zu identifizieren und die volle Komplexität des Geschehens zu erfassen.
Speed ist als wesentliche Metrik für den Erfolg von Entwicklungsteams ungeeignet und erzeugen ein grundlegend falsches Bild davon, wie Produkte entwickelt werden sollten. Der wahre Maßstab für den Erfolg ist eine Kombination aus dem geschäftlichen Wert - wie er von den Produktverantwortlichen in Zusammenarbeit mit dem Entwicklungsteam definiert wurde - und der Umsetzung dieses Wertes durch die Entwickler. (fm)
- Produkt- & Projektmanager
Ganz generell schätzen es Entwickler nicht so besonders, wenn ihnen jemand erklären will, wie sie ihren Job zu machen haben. Weil Produkt- und Projektmanager aber oft Entwickler-Teams leiten, passiert genau das. Das kann zu Unstimmigkeiten führen. <br /><br /> Dazu hat auch David Fox von devRant eine Meinung: "Letztendlich ist es in den meisten Fällen so, dass Produkt- und Projektmanager in irgendeiner Art und Weise die 'Besitzer' von Projekten und Prozessen sind, ohne dabei die täglichen Herausforderungen und Probleme der Softwareentwickler zu kennen." - Chefs
Genau wie die Produkt- und Projektmanager sind auch Development oder Engineering Manager dafür zuständig, Teams von Entwicklern zu führen und sicherzustellen, dass Projekte rechtzeitig und unter Budget fertiggestellt werden. <br /><br /> "In einigen Unternehmen können Situationen entstehen, in denen der Chef gleichzeitig Mitglied des Entwicklerteams ist. Insbesondere wenn der Chef vorher selbst Entwickler war und nach einer Beförderung zum Chef wird, ist Konfliktpotenzial gegeben", merkt Fox an. - Recruiter
Softwareentwickler müssen gar nicht selbst aktiv nach einem Job suchen, um von Recruitern und Headhuntern belästigt zu werden - dem Fachkräftemangel sei Dank. Es dürfte sehr schwer sein, einen Developer zu finden, der noch nicht in die Fänge der Recruiter geraten ist. <br /><br /> David Fox sieht insbesondere die Hartnäckigkeit der Recruiter als Problem: "Sie rufen an, sie e-mailen und sie lassen Dich einfach nicht in Ruhe - selbst dann, wenn Du gar keinen Job suchst. Und selbst wenn man eine Anstellung sucht, neigen viele Recruiter dazu, irrelevante Jobangebote zu machen oder Stellen zu empfehlen, deren Profil überhaupt nicht passt - etwa einen Job am anderen Ende des Landes, obwohl man gar nicht bereit ist, umzuziehen." - Dokumentation
Gibt es keine Dokumentation, beschweren sich die Softwareentwickler. Wenn es zuviel ist, beschweren sie sich und wenn sie die Dokumentation selbst erledigen müssen, auch. Sogar über die Art und Weise, wie andere Leute die Dokumentationsaufgabe bewältigen, beschweren sich die Entwickler. <br /><br /> An dieser Stelle seien sich auch endlich einmal alle Entwickler einig, wie Fox betont: "Softwareentwickler wollen eine ausführliche, gut geschriebene und akkurate Dokumentation - aber selber machen wollen sie es nicht." - Meetings
Meetings sind nicht nur für alle anderen ein Problem, sondern auch für Softwareentwickler. Insbesondere dann, wenn es sich um völlig unnötige, zeitraubende und stinklangweilige Zusammenkünfte handelt. Wie Fox erzählt, sind inzwischen auch Devotionalien mit der Aufschrift 'I survived another meeting that should have been an email' erhältlich. - Coworking Spaces
Mit dem Aufstieg der Agilität sind flache Hierarchien, Collaboration und Teamwork zum Alltag in Unternehmen geworden - insbesondere für Software-Development-Teams. Gerade die können ihre Arbeit in einem Großraumbüro aber meist nur schwer oder gar nicht bewältigen - sagen zumindest die Zahlen von devRant. <br /><br /> David Fox erklärt: "Es gibt einfach zuviel Ablenkung: die Kollegen unterhalten sich, Meetings werden verpasst, Telefonanrufe überhört. Es gibt auch eine Vielzahl an Beschwerden über den Kaffee im Büro und andere Annehmlichkeiten - oder eben das Gegenteil davon." - Kollegen
Selbsterklärend: Jeder hat wohl einen Kollegen oder eine Kollegin, den beziehungsweise die er ganz besonders schätzt. Nicht. <br /><br /> Im Fall der Softwareentwickler ist die Abneigung gegenüber Kollegen meist entweder in der mangelnden Qualität ihrer Arbeit oder einem völlig aus dem Leim gegangenen Ego begründet, gibt David Fox preis. - Vorstellungsgespräche
Wenn ein Softwareentwickler auf Jobsuche ist und zum Bewerbungsgespräch geladen wird, gibt es danach meist auch etwas zu meckern: <br /><br /> "Dumme Fragen oder die Lösung von völlig praxisfernen Aufgaben im Bewerbungsgespräch stoßen den Developern ebenso sauer auf, wie ein Gesprächspartner, der überhaupt nicht weiß, was ein Entwickler eigentlich genau macht", so Fox. - Fehler & Bugs
Softwareentwickler haben tagein, tagaus mit Fehlern und Bugs zu tun. Deswegen glaubt devRant-Gründer Fox, dass Entwickler in dieser Sache anders ticken: <br /><br /> "Die meisten anderen Probleme erfahren keine positive Auflösung, aber Bugs und Fehler sind behebbar und das fühlt sich gut an." - Quality Assurance
Die Quality Assurance (QA) - oder Qualitätssicherung - ist ein kritischer Teil der Softwareentwicklung. Dennoch bemängeln Softwareentwickler an QA-Experten häufig dieselben Dinge wie an Produkt- und Projektmanagern, so Fox. <br /><br /> "Die Qualitätssicherung bekommt das Produkt oder Projekt in die Hände, wenn die Entwickler es abgeschlossen haben. Deswegen verstehen sie oft nicht, welche Hürden und Workarounds die Entwickler im Entstehungsprozess bewältigen mussten. Offensichtlich kommt es auch regelmäßig vor, dass QA-Leute die Entwickler bitten, Bereiche nochmals zu überarbeiten, die sie auch selbst bewältigen könnten."
Dieser Beitrag basiert auf einem Artikel unserer US-Schwesterpublikation Infoworld.