Freitag, 27. Februar 2015

Denkanstoss: Scrum für Manager

FS
Noch einmal Input vom Lean Coffee on Tour in Köln: Wie verkauft man Scrum an die Management-Ebene?

  • Ein zentraler Punkt sind frühe Ergebnisse: Besonders im "Aufmerksamkeitswettbewerb" mit anderen, klassisch organisierten Teams ist von Vorteil, bereits funktionierende Komponenten vorweisen zu können, während die anderen noch in der Konzeptionsphase sind.
  • Ebenfalls wichtig ist die Transparenz: Durch Sprintlog und Backlog kann der Arbeitsfortschritt detailliert und nachvollziehbar visualisiert vorgeführt werden. Die Entwicklung ist aus Management-Sicht nicht länger eine Blackbox.
  • Frühen Ergebnisse und hohe Transparenz ermöglichen frühe Qualitätssicherung: Anders als im klassischen Projektmanagement muss nicht bis kurz vor Projektende gewartet werden um festzustellen ob das Ergebnis funktioniert oder ob es überhaupt den Anforderungen entspricht.
  • Langfristige agile Planung: Eine auf der Team-Velocity basierende Planung zukünftiger Sprints macht die langfristige (Release-)Planung möglich. Gleichzeitig ermöglicht der Soll-Ist-Abgleich nach jedem Sprint die Überprüfung ob diese Planung überhaupt noch realistisch ist.

Die Herausforderung bei der Management-Kommunikation ist die Vermittlung der Erkenntnis, dass die genannten Vorteile nicht ohne das "Drumherum" (Reviews, Retrospektiven, Scrum-Rollen, Stories, Epics, etc.) zu haben ist. Das ist schwer genug.

Montag, 23. Februar 2015

Scrum braucht kein Skalierungsframework, es ist selbst eines

FS

Bild: Piqsels - CC0 1.0
Die Geschichte von Scrum ist voller Missverständnisse, insgesamt so vielen, dass man sie kaum aufgezählt bekommen dürfte. Was die meisten von ihnen gemeinsam haben: mit einem schnellen Blick in den Scrum Guide würden sie sich aufklären lassen. Das gilt auch für eines der am weitesten verbreiteten, für die Fehlannahme nämlich, dass Scrum nur für die Organisation jeweils eines einzigen Teams gedacht wäre, während für die Koordination mehrerer Teams Skalierungsframeworks wie SAFe notwendig wären.

Dass das falsch ist kann man sich von Scrum-Begründer Jeff Sutherland selbst sagen lassen, man kann es aber auch durch Nachlesen im gerade erwähnten Scrum Guide selbst herausfinden. Dort findet man einiges zu diesem Thema, wenn man denn aufmerksam hinsieht:

  • Product Owner und Scrum Master haben führende Aufgaben nicht nur in einem Team sondern organisationsweit
  • Die verschiedenen Scrum Master arbeiten gemeinsam an der Etablierung von Scrum in der Gesamtorganisation
  • Das Sprint Review [sic] ist ein organisationsweites Planungs- und Abstimmungsmeeting
  • Mehrere Scrum Teams können ein gemeinsames Product Backlog haben (woraus sich ein gemeinsamer Product Owner ergibt)
  • Mehrere Scrum Teams können eine gemeinsame Definition of Done haben
  • Auch für gemeinsam entwickelte Produkte und Systeme kann eine gemeinsame DoD bestehen

Das ist deutlich mehr als den meisten Scrum-Anwendern bewusst sein dürfte, andererseits aber auch deutlich weniger als viele von ihnen gerne an Anleitung hätten. Dass dort nicht mehr steht hat aber einen bestimmten Grund: Scrum ist ein Framework und keine Methodik, die nicht regulierten Teile sind bewusst offen gehalten um Flexibilität zu gewährleisten und Bürokratie einzudämmen.

Und wer das noch immer nicht so ganz glauben kann, der kann sich eine weitere Quelle ansehen: auch der zweite Scrum-Begründer Ken Schwaber ist da sehr klar in seinen Aussagen.

Freitag, 20. Februar 2015

"Restart" von Scrum-Projekten

FS
Bild: Wikimedia Commons/James Petts - CC BY-SA 2.0

