Ich habe sehr wohl erlebt, wie iterative Softwareentwicklung auch ohne Scrum funktioniert. Ein guter Projektmanager schafft es dabei, jedem in seinem eine Aufgabe zu geben, die ihn über wenige Tage beschäftigt und gleichzeitig das Ergebnis näher zur Produktreife bringt.

- mehr Stress
- VIEL mehr Verantwortung
- weniger Geld für den Entwickler
- nicht automatisch das beste Produkt
- zuviel Gequatsche

1.) ProductOwner und das gesamte Management und der Vertrieb (einfach alle, die direkten Kundenkontakt haben und/oder die Vision des Unternehmens tragen) müssen die Kunden möglichst darauf einschwören, bei Scrum mitzuziehen.

2.) Wer Scrum mit ganz dogmatischen Ansatz umsetzen will und stark heterogene Fachkräfte in den Teams hat, muss akzeptieren, dass die Produktivität erstmal sinken kann. Ich kenne einige sinnvolle Scrum-Umsetzungen, die die Regeln beugen müssen, weil man sonst einfach kein Geld mehr verdienen würde.

unter http://scrum.dhbw-karlsruhe.de gibt es eine interessante Seite zu dem Thema Scrum. Mit Audio, Spielen und Fragebogen und alles was dazu gehört.

Viele Grüße
DeBugger

Scheitern ist halt immer eine Optio mit der die meisten Projektmanager nicht umgehen können.

In jedem Falle hat sich der Term “Scrum” bereits seit längerem für das Bullshit Bingo qualifiziert und sollte jeder Entwicklerin von den Lippen gehen.

Im Übrigen, dass der Code allen gehören würde ist in vielen Produktionen schlichtweg nicht der Fall und birgt ein gewisses Risikopotential von Redundanz bis zu Abhänigkeiten von Entwicklern.

Danke aber für den tollen Artikel der einen guten Überblick gibt. Würde mich nach deinen anfänglichen persönlichen Erfahrungen mal interessieren ob / wie / wann man scrum dann ergänzt.

Du sprichst wahre und bittere Worte aus. Das was Du schreibst ist leider vielerorts so.

Unsere Geschäftsführung möchte jetzt via künstlichen Sprintzielen dieses Hochdrucktempo das ganze Jahr halten

Eine solche Einstellung einer Geschäftsführung geht an der Grundidee der agilen Entwicklung vollständig vorbei. Das hilft zwar nicht in Eurer konkreten Situation dennoch würde ein solcher Managementstil auch andere Wege finden um Druck auszüben.

Einen Chef als Scrum Master umzulabeln ist Unsinn. Es gibt die Metapher “scrum master is a leader without power” insofern kann ein disziplinarischer Vorgesetzter schwerlich die Scrum Master Rolle übernehmen. Agile Entwicklung und damit auch Scrum erfordert eine bestimmte Einstellung und Werte, die leider nicht überall dort wo Scrum drauf steht zu finden sind.

Das mit dem Gruppendruck würde ich differenziert betrachten. Wenn der Gruppendruck von außen verstärkt wird – was ein Scrum Master mit disziplinarischer Macht tun könnte – ist das verwerflich. Wenn die Gruppe wirklich selbst organisiert ist entsteht ein Netz von Verantwortungsgefühlen (Solidarität), die sich in manchmal auch wie Druck anfühlen können. Eine echte gelebte Solidarität, die den einzelnen gelegentlich (!) dazu bringt über seine Grenzen zu gehen, halte ich hingegen nicht für verwerflich. Ich würde das vielleicht mit dem “Aushelfen” oder “Zähne zusammenbeißen” in einer Sportmannschaft vergleichen. Wichtig ist, dass diese Solidarität nicht überstrapaziert und zum Regelfall wird. Diese Gefahr besteht – das darf auch nicht weg diskutiert werden – deshalb ist es so wichtig, dass der Scrum Master eben auch auf die “Sustainability” achtet.

Ich verstehe das nicht.
Bei uns wurde “von oben” ein Pseudo-Scrum eingeführt.
Und es gibt nur Probleme.

Es fängt damit an, dass unser Programm sehr sehr groß und schon sehr sehr alt ist. Das heißt, wir haben viel zu wenige automatisierte Tests, jedes Release ist mit viel Testerei von Hand verbunden.

Es geht weiter damit, dass wir sehr schnell auf gesetzliche Änderungen von außen reagieren müssen. Diese Änderungen kommen teilweise von verschiedenen Quellen, haben also schon mal ein bis zwei Wochen Versatz. Das ist halt problematisch bei einem festgezurrten Sprint.

Das weiteren arbeitet eine große Anwendergruppe mit dem Programm, so dass der Support unregelmäßig Unterstützung der Entwicklung anfordern muss. Hier ist unser Chef, der jetzt Scrummaster heißt, der Meinung der Sprint geht vor. Es ist ihm nicht begreiflich zu machen, dass alle Beteiligten darunter leiden, wenn der Support aufgrund mangelnder Unterstützung falsche Aussagen gegenüber dem Kunden trifft. Schlussendlich arbeiten die Entwickler tagsüber am Sprintziel und nach Feierabend unterstützen sie die Supporter. Weil wir ihnen nicht mehr in die Augen sehen könnten, wenn wir sie so hängen lassen würden.

Wir Entwickler sind spezialisiert. Jeder ist für “seinen Bereich” zuständig. Das ist so, weil auch sehr viel Businesslogik dahinter steckt. Es ist nicht möglich in allen Bereichen so weit Experte zu sein, dass man verantwortlich programmieren könnte. Das ist alles zu komplex.
Das wiederum führt dazu, dass das Sprintziel nicht erreicht wird, sobald ein Spezialist in Verzug gerät.

Ich empfinde das Sprintziel als künstliches Ziel. Im Gegensatz zu den “echten Zielen”: Zum Stichtag x muss in unserem Programm die Gesetzesänderung umgesetzt sein und das Programm muss ausgeliefert sein. Dieser Druck ist hoch, der ist sehr real und spürbar und wir Entwickler stellen uns da unserer Verantwortung und arbeiten in der heißen Phase wirklich hart.
Unsere Geschäftsführung möchte jetzt via künstlichen Sprintzielen dieses Hochdrucktempo das ganze Jahr halten – was uns Entwickler ausbrennt.

Verwerflich finde ich auch, dass bei Scrum massiv über Gruppendruck gearbeitet wird.