TOP 3 Agile Worst Practices – Teil 1: Superhelden vs. Clean Code

NR. 1: SUPERHELDEN

Wer kennt sie nicht: Die erfahrenen Entwickler, die alles scheinbar schneller hinbekommen? Die ein hohes Ansehen beim Management haben, sich keiner Aufgabe zu schade sind, keine Restriktionen beim Mergen haben und einfach mal auf Master pushen. Die Code nicht kommentieren, Refactoring auf später verschieben, Tests nicht schreiben… Moment. Stop!

Spätestens jetzt solltest Du hellhörig geworden sein. Ja, man kann augenscheinlich “schneller” etwas entwickeln, wenn man die generelle Qualität links liegen lässt. Und das ist bei genau EINEM Anwendungsszenario auch richtig: Beim Prototyping.

Warum? Ein echter Prototyp wird, nachdem er bewiesen hat, dass er funktioniert, d. h. seinen Proof of Concept erbracht hat, weggeschmissen. Manchmal wird er auch radikal refactored. In allen anderen Fällen ist diese Art von Softwareentwicklung eine sehr schlechte Idee. Leider wird es bei erfahrenen Entwicklern oft toleriert, wenn sie keinen Clean Code produzieren. Daraus folgt:

• Scrum Teams müssen aufräumen
  Natürlich muss der Code irgendwann aufgeräumt, gewartet und weiterentwickelt werden. Das fällt dann meistens in das Aufgabengebiet der Scrum Teams, die sich dann mit dem Kackhaufen rumschlagen dürfen.
• Superhelden machen zu viel parallel.
  Dadurch, dass diese Personen immer wieder behaupten, dass sie etwas schneller hinkriegen, bearbeiten sie zu viele Aufgaben parallel. Durch das notwendige Context Switching sinkt ihre Produktivität massiv! Wenn man an fünf Dingen parallel arbeitet, sinkt die Produktivität auf 20 % (Quality Software Management: Systems Thinking by Gerald M. Weinberg).
  
• Frustration bei Scrum Teams.
  Wenn einem gesagt wird, dass die eigene Aufgabe von jemandem auf dem Klo während der Mittagspause erledigt wird, statt X Sprints zu dauern, kann sich jeder ausmalen, wie frustrierend das für einen ist. Vermeintlich gute Entwickler verlangsamen den Projektfortschritt dadurch ungemein. Es ist von ihnen keine böse Absicht. Im Gegenteil: Sie sind meistens die motiviertesten Entwickler im gesamten Projekt und stellen den Projekterfolg gefühlt über alles. Sie erreichen durch ihr Handeln aber leider das Gegenteil, wenn das Projekt es nicht schafft, ihre Kompetenzen produktiv und gewinnbringend einzusetzen.