Workflow + Kommunikation + Verantwortung = Spaß

Bevor wir starten, machen wir eine kleine Übung: Setzen Sie sich aufrecht hin ohne sich anzulehnen oder stehen Sie auf. Schließen Sie die Augen. Atmen Sie eine Minute lang über die Nase tief ein, und über den Mund aus. Spüren Sie dabei, wie sich Ihre Lungenflügel bis zum untersten Winkel mit Luft füllen und wie sich nach dem Ausatmen ein erleichtertes Gefühl einstellt.

Warum diese Übung? Sie kann jederzeit mehrmals am Tag wiederholt werden. Ich möchte mit ihr auf das lateinische Sprichwort aufmerksam machen: 'mens sana in corpore sano', zu deutsch 'ein gesunder Geist in einem gesunden Körper'. Die Atemübung soll für eine kurze Zeit den eigenen Körper in den Mittelpunkt stellen. Die meisten Menschen, die in der IT arbeiten, arbeiten im Sitzen, manche manchmal im Stehen an einem Stehpult. Die einseitige Haltung ist jedoch Gift für unseren Körper. Bewegung ist die einzige Alternative. Es reicht nicht früh morgens die Treppe in den fünften Stock zu nehmen, um dann den ganzen Tag vor dem Schreibtisch zu sitzen. Wie ich später noch ausführen werde, ist ein wichtiger Bestandteil unserer Arbeit die Kommunikation. Diese lässt sich ganz gut mit Bewegung verbinden.

Genauso achtsam, wie wir mit unserem Körper umgehen müssen, müssen wir gegenüber den Anforderungen umgehen, die täglich an uns gestellt werden. Es reicht schon lange nicht mehr aus, nur noch die Aufgaben als Software-Entwickler herunter zu programmieren, die an uns gestellt werden. Dafür sind sowohl die Aufgaben als auch die Systeme zu komplex geworden.

Die Atemübung und die durch sie gewonnene Achtsamkeit soll den Blick objektivieren und auf die Frage lenken, worum geht es eigentlich.

Wenn wir der Frage nach dem "worum geht es" nachgehen, dann können wir zunächst einmal den täglichen Workflow unter die Lupe nehmen, dem ein Software Entwickler jeden Tag unterliegt. Im wesentlichen sind das die folgenden fünf Schritte:

1. Task / Spezifikation
2. Analyse
3. Plan zur Umsetzung
4. Programmierung
5. Abgabe zum Test

Der Task oder die Spezifikation kommt rein und muss erst einmal analysiert werden. Was ist das Ziel? Ist es ausreichend definiert. Wenn nicht muss mit dem Auftraggeber gesprochen werden. Was ist betroffen? Ist dieser Umfang dem Auftraggeber bekannt? Wenn nein, müssen Abhängigkeiten von ihm kommuniziert werden. Kann die Aufgabe in Teilaufgaben aufgeteilt werden? Wenn ja, kann sie auf mehrere Entwickler aufgeteilt werden? Welche Auswirkung könnte das haben auf die Tests und den Fertigstellungstermin? Ist die Aufgabe eigentlich ein Projekt?

Ist die Analyse abgeschlossen, kann der Entwickler sich an den Plan zur Umsetzung machen. Dabei können sich neue Abhängigkeiten ergeben, welche erneut beurteilt werden müssen und gegebenenfalls abgesprochen werden müssen mit

• dem Auftraggeber,
• dem eigenen Abteilungsleiter zwecks der human resource Planung,
• den Team-Kollegen, falls eine neue Technologie eingeführt werden soll.

Auch beim Programmieren können Entscheidungen eine Kommunikation erforderlich machen. So kann die Überlegung, ob die neuen Features sinnvoll durch Unittests oder Integrationstests abgesichert werden können, z.B. für den DevOps Workflow interessant werden.

