Scrum

Scrum ist mit Extreme Programming die bekannteste agile Methodik zur Softwareentwicklung (und nein: sie ein Framework zu nennen ändert nichts daran). Als Erfinder können Jeff Sutherland und Ken Schwaber gelten.

Hinderniswörter

 Prohibited Place © Watt_DabneySam Laing und Karen Greaves von Growing Agile haben vor kurzem ein paar praktische Tipps zu Impediments, also Hindernissen, auf Youtube zusammengestellt: Wie erkennt man sie? Wie kann das Team sie zusammen anpacken?

Schöner Tipp daraus: macht Euch eine Liste von Hinderniswörtern und fragt genauer nach, wenn Ihr sie öfters oder von mehreren hört. Nicht nur der Scrum Master ist dabei gefordert - jeder hat seinen blinden Fleck, oder besser: sein taubes Ohr.

Hier Sams und Karens Liste, mit den deutschen Entsprechungen:

Der Scrum Guide 2013 - was gibt es Neues?

  The 10 Commandments © John TaylorDer neue Scrum Guide 2013 ist seit einer Woche herunterladbar, momentan noch ausschließlich auf Englisch. Es lohnt sich, genauer hinzusehen, was Ken Schwaber und Jeff Sutherland geändert haben.

(Alle Hervorhebungen in Zitaten von mir).

Praxisnäher oder schon ScrumBut?

Viele kleine, unscheinbare Einfügungen (best, usually, ...) und Änderungen im Text sorgen für neue Ausnahmen und Relativierungen. Was früher noch zumindest als fragwürdig galt, taucht nun als dezentes Zugeständnis auf:

  • Die Sprintlänge darf jetzt offiziell variieren, sollte es aber am besten nicht («Sprints best have consistent durations throughout a development effort.»).
  • Das Sprintziel darf jetzt im Sprint nicht mehr gefährdet werden, bisher war bereits die Beeinträchtigung verboten («endangered» ersetzt das alte «affected»). Über die Grenze dazwischen darf spekuliert und viel diskutiert werden. Bei der Arbeit.
  • Die Zusammensetzung des Entwicklungsteams muss über einen Sprint nicht mehr konstant bleiben. Niemand muss sich also mehr verstecken mit Modellen wie einer Teilzeit-Mitgliedschaft (z.B.: Frank ist nur jeden Mittwoch da) oder auch der Austauschbarkeit von Human Resources (z.B.: es muss immer «ein Entwickler» im Team sein, egal ob das Michael oder Frank ist).

Heute kauf ich mir ein Zertifikat

  Certificates, certificates! © Dennis WongFormulierungen wie «zertifizierter Scrum Master», und «Certified Scrum Master (CSM), alternativ Professional Scrum Master (PSM) I» tauchen immer öfter in Projekt- oder Stellenbeschreibungen auf, manchmal sogar unter der Rubrik must have. Das ist einerseits verständlich, weil jede/r sich einfach «Scrum Master» nennen kann. Andererseits scheint wenig bekannt, was man sich unter «zertifiziert» konkret vorstellen darf.

Um es einfach auszudrücken und es im entsprechenden Selbstversuch zu demonstrieren:

Wissenstransfer mit Shu-Ha-Ri-Sprints

  Puzzled Kitty © David KAgile Teams leben in der Grauzone: Skills und Aufgaben sind keine Frage von Schwarz oder Weiß, ich oder Du.

Wenn die Testerin zum «Bottleneck» wird, weil Entwickler nicht wissen (wollen), wie man ein Testskript anwirft: schlecht fürs Ziel. Wenn der Product Owner (PO) keinen Sinn darin sieht, von Anfang an mit der Testerin an brauchbaren Akzeptanzkriterien zu feilen: schlecht fürs Ziel. Wenn die Testerin zwar programmieren könnte, aber sich sträubt, auch mal Unittests zu erweitern: schlecht fürs Ziel.

Der Scrum Guide sagt:

Unabhängig von der verrichteten Arbeit werden die Mitglieder des Entwicklungs-Teams als Entwickler bezeichnet. Scrum sieht keine anderen Titel für die Mitglieder eines Entwicklungs-Teams vor; es gibt keine Ausnahme von dieser Regel

