Wer den Zeitaufwand für die Entwicklung von Software plant, kalkuliert ganz selbstverständlich Zeit für das Ausbessern von Fehlern und das Ausweiten des ursprünglich gedachten Umfangs mit ein. Unter Programmierern spricht man dabei von “Technical Debt” also quasi Schulden oder ein Minus, das man von der produktiven Zeit abziehen muss. Die Ursachen hierfür reichen von schlicht unvermeidbaren Bugs bis hin zu groben Fehlkalkulationen bei der Aufstellung des Zeitplans für ein Projekt. Doch der COO der größten Entwicklerplattform weltweit beginnt seinen Vortrag mit einer oft übersehen Kategorie dieser technischen Schulden.
Was hält erfolgreiche Entwicklerteams von Leistungssteigerung und Wachstum ab?
Oftmals stellt ein Unternehmen fest, dass es – ohne strukturelle Veränderungen am Entwicklungsteam vorgenommen zu haben – plötzlich weniger Resultate liefern kann. Im Team hat sich nichts geändert, dennoch hat es den Anschein, dass man plötzlich langsamer entwickelt. Unter diesem Handlungsdruck wird stets die Grundsatzfrage nach dem Managementstil gestellt. Es kommt zum altbekannten Grabenkampf zwischen den Verfechtern eines agilen Vorgehens im Gegensatz zu traditionelleren Wasserfallmodellen des Projektmanagements. Dabei handelt es sich um ein lineares Vorgehensmodell, das in aufeinander folgenden Projektphasen organisiert ist. Szczepanski beschreibt, das diese spezielle Art der technischen Schulden, immer dann auftreten, wenn sich die Ansprüche eines Unternehmens an die eigene Code-Basis und die Datenstrukturen ändern. Seiner Meinung nach greift die gängige Ansicht “agile” sei ein Synonym für modern und innovativ, während “Wasserfall” von Entwickler einstimmig verteufelt werde, jedoch zu kurz.
Wer dem schnellen Feature-Launch nachrennt, verhindert den langfristigen Erfolg
Vielmehr beschreibt er die dynamische Bewegung zwischen den zwei Polen “Agil” und “Wasserfall” als Teil des natürlichen Wachstumsprozesses. Das agile Verhalten sei oft selbstverständlich für kleinere Teams, die zunächst mit sehr limitierten Features und Zielen arbeiten. Später, wenn jedoch 20, 50, 100 oder mehr Entwickler mit einer Code-Base arbeiten und das Unternehmen über verschiedene Abteilungen, Produkte oder Services verfügt, wandelt sich dies. Auf einmal gibt es Vertrieb und Marketing, die verbindliche Ansagen zur Fertigstellung eines neuen Features brauchen, um den wirtschaftlichen Erfolg des Unternehmens weiter gewährleisten zu können. Aus seiner Erfahrung merkt Szczepanski hier an, dass es für Entwicklungsabteilungen gerade zu zwingend ist, eine Roadmap und verbindliche Deadlines einzuführen, wenn man die eigene Produktivität transparent bewerten will. Nur mit der Selbsteinschätzung “Wir arbeiten schnell” lässt sich weder planen, noch verschiedene Features vernünftig priorisieren. Das kann fatale Folgen für Unternehmensentscheidung bei der Kosten-Nutzen-Abwägung neuer Features haben.
Agil vs. Wasserfall ist keine Stilfrage, sondern eine Frage der Anforderungen
Um das eigene Team entlang der Achse zwischen “agil” und “waterfall” zu verorten, gibt Szczepanski fünf Beispiele für Anforderungen die eine Bewegung in die eine oder andere Richtung erfordern können. Zunächst gilt es wirklich zu verstehen, was die Kunden benötigen, jetzt und in Zukunft. Die nächste Frage ist dann, kann die bestehende Code-Base dies liefer? Und gleich die dritte Frage: Können mit ihr Features schnell genug zur Marktreife gebracht werden?
Des weiteren bewegt sich die „Agile-Water-Fall-Achse“ von simplen zu komplexen Systemen. Bei zunehmender Komplexität kann eine agile Vorgehensweise nicht länger liefern, so Szczepanski. Zum Schluss gilt es noch die Fragen nach der Größe des eigenen Softwareteams und der Kundenzahl zu stellen. Darüber hinaus entscheiden die Art des Produkts und beispielsweise Sicherheitsrisikos darüber, wo für jedes Unternehmen der goldene Mittelweg zwischen den beiden Management-Modellen liegen kann.
Sorgen Sie sich weniger um die “Agil”-Frage und mehr um Ihr Team
Dieser Kompromiss, so der Stack Overflow COO, muss auf verschiedenen Ebenen des Teams und für verschiedene Teilprojekte regelmäßig neu ausgelotet werden. Er möchte Teams, die sich um die eigene Produktivität und Entwicklungsgeschwindigkeit Gedanken machen, jedoch auf einen weiteren Aspekt aufmerksam machen. Für die Motivation im Team viel entscheidender ist seiner Meinung nach die klare Rollentrennung zwischen Team Leads und Engineering Management.
Er beschreibt dies in der Analogie der Formel 1: Team Leads sind gewissermaßen auf die Geschwindigkeit des Teams bedacht, gleichsam der Boxencrew sind sie Coaches im täglichen Arbeiten. Während die Engineering Manager, vergleichbar mit den Mechanikern, sich über die langfristige Performance, also die Weiterentwicklung, Qualifizierung und Aufstellung des Teams kümmern. So gewährleisten Sie ein Team aus Software-Entwicklerinnen und -Entwicklern, das motiviert und qualifiziert genug ist, die Herausforderungen des Wachstums Ihrer Code Base zu meistern.
Jeff Szczepanski ist Chief Operating Officer bei Stack Overflow und verantwortlich für die Bereiche Werbung und Stack Overflow Talent. Bevor seiner Zeit bei Stack Overflow war er Gründer und CTO von Allworx Corp, wo er als Head of Product Developement der VoIP Software und Hardware-Lösungen die Firmenstrategie zum Erfolg führte und dabei selbst noch hin und wieder Zeit fand eine beträchtliche Menge C/C++ Code für die Produkte zu schreiben.
