Drei wichtige Dinge für Führungskräfte und Programmierer
9. Echtes Commitment wird abgewürgt
Auch wenn Scrum ein Framework ist, geht es bei Agilität natürlich auch darum, dass sich das Team selbst organisiert. Das klingt erstmal nach der Lizenz zum Chillen. Dabei sind selbstorganisierte Teams nach meiner Meinung hochmotiviert und am produktivsten.
Dafür muss ihnen aber auch die Freiheit eingeräumt werden, die Rahmenbedingungen selbst zu setzen: Das Daily lieber morgens oder nachmittags ansetzen? Alle zwei Wochen eine Retrospektive durchführen oder nur nach jedem dritten Sprint? Wie wird das Backlog organisiert, was sind die Messgrößen für ein Sprint-Planning, wie soll ein Refinement laufen?
Das Team muss alle diese Dinge selbst entscheiden und sich dabei auch ausprobieren dürfen. Scheitern bedeutet dabei die Möglichkeit zur Verbesserung und nicht, dass Köpfe rollen müssen, weil jemand daneben lag. Mit der Selbstorganisation wächst die Verantwortung und mit der Verantwortung wächst meist das Commitment des Teams.
Für die Organisationsfragen sind der Product Owner und der Scrum Master zuständig. So kann viel Last vom Team genommen werde. Damit erübrigt sich auch die Frage, die ich oft gestellt bekommen, ob denn Scrum Master für ein agiles Projekt wirklich notwendig sind.
Wer viel darf, wird auch viel leisten - wenn diese Einstellung im gesamten Team geteilt wird. Gute Teams arbeiten nach diesem Prinzip und liefern entsprechende Ergebnisse.
"Entscheidend is' auf dem Platz"
Alfred Preißler sagte einst: "Grau is' im Leben alle Theorie - aber entscheidend is' auf'm Platz." Das gilt auch für Agilität. Wer heute noch mit dem Scrum Guide und seitenweise Lehrmaterial argumentiert, wie etwas genau zu sein hat, der hat die immer individueller werdende Realität nicht erkannt.
Scrum ist also nicht als Methode schlecht, aber es wird oft falsch verstanden und angewendet. Genau deshalb macht es auch gute Entwickler nicht zu schlechteren. Ganz im Gegenteil: Scrum kann aus Entwicklern das Beste herausholen.
Führungskräfte und Programmierer sollten auf drei Dinge besonders achten:
- dass die täglichen Besprechungen wirklich Besprechungen sind und nicht nur den Kontrollzwang einer Führungskraft bedienen. Die Meetings sollten ein echter Austausch sein und die Team-Mitglieder einander mit ehrlichem Interesse fragen können, wie sie sich gegenseitig unterstützen können. Wer nichts sagt, ist nicht schlecht, es gibt dann eben einfach nichts zu sagen.
- dass Sprints wirklich abgeschlossen und Bugs nicht auf einen nächsten Sprint verschoben werden. Wenn ein Sprint dadurch länger dauert, ist das eben so. Die Qualität wird auf jeden Fall besser sein, wenn Bugs als natürlicher Bestandteil von Software anerkannt werden und nicht als Fehler einer Person.
- dass ein Team das Vertrauen bekommt, selbst entscheiden zu dürfen, wann es zum Beispiel eine Retrospektive macht oder welche Erfolgsmessgrößen es für einen Sprint ansetzt. Denn die klassischen Messgrößen wie: Wie viele Tickets hast du abgearbeitet? führen nur dazu, dass Programmierer diese Tickets schnell abhaken wollen - auf Kosten der Qualität.
Ich sage nicht, dass Scrum die perfekte Lösung für alle Software-Projekte ist. Meine Meinung ist aber, dass Scrum kein schlechtes Framework ist, sondern dass viele Beschränkungen und Blockaden des Umfelds die Einführung und Durchführung von Scrum erschweren. Oft fehlt der Mut, zum Beispiel Scrum Master mit der nötigen Power auszustatten, Dinge wirklich zu bewegen.
Vor allem bei der Budgetierung hört Agilität in den Unternehmen ganz oft abrupt auf. Dann geht es um Zahlen, Erwartungen, Liefertreue und Bestellungen. Dann wird mit rechtlichen Konsequenzen gedroht, statt Probleme verstehen zu wollen.
Alle Beteiligten tun gut daran, diesen Druck, dem alle Unternehmen unterliegen, vom Team fernzuhalten. So kann es zu seiner Bestleistung gebracht werden und wird seine Leistung auch gerne auf den Platz bringen wollen.
Marvin Engel ist selbständiger IT-Projektmanager, Coach, Berater und Trainer. Für Golem.de schreibt er seit 2018 Artikel aus seiner Berufspraxis. Seit Herbst 2020 berät er auch über die Plattform Shifoo von Golem.de IT-Profis in beruflichen Fragen.
Weitere Informationen gibt es hier in unserem Karriere-Ratgeber zum Thema Agilität
Oder nutzen Sie das Golem-pur-Angebot
und lesen Golem.de
- ohne Werbung
- mit ausgeschaltetem Javascript
- mit RSS-Volltext-Feed
Über Bug-Monster und Schummeln beim Scrum-Poker |
Der Punkt ist halt dass die Story Points keine Schätzung in Tagen ist, sondern ein...
Jup sehe ich auch so. 4 Entwickler sollen am selben UI rumwerkeln? Da ist man ja mehr...
Da hast du leider recht... Scrum verursacht meist mehr Probleme als es löst...
Ja, Rollenwechsel sind schwierig (bzw. unmöglich, wenn nicht mal gesehen wird, daß man...
Kommentieren