Kolumne

DevOps Stories: Verweile doch, es ist so schön: Warum es wichtig ist, sich mit Developer-Happiness zu beschäftigen

Konstantin Diener

© S&S_Media

Lukas besucht seit ungefähr zwei Jahren eine ganze Reihe von Meet-ups in der Stadt und ist sehr begeistert davon. Es ist ihm gelungen, eines seiner liebsten Meet-ups zu sich in die Firma zu holen. Auch sein Freund Arne hat die Gelegenheit genutzt, endlich mal bei Lukas im Büro vorbeizuschauen. Nach dem offiziellen Teil hat Lukas angeboten, interessierte Teilnehmer durch die Räumlichkeiten der Firma zu führen, und eine Handvoll hat seine Einladung angenommen. Sie sind sehr interessiert und löchern ihn mit Fragen.

  • Arne: „Du hast mir ja schon öfter von euren physischen Taskboards und euren Räumen erzählt, Lukas, aber das alles mal in der Realität zu sehen, ist schon was anderes. Wie viele Leute arbeiten in einem solchen Raum? Gehören sie zu verschiedenen Teams?“
  • Lukas: „Die Räume sind so ausgelegt, dass hier maximal neun Personen sinnvoll arbeiten können. Jedes Team hat seinen eigenen Raum. Wenn mehrere Teams in einem Raum sind, hat sich gezeigt, dass sie sich doch massiv gegenseitig stören.“
  • Besucher 1: „Davon kann ich im Großraumbüro nur träumen. Vor allem die großen höhenverstellbaren Schreibtische mit mehreren Monitoren gefallen mir gut. Auf den Tischen befinden sich sehr viele Post-its und private Gegenstände. Clean Desk gibt’s bei euch vermutlich nicht, oder?“
  • Lukas: „Wir haben mal kurz damit experimentiert, es hat bei uns aber nicht funktioniert. Seitdem hat wieder jeder seinen individuellen Tisch.“
  • Arne: „Haha, das Ding hier ist aber offiziell, oder? Auf dieser Pappkrone ist zumindest ein Firmenlogo drauf – und das von einem Open-Source-Projekt. Was soll das?“
  • Lukas: „Ach, das! Die Kollegen in diesem Team sind sehr aktiv in dem abgebildeten Open-Source-Projekt – und Norman ist aktuell der Commit-König.“
  • Besucherin: „Wie cool, ihr arbeitet an Open-Source-Projekten? Ich darf noch nicht einmal drüber sprechen, an welchem Projekt für welchen Kunden ich arbeite.“
  • Besucher 2: „Lukas, kannst du mir erklären, was das hier ist? Darf ich mir das genauer ansehen?“
  • Lukas: „Ja klar, schaut euch nur um. Das ist die Product Vision des Produkts, an dem das Team arbeitet. Sie haben sie zusammen mit ihrem Product Owner erarbeitet und sie gut sichtbar hier aufgehängt, damit sie sie bei allen Sprint Plannings etc. im Blick haben.“
  • Besucherin: „Cool! Und kannst du mir auch sagen, wofür die Ampeln hier auf dem Flipchart sind?“
  • Lukas: „Wir alle machen uns regelmäßig Gedanken über die Qualität unserer Codebase etc. und nehmen dafür diese Flipcharts.“
  • Besucher: „Die Werte sind in den letzten sechs Monaten viel besser geworden. Was ist da passiert?“
  • Lukas: „Das Team hat in den letzten Monaten stark in die Qualität des Codes investiert. Sie haben auch ein kommerzielles Tool angeschafft, das ihnen sehr dabei geholfen hat.“
  • Arne: „Wir sind hier aber nicht in deinem Teamraum, oder?“
  • Lukas: „Nein, mein Büro ist zwei Räume weiter, wieso?“
  • Arne: „Mich wundert nur, dass du dich hier so gut auskennst.“
  • Lukas: „Wir haben regelmäßige Formate zum Informationsaustausch, deswegen weiß ich das.“
  • Besucher 1: „Verwenden jetzt alle Teams das kommerzielle Tool, von dem du sprachst?“
  • Lukas: „Das ist jedem Team selbst überlassen. Wir haben hier in unseren Teams die freie Wahl, welche Werkzeuge, Sprachen etc. wir verwenden.“
