Wie funktioniert eigentlich Software-Entwicklung?
Auf welche Schwierigkeiten trifft man da, vor allem, wenn man disruptiv arbeiten will?
Was wird die nächste Tesla-Produktion der pharmazeutischen oder Biotech-Industrie?
Darüber spricht Christof Layher in der neuen Folge vom ChaosHacker-Talk mit Marc Bleß, der sind in der Unternehmensberatung damit beschäftigt, KI und Agilität zusammenzubringen.
Vor Jahren hat er mal einen KI-unterstützten Coaching-Bot angefangen zu bauen - ein halbes Jahr später kam ChatGPT um die Ecke. Idee vertan und jetzt kümmert sich Marc darum, dass Unternehmen Künstliche Intelligenz richtig einsetzen.
Christof hat schon öfter gesehen, dass Unternehmen versuchen, Software zu bauen ohne Agilität, also in traditionellenProjektmanagement-Methoden.
Für ihn ist das völlig unverständlich.
Was hält die Menschen davon ab, agil zu arbeiten?
Für Marc ist das die Tendenz zum Micromanagement. Kontrolle ist schlecht möglich, wenn man Teams Aufgaben gibt, die diese in einerfestgelegten Zeit dann erledigt haben sollen.
Im Engineering wird immer agil gearbeitet, in der Wissenschaft auch.
In Unternehmen sollte das so auch normal werden.
Das Problem besteht aber auch in der Kommunikation.
Für viele ist Software abstrakt.
Wenn man sich nicht täglich damit beschäftigt, dann versteht man gar nicht, was gemacht werden muss.
Deswegen ist es oft sinnig, MVPs zu bauen und diese den Kunden, bzw. dem Business, zu präsentieren und so die eigene Arbeit sichtbar zu machen.
Sonst verliert man schnell den Connect.
Mit einem ersten Proof of Concept kann man aber schonmal Feedback einsammeln.
Doch dann entsteht ein neues Problem: Technische Schuld.
Die muss dann erstmal abgebaut werden.
Die beiden sprechen auch über architektonische Schuld in der Produktion:Produktionsmaschinen sind oft so groß und keine einzelnen Inseln, dass man sie nicht „mal eben“ stoppen kann, um ein Update aufzuspielen.
Hier hilft es auch, über Notwendigkeiten zu sprechen.
Eine dritte Schuld ist die organisatorische Schuld: Viele Unternehmen halten sich an Normen, Regeln und Dokumentationen fest.
Ein Aufwand, der nicht getrieben wird, ist zu verstehen, was man sich bei der Entwicklung der Norm eigentlich gedacht hat.
Das sollte man erfassen und sich dann überlegen, wie man den Grundideen folgt, aber in der Praxis freier wird in der Ausgestaltung.
00:00:00 Vorstellung Marc Bless
00:03:47 Software bauen ohne Agilität?
00:08:00 Software als abstraktes Konzept
00:13:00 Iterative Phasen
00:15:47 Connect zum Business
00:20:38 Technische Schuld
00:25:05 Arbeitsmethodiken
00:33:12 Architektonische Schuld
00:35:13 Organisatorische Schuld
00:37:49 Disruptive Produktion
00:39:48 Dokumentation und Normen
00:46:08 Organisationsoptimierung
00:54:10 Mensch im Vordergrund
00:55:22 Zwei Fragen an Marc
