In der modernen Softwareentwicklung ist Verschwendung oft allgegenwärtig und trotzdem unerkannt.
Softwareteams stehen unter enormem Druck und sollen immer produktiver arbeiten. Dennoch verschwenden viele Teams wertvolle Zeit und Ressourcen durch ineffiziente Prozesse und vermeidbare Hindernisse. Diese verborgene Verschwendung kostet Dein Unternehmen wertvolle Ressourcen und bremst Innovation sowie Wertschöpfung.
Werfen wir also einen Blick auf sechs weitere Quellen von Verschwendung in der Softwareentwicklung.
Da hast Du den schönsten Plan für den Tag. Das Team ist tief in seine Aufgabe vertieft. Und plötzlich …
… taucht etwas unwahrscheinlich Wichtiges auf.
Das Produktivsystem ist abgeraucht. Das freundliche Scriptkiddie von nebenan meldet sich und bietet Dir Deine Kundendaten zum Kauf an. Oder eine andere Art von Notfall, wie das mindestens weltverändernde neue Feature, das irgendwem unter der Dusche einfiel.
Auf jeden Fall war es das mit dem Fortschritt. Ab jetzt gilt der reaktive Modus für ungeplante und unmittelbare Arbeiten.
Wie konnte es so weit kommen?
Gespart an den Entwicklergehältern? Zeit gespart bei den Tests? Das willkürliche Releasedatum war wichtiger als die Qualität? Die Planung schnell mal übersprungen? Monitoring machen die Kunden?
Tja. So kannst Du eben auch die Produktivität Deines Entwicklungsteams schnell ruinieren.
Wie viel Zeit verschwendet Dein Team mit nicht wertschöpfender Verwaltungs- und Compliance-Arbeit?
Also die Art von Aufwand für Verwaltungsarbeiten, die keinen direkten Nutzen für Kunden haben.
Ich spreche z. B. von Zeit zur Beantragung von Tools, die eigentlich selbstverständlich für die tägliche Arbeit sein sollten. Oder umgedreht betrachtet die Zeit, die verloren geht, weil nicht das am besten passende Tool für den Job genutzt werden muss.
Wie sieht es aus mit der Befriedigung des Compliance-Papiertigers? Im besten Fall auch noch für Aufgaben, die das Risiko für Kunden oder das Unternehmen überhaupt nicht effektiv reduzieren?
Gibt es vielleicht aus Gründen von nur auf den ersten Blick sinnvoller Vereinheitlichung global vorgegebene Prozesse, die irgendwie umschifft werden müssen? Und sind diese lokal anpassbar?
Oder mein ewiger Favorit: Reisebuchungen und (Reise-)Kostenabrechnungen. Achte mal darauf, für wen diese Prozesse und Tools in Deiner Organisation optimiert sind: für die Arbeit von Assistenz oder Finance im Hintergrund oder für Dich als Nutzerin?
Wie viel Zeit verwendest Du und Dein Team für Planungsthemen? Zu viel? Zu wenig? Genau richtig?
Das Pendel hat auch hier mal wieder zwei Extreme.
Einerseits verbringt ihr vielleicht massig Zeit in Besprechungen und sinniert über Features, die erst in Monaten fertig sein werden? Habt ihr frühzeitig die Zeit investiert und dann stellte sich heraus, dass die Anforderungen sich geändert haben oder die Funktion komplett gestrichen wurde? Ärgerlich. Dokumentation in der Form von ausgiebigen Spezifikationen schafft keinen Wert. Die frühzeitige Arbeit daran ist Verschwendung.
Andererseits plant ihr vielleicht zu wenig oder gar nicht? YOLO und einfach mit der Programmierung anfangen? Auch da wird ein Preis für fällig werden.
Die Kunst bei Planungsaktivitäten in sich verändernden Umgebungen ist die Anwendung des Konzepts der Entscheidungsfindung im „Last Responsible Moment“.
Dieser „Last Responsible Moment“ ist der Zeitpunkt innerhalb eines Projekts, an dem eine Entscheidung über ein bestimmtes Vorgehen getroffen werden muss. Es ist der spätestmögliche Zeitpunkt, an dem eine Entscheidung getroffen werden kann, ohne den Projekterfolg negativ zu beeinflussen.
Wenn ihr also etwas aufschieben könnt – die Planung einer Funktion, die Festlegung eines Teils der Architektur, die Auswahl eines Tools oder Frameworks oder die Entwicklung von Code, dann macht das. Solange ihr den Projekterfolg damit nicht gefährdet 😈
Wie viel Zeit verschwendet Dein Softwareteam mit vermeintlichen Selbstverständlichkeiten wie Pull Requests und Build-Prozessen?
Oder andersherum gefragt: wie viel investierst Du in Deine „Developer Productivity“ und „Developer Experience“?
Dazu eine kleine Geschichte. Es war einer dieser magischen Momente, an denen meine eigenen Beobachtungen und zwei Artikel aufeinandertrafen und es mal wieder passte wie A**** auf Eimer.
Die Beobachtung: verschiedene Teams erwähnen beiläufig Probleme. Pull Requests liegen ewig und sind zu groß. Die automatischen Builds laufen entweder gar nicht, sehr langsam, brechen mittendrin ab oder die Tests sind unzuverlässig usw.
Artikel Nummer 1: „Hans Dockter on Developer Productivity“ in der aktuellen IEEE Software. Da möchte ich fast alles zitieren und beschränke mich auf das:
Ein häufiges Beispiel ist, wenn ein Pull-Request-Build fehlschlägt und der Entwickler keine Ahnung hat, warum. Dies geschieht in vielen Unternehmen, wo 5–10 % der CI-Builds aufgrund von Unzuverlässigkeiten in der Pipeline fehlschlagen. Die Entwickler verschwenden Zeit damit, herauszufinden, ob der Fehler auf ihren Code oder die Umgebung zurückzuführen ist. Oft führen sie den Build einfach noch einmal aus, und wenn er erfolgreich ist, machen sie weiter. Dies führt zu erheblichen Unterbrechungen und Frustration.
Artikel Nummer 2: „Identifying Factors Contributing to 'Bad Days' for Software Developers: A Mixed-Methods Study“. Neben anderen Faktoren und deren Auswirkungen zeigt dieser Beitrag auch in Summe 8 Kennzahlen zur Messung der „Pull Request Time“ und „Build Process Time“.
Es ist doch schön, wenn da alles zusammenkommt, von Situation über Bestätigung bis zu potenziellen Messungen gegen das reine Bauchgefühl.
Allerdings kenne ich auch die üblichen Gegenargumente:
Mei, gehört zum Job. Und was entgegne ich darauf gerne:
Ja, und was kostet die verlorene Zeit pro Dev? Mal die Anzahl solcher Zyklen, die pro Tag auftreten? Mal die Anzahl der Entwicklerinnen und Entwickler in allen Deinen Teams?
Das muss man sich alles erstmal leisten können.
Wie viele Geisterbrücken bauen Du und Dein Softwareteam?
Was ist eine Geisterbrücke? Das sind Investitionsruinen, die einfach so in der Landschaft rumstehen. Die einfach nur „so da“ sind, also derzeit keinerlei Funktion erfüllen und mangels Zufahrten nicht benutzbar sind.
Bezogen auf die Softwareproduktentwicklung verbringen Entwicklungsteams also ihre Zeit damit:
Und wir alle kennen So-Da-Brücken in der Softwareentwicklung, die mit Eh-Da-Kosten verbunden sind.
Was für eine Verschwendung.
„Nur unter Druck formen sich Diamanten.“
Klar, weil erwachsene, gut ausgebildete, erfahrene und motivierte Menschen eine Umgebung brauchen, die sie unter Druck setzt.
Mal abgesehen von dem fragwürdigen Menschenbild und den Zuordnungsproblemen zwischen Korrelation und Kausalität ist dieser Ansatz auch eine Form von Waste.
Um eine künstlich festgelegte Frist einzuhalten, werden Teams in Überstunden getrieben. Das ist weder effizient noch effektiv.
Die Hetze lässt keine konzentrierte Arbeit zu. Somit führt der Druck einer zu erreichenden Deadline zu Fehlern. Die Behebung dieser Fehler in der Zukunft, denn aktuell ist ja keine Zeit dafür, wird um ein Vielfaches teurer werden.
Oder diese (Vor-)Eiligkeit führt dazu, etwas zu bauen, das aktuell noch gar nicht benötigt wird. Und verhindert dadurch Arbeit an etwas, das mehr Wert erbringt.
Ja, natürlich gibt es auch plausible Gründe für eine harte Frist. Doch bitte greift nicht irgendwelche künstlichen Termine aus der Luft. Plant vernünftig. Alles andere ist Verschwendung.
Entscheidend ist, die verschiedenen Arten von Verschwendung zu erkennen und bewusst zu entscheiden, ob und welche Optimierungen den größten Wert liefern. Nur so kann Dein Unternehmen die Produktivität Deiner Softwareteams nachhaltig steigern und bessere Produkte entwickeln.
Und es ist nicht einfach nur „das Team“, an dem gearbeitet werden muss, damit die Produktivität steigt. Es ist eben auch die Umgebung, in der das Team eingebettet ist.
Schnapp Dir die 7 Fragen für hochproduktive Entwicklungsteams und buche Deine kostenlose Teamanalyse und wir finden gemeinsam heraus, wie ich Dich am wirkungsvollsten unterstützen kann.