Gutes Projektmanagement bezieht alle Beteiligten mit ein Die neue Rolle der Developer im Projektcontrolling

Anbieter zum Thema

OutSystems

Komplexe Softwareprojekte bringen Risiken mit sich, die das Zeit- und Kostenbudget gefährden. Als Urheber wissen Entwickler und Entwicklerinnen am besten über den Projektverlauf Bescheid und sollten daher eine zentrale Rolle beim Controlling einnehmen.

Wer bereits an einem nichttrivialen Software-Projekt mitgewirkt hat, kennt den hohen Zeitaufwand, den Planungs-Meetings im Vergleich zur eigentlichen Programmiertätigkeit einnehmen können. Aber selbst wenn das Planning absolut gründlich und ausführlich angegangen wurde, läuft letztlich doch häufiger mehr schief als man für möglich hielt.

Kurz vor dem Release-Termin stellt man fest, dass das Budget überzogen wurde oder scheinbar völlig grundlegende Features nicht funktionieren: die Kundendatenbank gibt jede Zeile doppelt zurück, die Uhr zeigt immer die falsche Zeit an und Scrollbalken zerstören das Design.

Wie konnte das passieren? Die agilen Planungsmeetings wurden ordentlich durchgeführt und die Projektziele und Gesamtvision klar definiert. Die Product Owner schneiden alle Tickets in kleine Teile, spezifizieren detaillierte Akzeptanzkriterien und Entwicklungsteams schreiben zu jedem Feature passende Integrationstests gemäß ihrer Definition of Done.

Die Scrum Master sorgen für Interessenausgleich, geben Probleme mit der Kernarbeitszeit und geschlossener Kitas an die Geschäftsführung weiter und vermitteln den Auftraggebern die Situation und Wehwehchen des Teams. Der Grund für den Misserfolg liegt stattdessen ganz woanders.

Planung misslingt, wenn sie von oben herab erfolgt

Egal wie gründlich das agile Konstrukt des Entwicklungsprozesses ausgefeilt wurde – letztlich kann es nur funktionieren, wenn Anforderer und Developer auf Augenhöhe zusammenarbeiten und miteinander kommunizieren. Zum Scheitern verurteilt sind daher Planungsprozesse, bei denen Wünsche nur von oben herab weitergereicht werden, jeder irgendetwas besser weiß und wer anfordert, Recht bekommt – vor allem, wenn dafür bezahlt wird.

Viel zu selten wird dabei die Frage gestellt, welche Beteiligten eigentlich am meisten über das Digitalisierungsprojekt Bescheid wissen. Und das sind ohne Zweifel diejenigen, die den Code schreiben und die Funktionsweise unter der Haube am besten kennen: die Entwicklerinnen und Entwickler.

Dennoch kommt es häufig vor, dass das Entwicklungsteam nicht genügend bzw. nicht gleich zu Beginn der Spezifikation einbezogen oder nach ihrer Einschätzung und ihren bevorzugten Herangehensweisen befragt wird. Das kann schnell zu Frustration führen und Developer letztlich resignieren lassen, sodass sie Anweisungen ausführen, deren Sinnhaftigkeit sie eigentlich in Frage stellen.

Um diese Dynamik zu vermeiden, müssen sich nicht nur die Scrum Master, sondern das ganze Team angesprochen fühlen. Für diesen gemeinschaftlichen Aufwand ist die interne Kommunikation von besonderer Bedeutung. Daher kann es oft helfen, die üblichen und manchmal bereits eingefahrenen Wege der Kommunikation und Planung einmal grundlegend zu hinterfragen.

Wer bekommt alle Details im CC und löscht deswegen die meisten Mails ungelesen gleich nach Eingang? Bringt das übermächtige Atlassian-Tool wirklich Mehrwert oder steht es dem kreativen Prozess der Planung eher als Hindernis im Weg? Die Zeit eines Daily Standups sollte nicht mit wertlosen „Gestern habe ich ein paar Bugs gefixt und heute werde ich ein bisschen refactoren“-Statements totgeschlagen, sondern als Quality Time für Feedback und das Aufwerfen konkreter Fragen verstanden werden.

Erfolgreiches Controlling braucht einen agilen und transparenten Entwicklungsprozess

Im agilen Prozess geht es vorrangig darum, das Fundament für maximale Projekttransparenz herzustellen. Notfalls, indem man dem Entwicklerteam zugesteht, einen Sprint für die Neugestaltung ihres Team-Prozesses zu opfern, aber nicht, ohne sich auf eine klare Zieldefinition dafür festzulegen.

Wer noch keinen stabilen CI-Prozess hat, braucht dringend Github Actions, Circle CI oder Gitlab. Denn ohne CI gibt es keine abnahmefähigen Stage-Deployments, die sich Product Owner zum Sprint-Ende anschauen können, um neue Tickets für absurdes neues Fehlverhalten zu schreiben. Ohne gutes CD gibt es keinen Rollback-Mechanismus, der missglückte Deployments rückgängig machen kann. Das leuchtet Developern in der Regel ein, aber haben auch alle Stakeholder auf dem Schirm, dass solche Prozesse Aufwände für Zeit und Pflege verursachen?

Schwierig wird es, wenn ein „Test Driven Development“-Ansatz mehr Aufwand erzeugt, als er potenziell verhindert: Nur mit einem gut automatisierbaren Projekt-Setup, skalierbarer Infrastruktur und einem abgestimmten Test-Prozess können Tests die Qualität stabilisieren. Moderne E2E-Test-Tools wie Cypress, Smartbear, Puppetry oder Screenster erlauben es auch Personen mit beschränkten Code-Kenntnissen, Smoke-Tests für die allerwichtigsten Anforderungen zu bauen.

Damit lassen sich weite Teile des Systems bereits einer ganz generellen Qualitätssicherung zu unterziehen. Moderne Konzepte wie Snapshot-Testing oder Consumer Driven Contract Tests helfen auf technischer Seite, der Antizipationsfalle („What could possibly go wrong?!“) zu entkommen und solide Tests zu schreiben, auf die man sich verlassen kann.

Kreative Lösungen entstehen durch Offenheit und genügend Freiraum

Letztlich ist das Projektcontrolling ein vielschichtiger und -seitiger Prozess, der dann zum Erfolg führt, wenn alle Beteiligten unmittelbar einbezogen werden. Dies fängt damit an, dass Anforderer alle Sprint-Ergebnisse so detailliert wie möglich nachvollziehen, damit sie Wünsche neu überdenken oder anders priorisieren können.

Gleichzeitig müssen aber ebenfalls Entwicklerinnen und Entwickler den Raum bekommen, um auch ungewöhnliche Wege zu gehen und Probleme kreativ lösen zu können. Denn manche Herausforderungen lassen sich nur mit kreativem Coding, geschickter Interpretation von StackOverflow-Antworten und sogenanntem Mob-Programming bewältigen: Viele Developer setzen sich gemeinsam an einen Bildschirm, um ein Problem zu lösen.

Die Bereitschaft, Dinge auch mal völlig anders anzugehen, gehört zum modernen Engineering: In Zeiten von Containerisierung und Cloud-Deployments sollte es nicht allzu schwer sein, lahmen PHP-Code in Rust neu zu schreiben und die Daten über Kafka-Streams in die Datenbank zu pumpen. Man muss den Entwicklungsteams nur die Zeit geben, überhaupt auf diese Idee zu kommen.

* 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.

(ID:47563437)