Icon Menu Icon Linkedin Icon Xing Icon Suche

Die Psychologie hinter Scrum

Scrum

Scrum begeisterte mich von Beginn weg. Je genauer ich diese Projektmethodik kennen lerne, desto faszinierter bin ich. Als Psychologe sehe ich, wie bei Scrum zahlreiche wissenschaftliche Erkenntnisse erfolgreich angewandt werden.

Scrum wurde als agile Projektmethodik entwickelt. Mittlerweile finden agile Ansätze weit über die Software-Entwicklung hinaus Anwendung. Der grosse Erfolg beruht meiner Meinung nach auch darauf, dass Scrum in der Praxis schlicht und einfach funktioniert. Das ist auch darauf zurückzuführen, dass diverse psychologische Erkenntnisse – bewusst oder unbewusst – geschickt in die Methodik eingearbeitet wurden. Das werde ich an einigen Beispielen aufzeigen.

Sprints und die Bedeutung von Deadlines

Ein Sprint ist eine Projektphase mit definiertem und vorzeigbarem Resultat und dauert ungefähr drei Wochen. Damit ist ein Sprint von absehbarer Länge, im Gegensatz zu Monster-Projekten, welche sich über Jahre hinziehen. Damit zusammen hängt die Wirkung von Deadlines auf das Verhalten. Diese ist exponentiell. 95 Prozent der Zeit hat eine Deadline kaum Auswirkungen auf das Verhalten und dann, zack, ganz plötzlich unglaublich grosse Bedeutung. Drei Wochen während eines Sprints sind absehbar und es ist intuitiv spürbar, dass heute mit der Arbeit begonnen werden muss, um in drei Wochen das Resultat zu erreichen.

Sprint Planning und Commitment

Bei Scrum bestimmt der Product Owner, welche Schritte (User Stories) aus den offenen Aufgaben (Product Backlog) zuerst umgesetzt werden. Die Scrum-Teammitglieder dagegen schätzen gemeinsam, wie lange die Umsetzung der einzelnen User Stories dauert. Dass der Product Owner für die «Wichtigkeit» und das Scrum Team für den «Aufwand» verantwortlich ist, überrascht in seiner Einfachheit und trifft den Punkt.

Der Product Owner kann besser einschätzen, wie wichtig eine einzelne User Story für die Anwender ist, da er in ständigem Kontakt mit diesen ist. Das Team dagegen verfügt über die Expertise in der Umsetzung und schätzt die benötigte Zeit für die einzelnen Stories. Dadurch bestimmt das Team, wie viele Stories im nächsten Sprint umgesetzt werden und nicht der Product Owner. Dies erhöht das Commitment der Gruppe und damit die Wahrscheinlichkeit der Zielerreichung massiv.

Planning Poker und gruppendynamische Prozesse

Im Planning Poker schätzen alle Teammitglieder den Aufwand zur Umsetzung einer User Story. Dabei werden gleichzeitig Karten mit der geschätzten Zeit aufgedeckt. Durch die Gleichzeitigkeit kommt auf effiziente Art und Weise das kombinierte Wissen der ganzen Gruppe zum Tragen. Teams finden generell zu besseren Lösungen als Einzelpersonen. Dabei sind heterogene Teams noch besser als homogene.

Beim Planning Poker wird durch das gleichzeitige Aufdecken der Karten verhindert, dass Personen mit geringerem Status sich der Meinung von statushöheren Personen anschliessen. Obwohl alle Menschen beeinflussbar sind, nehmen sich die meisten davon aus. Ein spannendes Phänomen, das unter dem Namen «Blind spot bias» bekannt ist.

User Stories als Kommunikationshilfe

Eine User-Story ist eine Aufgabenbeschreibung in strukturierter Form. Sie ist nach folgendem Muster aufgebaut: „Als <Rolle> möchte ich <Ziel/Wunsch>, um <Nutzen>“.

