Beschreibung
Die Arbeit eines Druckers lässt sich nicht beschleunigen, indem vorne mehr Papier hineingepresst und hinten daran gezogen wird. Auch die Qualität des Ausdrucks verbessert sich dadurch nicht. Warum tun wir es trotzdem?
Dieses Vorgehen steht sinnbildlich für ein Anti-Pattern, welches in sehr vielen Unternehmen omnipräsent ist. Den Entwicklungsteams einer Abteilung wird mehr Arbeit übergeben, als machbar ist. Die Arbeitsaufträge kommen auf verschiedenen Wegen direkt zu den Entwicklern, häufig auch direkt aus dem Management. Häufig handelt es sich dabei um «ganz dringende Arbeiten», welche «direkt von den Kunden» kommen. Oft sind es auch Fehlerkorrekturen als Folge von Kompromissen bei der Entwicklungsarbeit. Das Problem: Niemand kann gute Qualität abliefern, wenn die Zeit dafür schlicht nicht vorhanden ist.
Schlechte Qualität hat (nicht nur) in der Softwareentwicklung fatale Folgen. Technische Schulden nennen wir die Folgen von schlechter Qualität die sich über Zeit akkumuliert. Irgendwann müssen wir sie wieder abbauen. Diese sind oft das Ergebnis der Priorisierung einer schnellen Lieferung gegenüber einem qualitativ hochwertigen Code. Versuchen Unternehmen den Entwicklungsprozess zu verkürzen, indem sie technische Schulden aufbauen, lassen sich diese in Folge nur aufwendig tilgen. Bestenfalls verlangsamt sich beim Abbau nur der Entwicklungszyklus, schlimmstenfalls kommt es jedoch zum Ende einer Produktentwicklung. Viele Teams sind zu 50-80% damit beschäftigt, Software-Probleme zu beheben und für den Unterhalt von digitalen Produkten zu sorgen. Wo bleibt da noch Zeit für neue Features und Produktideen?
Beispiele
Wenn die HR-Abteilung im Unternehmen unsorgfältig arbeitet, fällt dies relativ schnell auf. Schlecht definierte Prozesse verlangsamen zum Beispiel den Recruiting-Prozess und Bewerber müssen mit langen Wartezeiten rechnen, was sich schlecht auf das Image als Arbeitgeber auswirkt. Prüft das HR die eingehenden Bewerbungen ungenügend, arbeiten nicht ausreichend qualifizierte Mitarbeiter in den falschen Rollen. Sie verursachen Schaden bzw. erzielen nicht die gewünschte Leistung.
In der Softwareentwicklung verhält es sich ähnlich mit mangelnder Qualität und den Aufbau von technischen Schulden. Nur das man diese leider lange Zeit überhaupt nicht bemerkt. Im HR wird nach Monaten klar, dass etwas nicht stimmt. Noch schneller geht es im Manufaktur-Bereich. Dort fällt sofort auf, wenn die Autotür grün statt rot aus der Lackierung kommt. Digitale Produkte sind im Hintergrund jedoch so komplex, dass mangelnde Qualität oft erst Jahre später zum echten Problem wird.
Nachteile
Keine Kapazität für Neu- und Weiterentwicklung: 50-80% der Arbeitskapazität wird mit Fehlerbehebung und Unterhalts-Betreibung bestehender Produkte beansprucht
Steigende technische Schulden: Zu Beginn stören sie kaum, aber nach Jahren sind daraus riesige Berge entstanden, deren Abbau langwierig und teuer ist
Sinkende Motivation in den Teams: Kein Mitarbeiter findet es toll, Feuerwehr zu spielen und Brände zu löschen
Gefährdung der mentalen Gesundheit: Teams arbeiten oft viel zu lange unter enormen Druck und vielen Überstunden ohne notwendige Erholungspausen
Fehlende Qualitätskontrolle: Wenn Entwickler eigenständig priorisieren müssen wird das Ergebnis von «Zusatzaufträgen» meist nicht kontrolliert
Merkmale
Herrscht dieses Anti-Pattern an einem Arbeitsplatz, muss ein Entwickler sich vielen Herausforderungen stellen. Zunächst wird ihm die Entscheidung der Priorisierung selbst überlassen. Normalerweise wird er durch einen Product Owner unterstützt, der im Sprint die offizielle Planung vornimmt. Werden jedoch Arbeitspakete am Product Owner «vorbeigeschleust», ist der Entwickler auf sich alleine gestellt. Er sieht sich mit Tickets aus der Produktion sowie Anfragen aus dem Management und Business konfrontiert, die alle nicht im Sprint Planning auftauchen. Es bleibt ihm nichts anderes übrig, als seine knappe Zeit so gut wie möglich einzuteilen. Die Priorisierung erfolgt nach eigenem Ermessen.
Das führt zu einer weiteren Herausforderung: Kompromisse. Die meisten Mitarbeiter wollen gute Arbeit leisten. Sie sind intrinsisch motiviert, bestmöglich die vielen Anforderungen des Arbeitsalltags zu erfüllen. Vermittelt der Manager dem Entwickler die Dringlichkeit seiner Anfrage und begründet sie z.B. mit dem Erfolg des Produkts auf dem Markt, fällt es dem Entwickler schwer, sich abzugrenzen. Wer will schon für ein schlechtes Produkt verantwortlich sein? Überstunden sind die Folge, und weil das meistens immer noch nicht reicht, müssen weitere Kompromisse eingegangen werden. Schlussendlich leidet darunter immer die Qualität.
Bei der Qualität sind die Folgen oft lange nicht sichtbar. Dass Produkte nur schwer gewartet oder erweitert werden können zeigt sich oft erst nach Jahren. Der Feedback Zyklus ist hier sehr lange und addiert sich nur langsam auf. Umso schmerzvoller ist jedoch dann das Reduzieren der technischen Schulden. Schmerzvoll bedeutet hier dass ein Team mit nur noch wenig Kapazität für Neues diese nutzen muss, um aufzuräumen. Nicht umsonst heisst es go slow to go fast.
Auswege aus dem Anti-Pattern
Es ist die Aufgabe des Managements ausreichend gute Bedingungen für die Teams zu schaffen. Es muss dafür sorgen, dass Mitarbeiter nicht mehr erledigen müssen, als sie bewältigen können.
Ein funktionierendes Muster dafür ist der Einsatz eines Product Owner, der den Backlog für das Entwicklungs-Team priorisiert. Das Team «zieht» sich daraus nur soviel Arbeit, wie es glaubt erledigen zu können (Pull-Prinzip). Ein gemeinsames Verständnis über die angestrebte Qualität sorgt dafür, dass Produkte «gut genug», aber nicht «vergoldet» sind. Dadurch lässt sich langfristig eine hohe Produktivität gewährleisten.
Doch Qualität, auch wenn sie nicht «vergoldet» ist, hat ihren Preis. Das Management muss bereit sein, die erforderlichen Ressourcen bereitzustellen und im Zweifelsfall zu verteidigen. Eine der wichtigsten Aufgaben für das Management beim Herstellen von guten Bedingungen im Team, ist das Nein-Sagen zu mehr Arbeit. Es gibt immer mehr zu tun, als Zeit und Geld vorhanden ist. Deshalb braucht es einen Product Owner, der sich seiner Rolle bewusst ist. Der wichtigste Satz eines Product Owner ist bekanntlich das «Nein». (https://youtu.be/502ILHjX9EE). Seine Aufgabe ist es, sein Team vor zu viel Arbeit zu schützen, um langfristig eine hohe Qualität der Ergebnisse sicherzustellen. Dafür braucht er die volle Unterstützung aus dem Management.
Erstaunlicherweise ist dem Management oft klar, in welcher heiklen Situation sich sein Team befindet und welche Folgen «billige Kompromisse» haben. Jedoch sieht es sich häufig ausserstande, etwas dagegen zu unternehmen. Warum? Niemand lehnt gerne zusätzliche Arbeit und damit höhere Einnahmen ab. Es ist ein schwieriger Balance-Akt, sich zwischen Marktgeschwindigkeit und Qualität zu bewegen. Aber es sagt ja niemand, dass Management-Aufgaben einfach sind.
Links:
Comments