Schlagwort: Scrum
Hört mit dem Etikettenschwindel auf!
Auf die Gefahr hin zu provozieren oder den einen oder anderen zu verstimmen muss ich mir heute meinen Ärger um nicht zu sagen meine Frustration von der Seele schreiben. In einem Cartoon zum Thema Retrospektive klang es schon verhalten an, dass es unzählige “Scrum-but”-Implementierungen gibt. Das reicht von kleinen Abweichungen oder Missverständnissen bis hin zu groben Fehlern. Eine besonders destruktive Ausprägung ist mir schon mehrfach untergekommen.1
Eine “irgendwas” Implementierung, die sich Scrum nennt, verzichtet praktisch auf alles was Scrum ausmacht. Keine der Rollen ist besetzt, es gibt kein Backlog, daily scrum findet nicht statt. Das Einzige was es gibt sind “Sprints”. Dafür wird deren Ergebnis von außen vorgegeben. Sprints – das hört sich so schön schnell an, da kommt mehr dabei heraus – außerdem lassen sich Teams schneller takten, die Leute leisten mehr. Ein minimales agiles Zugeständnis gibt allerdings noch: Kundenvertreter wurden mit ins Team gesteckt. Das Mikromanagement wird durch Gruppendruck ersetzt. Die Arbeitsbelastung steigt und steigt. Gleichzeitig steigt die Angst aufzubegehren, weil der Druck von zwei Seiten kommt.
Mir schwillt der Kamm wenn ich so etwas erlebe. Sicher möchte ein Arbeitgeber, dass die Arbeitsergebnisse zählbar und gut sind. Wenn es aber nur noch um Taktung geht, die Mitarbeiter ausgepresst werden und jede Idee, die noch mehr Leistung verspricht, völlig einseitig aufgesetzt wird, hat der “Scrum-but”-Spaß ein Ende. Ja – ein gutes Team kann große Leistungen erbringen. Um diese zu erbringen benötigt es aber die eigenverantwortliche Freiheit selbst zu bestimmen was im nächsten Sprint erledigt werden soll. Organisationen, die derartige “Scrum-irgendwie” Ansätze verfolgen, handeln in meinen Augen unethisch. Die Dualität von Rechten und Pflichten, die Verantwortung für die Mitarbeiter wird ignoriert. Ich befürchte, dass der geschilderte Fall kein Einzelfall ist. Möglicherweise werden viele Änderungen, die unter den Flaggen “agil”, “Team”, “Verantwortung” usw. segeln, insgeheim nur vorgenommen um den Leistungsdruck erhöhen zu können.
Eine (ggf. höhere) Leistung, die aus echter Verantwortung der Mitarbeiter resultiert, ist nicht von heute auf morgen zu bekommen. Die Einführung neuer Arbeitsweisen wird in der Regel die scheinbare Leistung erst einmal verringern. Es ist vergleichbar mit einer Investition – auf die Rendite muss man ein wenig warten.
Warum schreibe ich das Ganze? Ich hinterfrage gerade selbstkritisch ob all die Lobeshymnen für die häufig genannten Ansätze nicht kontraproduktiv sind. Eine kurze Übung auf einem Scrum-Training, die eindrucksvoll demonstriert wie schnell und um welche Größenordnungen sich die Geschwindigkeit für eine bestimmte Aufgabe im Team erhöhen lässt ist das Eine. Den langen Weg diesen Effekt auch bei komplexen Aufgaben zu erzielen ist das Andere. Die Verheißung eines Hochleistungs-Teams erinnert mich ein wenig an die Renditeversprechen von Wertpapieren. Im Gegensatz zum reinen Finanzmarkt geht es in Projekten jedoch um reales Arbeiten – dazu gehört auch Anstrengung und zwar von ALLEN Seiten.
Hört mit dem Etikettenschwindel auf!

wir sind fast fertig

Hybrides Projektmanagement ist keine Ausrede

#PM.Vorlesungen

Projekt oder »das nach vorn Geworfene«

- Die erste Fassung des Textes hatte ich 2012 geschrieben, die beschriebene “Scrum-Ausprägung” ist mir seitdem immer wieder aufs neue begegnet. [↩]

