Energized Work: Oder wie agile Arbeitsweise Devs vor sich selbst schützt
Fallstricke der Softwareentwicklung
Software zu entwickeln ist, als würde man ein überdimensionales Sudoku lösen. Man muss ständig die Rahmenbedingungen und den Rest des Systems im Hinterkopf jonglieren, während man Ideen in Code verwandelt und möglichst reibungsfrei in einer Struktur arrangiert. Im Idealfall findet man eine elegante Lösung und alle Teile greifen perfekt ineinander. Setzt man aber ein Element an die falsche Position, passt am Ende eventuell nichts mehr zusammen und die Struktur kollabiert.
Diese Aufgabe erfordert viel Konzentration. Uns kommt hier der viel zitierte “Flow” zugute, der eintritt, wenn man sich regelrecht in seiner Arbeit verliert, um ein kniffliges Problem zu lösen. Man fokussiert sich teilweise stundenlang auf die Aufgabe und blendet alles andere komplett aus. Findet man dann schließlich eine Lösung, fühlt sich das großartig an. Man ist stolz, fühlt sich unheimlich clever, ist aber auch erleichtert, dass das Problem endlich überwunden ist. Dieses Gefühl macht in meinen Augen einen großen Reiz bei der Arbeit als Softwareentwickler*in aus.
Auf diese Weise zu arbeiten, hat aber auch Schattenseiten. Die Erste ist eine gewisse Überheblichkeit. Durch das Erfolgserlebnis neigen wir dazu, uns selbst zu über- und Probleme zu unterschätzen. Voller Optimismus versprechen wir dann unrealistische Dinge und arbeiten lieber aus Stolz heraus ein Wochenende durch, als zuzugeben, dass wir uns geirrt haben. Sowieso schon weniger prestigeträchtige Aufgaben, wie Tests oder Refactoring, drohen unter diesem selbst gemachten Druck komplett unter den Tisch zu fallen.
Diese mangelnde Qualitätssicherung sorgt dafür, dass Probleme in eigentlich schon fertigem Code uns später wieder einholen. Darunter leiden Nerven und Effizienz. Die zweite große Gefahr sind die Scheuklappen, die wir beim Fokus auf die Aufgabe aufsetzen. Wir verlieren den Blick auf das große Ganze des Projekts und achten weniger auf unsere eigenen physischen und psychischen Bedürfnisse.
Dieses Verhalten führt schnell zu einer Negativspirale. Wir erzeugen eine unrealistische Erwartungshaltung und liefern auf persönliche Kosten schlechte, kurzsichtige Ergebnisse ab. Diese häufen sich und erzeugen mittelfristig Frust bei allen Beteiligten. Dazu gewöhnen sich Projektverantwortliche daran, dass Dinge “mal eben” gemacht werden und erwarten es von nun an auch.
Teilweise wird dieses unprofessionelle und ungesunde Verhalten sogar bewusst gefördert, indem es durch Lob oder Unworte, wie “Rockstar Developer” idealisiert wird. Unerfahrenere Teammitglieder lernen, es wäre normal, sich aufzuopfern und Aufgaben um jeden Preis vermeintlich erfolgreich abzuschließen. Dreht sich diese Spirale lange genug, steht am Ende ein unwartbares Projekt, das eine Menge Geld gekostet, technische Schulden angehäuft und alle Entwickler*innen ausgebrannt oder vertrieben hat.
Agile Projektorganisation als Ausweg
Wie kann Agilit ät hier helfen? In erster Linie geben agile Methoden Projekten Struktur. Eine gute Planung sorgt dafür, dass wir ein realistisches Bild davon haben, was machbar ist und was nicht. Ein eingespieltes Team weiß genau, was es in welcher Zeit schaffen kann. Voraussetzung dafür ist natürlich ein gut gepflegtes Backlog. In so einem Team ist es schlicht einfacher, begründet “Nein” zu unrealistischen Deadlines zu sagen.
Slackzeit schafft den Raum, um den Code am Ende des Sprints immer wieder ein bisschen besser zu machen und so die technischen Schulden in Schach zu halten. So können Teams durchatmen, anstatt von Sprint zu Sprint zu hetzen.
Neben der Planung gibt es feste Werte und Methoden, auf die sich das Team gemeinsam geeinigt hat. Legt man fest, dass nur sauberer und getesteter Code in das Produkt aufgenommen wird, gibt es keine Feierabende mehr, an denen mir plötzlich ein systemkritischer Bug auffällt, den ich schnell nochmal patche. Außerdem teilt sich das Team die Verantwortung für den Code. Entsprechend gibt es keine individuellen Schuldzuweisungen, wenn Probleme auftauchen – das reduziert den Druck und trägt zu einer kollaborativen Arbeit bei.
Das wichtigste Werkzeug ist in meinen Augen, dass Entwickler*innen immer nur genau eine Aufgabe gleichzeitig haben. Und diese ist erst abgeschlossen, wenn sie komplett fertiggestellt ist. Es gibt nicht noch diesen einen Bug oder jenes dringende Problem. Dieser Fokus schafft den Raum, um eine Aufgabe sorgfältig erledigen zu können, anstatt sie verbissen zu bezwingen.
All diese Dinge kann man natürlich auch umsetzen, ohne explizit agile Methoden einzusetzen. Es braucht dann nur ungleich mehr Disziplin und Erklärungsbedarf, als wenn man sich gemeinsam in einem Alignment auf ein Vorgehen einigt und darauf berufen kann.
Aber nicht nur die Projektorganisation profitiert vom agilen Vorgehen. Auch für die eigentliche Entwicklungsarbeit gibt es unterstützende Werkzeuge, die sich stark am Extreme Programming orientieren. Um Qualität sicherzustellen und Flüchtigkeitsfehler zu vermeiden, lassen sich Test Driven Development und Continuous Deployment einsetzen. Sie sorgen dafür, dass ich gefahrlos auch an unbekanntem Code arbeiten und diesen selbstständig deployen kann. Wenn doch Fehler passieren, dann immer, weil das System nicht wasserdicht gebaut war und nicht, weil jemand Einzelnes das falsche Kommando eingegeben hat.
Sowieso sollten wir eher selten alleine arbeiten, sondern als Pair oder Mob. Während eine Partei sich dabei um die Details kümmert, kann die andere das große Ganze im Auge behalten. So kann man einen großen Teil der Komplexität aus dem eigenen Kopf kurzzeitig auslagern. Zusätzlich transferieren wir automatisch Wissen und vermeiden Abhängigkeiten von Einzelnen. Wir achten dabei außerdem aufeinander und sorgen dafür, dass sich niemand zu sehr in Problemen verbeißt. Es ist viel einfacher, zusammen mit Kolleg*innen zu beschließen, Feierabend zu machen und am nächsten Tag weiterzuarbeiten.
Agilität verspricht, dass Projekte langfristig und nachhaltig entwickelt werden können, ohne mit der Zeit an Entwicklungsgeschwindigkeit zu verlieren. Ich denke, dass der wichtigste Aspekt hierfür zufriedene Entwickler*innen sind. Dummerweise neigen wir allerdings dazu, nicht sehr gut auf uns selbst aufzupassen.
Die genannten agilen Methoden haben alle vordergründig zum Ziel, die Technik oder den Prozess zu verbessern und damit die Effizienz zu steigern. Wichtiger ist aber, dass sie für ausgeglichene Teammitglieder sorgen, die so arbeiten können, dass es sie nicht auslaugt oder frustriert.
„We work at a pace that allows us to do our best, most productive work indefinitely.”
Ich habe so den Raum, um Aufgaben in Ruhe zu erledigen. Mein Privatleben leidet nicht unter meinen Überstunden oder schlechter Laune. Ich habe ein Team, in dem ich mich sicher und wertgeschätzt fühle. Und ich habe Lust auf meine Arbeit. James Shore beschreibt diesen Zustand als “Energized Work” und die einzige Möglichkeit, Projekte langfristig erfolgreich durchzuführen. Ich denke, er hat Recht damit.
Er hat's geschrieben
Entwickle mit Ole und mindmatters bessere Produkte!
Ole
Software-Projekte werden oft wie Bausätze behandelt, die dann gelingen, wenn man die passenden Bauteile korrekt zusammensetzt. In der Realität entfalten sie aber meist eine unerwartete Komplexität. Diese Komplexität mit einer Balance aus Logik, Handwerkszeug, Kreativität und Kollaboration zu meistern, bereitet mir in der täglichen Arbeit Freude. Bei mindmatters habe ich endlich einen Ort entdeckt, an dem diese Sichtweise als unverzichtbar für erfolgreiche und erfüllende Arbeit geteilt wird!