Meine Dienstleistung Ihr Nutzen – Scrum Master, Product Owner, Scrum Coach

 

Als ScrumMaster sehe ich mich als Ihr Talenteentwickler. Für mich ist es extrem spannend Ihren Teams dabei zu helfen, selbstorganisierend eine Teamstruktur aufzubauen. Dazu gehört die Entwicklung stabiler und wertschätzender Kommunikation auf Augenhöhe.

scrum Maskottchen

IHR NUTZEN

  • Sie profitieren von meiner  langjährigen Erfahrung als ScrumMaster in der Softwareentwicklung in digitalen Transformationsprojekten.
  • Als Ihr freiberuflicher Scrum Master sorge ich für einen effektiven Scrumprozess.
  • Als Ihr freiberuflicher Product Owner liegt mein Fokus auf Vision|Backlog|Aufwandschätzung|Priorisierung|Releasemanagement.
  • Sie ziehen Nutzen von meinem Scrum Coching bei der Herausforderungen Scrum einzuführen.
  • Durch meine Erfahrungen aus mehreren Jahren im Ausland leade ich mit hoher interkultureller Kompetenz (Distributed Scrum, Scaled Scrum, Scrum of Scrums, Nexus).

Mein Portfolio

Scrum

Sechs wichtige Scrum Coaching Schwerpunkte 

1) Wertschätzende Kommunikationsstrukturen

Kommunikationsstruktur
Nur durch klare Kommunikationsstruktur sind wir effizient!

Die gute Kommunikationsstruktur ist für mich die Basis für die optimale Anwendung des  gesamten Scrumprozesses. Nur wenn das Developement Team, der Product Owner und die Stakeholder Ihre Rolle und Verantwortung kennen, führt Scrum zum Erfolg. Diese Struktur aufzubauen, und hier einen vertrauenswürdigen, kreativen Handlungsraum zu schaffen, verstehe ich als wichtig Aufgabe als ScrumMaster für Sie. Wie schaffe ich das? Ich persönlich rede einfach gerne mit meinen Kollegen und Kolleginnen. Auch interessiere ich mich für sie. Welche Skills haben sie, welchen Background haben sie und was sind ihre Wertehaltungen? Besonders die Wertehaltungen sind für mich essentiell. Nur wenn die Wertewelt halbwegs zusammenpasst, wird das Team innovativ sein, selbstorganisiert agieren und performen können.

2) Gegenseitiges Vertrauen

Meiner Erfahrung nach bringt das Scrumframework mit seinen Rollen, Prozessen und agilen Modalitäten bei hoher Disziplin den gewünschten Mehrwert zu 100%. Der Enabler dazu ist gegenseitiges Vertrauen.  So wie im Rugby der Spielezug „Scrum“ einer bestimmten Regel folgt, so ist für das ScrumTeam die Annerkennung gemeinsamer Regel unerlässlich. Dadurch kommt Verlässlichkeit ins Team und somit Vertrauen.

3) Scrum Teambuilding hat eine ganz eigene Gruppendynamik

In jedem Projekt herrschen andere Grundbedingungen und mein Coachingschwerpunkte sind daher jedesmal anders gelagert. Zullerst sind die Teammember wenig vertraut, sehr höflich und orientierungssuchend im Umgang.

Um das ScrumTeam zu formen (ScrumMaster, ProductOwner, DevelopmentTeam) habe ich sehr, sehr gute Erfahrungen mit dem Innovation Game „Product Vision Box“ gemacht. Für mich ist dieses Game sehr entscheidend darüber, ob der Scrum erfolgreich wird, oder nicht. Warum vertrete ich diese Meinung? Im Laufe der Jahre hat sich gezeigt, dass ein Scrumprojekt aufgrund zweier zentraler Fehler scheitert: Erstens – das DevelopmentTeam und der ScrumMaster kennen das Produkt nicht E2E, und zweitens – der ProductOwner liefert schlechte User Stories. Die Product Vision Box hilft ein gemeinsames Produktverständnis zu entwickeln. So nehme ich die Product Box dann zu jedem Meeting mit. Die Symbolwirkung ist enorm – jeder weiß woran wir wirklich arbeiten. Diese Herangehensweise hilft sehr dabei, das DevelopmentTeam in seiner Motivation vor Gold Plating, aber auch vor Scope Crepe zu schützen.

