Agiles Arbeiten: Gutes Scrum macht Entwickler nicht schlecht

Die Idee von Scrum ist es, Software flexibler anpassen zu können. Das heißt nicht, dass schneller programmiert wird. Viele verstehen das immer noch nicht.

Ein Erfahrungsbericht von Marvin Engel veröffentlicht am 25. April 2022, 8:42 Uhr

Viele Programmierer ärgern sich über Scrum. Ob das wirklich an der Methode liegt? (Bild: Pixabay)

Agiles Arbeiten und Scrum sind ein Hype. Es gibt eigentlich kein IT-Unternehmen mehr, das nicht irgendwie agil arbeiten möchte. Auf der Jobbörse Indeed sind in Deutschland allein die Stellenanzeigen für Product Owner im vergangenen Jahr um 86 Prozent gestiegen.

In letzter Zeit ist aber auch der Vorwurf häufiger geworden, dass vor allem Scrum die Arbeit nicht nur verbessert, sondern sogar verschlechtert. Immer mehr Entwickler äußern öffentlich ihre Bedenken zu Agilität und zur Scrum-Methode - übrigens auch unter vielen meiner Golem.de-Artikel.

Steigt man tiefer in die Diskussion hinein, hört man sogar, dass Scrum gute Entwickler zu durchschnittlichen Entwicklern mache. Zu schnell müssten sie im Sprintmodus Ergebnisse präsentieren, das gehe auf Kosten der Qualität. Um unter einem wachsenden Druck bestehen zu können, nähmen Entwickler Abkürzungen, um etwas fertigzustellen; sie ließen sich von ihrem Ticket-Highscore ablenken oder täuschten sogar Produktivität für Manager vor.

Dabei ist die Idee des Scrum-Frameworks, einen Entwicklungsprozess zu organisieren, damit verschiedene Projektzyklen schneller durchlaufen werden können. Das heißt nicht, dass ein Produkt unbedingt schneller fertig werden muss. Im Vergleich zu einem Wasserfall-Modell dauert es unter Umständen sogar länger. Im agilen Kontext heißt schnell: schnell auf Veränderungen zu reagieren, schnell Dinge anzupassen. Gerade weil ständig neu justiert wird, kann es dauern, bis das Endprodukt steht.

Woran liegt es nun, dass Scrum unter Entwicklern so einen schlechten Ruf hat? Meine Erfahrung als jemand, der sich seit Jahren mit agilen Transformationen in Unternehmen beschäftigt, ist: Es liegt nicht an der Methode, sondern an der Umsetzung.

Gefragt sind die Manager, aber auch die Programmierer selbst. Die Manager müssen dafür sorgen, dass Entwickler nicht unter Druck gesetzt, sondern anders motiviert werden. Sie sollten zudem ein Umfeld schaffen, in dem Entwickler auch in Sprints gute Arbeit leisten können. Die Entwickler wiederum müssen sich selbst dazu disziplinieren, mehr auf Klasse statt auf Masse zu achten, und dazu, die richtigen Prioritäten zu setzen.

Natürlich ist das als pauschaler Rat im Alltag nicht umzusetzen - deswegen folgen nun etwas konkreter die einzelnen Punkte, wo es bei Scrum meiner Meinung nach oft knirscht.

1. Das Daily verkommt zum Reporting

Immer wieder erlebe ich, dass die wichtigen Daily-Meetings zu einem Reporting-Werkzeug verkommen. Einige Product Owner wollen Statusberichte von ihren Entwicklern haben, weil sie diese an das Management weitergeben müssen.

Fragen wie: Was hast du gestern fertiggestellt?, Warum bist du noch nicht fertig? oder: Was ist denn das Problem und warum geht es nicht schneller? werden dann in einem Daily-Standup gestellt.

Die eigentliche Idee des Daily-Standups ist aber, dass die Team-Mitglieder einander mitteilen, welche Erfolge und Probleme es gestern gab, heute gibt und morgen geben kann. Wer kann anderen wie helfen und wie arbeiten wir möglichst unterstützend zusammen?

Hat jemand nichts beizutragen, muss er auch nichts beitragen. Einfach nur die Anwesenden abzufragen, wer was gerade macht, erzeugt ein Gefühl, sich täglich beweisen zu müssen, täglich zeigen zu müssen, dass man ausgelastet ist. Das ist aber ein komplett falscher Ansatz, der mir leider immer wieder begegnet. Er führt zu Frust beim Team und wenig Vorfreude auf ein eigentlich so wichtiges Zusammentreffen des Teams.