Abb. 1: Lukas führt die Meet-up-Teilnehmer durch die Firma

Abb. 1: Lukas führt die Meet-up-Teilnehmer durch die Firma

Software-Craftsmen brauchen einen adäquaten Arbeitsplatz und die richtigen Werkzeuge

Die Meet-up-Teilnehmer sind sehr begeistert von dem, was sie in Lukas’ Firma sehen – vor allem, weil es in den Firmen, in denen sie arbeiten, offenbar anders aussieht. Dass Softwareentwickler keine optimalen Arbeitsbedingungen vorfinden, ist heute leider noch die Regel. Oft werden die Arbeitsräume von Mitarbeitern gestaltet, die selbst nie Software entwickelt haben. Sie können sich schlecht vorstellen, dass es für die Softwareentwicklung z. B. durchaus hilfreich ist, mit mehreren Bildschirmen zu arbeiten, sondern sehen nur die hohen Kosten. Stellen die Softwareentwickler nur eine Berufsgruppe unter mehreren (z. B. Sachbearbeiter, Handwerker, …) in der jeweiligen Firma dar, kommt es außerdem nicht selten vor, dass für alle Mitarbeiter eine einheitliche Hardwareplattform angeschafft wird, die für Entwickler in der Regel stark unterdimensioniert ist. Den für die Arbeitsplatzplanung Verantwortlichen ist dabei nicht klar, dass die Produktivitätseinbußen in der Softwareentwicklung die Einsparungen um ein Vielfaches übersteigen – unter anderem, weil ein Entwickler deutlich teurer ist als Hardware.

Dieser Effekt lässt sich aber nicht nur im Zusammenhang mit dem Bedarf der Entwickler beobachten. In vielen Firmen ist es aus Kostengründen meist schwierig, einen höhenverstellbaren Schreibtisch und einen ergonomischen Stuhl zu bekommen. Oft haben die Mitarbeiter aus Kostengründen gar keinen festen Arbeitsplatz mehr, sondern müssen sich jeden Morgen im Reise-nach-Jerusalem-Modus einen neuen suchen. Tom de Marco und Timothy Lister haben der Arbeitsplatzgestaltung in ihrem Buch „Peopleware“ [1] gleich mehrere Kapitel gewidmet.

DevOpsCon Istio Cheat Sheet

Free: BRAND NEW DevOps Istio Cheat Sheet

Ever felt like service mesh chaos is taking over? As a follow-up to our previous cheat sheet featuring the most important commands and functions, DevOpsCon speaker Michael Hofmann has put together the 8 best practices you should keep in mind when using Istio.

Auch die großen physischen Taskboards werden z. T. mit der Begründung, die Computer seien ja sowieso schon da, durch elektronische Pendants ersetzt, und die unzureichende Anzahl von Besprechungsräumen wird damit begründet, dass man seine Meetings auch in der Kantine abhalten könne.

Softwareentwickler möchten Wertschätzung erfahren und nicht als reiner Kostenfaktor gesehen werden

All diese Kosteneinsparungen sind sehr kurzsichtig gedacht. Die Mitarbeiter von heute – und Softwareentwickler im Besonderen – möchten nicht wie Ressourcen oder Kostenfaktoren behandelt werden. Sie wünschen sich Wertschätzung für ihre Arbeit und diese Wertschätzung beginnt bei der vernünftigen Ausrüstung ihres Arbeitsplatzes mit Hard- und Software. Auch wenn diese Ausrüstung Geld kostet, wie z. B. das kommerzielle Tool, von dem Lukas erzählt.
Dafür ist auch das Verständnis notwendig, dass sich Softwareentwicklung und Industriearbeit in ihren Wesen unterscheiden, erstere nämlich eine kreative Tätigkeit ist, die Ruhe und einen stabilen Arbeitsraum verlangt (keine Großraumbüros, Shared Desks oder Meetings in der Kantine).

Der Wunsch nach Wertschätzung geht aber über die Gestaltung des Arbeitsplatzes hinaus. In einem Blogpost sind die weiteren Faktoren sehr schön vermittelt. Der Post orientiert sich dabei an den Elementen Autonomy, Mastery und Purpose aus dem Buch „Drive“ von Daniel Pink [2].

