Mehr Freiraum für Großartigkeit

Raus aus den Meetings, rein in die Kreativität: Warum Entwickler Stakeholder werden müssen

Stefan Adolf

© Shutterstock / iQoncept

Softwareprojekte sind komplex. Es lohnt sich, allen Stakeholdern diesen zugegebenermaßen lauwarmen Allgemeinplatz immer wieder ins Bewusstsein zu rufen. Denn sowohl die schiere Bandbreite der zu leistenden Aufgaben als auch die Menge der unplanbaren Sekundäraufgaben kann überwältigend sein, z.B. im Deployment, der Stabilisierung und Optimierung eines laufenden Produkts, der Aufrechterhaltung einer hohen Softwarequalität oder die vorausschauende Planung von Technical Debts.

Gutes Planning schafft Klarheit und Sicherheit

So weit, so entmutigend. Wie bekommt man das alles auf die Kette? Mit einem guten Plan, natürlich! Ein erfolgreiches Projekt braucht immer eine gute Planung, sowohl für seine Steuerung insgesamt als auch für sämtliche Unterprojekte, von der technologischen Umsetzung der Anforderungen bis zum Controlling und Qualitätsmanagement. In agilen Projekten sind Planning-Meetings omnipräsent, in denen der Projektplan kontinuierlich an die Realität angepasst werden soll.

Pläne schaffen Klarheit und Sicherheit über alle Etappen: Alle wissen, wie das Projekt ablaufen soll, wo die Prioritäten liegen und bestenfalls zu jeder Zeit was sie zu tun haben, ganz gleich ob Entwickler, Product Owner oder Agile Coach. Getreu dem Motto: „Weeks of coding can save you hours of planning.“ Wer auch nur ein bisschen Zeit in einen stichhaltigen Plan investiert, spart sich damit unnötige und zumeist aufwendige Programmierarbeit.

Wer in seinem Arbeitsalltag von einer Videokonferenz zur nächsten springt, weiß aber auch: Mit dem Planning kann man es durchaus übertreiben. Manch Entwickler überhitzt seine Prozessorkerne mittlerweile nicht mit seiner IDE, sondern mit permanenten Zoom-Konferenzen. Spätestens, wenn Planungs-Meetings und Abstimmungen mehr Zeit verschlingen als das Programmieren selbst, merkt man, dass etwas schiefläuft.

Zu viel Plan macht den Horizont kleiner als er sein muss

Wer es mit dem Planning übertreibt, riskiert den Horizont des Projekts zu verengen. Das Team fixiert sich auf die Anforderungen und Story Points, die es gerade umzusetzen gilt. Das Abhaken von Aufgaben erzeugt ein wohlig-warmes Gefühl des Fortschritts, doch im Ergebnis liefert das Team nicht mehr zwangsläufig die beste Lösung für jede Aufgabe, sondern genau die Lösung, die im Planning dafür vorgesehen wurde. Der Plan ist selbst zum Projekt geworden, ein Softwareprojekt mit Scheuklappen.

Diese Kritik trifft freilich nicht auf jedes Projekt zu; je höher der Standardisierungsgrad der zu lösenden Aufgaben, desto hilfreicher ist auch ein detailliertes Planning. Abseits des Standards, also je dichter man sich der Individualentwicklung nähert oder man etwas vollkommen Neues entwickelt, desto wertvoller werden gedankliche Freiräume.

Entwickler: schafft Euch Raum, um Euren Job zu machen!

Ein Plan, der zu viel Platz einnimmt, verengt den Handlungsspielraum für das Entwicklungsteam. Diesen Freiraum zu haben ist jedoch entscheidend dafür, kreative Lösungen für komplexe technologische Probleme zu finden. Und genau darin steckt die Berufung von Entwicklern: Wir sind keine reinen Umsetzer, die Aufgaben von Listen abhaken und zusehen, dass der Backlog-Stapel kleiner wird. Wir sind in höchstem Maße kreative Problemlöser, Ingenieure und digitale Prozesse, erfahrene Architekten für Gebäude mit hochkomplexer Code-Statik und Kommunikationswissenschaftler für Programmiersprachen und API-Spezifikationen.