Mitgenommenes Thema vom Lean Coffee on Tour in Köln - der Neustart von Scrum in Projekten, in denen die Methodik so stark "angepasst" wurde, dass sie nicht mehr oder nicht mehr richtig funktioniert. Zentrale Punkte:

  • Wenn die Gründe für diese Anpassungen interne Vorschriften oder die Intervention verschiedener Stakeholder (Revision, Betriebsrat, etc.) sind, dann liegt ein grundlegendes Problem vor - es wurden nicht alle relevanten Gruppen und Personen eingebunden (oder sie wollen sich nicht einbinden lassen).
  • Wenn Scrum durch zu starke Anpassungen nicht mehr funktionieren kann werden die Beteiligten die Ursache häufig nicht bei den Verschlimmbesserungen sehen sondern bei der Methodik selbst ("Scrum funktioniert nicht").
  • Um ein für alle Beteiligten frustrierendes Aufreiben im Klein-Klein zu vermeiden ist der "Restart" eine Möglichkeit. Alle Anpassungen werden nicht nur in Frage gestellt sondern verworfen, das Team/die Teams machen wieder Scrum "nach Lehrbuch".
  •  Notwendige Voraussetzungen eines Restarts
    • Es muss allen Beteiligten klar sein (oder klar gemacht werden), dass die Anpassungen der Methodik zu Verschlechterungen geführt haben. 
    • Es muss dem Kunden/Sponsor bewusst sein, dass eine Reorganisation kein Zeitverlust ist, sondern das Projekt langfristig effektiver macht.
    • Der Restart darf nicht zu Fingerpointing führen ("Ihr habt alles falsch gemacht!"), sondern muss als Teil eines Lern- und Verbesserungsprozesses gesehen werden.
Was natürlich klar sein muss: der erste oben genannte Punkt gilt natürlich auch bei einem Neustart der Methodik - wenn nicht alle relevanten Gruppen und Personen eingebunden werden wird es auch hier zu Problemen kommen.

Donnerstag, 19. Februar 2015

Lean Coffee

FS
Bild: Pexels/Startupstockphotos - CC0 1.0
 Erstes Scrum-Event des Jahres - der Scrumtisch Köln. Erster Denkanstoß des Jahres - Lean Coffee. Die Regeln sind einfach:
  • Die Themenvorschläge werden gemeinsam gesammelt (z.B. als Post-Its auf einer Wand) und priorisiert (z.B. durch Dot-Voting)
  • Jedes Thema ist timeboxed auf 10 Minuten, danach wird mit Daumen hoch oder Daumen runter abgestimmt ob es um fünf Minuten verlängert wird oder nicht
  • Auch der gesamte Lean Coffee ist timeboxed (eine oder zwei Stunden). Wenn dann noch Themen übrig sind, dann sind sie noch übrig
Durch dieses Vorgehen wird verhindert, dass wenige Leute sich in einer Diskussion verbeissen während der Rest gelangweilt dabeisitzt. Und es gibt eine regelmässige Erinnerung, dass es noch weitere Themen gibt die noch nicht besprochen wurden. Das ist alles weder neu noch revolutionär, aber es hätte in den letzten Jahren einige quälend lange Diskussionen abkürzen können. Man hätte es nur machen müssen.

Freitag, 13. Februar 2015

Denkanstösse

FS
Das vermutlich größte Problem auf langfristigen agilen Projekten dürfte die Betriebsblindheit sein, die nach und nach alle Beteiligten (auch Scrum Coach und Scrum Master) befällt. Man macht Zugeständnisse an die Unternehmenskultur, man geht Kompromisse ein, man freut sich über kleine Erfolge, man resigniert. Sometimes ScrumBut is as agile as it gets. Die Herausforderung an dieser Stelle ist es, aus diesem Gedankengefängnis wieder auszubrechen. Der beste Weg dafür ist sicher eine Reflektion des Ist-Standes zusammen mit anderen, unbefangenen Personen, die einen nicht von der Projekthistorie verstellten Blick haben.

Daher jetzt endlich die (verspätete) Umsetzung des Neujahrs-Vorsatzes: häufiger auf Events der Scrum-Community gehen und Denkanstöße einholen. Also: zum Scrumtisch, zum Lean Coffee on Tour und wenn es geht auch zur Agile Cologne.

Mittwoch, 11. Februar 2015

Hallo Welt

FS
Jedem Anfang wohnt ein Zauber inne, so auch diesem hier. Mal sehen wieviel Zeit ich für diese kleine Internetpräsenz hier aufbringen werde.
Powered by Blogger.