Autonomy bedeutet für Softwareentwickler die Freiheit, ihren Job so zu tun, wie sie es für richtig halten. Dazu gehört – wie in Lukas’ Fall – auch die Auswahl der passenden Technologien. Außerdem möchten sie an der Gestaltung des Produkts beteiligt sein und es nicht einfach nur umsetzen. Das Team, in dessen Raum die Meet-up-Teilnehmer mit Lukas stehen, hat die Vision für ihr Produkt gemeinsam mit ihrem Product Owner erarbeitet, sie wurde nicht vom PO vorgegeben.
Lebenslanges Lernen gehört zum Job des Softwareentwicklers wie zu kaum einem anderen. Entwickler möchten die Rahmenbedingungen bekommen, um in dem, was sie tun, immer besser zu werden (Mastery). Dafür erwarten sie Freiräume und entsprechendes Coaching. Außerdem möchten sie gerne zeigen, was sie können und ihre Fähigkeiten nicht im stillen Kämmerlein verstecken müssen. Die Meet-up-Teilnehmer sind sehr begeistert, dass das Team an Open-Source-Projekten arbeiten kann, was die intensivste Form von Zeigen-was-man-kann ist.

Den Softwareentwicklern ist dabei aber klar, dass Technologie kein Selbstzweck ist. Sie möchten den Sinn und das Warum hinter ihrer Arbeit kennen (Purpose). Auch dazu trägt z. B. das gemeinsame Erarbeiten einer Product Vision bei. Auch dieser Punkt hat viel mit Wertschätzung zu tun: Softwareentwicklung, Business, Design etc. sind hier Partner auf Augenhöhe, die Entwickler keine Coding Monkeys.

Es war für Entwickler noch nie so einfach, die Firma zu wechseln, wenn es ihnen nicht gefällt

Viele der genannten Aspekte treffen auch auf andere Berufsgruppen (wie z. B. Designer) zu. Entwickler haben den Vorteil, dass sie auf dem Arbeitsmarkt sehr begehrt sind und es nie zuvor so einfach war, einen neuen Job zu finden, wenn der aktuelle nicht die passenden Rahmenbedingungen bietet. Aus diesem Grund tun die Firmen gut daran, auf ihre Developer-Happiness zu achten. Allein schon deshalb, weil eine Neueinstellung um ein Vielfaches teurer ist, als einen bestehenden Mitarbeiter zu halten.

Abb. 2: Karten des Squad Health Check Models

Abb. 2: Karten des Squad Health Check Models

Die Developer-Happiness lässt sich z.B. mit dem Spotify Squad Health Check Model regelmäßig überprüfen. Dabei entscheidet das Team für verschiedene Dimensionen, wie ihr Ampelstatus gerade ist (Abb. 2) und ob sich die Situation gerade verbessert, gleichbleibt oder verschlechtert. Das Team aus Lukas’ Firma hat die Ergebnisse auf Flipcharts visualisiert, um Veränderungen über einen längeren Zeitraum zu erkennen (Abb. 3).

Abb. 3: Visualisierung der Health-Check-Ergebnisse

Abb. 3: Visualisierung der Health-Check-Ergebnisse

Die Meet-up-Teilnehmer haben sich fest vorgenommen, einige der Impulse aus Lukas’ Firma mit in ihre eigene Organisation zu nehmen. Lukas hat ihnen außerdem den Tipp gegeben, dass es helfen könnte, sich die Personalabteilung als Verbündeten zu holen – auch dort ist man an einer attraktiven Außenwirkung und einer möglichst niedrigen Fluktuation interessiert.

Geschrieben von
Konstantin Diener
Konstantin Diener
Konstantin Diener ist CTO bei cosee. Sein aktueller Interessenschwerpunkt liegt auf selbstorganisierten Teams, agiler Unternehmensführung, Management 3.0 und agiler Produktentwicklung. Daneben entwickelt er noch leidenschaftlich gerne selbst Software. Twitter: @onkelkodi
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
4000
  Subscribe  
Benachrichtige mich zu: