Vor einer Weile wurde ich zu einer Entwicklung hinzugezogen, bei der eine ältere Software für eine Maschinensteuerung durch eine moderne abgelöst werden sollte. Das Team befand sich in einem Disput über die einzusetzenden Technologien, die sogenannte Tool-Chain. Um die Sache voran zu bringen, hoffte das Management mit Hilfe eines externen Experten die Richtung vorgeben zu können. Doch Software-Entwicklung ist ein Innovationsprozess, das hatte man nicht richtig verstanden.
Bei agilen, selbst organisierten Teams gilt es einen Eingriff von außen wenn möglich zu vermeiden, deshalb erklärte ich mich nur zur Rolle eines Moderators bereit.
Auch die Ablösung von Software entspricht einem Innovationsprozess. Software die ohne eine Grunderneuerung oder ohne weiteren Nutzen durch andere Werkzeuge ersetzt wird, ist verbranntes Geld!
Wie sehr Innovationsprozesse und Software-Entwicklung miteinander verbunden sind, wurde bei diesem Projekt besonders deutlich.
Wer ist der Kunde?
Zu Beginn des ersten Meetings konnte die Frage, wer der Kunde der Software sei, nicht eindeutig beantwortet werden. Es fielen die Namen von unterschiedlichen Personengruppen aus dem Bereich der Stakeholder. Bei der anschließenden Diskussion blieben zwei Kunden übrig. Der Hersteller der Maschine, der auch der Auftraggeber der Software war und der Käufer der Maschine mit seinem Bedienpersonal. Bei modernen Innovationsprozessen sollte der endgültige Anwender als Kunde betrachtet werden, nie die zwischen geschalteten Auftraggeber. Ein Innovations-Team muss im Zweifelsfall Funktionalität im Sinne des Anwenders gegen den Auftraggeber verteidigen können.
Der Besteller eines Erzeugnisses denkt häufig in Kostengrenzen, Innovationen sollten aber in erster Linie der Kundenzufriedenheit und Produktivität während der Nutzung des Produktes dienen!
Grund und Zweck des Produktes
Weil alle ihren Laptop dabei hatten, bat ich jeden im Team eine kurze Zusammenfassung von dem zu entwickelnden Produkt zu machen und mir auf den vereinbarten Messanger zu senden. Interessanterweise gingen die Vorstellungen auch hier weit auseinander.
An dieser Stelle der Entwicklung ist es wichtig, dass sich jeder Beteiligte vollständig in die Rolle des späteren Anwenders hinein versetzen kann. Wir haben uns in diesem Fall zu einem Kunden an eine ältere Maschine begeben und uns intensiv mit dem Bedienpersonal ausgetauscht. Dabei kam so ganz nebenbei heraus, dass die Maschine in Zukunft ein Kandidat für ein Edge-Computing war, weil eine Kommunikation mit anderen Maschinen und eine Remoteüberwachung notwendig werden würde.
Die Analyse des Problembereiches ist sowohl aus der Vogelperspektive als auch bis ins kleinste Detail notwendig. Das zu entwickelnde Produkt sollte zunächst nur als eine Liste von Anforderungen definiert werden. War der Bedarf schon vor zehn Jahren vorhanden und ist vielleicht auch noch in zehn Jahren interessant, dann lohnt es sich die Anforderung aufzunehmen. Keine Zeit verschwenden mit „nice to have“ Funktionen.
Anforderungen strukturieren
Mit diesen neuen Erfahrungen und der Kenntnisse über den genauen Zweck des Produktes konnte das Team eine Struktur mit den notwendigen Produktfunktionen aufbauen und diskutieren. Nach vielen Änderungen und Ergänzungen fand sie schließlich eine breite Zustimmung. Dadurch war eine rudimentäre Dokumentation über das finale Produkt entstanden und das Team hatte so etwas wie eine Guideline.
Auf dieser Basis ließ sich eine zu entwickelnde Software gut in granulare Funktionalitäten modularisieren und wichtige Zusammenhänge konnten isoliert werden. Es entstand eine technologisch und ökonomisch gut bewertbare Grundlage für die Auswahl von Frameworks und Tools sowie ein späteres Burn-down-Sheet. Das lief alles nicht nach einem determinierten Konzept ab, denn Software-Entwicklung ist ein Innovationsprozess!
Tools und Methodik
Entwicklungs-Team werden mittlerweile weitestgehend nach technologischen Fertigkeiten ausgewählt, nicht mehr bezogen auf die Aufgabe, Domänen-Knowhow, Innovationsfähigkeit, Diversifikation usw. Dadurch wird die Entstehung von außergewöhnlicher, kreativer Software in vielen Bereichen unterdrückt und die Entwicklung degeneriert zu Fließbandarbeitern. Damit kann sich keiner identifizieren und es kann kein „Flow“ im Team entstehen.
Die Festlegung von Entwicklungsumgebungen und Tools noch bevor ein Team zusammengestellt oder das Produkt richtig bekannt ist, verletzt die Prinzipien agiler, selbst organisierter Arbeitsweise. Eine falsche Entscheidung zu diesem Zeitpunkt kann unnötig viel Ressourcen binden, die Fertigstellung entscheidend verzögern oder folgenschwer in eine Sackgasse und dann zum Abbruch führen.
Aber selbst wenn das Team die Festlegungsphase selbst verantworten kann, ist es sehr schwierig, jeden Einzelnen bezüglich seiner technologischen Vorlieben zu neutralisieren und eine produktgerechte Auswahl zu erreichen.
Fragt man einen Entwickler nach den einzusetzenden Werkzeugen, wird er sich auf seine bisherigen Kenntnisse stützen und das Gewohnte vorschlagen. Sie hassen es zuzugeben, dass sie etwas nicht wissen oder bei etwas falsch liegen. Es ist begründet in deren Kultur. Niemand kann alles wissen, schon gar nicht in diesem Arbeitsbereich. Menschen können jedoch motiviert werden, Nichtwissen oder Fehler ohne Furcht zu äußern. Gutes Management, Coaches oder Moderatoren schaffen es durch richtige Fragen ein offenes Verhalten im Team zu fördern.
Holistisches, invertiertes Denken
In einem meiner Innovationsprojekte sollte ein mechatronisches Team eine neue Variante einer Bearbeitungsmaschine entwickeln. In der Kreativ-Phase begann man wie gewohnt mit der klassischen Vorgehensweise: erst die Mechanik, dann Elektrik/Elektronik und schließlich die Steuerungssoftware. Doch nach mehreren durchgespielten Varianten kam irgendwie keine Begeisterung auf. Die Nachfolgemaschine unterschied sich nicht groß von dem Vorgänger.
Daraufhin forcierte ich das holistische, kreative Denken und es entstand ein invertierter Ansatz. Die Produktfunktionen wurden über die Software des Bedienpultes definiert und zusammen mit ausgewählten Kunden solange optimiert, bis jeder von einer gewisse Euphorie erfasst wurde. Ausgehend von den entstandenen Software-Modulen wurden dann die mechanischen und elektrischen Komponenten festgelegt oder entwickelt.
Das Ergebnis war eine Maschine, die konzeptionell völlig anders war als alles auf dem Markt. Sie hat sich später als durchschlagender Verkaufserfolg herausgestellt. Wettbewerber begannen das Konzept übereilt und wenig erfolgreich zu kopieren.
Software-Entwicklung ist ein Innovationsprozess, das wurde hier besonders deutlich.