Das bedeutet für das interdisziplinäre Team eben nicht, dass jeder wirklich alles und noch dazu gleich gut können muss. Es bedeutet, dass jeder zu jedem Zeitpunkt Meister, Geselle und Azubi zugleich ist, nur eben auf unterschiedlichen Gebieten - und immer wieder von neuem.

Agiles Teamwork lebt von dieser Grauzone. Davon, dass nicht danach gefragt wird, wer für das Erreichen des Ziels verantwortlich ist, weil die Antwort ohnehin klar ist: das gesamte Team.

Wann immer das Schwarz-oder-Weiß-Spiel («Was soll ich denn noch alles können?», «Das ist nicht mein Job!», ...) gespielt wird, um letztlich gar nichts außerhalb der eigenen Expertise kennen lernen zu müssen: schlecht fürs Ziel. Eine meiner wichtigsten Fragen an jedes Team ist deshalb: wie spielt Ihr denn statt dessen das Meister-Geselle-Azubi-Spiel, so dass es funktioniert?

Shu-Ha-Ri-Sprints: lernen, verstehen, vermitteln

Ein interessanter Weg neben z.B. Workshops, Schulungen und Communities of Practice (CoPs): das Team erklärt jeden Sprint zu einem Shu-, Ha- oder Ri-Sprint, rotierend.

Reminder: Velocity

Agiler Spickzettel 2: Scrum Flow

Scrum FlowAusgedruckt umfasst die definitive Beschreibung von Scrum auf Deutsch gerade mal 19 Seiten. Und enthält leider kein einziges Bild, nimmt man die Portraits von Jeff Sutherland und Ken Schwaber mal aus. Dem kann abgeholfen werden! » Weiterlesen: Agiler Spickzettel 2: Scrum Flow

Hier stinkt's! Platz 10: Für immer Azubi

Nach gut 12 Jahren Arbeit mit agilen Teams habe ich vor einer Weile meine Notizbücher hervorgekramt und Revue passieren lassen, was häufig weniger gut lief. Herausgekommen sind meine subjektiven Top 10 der Ursachen für müffelnde «Agilität», die ich hier in loser Folge vorstelle. Zusammen natürlich mit Vorschlägen zu Lösungswegen, statt nur zum Desodorieren.

Ich freue mich auf Eure Meinungen und Kommentare dazu!
Rolf

  Der erste (und manchmal letzte) EindruckJa, tatsächlich: ich bin großartig. Schwierige Momente und Missionen löse ich lässig und unaufgeregt. Unfassbar sicher ist mein Auftreten.

Während das Team noch rätselt, während die Führungsriege mich mit flehenden Augen ansieht, sind mir die Lösungen schon in der Sekunde klar, in der das erste Wort über ein mögliches Problem fällt. Sagte ich gerade «Problem»? Ich meinte natürlich: Petitesse.

Mein Dauerzustand entspannter Unterforderung weicht nur für einen flüchtigen Augenblick, wenn ich die Verzweifelnden (wie üblich) mit einer fabelhaften, den Tag rettenden Geste aufrichte und in meinen Bann ziehe.

Und dann klingelt der Wecker. Ich wache auf, und das echte Leben beginnt.

Jammerschade - spätestens nach der Pubertät hat Hollywood wohl ausgedient und Platz gemacht für den Klassiker «Übung macht den Meister». Das hat man verstanden und verinnerlicht.

Oder etwa nicht?

Hier stinkt's! Die Top 10 Ursachen für müffelnde «Agilität»

Nach gut 12 Jahren Arbeit mit agilen Teams habe ich vor einer Weile meine Notizbücher hervorgekramt und Revue passieren lassen, was häufig weniger gut lief. Herausgekommen sind meine subjektiven Top 10 der Ursachen für müffelnde «Agilität», die ich hier in loser Folge vorstelle. Zusammen natürlich mit ein paar Vorschlägen zum Abstellen, statt nur zum Desodorieren.

Ich freue mich auf Eure Meinungen dazu!
Rolf » Weiterlesen: Hier stinkt's! Die Top 10 Ursachen für müffelnde «Agilität»

Seiten