Eine neue Perspektive auf Arbeitsweisen

Einleitung

Es mag überraschen, dass auf einer Konferenz, die bis zum Rand mit spannenden Tech-Ankündigungen und Vorführungen neuer Tools gefüllt war, die für mich einprägsamsten Vorträge größtenteils keinerlei Bezug zum eigentlichen Programmieren hatten.

Tatsächlich ist es so: Wenn man das Vue-Ökosystem sehr genau verfolgt und jede Andeutung einer neuen Ankündigung wie den heißesten Klatsch der Stadt behandelt, sind die meisten der vorgestellten Themen kaum noch eine Überraschung – so spannend sie auch sein mögen.

Am anderen Ende des Spektrums finden sich diese weniger technischen Vorträge, bei denen es mehr um die richtige Einstellung geht, mit der man seine täglichen Herausforderungen angehen sollte, und weniger um die technischen Details der Umsetzung, die man beim Programmieren anwenden könnte.

Diese Vorträge plädieren dafür, einen Schritt zurückzutreten und über das „Was“ und „Warum“ des eigenen Tuns nachzudenken, bevor man seine gesamte Aufmerksamkeit auf das „Wie“ richtet. Das sind genau die Vorträge, die man – wenn man so ist wie ich – wahrscheinlich überspringt, wenn man die Aufzeichnungen einer Konferenz durchstöbert.

Die Präsentationen, die mir am meisten im Gedächtnis geblieben sind, vermitteln weitgehend dieselbe Botschaft, die sich meiner Meinung nach so zusammenfassen lässt: Hör auf, Dinge zu überkonstruieren, und konzentriere dich auf das, was wirklich zählt.

Die Gespräche

Wie der Blick auf die kleinen Dinge die Softwareentwicklung grundlegend verändert

Im ersten Vortrag der dreitägigen Konferenz legte Sander Hoogendoorn gleich mit voller Kraft los, bereit, jeden wachzurütteln, der es nötig hatte. In seinem äußerst energiegeladenen Vortrag ging es darum, dass sich die Welt nicht schnell genug weiterentwickelt, um mit den technologischen Fortschritten Schritt zu halten. Er wies darauf hin, dass sich die Welt der Softwareentwicklung zwar seit 2001 grundlegend verändert hat, die Branche aber immer noch an den Prinzipien des Agilen Manifests festhält, als wären sie Gesetz. Er weist besonders darauf hin, dass der agile Prozess es uns nicht ermöglicht, Mehrwert in derselben Geschwindigkeit zu liefern, wie es moderne Werkzeuge ermöglichen.

Die meisten Unternehmen befolgen Scrum- oder Kanban-Prozesse bis ins Detail, weil sie davon ausgehen, dass diese richtig sind, und nicht, weil sie am besten zu ihren jeweiligen Umständen passen. Infolgedessen sind ihre Prozesse wie Stand-ups, Retrospektiven usw. zu Ritualen geworden, die nicht unbedingt einen Mehrwert bieten.

Die Technologie schreitet exponentiell voran, doch unsere Prozesse halten mit dieser Geschwindigkeit nicht unbedingt Schritt. Angesichts der rasanten technologischen Entwicklung der letzten Jahre und der deutlich gestiegenen Zugänglichkeit ist jeder Markt anfällig dafür, jederzeit von jedem disruptiert zu werden – so wie der Hotelmarkt durch Airbnb, der Taximarkt durch Uber und der Bankensektor durch N26 und ähnliche Anbieter disruptiert wurden. Diese Unternehmen tun vielleicht dasselbe wie wir, aber schneller, effizienter und kostengünstiger. Deshalb müssen wir noch schneller handeln, um nicht den Anschluss zu verlieren. Wir müssen agiler sein als „Agile“.

Laut Sander müssen wir dazu Folgendes tun:

Kleine Funktionen bereitstellen

Als Entwickler ist unsere Arbeit – wenn wir überhaupt sinnvolle Arbeit leisten – „chaotisch“. Das bedeutet, dass wir nicht versuchen können, die Lösung und den Weg dorthin linear vorherzusagen. Die Dinge ändern sich, und wir müssen umdenken und auf unsere Umgebung reagieren. Es gibt keinen vorgegebenen Satz von Lösungen, aus dem wir wählen können. Das Einzige, was wir tun können, ist, einen kleinen Schritt zu machen, abzuwarten, was passiert, und dann zu entscheiden, wie der nächste Schritt aussehen soll.

Um Dave Snowden zu zitieren:

„In einem chaotischen Umfeld wäre die Suche nach den richtigen Antworten sinnlos: Die Zusammenhänge zwischen Ursache und Wirkung lassen sich nicht bestimmen, da sie sich ständig verändern und es keine überschaubaren Muster gibt, sondern nur Turbulenzen. Dies ist der Bereich des Unbekannten. Der chaotische Bereich ist für Führungskräfte fast immer der beste Ort, um Innovationen voranzutreiben.“

