In vielen IT-Teams und vor allem in Agenturen sind Stand Ups oft kein agiles Werkzeug, sondern mehr ein notwendiges Übel und überhaupt nicht etabliert. Das gehört halt irgendwie in die heutige Zeit. Dabei gilt auch hier “Über neue Wege muss man vor allem nachdenken, wenn man falsche geht”. Das Schöne ist: um einen Turnaround kommt irgendwann einfach keiner mehr rum. Und genau deshalb ist es auch eine große Chance. Kunden merken auch langsam, wenn sie hinters Licht geführt werden. Entwickler flüchten vor dem unnötigen Druck in schlechten Arbeitsbedingungen. Das haben auch viele Agenturen erkannt. Sie haben es gerade wirklich besonders schwer. Die Projekte geben das Budget nicht her, dass nötig ist damit Projekte aus ihrer Schieflage befreit werden können. Die Verantwortung und Kosten hier auf den Kunden zu legen ist falsch und auch moralisch nicht richtig. Ein ganz anderes Thema, aber wer kommt für Legacy Code eigentlich auf?
Scheiße, die stinkt, wird gefunden und kann nicht immer nur unter den Teppich gekehrt werden – Agile Stand Ups konfrontieren täglich mit der Wahrheit
Fertig wäre besser und alles andere ist schlecht. Von daher müssen wir als erstes anfangen zu definieren, wann etwas fertig ist. The Definition of Done. Da aber ständig neue Dinge im Neuland entdeckt werden und die Fertigstellung aktueller Tasks sich immer weiter verzögert, kommt es ständig zu Überschneidungen. Leider können Tasks in der Regel aber nur von einer sehr begrenzten Ressource umgesetzt werden: den Entwicklern selbst. Genau hier kommt es dann zu erhöhtem Druck und Fehlern. Das holt man mit mehr Kommunikation dann auch nicht mehr raus. Agile Stand Ups haben ja klare Ziele und brauchen keine CC-Krisen-Mails. Schließlich war auch alles entsprechend zugesagt worden. In professionellen Strukturen sollen durch eine agile Softwareentwicklung Engpässe früh erkannt und auf kurzem Dienstweg entgegengesteuert werden. Wenn jetzt aber Hände, Know-how und automatisierte Prozesse fehlen, dann bringt es reichlich wenig morgens nochmal Zeit in der Gruppe zu verbrennen. So die einheitliche Meinung frustrierter Entwickler. Glückliche Entwickler lieben dagegen Stand Ups. Also frage deine Entwickler mal was, sie von Stand Ups halten 😉
Zeit ist wichtig und ein hohes Gut – gebt die nicht so einfach her
Wer täglich am Limit ist kann keinen kühlen Kopf bewahren und macht Fehler. Neben dem tatsächlichen Projektdruck gibt es noch den persönlichen Druck. Der ist natürlich näher an einem dran und deshalb auch gefährlicher für die eigene Gesundheit. Man nimmt das Scheitern eines Projekts persönlich und hat auch Angst vor Konsequenzen. Wenn agile Stand Ups keinen Mehrwert bringen, dann ist das eben so. Es bringt ja nichts jeden Morgen oder einmal am Tag festzustellen, dass man im Sumpf steckt und auf der Stelle tritt. Ganz im Gegenteil. Das frustriert dann so richtig. In diesem Moment ist es besser sich ein Etappenziel, z.B. PHPStan auf Level 5, noch einmal klar machen und in einen ersten Schritt zu definieren. Bei nachhaltiger Softwareentwicklung geht es darum mögliche Engpässe zu vermeiden und gegebenenfalls auch Klärungen bei dem Projektmanagement anzufordern. Bei kreativer Arbeit geht es viel um Vertrauen. Wir müssen unserer Software und unserem Team vertrauen. Ein Stand Up soll ja auch die Möglichkeit bieten als Team zu reagieren und eingreifen zu können. Sofort und nicht erst später nach einem anderen großen Problem. Wenn man aber nicht als Team arbeitet, sondern einfach fest auf Projekten ohne Austausch hockt, dann führt das zu einem Schaden der seelischen Gesundheit. Deshalb fordert Never Code Alone auch Arbeitsschutz in der IT.
Die Struktur muss es auch hergeben – Agile Stand Ups sind für Teams und nicht für Einzelkämpfer
Häufig arbeiten Programmierer projektbezogen und nicht nur für eine Seite, wie ein festes E-Commerce Projekt. Dieses Inselwissen ist ein großes Problem. Anderen Entwicklern ist es ohne eine intensive Einarbeitungszeit nicht möglich in Projekte einzusteigen. Hier fehlt leider oft überhaupt ein entsprechender Know-How-Transfer. Das hat natürlich Auswirkungen auf die Stand Ups und deren inhaltliches Interesse. Alleine gerät ja jeder mehr und mehr unter Druck. Und dann noch ein Standup auf dem man sich anhört, dass die anderen auch unter Druck sind. Wer will das schon jeden Morgen hören und mit in den Tag nehmen? Da werden dann schnell nur noch die Projektnamen aufgezählt und vielleicht noch der Task genannt. Wichtig ist hier eine Struktur zu haben, die auf echten Teams basiert. Sind die nicht vorhanden, dann ist das ein wichtiger und erster Schritt. Denn dann können auch kurze Lösungswege und vor allem Hilfestellungen gefunden werden. Stichwort “Code Reviews” und “Pair Programming”. Beides sind sehr gute Werkzeuge, die sehr viele positive Nebeneffekte haben.
Nicht immer alles verkaufen und versprechen – Kreative Arbeit muss Spaß machen und wenig Druck haben
Kunden mit Geld fahren gerne sehr schnell geradeaus. Das ist auch ihr gutes Recht, denn sie wollen und sollen ihre Produkte digital noch besser vermarkten und verkaufen. Es wird mit Skalierung gearbeitet. Mehrsprachigkeit für die Nachbarländer ist hier ein sehr beliebter Weg. In der hippen IT versucht man dem auch immer nachzukommen. Es wird einfach zu selten “Nein” gesagt und immer noch nach kurzfristigen und nicht nachhaltigen Lösungen gesucht. Auch weil das System ja immer schon auf Mehrsprachigkeit ausgelegt ist. Dabei ist das gerade beim Thema “E-Commerce” weit mehr, als eine Übersetzung. Schneller “Fertig” bedeutet ja bekanntlich auch schnelleres Geld. Wer sich privat mit Haus- und Wohnungsbau beschäftigt weiß, dass es längst nicht bei allen Handwerkern so ist. Und man vor allem als Kunde sehr viel Geduld mitbringen muss. Agile Stand Ups bedeuten auf keinen Fall einen Zeitgewinn. Ganz im Gegenteil – sie sind eine kleines Guckloch auf tägliche Probleme, oder sagen wir mal Herausforderungen. Denen gegenüber steht das alles vernichtende „Keine Zeit und das muss fertig werden. Am besten gestern“. Das ist ein Interessenkonflikt, der leider zu oft nicht in einen guten Ausweg und Hoffnung führt, sondern noch eher in einen Kollaps. Es ist eben nicht nachhaltig. Hier empfehle ich gerne einmal das Buch “Kollaps”. Hier geht es um falsches Verhalten ausgestorbener Völker gegenüber ihrer Umwelt. Oder was man von Mayas und Wikingern lernen kann.
Keine Tests – keine Build Pipeline – keine Zeit – keine Reviews – keine Software-Qualität
Zeit gewinnt man nicht, wenn man die Finger beim Programmieren schneller bewegt. Man gewinnt sie nur, wenn man diese weniger bewegt. Leider gibt es immer wieder viel unnütze Bewegung, die automatisiert werden kann. Damit holt man nachweislich mindestens 30% der Zeit raus. Das sind knapp 2 Tage pro Woche, also über eine Woche pro Monat und mehrere Monate im Jahr. Laut den Umfragen auf den #NCAEvents dauert die beiläufige Einführung automatisierter Prozesse und Build Pipelines mit eigenem Inhouse Know-how Aufbau ca. 2 Monate. Danach ist das Leben sofort spürbar besser und vor allem werden die Arbeitsbedingungen geschätzt. Die Stimmung steigt also deutlich. Um man hat Zeit für Stand Ups, Reviews, Pair Programming und auch mal für den Kickertisch. Dann macht das Leben und die Arbeit einfach wieder Spaß. Das steigert die Motivation und das Ergebnis. Das wirkt sich alles positive auf das Betriebsklima aus. Nachhaltige Investitionen haben positive Effekte für viele Bereiche. Sie lohnen sich sehr.
An Stand Ups teilnehmen – Die Kunden sind auch in der Verantwortung – Sachverstand fehlt und Legacy Code verursacht extreme Kosten
Agilität steht auch für Transparenz und die Einbindung des Kunden. Konkret gibt es hier die Positionen des Shareholders, Product Owners und noch weitere. Eine sehr wichtige Position ist auch der/die Projektmanager/in. Die sehe ich auch im aktuellen IT-Trend beim Wechsel auf Kundenseite und ein erhöhtes technisches Outsourcing. Das ist eine sehr gute Chance für kleine Teams sich im Markt zu etablieren. Diese Entwicklung ist eine Folge von Misstrauen und Enttäuschungen. Hier kann man aber auch als IT-Dienstleister nach vorne gehen und Kunden in die Arbeit integrieren. So werden auch Entscheidungsprozesse deutlich kürzer. Die Arbeit von einzelnen kann so auch viel besser wertgeschätzt werden. Als Kunde sollte einem das und seine eigene Software wichtig sein. Gute und glückliche Leute machen gute Ergebnisse bei einer kreativen Arbeit. Kunden die Dinge “einfach nur fertig” haben wollen passen nicht in diesen Arbeitsprozess. Das ist das eben ein Kunde, der keine Probleme will. Damit wird er für Probleme und deren Lösungen auch nie empfänglich sein. Dinge wie Schulungen, externe Dienste für Testing und Infrastruktur, oder auch Updates auf neue Versionen werden hier leider nicht gerne gesehen. Kurz gesagt, Kunden müssen ihre Internetseite auch wollen und daran mithelfen und mitwirken.
Fazit zu Stand Ups als agiles Werkzeug – Bitte arbeitet zusammen und jeden Tag besser als Team
Ein Stand Up ist ein agiles Werkzeug, damit Probleme erkannt und Ressourcen kurzfristig auf Engpässen verwendet werden können. Die Entwicklung neuer Software-Anforderungen soll schneller und besser werden. Dazu muss es auch einen klaren Willen geben die Softwarequalität zu erhöhen. Dafür sind Ziele nötig. Hier braucht man keinen völligen Stillstand des kompletten Betriebes und Projekts. Aber man muss doch einiges an Zeit dafür investieren und auch bereit sein neues Know-how aufzubauen. Stand Ups alleine reichen dafür nicht. Die sind, wenn sie nichts ändern auch wirklich frustrierend. Dann schaden sie und werden am Ende auch von allen abgelehnt. Stand Ups sind kein Anfang für agile Softwareentwicklung. Sie sind lediglich ein wichtiges Tool, damit man agil reagieren kann. Wenn man allerdings insgesamt völlig unbeweglich und starr ist, dann sind die Probleme in der Regel an anderen und bereits bekannten Stellen. Zeit für erste Schritte. Es lohnt sich.