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_DabneyProhibited Place © Watt_Dabney

Sam 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 TaylorThe 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 WongCertificates, 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 KPuzzled Kitty © David K

Agile 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

Credits: uses «Enduring», by Nicholas A. Tonelli.
Thanks to Nicholas for publishing it under CC-BY.

Agiler Spickzettel 2: Scrum Flow

Spickzettel Nr. 2: Scrum FlowSpickzettel Nr. 2: 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!

An anderer Stelle habe ich bereits den Agilen Spickzettel 1: Werte, Prinzipien, Praktiken veröffentlicht, der den Motor hinter agilem Denken beschreibt, ohne den nichts wirklich läuft. Der Spickzettel Nr 2 hier dagegen ist ganz den Rollen, Artefakten und Aktivitäten gewidmet - also dem was meistens als «Scrum» verkauft wird. An Rollen, Artefakten und Aktivitäten ist per se nichts falsch - aber Scrum darauf zu reduzieren ist etwa so sinnig wie die Phrase «Die Beziehung zu meinem Kind ist auch nur ein Prozess». Also nicht wirklich Erfolg versprechend.

Zu sehen sind die wesentlichen allgemeinen Stationen von der Produktvision bis hin zu burndown charts, Review und Retrospektive. So läßt sich die sichtbare Seite von Scrum erläutern, das Wie.

Ich freue mich über Feedback und Verbesserungsvorschläge dazu - viel Spaß beim Verwenden, der Spickzettel steht unter der Creative Commons Attribution-ShareAlike 3.0 Germany License

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) EindruckDer erste (und manchmal letzte) Eindruck Ja, 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

Neuer Service: Assessment Agiles Arbeiten (A³)

«Feedback? Gerne - aber bitte konstruktiv, und nicht von oben herab!»

What do you see? © Bill WardWhat do you see? © Bill WardAb sofort biete ich als neuen Service das Assessment Agiles Arbeiten (A³) - für alle, die

  • den erreichten Stand agilen Arbeitens zuverlässig einschätzen wollen,
  • an einer konstruktiven externen Sicht z.B. auf Ursachen und Menge von «Sand im Getriebe» interessiert sind und
  • konkrete Anregungen und Vorschläge für die Weiterentwicklung der eigenen agilen Arbeit suchen.

Ich freue mich schon auf unser erstes Gespräch darüber!

Assessment Agiles Arbeiten (A³)

Für ein Assessment Agiles Arbeiten (A³analysiere ich mit Ihnen die Arbeit Ihrer agilen Teams und Führungspersonen, einschließlich der Zusammenarbeit mit dem gesamten Umfeld: wie agil wird wirklich gearbeitet? Wo gibt es «blinde Flecken»? Wird die eigene agile Arbeitsweise konsequent ausgebaut und verbessert? Was könnte man als nächstes noch tun, um noch besser zu werden?

Ich besuche und interviewe Ihre Teams, die Führungspersonen und das Umfeld vor Ort, analysiere den erreichten Stand und erstelle einen ausführlichen Bericht, inklusive Anregungen und Vorschlägen für nächste Schritte. Der Bericht ist stets als hilfreiches Material für alle Beteiligten konzipiert, nicht als Verschlusssache: unterstützen, statt nur «bewerten»!

Mit Hilfe des Berichts können Teams, ihre Führungspersonen und das Umfeld

  • den gemeinsam erreichten Stand agilen Arbeitens zuverlässig einschätzen,
  • über eine konstruktive externe Sicht (z.B. auf Ursachen und Menge von «Sand im Getriebe») diskutieren, sowie
  • konkrete Anregungen und Vorschläge für die Weiterentwicklung der eigenen agilen Arbeit praktisch nutzen.

Wann sollten Sie ein  Assessment Agiles Arbeiten (A³) buchen? Sie wollen sich vergewissern, beim agilen Arbeiten auf dem richtigen Weg zu sein. Sie möchten eine systematische Einschätzung Ihres erreichten Stands durch einen erfahrenen Experten und Praktiker, auf Basis dessen, was Ihre Beteiligten denken und sagen. Sie möchten weiterführendes Feedback für alle Beteiligten - keinen «Geheimreport» für die Schublade. Sie möchten Vorschläge hören, was Ihre Teams, deren Führungspersonen und das Umfeld als nächstes anpacken können - und keine deprimierende Verurteilung Ihrer bisherigen Anstrengungen und Initiativen. Und das alles innerhalb von wenigen Tagen.

Für Besuch und Interview sollten sie rund einen Tag je Team einkalkulieren, an dem auch Umfeld und Führungspersonen Zeit einplanen müssen.

Inhalt abgleichen