Angesichts dieser Unsicherheit sollten wir uns lieber darauf konzentrieren, kontinuierlich kleine Schritte zu machen, anstatt selten große Projekte durchzuführen.

„Nachdem wir 50 Jahre Projekte alles falsch gemacht haben, sollten wir endlich aufhören sie durchzuführen“.

Noch kürzere Arbeitszyklen 

Anstatt zwei- oder dreiwöchige Sprints durchzuführen, sollten wir einen kontinuierlichen Arbeitsfluss anstreben. Dies können wir erreichen, indem wir Rituale aus unseren Prozessen streichen, kleinere Teams mit kleineren Zielen einsetzen und automatisieren, wo immer es möglich ist. Je mehr man automatisiert, desto schneller kann man in die Produktion übergehen.

Laut Sanders bedeutet „Agilität“ heutzutage, die Rituale aus SCRUM zu übernehmen, anstatt dessen Ideal der kontinuierlichen Wertschöpfung und der Verbesserung bei jeder Iteration zu verfolgen. Würden wir diesem Prinzip folgen, wären wir theoretisch dafür gerüstet, mit dieser sich ständig verändernden Welt umzugehen. Das Ziel war nie, dass eine Iteration alle paar Wochen stattfindet, sondern dass sie so schnell wie möglich abläuft.

Wir sollten danach streben, die für uns optimalen Prozesse zu finden, die nicht unbedingt aus Retros, Kick-offs oder anderen „Zeremonien“ bestehen müssen. Der Prozess könnte so einfach sein, wie die wichtigsten Aufgaben zu identifizieren und sie einfach auf einem Kanban-Board von links nach rechts zu verschieben. Je schneller man diese Bewegung ausführen kann, desto agiler ist man.

Bildet kleine Teams

Wir sollten uns um kleinere, selbstorganisierte und autonome Teams bemühen. Kommunikation ist schwierig, und um dem entgegenzuwirken, schaffen wir am Ende zu viele Besprechungen und Rituale. Bei Maßnahmen wie ganztägigen Refinement-Sitzungen beschäftigt man letztendlich eine große Gruppe, die nicht unbedingt dabei sein muss. Bei kleineren Teams gibt es hingegen weniger Kommunikationskanäle.

• Anstatt mehr Kommunikation anzustreben, sollte man sich um eine bessere Zusammenarbeit bemühen.
• Und anstatt jeden Punkt mit dem gesamten Team zu besprechen, sollten wir einen Punkt mit einem kleinen Team besprechen.
• In kleineren Teams wird in der Regel jedes Mitglied dazu angeregt, selbstständig zu denken und ein Gefühl der Eigenverantwortung und Autonomie zu entwickeln.
• Indem wir bürokratische Teamzusammensetzungen und Prozesse beseitigen, können wir unsere Aufmerksamkeit stattdessen auf den Kunden richten.

Mit Microservices und Serverless noch kleinere Komponenten erstellen

Sander geht darauf nicht näher ein, aber der Titel ist sehr eindeutig.

Stattdessen fasst er den Rest des Vortrags wie folgt zusammen:

• Denkt selbstständig, anstatt einfach nur ein anderes Modell zu kopieren, da dessen Wirksamkeit von Fall zu Fall unterschiedlich ist.
• Haltet die Dinge klein und einfach.
• Hört auf, Projekte durchzuführen.
• Hört nie auf zu lernen, gebt euch nicht mit der „richtigen Vorgehensweise“ zufrieden.

But, you are not Facebook

Viele Entwickler, die auf Konferenzen Vorträge halten, bemühen sich etwas zu sehr, ihre Präsentationen mit Humor zu würzen, um die Aufmerksamkeit des Publikums zu halten. Kitze schafft es jedoch, ebenso unterhaltsam wie aufschlussreich zu sein, während er uns einer Sünde bezichtigt, der die meisten von uns schuldig sind: Over-Engineering.

In diesem Vortrag beleuchtet Kitze die Tendenz von Entwicklern, das Rad jedes Mal neu zu erfinden, wenn sie bei der Webentwicklung auf ein gängiges Problem stoßen.

„Wie viele von euch haben schon einmal eigene Button-Komponenten geschrieben?“, fragt er, während ich (und der Großteil des Publikums) verlegen die Hand heben.

Egal, wie oft wir wiederholen, dass „voreilige Optimierung die Wurzel allen Übels ist“ – die meisten von uns machen sich im Alltag dennoch daran.

Anstatt uns darauf zu konzentrieren, unseren Kunden einen Mehrwert zu bieten, verwenden wir unsere Zeit und Energie darauf, Umgehungslösungen für Probleme zu entwickeln, die vielleicht gar nicht existieren.

Während wir darauf bedacht sind, vor unserer ersten Veröffentlichung absolut jeden Aspekt abzudecken (als könnten wir das später nicht einfach bei Bedarf iterativ nachbessern!), wagen andere vielleicht den Sprung und sind als Erste auf dem Markt, indem sie sich auf das konzentrieren, was den Kunden tatsächlich wichtig ist.

