Agilität ist ein Schlagwort, das fast alle Unternehmen erfasst hat. Auf Entscheiderebene gewinnt das Thema Business Agility, also die agile Arbeitsweise eines Unternehmens, beständig an Bedeutung. In der Folge versuchen Unternehmen, ihre Innovations- und Anpassungsgeschwindigkeit mit Hilfe entsprechender Initiativen signifikant zu erhöhen - besonders in der Softwareentwicklung. Gegen Entwicklungen im stillen Kämmerlein und fernab der Auftrag gebenden Fachabteilung soll auch hier die Agilität Abhilfe schaffen. Bevor Projektleiter aber blindlings auf die Versprechungen von Scrum und Kanban vertrauen, ist es wichtig, die Ideen hinter den Methoden zu verstehen und auf das Unternehmen anzupassen.
Foto: Olivier Le Moal - shutterstock.com
Seit Beginn der modernen Softwareentwicklung gibt es verschiedene Vorgehensweisen, um Software zu erstellen. Die bekanntesten und in den letzten zehn Jahren am weitesten verbreiten Methoden sind:
• Wasserfall, das heißt die Entwicklung von Software sukzessiv in Stufen mit Rückkopplung.
• Das V-Modell, das die Integration der Aspekte der Qualitätssicherung in das Wasserfallmodell beinhaltet.
• Evolutionäre oder inkrementelle Modelle, also die stufenweise Entwicklung des Softwareproduktes und
• als Weiterentwicklung daraus die heutigen gängigen agilen Methoden wie beispielsweise Scrum.
Mittlerweile geht der Trend ganz klar zu agil als De-facto-Standard, um moderne Software zu bauen, wobei Scrum und Kanban als verwendeten Methoden dominieren.
Ein Grund für diese Entwicklung ist in der Geschwindigkeit zu sehen, mit der neue Geschäftsmodelle sowie Produkte und Services auf die Märkte kommen.
Ein Blick auf die Fortune-500-Unternehmen zeigt die Auswirkungen der Marktveränderungen auf Unternehmen und die Notwendigkeit, sich anpassen zu können. Und das in immer kürzeren Zyklen, um am Markt zu bestehen. Vielfach dominieren Digital Natives den Markt und haben ihn durch moderne Arbeitsmodelle erobert. Diese Companies bringen Innovationen in viel schnelleren Intervallen Zyklen auf den Markt als viele der etablierten deutschen Betriebe.
- Produkt- & Projektmanager
Ganz generell schätzen es Entwickler nicht so besonders, wenn ihnen jemand erklären will, wie sie ihren Job zu machen haben. Weil Produkt- und Projektmanager aber oft Entwickler-Teams leiten, passiert genau das. Das kann zu Unstimmigkeiten führen. <br /><br /> Dazu hat auch David Fox von devRant eine Meinung: "Letztendlich ist es in den meisten Fällen so, dass Produkt- und Projektmanager in irgendeiner Art und Weise die 'Besitzer' von Projekten und Prozessen sind, ohne dabei die täglichen Herausforderungen und Probleme der Softwareentwickler zu kennen." - Chefs
Genau wie die Produkt- und Projektmanager sind auch Development oder Engineering Manager dafür zuständig, Teams von Entwicklern zu führen und sicherzustellen, dass Projekte rechtzeitig und unter Budget fertiggestellt werden. <br /><br /> "In einigen Unternehmen können Situationen entstehen, in denen der Chef gleichzeitig Mitglied des Entwicklerteams ist. Insbesondere wenn der Chef vorher selbst Entwickler war und nach einer Beförderung zum Chef wird, ist Konfliktpotenzial gegeben", merkt Fox an. - Recruiter
Softwareentwickler müssen gar nicht selbst aktiv nach einem Job suchen, um von Recruitern und Headhuntern belästigt zu werden - dem Fachkräftemangel sei Dank. Es dürfte sehr schwer sein, einen Developer zu finden, der noch nicht in die Fänge der Recruiter geraten ist. <br /><br /> David Fox sieht insbesondere die Hartnäckigkeit der Recruiter als Problem: "Sie rufen an, sie e-mailen und sie lassen Dich einfach nicht in Ruhe - selbst dann, wenn Du gar keinen Job suchst. Und selbst wenn man eine Anstellung sucht, neigen viele Recruiter dazu, irrelevante Jobangebote zu machen oder Stellen zu empfehlen, deren Profil überhaupt nicht passt - etwa einen Job am anderen Ende des Landes, obwohl man gar nicht bereit ist, umzuziehen." - Dokumentation
Gibt es keine Dokumentation, beschweren sich die Softwareentwickler. Wenn es zuviel ist, beschweren sie sich und wenn sie die Dokumentation selbst erledigen müssen, auch. Sogar über die Art und Weise, wie andere Leute die Dokumentationsaufgabe bewältigen, beschweren sich die Entwickler. <br /><br /> An dieser Stelle seien sich auch endlich einmal alle Entwickler einig, wie Fox betont: "Softwareentwickler wollen eine ausführliche, gut geschriebene und akkurate Dokumentation - aber selber machen wollen sie es nicht." - Meetings
Meetings sind nicht nur für alle anderen ein Problem, sondern auch für Softwareentwickler. Insbesondere dann, wenn es sich um völlig unnötige, zeitraubende und stinklangweilige Zusammenkünfte handelt. Wie Fox erzählt, sind inzwischen auch Devotionalien mit der Aufschrift 'I survived another meeting that should have been an email' erhältlich. - Coworking Spaces
Mit dem Aufstieg der Agilität sind flache Hierarchien, Collaboration und Teamwork zum Alltag in Unternehmen geworden - insbesondere für Software-Development-Teams. Gerade die können ihre Arbeit in einem Großraumbüro aber meist nur schwer oder gar nicht bewältigen - sagen zumindest die Zahlen von devRant. <br /><br /> David Fox erklärt: "Es gibt einfach zuviel Ablenkung: die Kollegen unterhalten sich, Meetings werden verpasst, Telefonanrufe überhört. Es gibt auch eine Vielzahl an Beschwerden über den Kaffee im Büro und andere Annehmlichkeiten - oder eben das Gegenteil davon." - Kollegen
Selbsterklärend: Jeder hat wohl einen Kollegen oder eine Kollegin, den beziehungsweise die er ganz besonders schätzt. Nicht. <br /><br /> Im Fall der Softwareentwickler ist die Abneigung gegenüber Kollegen meist entweder in der mangelnden Qualität ihrer Arbeit oder einem völlig aus dem Leim gegangenen Ego begründet, gibt David Fox preis. - Vorstellungsgespräche
Wenn ein Softwareentwickler auf Jobsuche ist und zum Bewerbungsgespräch geladen wird, gibt es danach meist auch etwas zu meckern: <br /><br /> "Dumme Fragen oder die Lösung von völlig praxisfernen Aufgaben im Bewerbungsgespräch stoßen den Developern ebenso sauer auf, wie ein Gesprächspartner, der überhaupt nicht weiß, was ein Entwickler eigentlich genau macht", so Fox. - Fehler & Bugs
Softwareentwickler haben tagein, tagaus mit Fehlern und Bugs zu tun. Deswegen glaubt devRant-Gründer Fox, dass Entwickler in dieser Sache anders ticken: <br /><br /> "Die meisten anderen Probleme erfahren keine positive Auflösung, aber Bugs und Fehler sind behebbar und das fühlt sich gut an." - Quality Assurance
Die Quality Assurance (QA) - oder Qualitätssicherung - ist ein kritischer Teil der Softwareentwicklung. Dennoch bemängeln Softwareentwickler an QA-Experten häufig dieselben Dinge wie an Produkt- und Projektmanagern, so Fox. <br /><br /> "Die Qualitätssicherung bekommt das Produkt oder Projekt in die Hände, wenn die Entwickler es abgeschlossen haben. Deswegen verstehen sie oft nicht, welche Hürden und Workarounds die Entwickler im Entstehungsprozess bewältigen mussten. Offensichtlich kommt es auch regelmäßig vor, dass QA-Leute die Entwickler bitten, Bereiche nochmals zu überarbeiten, die sie auch selbst bewältigen könnten."
Wasserfall als Schimpfwort
Vor diesem Hintergrund gilt "Wasserfall" schon beinahe als Schimpfwort und als Zeichen, dass Unternehmen, die diese Methode der Softwareentwicklung noch anwenden, noch nicht in der Neuzeit angekommen sind. Hierbei ist jedoch zu beachten:
1. Keine Softwaremethodik ist per se gut oder schlecht. Vielmehr muss es stets darum gehen, die richtige Methodik für das richtige Produkt und die gegebenen Rahmenbedingungen auszuwählen. Das war schon immer so. Leider ist es häufig der Fall, dass tiefgehendes Wissen über die verschiedenen Methodiken und deren Umsetzung nicht vorhanden ist. Zudem scheint die Hoffnung auf die "eine Methodik", die alles löst, zu unerwünschten Vereinfachungen zu führen.
2. Wasserfall wird heutzutage gerne wie folgt verbal beschrieben: "Monatelang werden Anforderungen erfasst, danach monatelang die Software gebaut und danach erst sieht die Fachabteilung die Software im Rahmen des Tests." In diesem Szenario, so die Kritik, würden die Fachabteilungen die Software viel zu spät präsentiert bekommen, Änderungen wären sehr teuer und Flexibilität sei nicht wirklich vorhanden. Vor diesem Hintergrund lohnt es sich nachzulesen, was die Wasserfallmethodik wirklich aussagt. 1970 veröffentlichte Winston W. Royce sein Paper "Managing the development of large software systems", er gilt damit als einer der Begründer der Wasserfallmethodik. Bei der Lektüre fällt auf: Dokumentation ist für Royce ein absoluter Schlüsselfaktor in der Entwicklung von Software. Dies scheint konträr zur heutigen Agil-Methodik zu sein. Hier ist aber Folgendes zu bedenken:
• Zum einen spricht das bekannte Agile Manifesto nicht davon, keine Dokumentation zu benötigen, sondern gewichtet "Working Software" einfach höher als "Comprehensive Documentation".
• Zum anderen hängt der notwendige Dokumentationsgrad auch immer von der Art des zu entwickelnden Systems ab.
Royce beschäftigte sich in seiner Arbeit mit der Erstellung von Software für die Planung, Durchführung und Analyse von Raumfahrtmissionen. Man kann sich vorstellen, dass derartige Systeme einen sehr hohen Grad an Dokumentation erfordern.
Beachtlich ist ferner, dass Royce damals schon die Risiken seiner Wasserfallmethodik erkannte und in seinem Paper auch vorschlägt, wie dieses Risiko minimiert werden kann, nämlich durch die
• Erstellung einer Vision und eines initialen Designs des zu erreichenden Zielproduktes zu Projektbeginn,
• Erstellung eines frühen Prototyps im Sinne von lauffähiger Software, der ständig weiterentwickelt wird, und
• Einbeziehung des Endkunden in jede Phase des Entwicklungsprozesses.
All diese Dinge würde man heute eher dem Lager der "Agilisten" zuschreiben.
Außerdem ist zu berücksichtigen, dass viele der Konzepte, die hinter den agilen Ansätzen von heute stehen, nicht notwendigerweise neu sind. Zur Hochzeit des Mainframes interagierten die Entwickler in der Regel direkt mit den Fachabteilungen und wurden neue Produktversionen in kleinen Zyklen live geschaltet. Leider wurden im Zeitalter von Industrialisierung und CMMI jedoch zahlreiche hierarchische Strukturen und Prozesse eingeführt, die den Entwickler immer weiter vom Endanwender entfernt haben.
Agile Prinzipien
Um es klar zu sagen: Die agilen Prinzipien sind für Unternehmen in der heutigen Zeit unabdingbar. Das Zeitalter der industrialisierten Softwareentwicklung hat zu vielen Auswüchsen geführt, welche durch die agile Bewegung korrigiert wurden. Das ist elementar, richtig und eine Grundvoraussetzung, um das eigentliche Thema - nämlich das Unternehmen in der Gesamtheit "agiler" zu machen - umzusetzen und die eigene Innovationsgeschwindigkeit signifikant zu erhöhen.
Es ist jedoch wichtig, hier nicht in die Falle zu tappen und einer Methodik wie Scrum oder SAFe blind zu vertrauen. Viel entscheidender als die Methodik sind die Prinzipen dahinter, diese zu verstehen und die Methodiken mit erfahrenen Leuten an die eigene Situation anpassen. Und eine agile Softwareentwicklung wiederum ist nur ein kleiner Baustein hin zu einem wirklichen agilen Unternehmen.