Scrum Team Building
Der Scrum Team Building Prozess hat eigene Gesetze!

Die crossfunktionalen, oft interkulturellen Teams müssen sich nicht nur als Kollegen und Kolleginnen sondern auch als Experten finden. Sehr gerne und seit mehreren Jahren verwende ich in dieser Phase der Gruppenbildung entweder „Mitch Lacey Team Prioritization“ oder „Affiniy Map„. Der Vorteil ist, dass das Team den Umgang mit dem Instrument Whiteboard und Sticky Notes lernt. Ich setze die Innovation Games gerne vor Sprint 0. Im Sprint 0 beginnt die Phase der persönlichen Positionierung. Für mich ist diese Phase sehr wichtig, weil sich hier die Expertise jedes einzelnen herauskristillisiert. Hier formt sich das Team funktional. Vor der ersten Retrospektive spiele ich mit dem Team „Actions for Retrospectives„.  Hier ist es mir ein Anliegen, dass der ProductOwner anwesend ist. Meiner Erfahrung nach beginnt erst nach dem Sprint 0 und nur mit der Unterstützung durch Innovation Games ein verfestigen der Selbstorganisation. Falls es nicht rund läuft, führe ich die „Trading Cards“ ein. Das macht Spaß und ist nicht so kompliziert und zeitaufwendig wie die Entwicklung von guten Personas. Dennoch ist etwas Geduld nötig. Der Scrumflow wird erst nach 2 – 3 Sprints wirklich effizient.

4) Es geht um Erwartungshaltungen

Its all about people!Daher ist eine meiner dringlichsten Empfehlungen die Erwartungshaltungen gleich zu Beginn miteinander besprochen werden. Dabei sollten folgende Fragen geklärt werden:

  • Was kann man von mir erwarten?
  • Was erwarte ich vom Team?
  • Was erwarte ich vom Product Owner, SrumMaster, Scrum Team?
  • Was erwarte ich von der Organisation?

5) Scrum ist Disziplin und Ordnung

Eine dogmatische Herangehensweise in Scrum ist wenig zielführend. Ganz im Sinne von Ken Schwaber und Jeff Sutherland bin ich davon überzeugt, dass Scrum flexibel sein muss. Nur so lässt sich die Methode erfolgreich in Ihr Unternehmen implementieren.
Dennoch ist einer der wichtigsten Aspekte von Scrum die Ordnung. Ordnung ergibt sich

Scrum Rollen
Das gute Rollenverständnis des Scrum Teams entscheidet über den Erfolg!

durch das Time Boxing, der Definition of Done (Fertig ist fertig!), den Acceptance Criteria, dem Prinzip „Avoid Waste!“, Entscheidungen auf Basis der empirischen Sprintergebnisse und den passenden User Stories. Persönlich plädiere ich dafür, dass die User Stories der Entwicklungsmethode des Development Teams angepasst werden. Wird beispielsweise die Methode Behaviour Driven Development angewandt, dann werden die User Stories als Szenarios benötigt.

6) Wer ist der Enduser?

Bisher bin ich am Besten damit gefahren, wenn der Product Owner, das Developement-Team und ich als ScrumMaster uns darauf einigen konnten, den End-User als die Kunden zu sehen. Das ist in einer E2E-Betrachtung des personenzentrierten Entwicklungsprozesses einer Software für mich das Um und Auf. Die End-User, oder anders ausgedrückt die Anwender, bestimmen in ihrem täglichen Arbeiten den tatsächlichen Nutzen einer Software. Nur wenn die Anwender den Nutzen in der Usability für ihr Tun sehen, wird der erwartete Business Nutzen eingefahren werden.