Dann nennt es bitte nicht Scrum
Die erste Fassung dieses Textes habe ich 2011 geschrieben. Möglicherweise war zu Beginn des Scrum-Hypes eine Menge Unkenntnis im Spiel, wenn es zu unvollständigen und manchmal abstrusen Scrum-Implementierungen kam. Zwischenzeitlich sollte das mit der Unkenntnis erledigt sein. Dennoch begegnen mir in letzer Zeit wieder vermehrt sehr seltsame Ideen mit der Aufschrift “Scrum”. Deshalb habe ich beschlossen dieses Text nach und nach zu ergänzen.
Originaltext aus dem Jahre 2011
Kürzlich wurde ich unfreiwilliger Ohrenzeuge eines so genannten Scrum-Meetings. Warum nur Ohrenzeuge? Das Meeting fand telefonisch statt und ich habe das Telefonat unfreiwillig mitgehört. Einer der Teilnehmer fragte mich hinterher: “Wie funktioniert Scrum wirklich?” Im weiteren Gespräch, in dem ich Details über das gerade beendete “Scrum-Meeting” erfuhr, stellte sich dann heraus, dass womöglich keiner der Beteiligten wirklich wusste wie Scrum funktioniert. Um ehrlich zu sein mir standen nach dem Gespräch die wenigen verbliebenen Haare zu Berge. Es gibt Organisationen, die guten Gewissens sagen “Wir machen Scrum” und dennoch in der täglichen Praxis ein Musterbeispiel abgeben, wie man es nicht machen sollte. Einige der Punkte aus dem Gespräch möchte ich nachfolgend kurz skizzieren und kommentieren:
- Es gibt kein Scrum-Meeting, es gibt das daily scrum. Das ist eine kurze, straff organisierte Zusammenkunft des Teams. Eine tägliche Telefonkonferenz von zwei Stunden ohne Moderation ist kein daily scrum.
- Das daily scrum ist eine Zusammenkunft des Teams und keine Konferenz eines ständig wechselnden Personenkreises. Das Team sollte wissen wer dazugehört und nicht erst zu Beginn des Termins erfahren wer heute dabei ist. Wenn nicht einmal klar ist wer zum Team dazu gehört ist schon die Minimalbedingung erfolgreicher Teamarbeit nicht erfüllt.
- Probleme werden im daily scrum nur öffentlich gemacht und angerissen. Sie werden notiert und außerhalb geklärt, gelöst oder einer Lösung zugeführt und nicht stundenlang im Meeting diskutiert. Wenn z.B. Schulungen notwendig sind werden diese organisiert und nicht im im daily scrum abgehalten. Das Notieren von Problemen und Hindernissen wie z.B. Schulungsbedarf und die Organisation von Abhilfen sind unter anderem Aufgaben des Scrum-Masters.
- Eine tägliche Telefonkonferenz mit Zeitzonenverteilung rund um den Globus1 ist wenig effektiv weil immer einer halb im Bett ist. Hier wäre eine andere Einteilung des Teams oder eine Aufteilung in zwei kleinere Teams die bessere Lösung.
- Qualitätskriterien werden als Abnahmekriterien für die User Stories formuliert und nicht als Meta-Use-Cases, deren Inhalt nichts mit den User Stories zu tun hat.
- Ein Scrum Team muss kompetent sein, das heißt die Teammember sollten in Summe die für die Arbeit notwendigen Kenntnisse besitzen. Es macht wenig Sinn eine Gruppe von Cobol-Entwicklern auf ein PHP – Projekt anzusetzen und sie als PHP-Scrum-Team zu bezeichnen.2
In besagter Organisation gibt es weder einen Scrum-Master noch einen Product-Owner. Insofern ist es faszinierend, dass überhaupt das Wort Scrum in den Mund genommen wird.
Epilog
Scrum ist ein außergewöhnlicher Ansatz im wahrsten Sinne des Wortes, der dementsprechend außergewöhnliche Ernsthaftigkeit in der Umsetzung erfordert. Ein Etiketten-Schwindel hilft niemand. Dann lieber wie bisher weiter machen – und – nennt es bitte nicht Scrum.
Nachtrag 1: Aus einer Projektanfrage, die mir auf den Tisch geflattert ist: Für ein Scrum-Team wird ein Projektleiter gesucht. Meine Rückfrage “Brauchen Sie einen Scrum-Master oder einen Product-Owner” stieß auf völliges Unverständnis. Scrum und die normale Projektleiter-Rolle passen nicht zusammen, zumindest nicht innerhalb des Aufgabenbereichs eines Teams.
Nachtrag :2 Die Rollen in Scrum sind wichtig. Die Aufgaben des Scrum-Masters können nicht vom ohnehin vorhandenen Projektleiter nebenher mitgemacht werden.

(k)ein Projekt- sondern ein Scrum-Cartoon
Aus gegebenem Anlass heute ein bitterer Cartoon, der leider mehr als ein Körnchen Wahrheit enthält. Gelegentlich wird die Retrospektive missbraucht um effektiver Schuldige zu suchen. Über die Hintergründe des Cartoons gibt es hier noch mehr zu lesen: Hört mit dem Etikettenschwindel auf!

Zeitschachteln und schnelle Läufe
Bernd Oesterreich schreibt im GPM-Blog über timeboxing und erklärt den Unterscheid zwischen Timebox und Iteration. Besonders gefallen hat mir seine Klarstellung bzgl. der eigentlichen Bedeutung des in Scrum verwendeten Begriffs des “Sprint” (siehe letzter Abschnitt). Lesenswert!
Was ist eigentlich timeboxing?