Vorab die zentrale Antwort – das „Wie“ folgt im Detail: Nur eine weitgehend standardisierte Softwareplattform ermöglicht es, Kundenanforderungen strukturiert einzuordnen und effizient, zeitnah sowie fehlerarm umzusetzen.
Es folgen Vorschläge zum Zuordnen von Verantwortungen analog dem Rollenmodell bei agiler Projektarbeit für ein Softwarehaus.
(In diesem Text wird aus Gründen der Lesbarkeit und Klarheit auf die Verwendung gendergerechter Sprache verzichtet.)
Die folgende Gegenüberstellung zeigt vereinfacht, wie klassische Projektrollen in agilen Vorgehensmodellen abgebildet werden – und an welcher Stelle in der Praxis häufig eine Lücke entsteht.
Kundenprojektleiter
Ist vertrieblich aktiv, nimmt Kundenwünsche auf, stimmt Anforderungen mit dem Auftraggeber ab und begleitet deren Umsetzung im Projekt.
Product Owner
Der fachliche „Was“-Verantwortliche: priorisiert Anforderungen, strukturiert das Product Backlog und stellt sicher, dass die aus Kundensicht relevanten Funktionen umgesetzt werden.
Entwicklungsleiter
Führt die Entwicklungsressourcen und verantwortet Planung, Koordination und Umsetzung der Entwicklungsleistungen.
Nicht eindeutig abgebildet
Die klassische Führungs- und Planungsverantwortung wird in agilen Modellen häufig auf mehrere Rollen verteilt oder implizit dem Team überlassen.
Technical Lead (Chefentwickler / Lead Developer)
Organisiert die Standardisierung der Software und verantwortet Architektur, Bibliotheken, technische Leitplanken, Wiederverwendbarkeit und Stabilität.
In vielen Modellen zu schwach verankert
Genau hier entsteht häufig eine Lücke: Die technische Führungsverantwortung für das „technische Wie“ ist oft nicht klar genug einer Rolle zugeordnet.
Kernaussage: Agile Modelle beantworten meist gut die Frage, was gebaut werden soll. Deutlich weniger klar geregelt ist häufig, wer verbindlich entscheidet, wie es technisch sauber, standardisiert und langfristig wartbar umgesetzt wird.
Erste These: Das agile Vorgehensmodell muss die Rolle und die Einschränkungen von Kompetenzen für den Product Owner (Kundenprojektleiter) meines Unternehmens viel mehr verankern als dies gemeinhin in der Praxis erfolgt.
Risiko:
Kundenwünsche werden individuell umgesetzt und zerstören die saubere Struktur meiner Softwarebasis.
Strategie:
Mein Softwarehaus muss wirtschaftlich agieren. D.h.: Die Lösung, die ein Kunde von mir erhält, sollte mittels der Nutzung meiner Software-Basis implementiert werden. Die Erweiterung dieser Basis wird sukzessive erfolgen, sollte aber immer mit Blick auf „meinen“ Softwarestandard erfolgen.
*Hier ist von der eingerichteten Entwicklungsumgebung über Architektur-Bibliotheken bis hin zur Oberfläche die Ergebnisse der bisherigen Entwicklungsarbeiten gemeint. Diese Ergebnisse sind neben dem Humankapital das wichtigste Asset meines Unternehmens.
Mein Kundenverantwortlicher bzw. Kundenprojektleiter – diese Rolle ist im agilen Vorgehensmodell nach Ansicht des Verfassers nur unzureichend abgebildet – muss seine Vorschläge zur Abbildung von Kundenwünschen in der Software eng mit dem Entwicklungsleiter bzw. dem Technical Lead abstimmen.
Andernfalls „zerfleddert“ meine Basis, jeder Kunde bekommt eine „Extrawurst“ und mein Second-Level-Support kann – wenn Befunde vom Kunden gemeldet werden – nicht mehr effizient arbeiten.
Beachten: Als Ziel muss mit dem Kunden vereinbart werden, dass Umsetzungen seiner Sonderwünsche so spezifiziert werden, dass ein neues Modul an alle Kunden ausgeliefert werden kann. Ggf. wird dann über das Berechtigungskonzept das neue Modul nur bei dem Anforderer freigeschaltet. Die anderen Kundenverantwortlichen erhalten die Funktionsbeschreibung des neuen Moduls als Vertriebsinformation und analysieren, ob sie es für den eigenen Kunden nutzbringend verkaufen können.
*Entwicklungsteam à la Agil: Ein selbstorganisiertes und interdisziplinäres Team, das die Arbeit aus dem Product Backlog umsetzt. Das Team ist für die Lieferung von Inkrementen funktionsfähiger Software verantwortlich.
Zweite These: Die Rolle „Entwicklungsleiter“ (im Fokus hier Technical Lead, d.h. Chef der Architektur und der Funktionsbibliotheken) ist im agilen Vorgehensmodell nicht exakt genug definiert.
Risiko:
Dem Team bzw. einigen Mitarbeitern werden zu viele Freiheiten eingeräumt.
Strategie:
Wer Softwareentwicklung geleitet hat, kennt das folgende Szenario: Ein findiges Teammitglied ist mit seiner Aufgabe überraschend schnell fertig geworden. Als Technical Lead schauen Sie sich das Ergebnis genauer an und stellen fest, dass hier neue Bibliotheken genutzt wurden, die Ihnen noch nicht bekannt waren.
Meist ist das sogenannte Open Source Software, die man in der Entwicklung einbinden kann. Allerdings hat Open Source ganz verschiedene Lizenz-Bedingungen. Eine kostenlose Nutzung kann mit einem Update passé werden und kann damit die Kostenkalkulation unvorhersehbar beeinflussen. Die Erweiterung mit neuen Bibliotheken bringt auch eine Erweiterung von neuen, oft noch unbekannten Schwachstellen mit sich.
Beachten: Bei der Unmenge von Drittsoftware muss die Aufgabe „Bibliotheksverwaltung“ unbedingt in eine verantwortliche Hand gegeben werden. Die Teams haben sich nur an freigegebenen Bausteinen zu bedienen. Neue Bausteine müssen beim Technical Lead beantragt werden. Ob diese Arbeit der Product Owner oder ein benannter Stakeholder leistet? Egal, aber diese Aufgabe muss unbedingt adressiert sein.
Dritte These: Eine Bedienphilosophie muss den heutigen Standards genügen und sich über die gesamte Software „ziehen“.
Risiko:
Wer kennt es nicht? Jede „Ecke“ in der Software verlangt eine andere Bedienung. An der einen Stelle kann ich mit einem Rechtsklick auf ein Objekt agieren, an der nächsten Stelle muss ich irgendwelche Buttons finden und in einem dritten Bereich komme ich ohne First-Level-Support nicht weiter.
Wir reden hier über Usability: Keiner hat heute die Zeit und bzw. die Akzeptanz, sich in exotische Bedienphilosophien einzuarbeiten.
Strategie:
Die für die User-Interaktion verwendeten Bibliotheken sollten auf Usability geprüft sein und den verbreiteten Standards entsprechen.
Beachten: Definieren Sie die Bedienphilosophie. Es existieren heute Pseudo-Industrie-Standards, die von bekannten Systemen wie Amazon, PayPal usw. gesetzt werden. Als Unternehmen in der Softwareindustrie muss ich organisieren, dass jeder in meinen Teams die im Zielland bekannten und genutzten Standards kennt. Organisieren Sie eine „Kundenreise“, d.h. lassen Sie Ihre Software von unbedarften Personen bedienen. Zwingen Sie Ihre Entwickler, sich mit den gängigen Pseudo-Standards auseinanderzusetzen, um damit kreative, aber exotische Eigenentwicklungen zu vermeiden.
Vierte These: Kein Entwickler ist in der Lage, jedes mögliche Fehlerszenario bei der Verarbeitung von Eingaben, Korrekturen, Copy-and-Paste-Aktionen und Rücksprüngen in den verschiedenen Browsern vorauszusagen.
Risiko:
Auch diesen Fall hat wahrscheinlich schon jeder einmal erlebt: Die Software hat sich „verklemmt“ und nur nach einem harten Restart – im Fall des Falles Gerät aus- und wieder einschalten – kann ich meine Arbeit mit dem System fortsetzen.
Strategie:
Es müssen Funktionsbausteine bereitgestellt werden, die eine Ausnahmebehandlung ermöglichen. Exception Handling bedeutet, dass bei einem Fehler nach Verarbeitung von Daten das System in einem Zustand zurückgebracht wird, der vor der Verarbeitung – also vor dem Fehler – bestand.
Beachten: Hier müssen mehrere Techniken – am besten per Code implementierte Lösungsbeispiele – bereitgestellt werden, die bei einer Datenverarbeitung sowohl eine Vorbereitung vornehmen, die Verarbeitung selbst kontrollieren und in einer Nachbereitung einen Check auf das Ergebnis vornehmen. Damit wird eine einfache Funktion natürlich relevant „aufgebläht“, aber ein komplexeres Softwaresystem kann nur so stabilisiert und handlungssicher werden. Jeder Entwickler muss mit der Anwendung dieser Funktionen vertraut sein.
Wer als Softwarehaus oder Inhouse-IT nachhaltig erfolgreich sein will, muss seine Kunden jederzeit zuverlässig und bedarfsgerecht bedienen können.
Das gelingt nicht mit individuell gewachsenen Softwarelösungen, die von sich selbst steuernden Teams agil an beliebige Kundenwünsche angepasst werden und deren Verständnis auf wenige Entwickler begrenzt ist.
Erfolgreich ist nur ein Ansatz, bei dem Softwarebausteine konsequent auf Anpassbarkeit ausgelegt sind und Kundenanforderungen systematisch innerhalb dieser Struktur abgebildet werden. Die Abbildung realer Objekte und Prozesse – also der digitale Zwilling – muss sich nahtlos in eine konsistente Funktionsbibliothek einfügen. Ist dies nicht möglich, muss jede Erweiterung so konzipiert werden, dass sie grundsätzlich für alle Kunden nutzbar ist.
Voraussetzung dafür ist eine klare technische Führung: Ein Technical Lead stellt sicher, dass Architekturprinzipien, Bedienphilosophie, Bibliotheken und Entwicklungsstandards einheitlich angewendet werden und sich die Lösung langfristig beherrschbar weiterentwickeln lässt.