Der Anwender informiert möglichst umfassend, damit der Entwickler sich bestmöglich in seine Lage hineinversetzen kann. Damit wirkt man der Tendenz entgegen, Botschaften zu verkürzen. Das geschieht in der Annahme, dass der andere schon verstehen würde, was man meine. Das ist jedoch nicht der Fall! Der «False-consensus bias» sagt, dass die Ähnlichkeit des Denkens anderer Menschen deutlich überschätzt wird.

Bei der Formulierung gefällt mir ausserdem, dass ausschliesslich Elemente erwähnt werden, in welchen der Anwender auch tatsächlich Experte ist. So erzählt er von seinem Wunsch, seinem Ziel und dem erhofften Nutzen. Aus der Umsetzung hält er sich aber komplett heraus. Das Scrum Team ist als Experte für die Umsetzung auch alleine für diese verantwortlich.

Daily Scrum und Commitment

Im Daily Scrum findet im Stehen statt und ist zeitlich klar begrenzt (meist 15 Minuten). Jedes Teammitglied erzählt, was es gestern erreichte und was es für heute plant. Bereits die klare Struktur und die Zeitbegrenzung begeistern mich. Fehler Nummer 1 in Meetings ist eine unklare Struktur und kein definiertes Ziel. Im Daily Scrum ist glasklar, was in welcher Zeit erreicht werden soll.

Dem Team mitzuteilen, was man in den nächsten Stunden erledigen wird, ist ein öffentliches Commitment. Dieses erhöht die Wahrscheinlichkeit massiv, das Ziel zu erreichen.

Wer erinnert sich an die «Akupunktur»-Ohrringe der 80er-Jahre? Die Träger wollten mit dem Rauchen aufzuhören. Mit Akupunktur hatte das nichts zu tun, sondern lediglich mit öffentlichem Commitment. Durch die breit gestreute Werbung wussten alle, dass der Ohrringträger mit dem Rauchen aufhören wollte. Das hat die Wahrscheinlichkeit massiv erhöht, dass er sein Ziel erreichte.

Auch für die Person selber ist die Aussage viel Wert. Anhand der Goal-Setting-Theory wird ein Ziel viel eher erreicht, wenn es klar umrissen und formuliert ist. Daher ist die Pomodoro-Technik meine bevorzugte Methode, um meine Arbeitseffizienz zu steigern. Wenn ich mir überlege, was ich in den nächsten 25 Minuten erreichen will, ist es wahrscheinlich, dass ich mein Ziel erreiche.

Gerne würde ich die Definition of Done, den Burndown Chart oder die Sprint Demo thematisieren. Alles wunderbare Instrumente! Weshalb es Vorgesetzten schwer fällt, agile Teams selbstorganisiert arbeiten zu lassen, können Sie in meinem Blogartikel «Finger weg von agilen Teams!» erfahren. Allerdings will ich die Geduld der Leserin und des Lesers nicht überstrapazieren und wünsche nun einfach viel Erfolg im nächsten Sprint!

Hinweis: Ich habe diverse agile Projekte nahe mitverfolgt und die Scrum-Master-Zertifizierung abgelegt. Ich war jedoch nie Teil eines Scrum-Teams. Sollten sich inhaltliche Fehler eingeschlichen haben, bitte ich um Entschuldigung und bin interessiert an Feedback.

Roger Renggli

Haben Sie Fragen?

Rufen Sie an: +41 (0)41 552 27 27
Schreiben Sie mir: roger.renggli@rrpb.ch
Roger Renggli

Verwandte Artikel ?>

Das Wichtigste zu Software Engineering, Karriere und Recruiting
– 1x pro Quartal

Durch Anklicken des Kästchens erklären Sie sich mit unserer Datenschutzerklärung einverstanden und willigen ein, dass die angegebenen Daten für die Bearbeitung dieser Anfrage von Roger Renggli Personalberatung verwendet werden.

Beginnen wir. Damit Sie und das Unternehmen gewinnen.

Kontakt
schliessen