Last but not least muss bei der Übergabe zum Test kommuniziert werden, welche Testfälle auftreten. Ein 'siehe oben' ist nur dann erlaubt, wenn der konkrete Testfall a la test driven development auch oben schon definiert wurde. Ist der Task beim Testen wird mit dem Abteilungsleiter besprochen, was als nächstes ansteht. Vorrangig sollten aber die noch offenen Test-Tasks nachgefragt werden.

Insgesamt beinhaltet dieser Workflow sehr viel Kommunikation und ich habe noch nicht mal alle Kanäle aufgezählt. Wichtig dabei ist aber die Erkenntnis, dass es sich dabei um bidirektionale Kommunikation handelt. Sehr oft muss die Initiative vom Entwickler ausgehen. Er arbeitet direkt mit dem Code und ist damit derjenige, der die unumstößliche Wahrheit kennt. In einem früheren Vortrag / Artikel zum Thema Wissensmanagement bin ich schon detailliert auf Verantwortung und Kommunikation bei der Verbreitung von Wissen eingegangen.

Da ein großer Teil der Kommunikation vom Entwickler angestrengt wird, muss er sich auch um die Qualität kümmern. Karl-Erik Sveiby hat einmal gesagt: 'Trust is the bandwidth of communication' - auch das Zitat habe ich schon oft in Vorträgen / Artikeln zum Besten gegeben. Vertrauen kann aber nur entstehen, wenn wir in Vorleistung gehen. Dazu gehört, zuhören zu können, auch wenn die Initiative von uns ausgeht, den anderen zu akzeptieren, auch wenn die anderen so anders sind (siehe 'Katzen und Hunde' von Gunther Dueck). Schließlich müssen wir offen sein und offen auf die anderen zugehen und nicht immer auf das eigene Recht beharren.

Wie machen wir das in der Praxis? Ein Anhaltspunkt ist das Wissen und die Fertigkeit, richtig feedback geben zu können. Auch zu diesem Thema gab es einen Vortrag / Artikel von mir.

Aufgrund der Tatsache, dass wir als Entwickler direkt am Code arbeiten, und damit das ultimative finale Wissen besitzen, haben wir eine große Verantwortung. Zu den Verantwortungsbereichen, die ich in meinem Vortrag / Artikel zum Thema 'Verantwortung' aufgeführt habe, kommt nun noch ein neuer hinzu: die Verantwortung zur Kommunikation. Der Satz 'Das steht aber nicht im Task drin.' zählt somit nicht mehr und nimmt uns nicht aus der Verantwortung sondern in diese hinein. Wenn wir feststellen, dass Angaben in der Aufgabenbeschreibung nicht vollständig sind, haben wir automatisch mit diesem Wissen die Verantwortung, diese Lücke zu beseitigen oder beseitigen zu lassen. Aus der puren Reaktion und Beschwerde muss eine Aktion werden. Die Informationslücke muss nachvollziehbar beseitigt werden und wir sollten uns Gedanken machen, was wir selbst tun können, damit diese Lücken uns in Zukunft nicht in unserer Arbeit behindern.

Die restlichen Verantwortungsbereiche sind:

• Qualität
• Leistungsfähigkeit
• Sicherheit
• Flexibilität
• Ausfallsicherheit

Letztendlich produzieren wir Programm-Code. Wird er compiliert, entsteht das Programm. Aber, warum schreiben wir den Code, so wie wir ihn schreiben? Er soll von anderen (Entwicklern) und einem selbst wieder verstanden werden können. Das geschieht in erster Linie über

• die Benennung von Variablen, Methoden und Klassen / Objekten
• die Verwendung der Domain-Sprache (siehe meinen Vortrag / Artikel zum Thema 'Domain Driven Design') und das Vermeiden von kryptischen Abkürzungen
• das Einhalten von Namenskonventionen
• sinnvolle Unittests, die die Schnittstelle einer Klasse beschreiben