Ein Problem, über das ich in meiner Laufbahn schon zu oft gestolpert bin: Irgendwann sagen Entwickler: „Ganz ehrlich, sag doch einfach, was wir tun sollen und wir machen es dann“ – selbst wenn sie insgeheim der Meinung sind, dass es so Mist wird und es eigentlich eine bessere Lösung gibt. Überschreitet man den phlegmatischen Ereignishorizont, stößt man irgendwann an Frustrationsgrenzen. Einen Weg dort heraus zu finden ist nicht alleine der Auftrag eines Scrum Masters, sondern verlangt großen Team Effort von allen Beteiligten. Dabei können gerade Entwickler helfen, bessere Entscheidungen zu treffen, weil sie diejenigen sind, die den Code schreiben und die jeden Tag die Datenbank oder Log-Ausgaben im Klartext lesen. In aller Regel wissen Entwickler am besten, wie sich Dinge technologisch umsetzen lassen.

Um das Problem zu lösen, sind in erster Linie Entwickler selbst in der Pflicht. Sie müssen sich einbringen. Scheut Euch nicht vor Projektverantwortung – steuert die eigenen Aufgaben mit! Wenn das bedeutet, kritischer, hartnäckiger und unbequemer zu werden, dann nur zu. Ihr seid der Meinung, es gibt eine bessere Lösung abseits der eingefahrenen Gleise? Sagt es und schafft Euch den Raum, sie umzusetzen. Softwareentwicklung ist keine Baustelle, auf der Stein auf Stein gesetzt wird. Entwickler, ihr müsst Architekten sein!

Gefragt sind aber auch alle anderen – insbesondere diejenigen, die Projektverantwortung tragen und zu den „Anforderern“ zählen. Sie müssen Freiräume für neue Ideen schaffen, nicht zu sehr auf dem einen Plan beharren und dürfen der Gleichgültigkeit keinen Millimeter nachgeben. Sie sollten Entwicklern positiv Druck machen, bessere, kreative Lösungsvorschläge zu finden. Von Beginn der Spezifikation an muss das Entwickler-Team dabei sein und das Projekt mitkonfektionieren. Kurz: Fragt das Team nicht nur, wie viele Sprints es brauchen wird, sondern verlangt von ihnen, die eigenen Aufgaben und Lösungen zu definieren.

Mit besserer Kommunikation Frustrationen auf beiden Seiten vermeiden

Wichtig ist es, den eingefahrenen Kommunikations- und Planungsprozess zur Disposition zu stellen: Gab es im Code Review-Prozess so große Anfeindungen unter Beteiligten, dass unüberwindbare Kommunikationsgräben entstanden sind? Steht das übermächtige Atlassian-Tool einem kreativen Planungsprozess eher im Weg als dass es Sinn stiftet? Eine gut geleitete, mit Tools wie parabol.co unterstützte Retrospektive hilft dabei, Erwartungen und Frustrationen des Teams aufzudecken, ohne Fingerpointing zu betreiben. Dann merkt man relativ schnell, dass dieses eine Ticket mit 13 Story Points, das bereits vier Mal in einen neuen Sprint geschoben wurde, entweder eines neuen Ansatzes, einer qualifizierten Zerteilung oder der vollständigen Entsorgung bedarf. Regelmäßige teamübergreifende Architektur-Meetings schaffen einen Raum, um offen und ehrlich über den aktuellen Qualitätsstand des Codes zu debattieren und interne Hackathons können dazu beitragen, Lösungen zu finden, auf die man gefangen im Projektalltag niemals gekommen wäre.

Nur Entwickler, die den Freiraum genießen, auf Augenhöhe über Anforderungen und Features zu diskutieren, schaffen es, aus funktionierenden Lösungen großartige werden zu lassen.

Verwandte Themen:

Geschrieben von
Stefan Adolf

Stefan Adolf ist Developer Ambassador bei Turbine Kreuzberg. Seine primäre Aufgabe ist die Kommunikation mit der Developer-Community. Der Fullstack-Entwickler mit Schwerpunkt auf Applikationen, IoT und Integration ist Organisator und Speaker auf Meetups und Konferenzen über entwicklernahe Themen. Zudem agiert er durch seine Expertise in dezentraler Technologie und dem Web3 als Tech Lead in Venture Projekten und als technologischer „Vordenker“ von Turbine Kreuzberg.

Kommentare

Hinterlasse einen Kommentar

avatar
4000
  Subscribe  
Benachrichtige mich zu: