Agile Softwareentwicklung: Entwickler und Controller gehören an einen Tisch

Inhaltsverzeichnis

Klassisches Controlling und agile Development-Methoden entstammen unterschiedlichen Welten, verfolgen aber grundsätzlich dasselbe Ziel: Softwareentwicklungsprojekte detailliert planen und flexibel aussteuern. In der Praxis erweist sich das Zusammenspiel aufgrund der unterschiedlichen Ansätze aber häufig als schwierig. Viel zu oft laufen Aufwand und Kosten aus dem Ruder, obwohl das Coding in kleinen, agilen Schritten stattfindet und dank regelmäßiger Meetings scheinbar jedes Problem besprochen wird. Was läuft da schief und wie lässt sich das verhindern?

Dass Projekte egal welcher Art und Größe von einer soliden Planung profitieren, wissen sowohl Projektmanager als auch Entwicklerinnen und Entwickler. Jedoch ist die jeweilige Herangehensweise durchaus verschieden. Die Anforderungen kommen aus unterschiedlichen Richtungen, und nicht zuletzt gehen auch die Meinungen darüber auseinander, wann ein erreichtes Ergebnis als gut bewertet werden kann. Das führt häufig zu einer unüberschaubaren Lage – ein Blick auf die Details verrät, warum.

Trotz agiler Entwicklung werden Probleme zu spät erkannt

Agile Development-Methoden haben die Art und Weise, wie Software entwickelt wird, in den letzten Jahren entscheidend verändert. Auch wenn nicht in jedem Unternehmen ausschließlich Scrum Master und Agile Coaches für die Strukturierung der Entwicklungsprojekte verantwortlich sind, ist die von Major Releases getriebene Softwareentwicklung in der unternehmerischen Praxis kaum noch anzutreffen. Und das hat gute Gründe: Agile Methoden sind effizienter, transparenter und führen schneller zu verwertbaren Ergebnissen.

Im Wesentlichen geht es darum, durch iterative Schritte, Code Reviews und Tests potenzielle Fehlerquellen früher zu erkennen und entsprechend gegenzusteuern. So werden zu Beginn Projektvisionen klar ausformuliert, Anforderungen katalogisiert und Aufgaben priorisiert. In regelmäßigen Meetings diskutiert das Team möglichst alle Details der in kleinere Stücke zerlegten Projekte – von Akzeptanzkriterien über Integrationsanforderungen bis hin zu Umsetzungsschwierigkeiten.

Wieso passiert es trotzdem, dass die Verantwortlichen oft erst spät im Verlauf des Projektes Budget- und Zeitengpässe erkennen? Das Problem liegt meist nicht bei der Entwicklung, sondern vielmehr an deren ungenügender Integration ins Gesamtprojekt. Denn während DevOps-Initiativen versuchen, Entwicklung und Betrieb schon früh eng miteinander zu verzahnen, um spätere Operations-Anforderungen von Beginn an in den Entwicklungsprozess einfließen zu lassen, finden sich entsprechende Initiativen auf der Business-Seite eher selten. Mit anderen Worten: Entwicklerinnen und Entwickler gestalten Software heute zumeist mit klar definiertem Scope, maßgeschneidert für die Kundenanforderungen. Jedoch sitzen sie in den seltensten Fällen von Beginn an mit am Planungstisch – obwohl das sinnvoll wäre, denn ihre Einschätzungen und bevorzugten Herangehensweisen können sowohl Zeit- als auch Kostenpläne entscheidend beeinflussen. Allzu oft beschränkt sich das gewünschte Feedback auf die Anzahl der benötigten Sprints. Das greift allerdings zu kurz, denn die Softwareentwicklung ist ein kreativer Prozess, der sich schwer planen oder in enge Vorgaben pressen lässt – zumindest dann nicht, wenn der Anspruch an die Qualität der Software hoch ist.

Technical Debt definieren und einpreisen

Es ist unvermeidlich, dass Softwareprojekte im Laufe der Zeit Technical Debt (technische Schulden) anhäufen. Bedingt durch Projektziel und Geschwindigkeit lassen sich im Prozess trotz überzeugender Vorteile nicht immer vollständige Testabdeckung, automatisiertes Testing, vollautomatische Main-Deployments und eine clevere Architektur sowie die reibungslose Orchestrierung von Updates aller Komponenten gewährleisten. Um ein schnell wachsendes Projekt später zu stabilisieren, müssen solche Aufgaben unweigerlich nachgeholt werden.

Da sich technische Schulden nicht vermeiden lassen, gilt es für das Controlling, sie einzupreisen und bei der regelmäßigen und mittelfristigen Planung zu berücksichtigen. Im Idealfall räumen Projektverantwortliche Entwicklerinnen und Entwicklern regelmäßige Sprints ein, um den Schuldenberg abzutragen. Wer das nicht tut, riskiert ein zunehmend instabiles System, das sich schwerer verändern und erweitern lässt. Je konsequenter und liberaler das Controlling technische Schulden behandelt, desto leistungsfähiger agiert das Entwicklerteam im langfristigen Projektverlauf. Auftretende Probleme lassen sich beseitigen, ohne das gesamte Projekt aus der Bahn zu werfen.

Developer gehören ins Planungsteam

Entwicklerinnen und Entwickler sind längst mit dafür verantwortlich, dass Kunden die gewünschten Features in der Form bekommen, die sie möchten. Der agile Ansatz umfasst die frühe und kontinuierliche Auslieferung von Software, Offenheit gegenüber Änderungswünschen in jeder Projektphase – wenn diese vorteilhaft für die Kunden sind –, ständige Rücksprache mit allen Beteiligten, wie beispielsweise den Fachabteilungen, die die Software als Kunden in Auftrag gegeben haben.

In der Praxis werden Entwicklerteams meist aber erst später im Prozess eingebunden, sodass bei ihnen häufig das Gefühl aufkommt, die Planung erfolge von oben herab und die Kunden könnten sich wünschen, was sie wollen – weil sie ja schließlich dafür bezahlen. Unter solchen Bedingungen neigen auch Entwicklerinnen und Entwickler, die sich agile Methoden auf die Fahnen geschrieben haben, dazu, nur noch Dienst nach Vorschrift zu leisten und stumpf alle Aufgaben abzuarbeiten. Das führt in der Regel zu Frustration und wenig zufriedenstellenden Ergebnissen.

Die wichtigste Konsequenz aus diesen Überlegungen ist, das Development-Team von Beginn an vollständig miteinzubeziehen. Wenn diejenigen, die das Projekt maßgeblich umsetzen sollen, bereits Zeit- und Budgetplanung mitverantworten, ergeben sich klarere Rahmenbedingungen für die Umsetzungsphase. So können außerdem die Erkenntnisse der agilen Meetings des Dev-Teams in die Gesamtplanung zurückfließen. Wenn sich beispielsweise die Herausforderung ergibt, weitere Sprints oder Code Reviews einzufügen oder unvorhergesehene Inkompatibilitäten auflösen zu müssen, kann sich das gesamte Projekt verzögern. Erfolgt jedoch die Rückkopplung aus dem Entwicklerteam direkt mit den Business-Verantwortlichen, lässt sich unmittelbarer nachsteuern oder zumindest rechtzeitig umplanen.