Während wir Überstunden machten, um Vuex so umzuschreiben, dass es den imaginären Bedürfnissen unseres Unternehmens entsprach, hatten andere bereits eine Nutzerbasis aufgebaut und arbeiteten aktiv daran, das Produkt auf der Grundlage von Nutzer-Feedback weiterzuentwickeln und zu verbessern.

„Aber Kitze! Facebook musste sein eigenes State-Management-System entwickeln, da die Datenpakete klein genug sein mussten für Leute mit einem Nokia 3310 und einer 2G-Verbindung!“

Und darauf antworten wir alle: „BUT YOU’RE NOT FACEBOOK!“

Zuerst das Team

In diesem Vortrag stellt Tim Benniks sein „Team First“-Konzept vor, mit dem sich bei Großprojekten Erfolg erzielen lässt, indem man den Menschen hinter den Projekten in den Mittelpunkt stellt.

„Team First“ basiert auf dem Grundsatz, dass die Entwicklung guter Technik in einem Umfeld mit hohem Druck direkt von einem gut organisierten Team abhängt.

Tim erklärt, dass Probleme wie Druck seitens der Kunden, kulturelle Unterschiede sowie ein Mangel an Anerkennung und Autonomie letztendlich Stress bei den Teammitgliedern verursachen und somit zu Ergebnissen von geringer Qualität führen. Das Team als Ganzes muss sich mit diesen Problemen auseinandersetzen, bevor auch nur eine einzige Zeile Code geschrieben wird.

So können Sie diese Probleme je nach Ihrer Rolle angehen:

Führungskraft

Vermitteln Sie dem Team das Gefühl, Verantwortung für seine Arbeit zu tragen, indem Sie Vertrauen, Überblick und persönliche Weiterentwicklung bieten.

• Vertrauen 
  • Das Vertrauen innerhalb des Teams muss die Grundlage seiner Kultur bilden.
  • Geben Sie den Mitarbeitern die Freiheit, Verantwortung zu übernehmen.
  • Geben Sie Orientierung, aber üben Sie keine Mikromanagement aus.
  • Lassen Sie die Mitarbeiter ihre Zeit selbst einteilen.
• Überblick 
  • Vermitteln Sie jedem Teammitglied Kenntnisse über alle Fachbereiche.
  • Fragen Sie die Mitarbeiter, was sie wollen, und lenken Sie sie auf die Bedürfnisse der Gemeinschaft hin.
  • Erklären Sie das Prinzip von „harter Arbeit und Ruhm“ und sprechen Sie Anerkennung aus, wenn sie verdient ist.
• Entwicklung: 
  • Lassen Sie die Mitarbeiter sich für bestimmte Themen einsetzen.
  • Bringen Sie die Mitarbeiter direkt in Kontakt mit dem Kunden.
  • Verfolgen Sie einen „Bottom-up“-Ansatz.

Entwickler

• Lerne dich selbst kennen (deine Grenzen und deine Ziele).
• Betrachte das große Ganze.
• Erreiche Selbstständigkeit, finde einen Sinn und meistere deine Fachgebiete.
• Setz dich für Themen ein, die dir gefallen.
• Sei dir bewusst, dass Scheitern ein Teil des Lernprozesses ist.
• Handle nach deiner Intuition.

Als Team

• Bildet ein Team, auch über Standorte hinweg.
• Drückt euch klar aus, geht nicht von Vermutungen aus.
• Geht Verpflichtungen ein und sagt „Nein“, wenn es nötig ist.
• Versteht kulturelle Unterschiede.
• Fördert soziale Interaktion.

Fazit

Die Technologiebranche, insbesondere im Bereich der Webentwicklung, ist geprägt von einem enormen Informationsrauschen, das durch die ständige Flut an Bibliotheken, Mustern und Meinungen verursacht wird, denen wir tagtäglich über alle Medien ausgesetzt sind. Aus diesem Grund verspüren wir möglicherweise einen immensen Druck, all unsere Anstrengungen darauf zu konzentrieren, dem Trend zu folgen (genau dieselben Frameworks, Bibliotheken, Entwurfsmuster, Entwicklungsprozesse usw. zu verwenden), und verlieren dabei möglicherweise den Blick für das, was wirklich zählt (unseren Kunden einen Mehrwert zu bieten, die Zusammenarbeit im Team zu fördern, unsere Fortschritte im Gesamtkontext zu betrachten usw.).

So spannend die technischen Ankündigungen auf manchen Entwicklerkonferenzen auch sein mögen, möchte ich andere dazu ermutigen, auch einen Blick auf die weniger technischen Vorträge zu werfen, die sich auf die Soft Skills konzentrieren, die wir manchmal vernachlässigen, und ab und zu einen Schritt zurückzutreten, um sicherzustellen, dass das, was man tut, immer noch Sinn ergibt.