RENEMT_DE

Rowan Bunning veröffentlichte auf dem Münchener Scrum-Gathering im letzten Jahr eine nette Präsentation mit dem schön zweideutgen Titel “Kicking ScrumBut”. ScrumBut beruht aus der englischen Aussage: “We do Scrum, but…”, also “Wir machen Scrum, aber…”

Warum gerade diese “Abers” dem Scrum-Prozess wenig förderlich sind und wie der Scrummaster dem entgegen wirken kann ist wie gesagt hier festgehalten:

(gefunden bei Boris)

The Product Owner as a role has 5 responsibilities:

1. Create a Vision and share it with the team.
2. Manage the Return-On-Investment ROI.
3. Prioritize the Product Backlog based on ROI
4. Define the Acceptance Criteria and accept the Product Increment.
5. Establish and maintain the Release Plan.

Wie ich erwähnte verließ uns unser Product Owner vor kurzem überraschend und das Team hing in der Schwebe. Wie geht es weiter? Wer übernimmt die Aufgaben?

Wie erwartet wird der für den Bereich Software-Entwicklung zuständige Geschäftsführer erstmal wieder der PO. Quasi die gleiche Situation, die wir hatten, bevor wir diese Stelle explizit neu besetzten. Er ist in meinen Augen auch durchaus geeignet, die damit verbundenen Aufgaben zu erfüllen, da er die Verantwortlichkeiten des POs sehr in sich vereint.

Problematisch ist in meinen Augen jedoch, dass er als Geschäftsführer zum einen noch etliche andere Aufgaben zu erfüllen hat. Und – noch wichtiger: Gerade bei unserem internen Software-Projekt (PM-System), wo das Feedback der Benutzer (=Angestellten) gefragt ist, bereitet seine Stellung erfahrungsgemäß Probleme. Denn die Leute tun sich einfach leichter, mit Vorschlägen/Wünschen zu einer Person “auf gleicher Augenhöhe” zu kommen als zum Boss der Firma.

Wir werden sehen, wie sich die Sache entwickelt. Für die nächste Zeit können (und müssen) wir damit leben. Auf jeden Fall gibt sich die Firma ernsthaft Mühe, Scrum weiterhin zu unterstützen. Ein Beweis dafür, dass wir mit der Einführung deutlich sichtbare Verbesserungen erzielt haben.

Völlig überraschend – zumindest für das Team – hat unser Product Owner heute die Firma verlassen. Das ist zunächst ein ziemlicher Schock für alle gewesen, denn seit dem er seine Aufgabe übernommen hat gab es viele, von ihm initiierte, sehr positive Entwicklungen. Diese haben dazu geführt, dass das Team insgesamt deutlich zufriedener und motivierter war und wieder deutlich mehr Spaß an der Arbeit hat.

Abgesehen von den persönlichen Beziehungen stehen wir jetzt auch vor großen Herausforderungen aus Prozesssicht: Wer soll die Rolle des POs nun einnehmen? Ich als Scrum Master darf es nicht – denn ich muss unabhängig bleiben. Eine Alternative wäre, ein Teammitglied in diese Doppelrolle zu befördern. Allerdings ist das unrealistisch, da wir die gesamte Kapazität der Entwickler auch zum Entwickeln brauchen. Dritte Möglichkeit: Eine Team-externe Person, z.B. einer der Geschäftsführer, tritt in die Fußstapfen des POs. Diese Situation hatten wir jedoch, bevor wir diese Position explizit anders besetzt hatten und es war völlig unbefriedigend. Denn Product Owner ist ein Vollzeitjob – und es gibt niemanden in der Firma, der dafür wirklich Zeit hat.

Ich bin gespannt, wie sich diese Situation entwickeln wird und hoffe für das Team und die Firma, dass wir schnell eine probate Lösung finden. Die große Gefahr wird jetzt sein, dass sich Teammitglieder, die vorher schon unzufrieden waren, nun mental von der Firma verabschieden (“innere Kündigung”). Von daher muss ich versuchen, möglichst schnell für alle einen akzeptablen Status quo herzustellen.