Ganz bewusst habe ich in der Aufzählung auf Kommentare und Dokumentation verzichtet!

Unterstützt wird der Entwickler dabei von seiner IDE und der Continuous Integration mit z.B. statischer Codeanalyse. Je besser der Entwickler diese Tools kennt, desto besser kann er sich darauf verlassen. Ein einfaches refactoring, z.B. ein besserer Name für eine Variable, sollte kein Problem sein.

Wie haben wir Entwickler mehr Spaß bei dem, was wir tun? Schließlich ist Spaß und Freude ein ganz erheblicher Motivationsfaktor und um bei der ganzheitlichen Betrachtung von der Einleitung zu bleiben: Spaß und Freude hält jung und gesund.

Entwickler probieren leidenschaftlich neue Technologien aus. Voraussetzung hierbei ist, die Zeit zu haben und die richtige Beurteilung der Technologie hinsichtlich des Einsatzes gemäß den Anforderungen. Auch der Aufwand sollte im Rahmen der Aufgabe bleiben. Das Erlernen und Anwenden von neuen Technologien sollte in den Alltag integriert werden, z.B. im Abteilungsmeeting. Wie man effektiv lernt habe ich schon in einem Vortrag / Artikel erläutert. Wurden neue Technologien umgesetzt, kann dies z.B. mit Perfomance Charts oder mittels einer Präsentation unter Kollegen gefeiert werden. Das Wissen um die neue Technik muss verbreitet werden.

Im Alltag bleibt wenig Zeit, vor allem wenn Entwickler immer mehr unter Zeitdruck leiden. Entscheidend ist, dass jeder einzelne lernt, mit diesem Druck umzugehen, ohne dass es in Resignation oder schlimmeren endet. Es gibt wenig Quellen mit praktikablen und einfach anzuwendenden Ratschlägen. Anfangen kann man damit, die Aufgaben in kleinerer Einheiten zu zerlegen und diese dann vernünftig auf die Releases aufzuteilen. Wichtig ist auch, dass das Wissen auf mehrere Köpfe verteilt wird, so dass der einzelne nicht fix an bestimmte Aufgaben gebunden ist. Am Ende muss der Entwickler als Individuum lernen mit dem Druck umzugehen und Methoden entwicklen, die ihn entlasten. Eine Methode für die eigene Arbeits-Organisation ist 'Getting Things Done'.

"Erfolg macht Spaß" lässt sich nur leben, wenn der Erfolg für den einzelnen greifbar ist. Das ist weniger der Fall beim Erreichen von Unternehmenszielen, besser schon bei der Retrospektive eines abgeschlossenen Projekts. Was war gut? Was war schlecht? Wenn man sich aus den Antworten auf die letztere Frage nur zwei Themen heraussucht und versucht, diese beim nächsten Projekt besser zu machen, hat man schon ein besseres Gefühl für das nächste Projekt.

Freude am Arbeiten stellt sich auch dann ein, wenn die Arbeit geschätzt wird. Wichtig hierbei ist gar nicht einmal die Wertschätzung von oben, entscheidender weil authentischer und direkter ist die Wertschätzung unter Kollegen und Teammitgliedern. Das bedeutet aber, dass jeder gefragt ist, die Arbeit des anderen positiv zu sehen. Der Ton macht die Musik und so ist ein einfaches Danke viel wert und verbessert das Klima. Jeder kann auf sich stolz sein, wenn er bei der Abschlusspräsentation den Teil in der Software wieder erkennt, an dem er mit gearbeitet hat.

Letztens in einem Tweet:

You want to stay relevant as a software developer for the next 10 years?

These are 3 major things you should focus on:

• GraphQL
• Web Assembly
• Web Components

Die Antwort auf diesen Tweet sah dann folgendermaßen aus:

You want to stay relevant as a software developer for the next 10 years?

These are 3 major things you should focus on:

• Empathy
• Cognitive diversity
• Self care