Als ich Scrum einführte hat das Team mit mir unsere “Definition of Done” erarbeitet. Seitdem hängt sie öffentlich an der Wand und jeder kann sie einsehen. Die Punkte ähneln vermutlich denen, die jedes gute Scrum-Team festgehalten hat: “Potential shippable”, so weit wie möglich mit Unit-Tests abgedeckt, unseren Coding-Standards entsprechend, getestet und dokumentiert.

Nun ist mir aufgefallen, dass wir jedes mal, wenn wir ein neues Release freigeben, überlegen müssen, ob das Changelog auch alle (für den Anwender interessanten) Änderungen enthält. Bei neuen Features ist das ja noch relativ einfach: Userstories abschreiben. Bei Bugs wird es schon schwerer – da müssen nämlich unter Umständen etliche rote Zettel am Taskboard durchgeschaut – und sich dann noch erinnert werden, was die Stichpunkte darauf bedeuten.

Um die Sache zu optimieren haben wir unsere Definition of Done erweitert: Die Aktualisierung des Changelogs, sobald eine Story (oder ein Bugfix) implementiert wurde ist neu dazu gekommen. So kann man die DoD auch prima als Checkliste dafür verwenden, ob ein Zettel am Taskboard auch tatsächlich nach “Done” umgehängt werden darf.

Boris Gloger, der mein Certified Scrum Master – Training durchgeführt hat, sagte zwei Dinge, die mir im Ohr geblieben sind.

“Als Scrum Master muss man sich mental von seinem Job verabschieden – erst dann kann man wirklich effizient arbeiten.”

und

“Scrum löst keine Probleme in einem Unternehmen – es macht sie nur sichtbar.”

(Von Stephan’s Place @ flickr)

Heute gab es für alle Mitgliedern der Entwicklungsabteilung Feedback-Gespräche in der Firma. Mit unserem Abteilungsleiter (der gleichzeitig auch PO ist) und unserer Human Resources – Verantwortlichen. Im Grunde sehr positiv, ich machen anscheinend einen guten Job Bermerkenswert war jedoch das HR-Feedback: Da waren einige Dinge auch etwas negativ aufgefallen.

Interessanter Weise sind die bemängelten Umstände direkte Auswirkungen des Fakts, dass ich mich bemühe – spätestens seit dem CSM-Training – den Scrum Master auch konsequent zu leben. Als Scrum Master ist man quasi ein Schäferhund: Man hält sein Team zusammen und treibt es in die richtige Richtung – man verteidigt es aber auch nach außen. Leistet das Team gute Arbeit braucht es sich keine Vorwürfe gefallen zu lassen. Arbeitet das Team hochkonzentriert darf man es nicht mit – natürlich immer “extrem wichtigen”, aber tatsächlich nicht kritischen – Fehler und Wünschen aus seinen Aufgaben reißen. Das senkt die Performance, weil die Entwickler umdenken müssen, um sich mit dem neuen Problem zu befassen.

Natürlich bedeutet das eine Umgewöhnung für alle Beteiligten. Früher kam jeder Anwender (und auch der CEO) mit Fehlern und Wünsche direkt zum ihm verantwortlich erscheinenden Entwickler. Heute muss er damit zum Scrum Master oder Product Owner, bekommt sogar einen Rüffel, wenn er sich nicht daran hält. Und Wünsche werden – im Gegensatz zu Fehlern – auch nicht mehr sofort berücksichtigt, sondern vor dem Hintergrund des Geschäftswertes bewertet und priorisiert.

Außerdem fordert Scrum Konsequenz. Es gibt nur eine Hand voll fester Rituale, mit festen Terminen und harten Timeboxen – und die sind von allen Beteiligten unbedingt einzuhalten. Es sei denn die Firma brennt. Sofern das Umfeld bis dato Pünktlichkeit bei Meetings und Konsequenz in deren ungestörter Durchführung eher als verhandelbar betrachtete erfordert natürlich auch das ein Umdenken.

Letztendlich steckt jedoch hinter den Scrum-Prinzipien ein ganz einfacher und verständlicher Zweck: Die (teure) Arbeitszeit der Entwickler optimal zu nutzen und nicht zu verschwenden. Eine konsequente Verfolgung dieser Ziele sollte daher jeder Firma Jubelschreie entlocken.

Letztendlich gibt es so etwas wie “ein bisschen Scrum machen” nicht. Entweder, die Firma steht vollkommen dahinter – oder sie macht kein Scrum.