Schlagwort-Archive: coaching

Tipps für angehende Scrum-Master: Das „Daily Scrum“-Event

Können Sie sich erinnern, was Sie vor ein paar Tagen gegessen haben? Oder vor einer Woche oder einem Monat? Wir erinnern uns nur an die außerordentlich köstlichen (oder außerordentlich schlecht schmeckenden) Mahlzeiten.

Aber alle waren wichtig, auch wenn wir uns nicht an sie erinnern. Denn wenn wir keinen von ihnen gegessen hätten, wären wir jetzt nicht am Leben. Ebenso schadet es nicht, ab und zu eine Mahlzeit zu verpassen. Wenn Sie dies jedoch häufig genug tun, verlieren Sie langsam an Gewicht und werden schwächer.

In diesem Sinne sind tägliche Scrums, die „daily standup events“, wie Essen: Sie spielen eine entscheidende Rolle, um den Entwicklungsprozess des Scrum-Teams gesund zu halten. Für manche Menschen ist diese „agile Mahlzeit“ jedoch ein nicht gut schmeckendes Gericht. Manchmal kann sich das Daily lästig, unnötig oder unangenehm anfühlen, und Sie würden es lieber ganz überspringen.

Hier sind einige Einwände, die Sie möglicherweise von Mitgliedern des Scrum-Teams oder sogar vom Management in Bezug auf das tägliche Scrum hören könnten:

„Es ist langweilig. Die Tätigkeiten an denen anderen arbeiten, haben nichts mit meiner Arbeit zu tun. Die interessieren mich ja gar nicht.“:

Aber: Das daily scrum event  ist ein Weg, um alle über das, woran alle anderen arbeiten, auf dem Laufenden zu halten. Dies ist wichtig, um ein funktionsübergreifendes Team aufzubauen. Die Teammitglieder erfahren auch, wie die Arbeiten, an dem sie arbeiten, in die Arbeiten anderer Personen passt. Dies ist besonders wichtig, wenn nicht alle Teammitglieder an demselben Projekt arbeiten.

Und selbst wenn sie an völlig unterschiedlichen Anwendungen arbeiten, können die Probleme, mit denen die einzelnen Teammitglieder konfrontiert sind, gemeinsame Merkmale aufweisen. Wenn Peter hört, dass Andrea, ein Junior-Teammitglied, mit einem Problem zu kämpfen hat, das sie zu beheben weiß, kann sie diese Gelegenheit nutzen, um Andrea zu coachen.

„Entwickler sprechen bereits den ganzen Tag miteinander. Dafür brauchen wir kein tägliches Treffen. „:

Die spontanen Unterhaltungen, die während des Tages stattfinden, sind in der Regel „Tagesgeschäft“ im Scrum: Peter hat einen Compilerfehler. Michael benötigt einige Informationen von Andrea, bevor er eine Schnittstelle definieren kann. Peter kann nicht herausfinden, warum eine Datei fehlt und so weiter. Sie konzentrieren sich auf die Behebung sofortiger Probleme, während das daily scrum event eher ein taktisches Planungstreffen ist in dem der Status der Arbeit aus dem aktuellen Sprint besprochen wird.

Es ist keine Besprechung zur Problemlösung, sondern eine Besprechung, bei der der Staus bekannt transparent gemacht und Probleme die unsere Arbeit behindern oder verhindern  (impediments) bekannt gegeben werden. Das Team findet so heraus wer blockiert ist und wer helfen kann.

„Dies ist doch nur eine Statusbesprechung. Die Zeit können wir uns sparen um zu arbeiten“:

Ja, Entwickler teilen ihren Status. Aber das ist wie sich zu beschweren, dass Sie einatmen müssen, um zu atmen. Wenn das daily scrum event nur aus der Beantwortung der drei Fragen besteht, was ich getan habe / was ich tun werde / was mich behndinert und nichts anderes, dann ist es in der Tat nur eine Statusbesprechung.

Aber genau wie Sie nicht atmen können, indem Sie nur einatmen und niemals ausatmen, wird Ihr daily scrum event  nicht wirken, wenn die gesamte Kommunikation die vom Entwickler kommt zurückgehalten wird. Es handelt sich bei dem täglichen event  um ein Meeting, bei dem für die Tagesarbeit im Scrum schwerwiegendere Probleme auftreten können, wenn niemand etwas kommentiert oder weitere Fragen stellt.

„Es ist ineffektiv oder unhöflich, wenn Sie niemanden außer Entwicklern daran teilnehmen lassen.“:

Das daily scrum ist. losgekoppelt von den technischen Details, ein Meeting auf höherer Ebene, aber nur für kurze Zeit. Wenn das Team das so sieht, sind sie möglicherweise weniger geneigt, auf „fremde“ Teilnahme zu bestehen. Und mit einer 15-minütigen time-box  bleibt ohnehin nicht viel Zeit für andere Personen, um effektiv teilzunehmen.

Daily Scrum zu haben ist wie eine gesunde Ernährung. Möglicherweise möchten Sie dies nicht immer tun, und einige der Mahlzeiten sind möglicherweise langweilig oder gelegentlich ausgesprochen schlecht schmeckend, aber Sie können sie nicht überspringen. Sie sehen möglicherweise keine unmittelbaren negativen Auswirkungen bei Nicht-Einhatung, und die Leute sind möglicherweise sogar glücklich darüber.

Dies wird jedoch die Beweglichkeit und den Zusammenhalt des Teams im Laufe der Zeit beeinträchtigen. Ebenso kann es natürlich einige Zeit dauern, bis sich positive Effekte durch das daily manifestieren, aber sie helfen auf jeden Fall dem Team sich zu verbinden und ein höheres Leistungsniveau zu erreichen

(c) AML 2019

Vergleich von skalierten SCRUM-Frameworks: LeSS, SAFe und Scrum@Scale

Eigentlich gibt es ein, laut Craig Larman and Bass Vodde (Erfinder von LeSS), nur eine primäre Regel für alle  "scaled frameworks":  Lassen Sie die Finger davon! 🙂

Hinweis: Dieser Fachartikel behandelt die Unterschiede zwischen den agilen Rahmenwerken LeSS, SAFe und Scrum@Scale. DAD (Disciplined Agile Delivery) und Nexus werden hierbei nicht betrachtet.

EINLEITUNG

Wenn Sie Probleme mit Abhängigkeiten zwischen Teams haben, Risiken die gleichzeitig verschiedene Bereiche betreffen und der Planung von koordinierten Auslieferungen eines Produktes oder (Teil)Instanzen, dann sind sie reif für skalierten SCRUM.

GEMEINSAMKEITEN

Die Gemeinsamkeiten von LeSS, SAFe und Scrum@Scale: Sie basieren auf „klassischen“, cross-funktionalen und selbstorganisierten SCRUM-Teams.

LARGE SCALE SCRUM (LeSS)

Dieses Framework wurde von Craig Larman and Bas Vodde entwickelt und kommt aus den Bereichen Finanz- und Telekommunikationsbranche. Es basiert darauf Prozesse so einfach und klein wie möglich zu halten, d.h. mit minimalem Aufwand mehrere Teams „zum Laufen zu bekommen“. Dazu bedarf es nur einer Handvoll Regeln.

Basis (bis 8 Teams)

Die Basisidee hinter Less ist es, bereits funktionierende Scrum-Teams nicht nach Projektende aufzulösen, sondern als langfristig agierende „scrum facility“ zu etablieren die in  verschiedenen Projekten tätig sind. Es gibt mehrere Scrum-Teams mit nur einem Product Owner und einem gemeinsamen Backlog. Die Sprints laufen parallel mit dem Ziel alle Ergebnisse in ein einziges, gemeinsames PSPI („Potentially Shippable Product Increment“ ) zu implementieren. Die Scrum-Events  „Sprint-Planning“, „Sprint-Review“ und „Sprint-Retrospektive“ finden in allen Teams gleichzeitig, also parallel,  statt.

Abweichungen

Jedes Team arbeitet also erst mal mit „echtem Scrum“ mit folgenden Abweichungen:

  • Sprint-Planning: Dieses wird in zwei Teile aufgesplittet. In Teil 1 treffen sich Repräsentanten aus den Teams zu einer gemeinsamen Betrachtung und Planung welche PBIs (Product Backlog Items) aus dem Backlog in den Sprints umgesetzt werden soll. In Teil zwei beschließen dann die Teams intern wie die PBIs im kommenden Sprint umgesetzt werden und bauen Ihr Sprint Backlog.

Dabei sehe ich persönlich einen großen Nachteil, der gegen das „agile mindset“ (gemeinsame Team-Beschlüsse, Transparenz und gleicher Wissensstand für alle Beteiligten) arbeitet und somit eine große Schwachstelle darstellt: Es wählen also nur einzelne Teammitglieder, stellvertretend für Ihr Team, die Backlog Items aus.  Die Auswahl sollte jedoch das GANZE  Developer Team treffen.

  • Retrospektive: Auch hier wird in zwei Teile aufgeteilt. Teil 1 ist die „interne“ Retrospektive jedes Scrum-Teams. Im zweiten Teil treffen sich wieder Repräsentanten aus jedem Team um gemeinsam eine Retrospektive abzuhalten um Issues zu identifizieren, die nicht vom Team selber gelöst werden können.

Es besteht dabei ebenfalls eine Gefahr: Es könnte sein das das Team es sich leicht macht und unbequeme Themen, die nicht so beliebt sind oder ein umfangreicheres Verlassen der Komfortzone benötigen würden, einfach in die Verantwortung der Teil 2-Runde  abschiebt.

Größere LeSS-Implementierungen (mehr als 8 Teams)

Wenn mehr als acht Teams an einem Product Backlog (BP) arbeiten, wird es Zeit es in mehrere Aria-Product-Backlogs (A-PB) zu unterteilen.

Jedem BPB werden 4 – 8 Teams zugeordnet und jeder Area ein eigener Area Product Owner (A-PO).

SCALED AGILE FRAMEWORK (SAFe)

Dieses Framework wurde von Dean Leffingwell im Jahr 2011 vorgestellt. Es teilt die zu leistende Arbeit in „value streams“ auf. Innerhalb eines Streams gibt es ein oder mehrere „release trains“. In einem „release train“ werden dann 5 – 15 Scrum-Teams eingesetzt.

Die Sprints der Teams sind in der Regel auf eine Länge von 2 Wochen festgelegt. Als time box container dazu fungiert ein „program increment“ von 8 – 12 Wochen.

Dieses beginnt mit dem PI-Planning („big room planning“). Die time box dafür beträgt 1 – 2 Tage. In dieser Zeit treffen sich alle Teams und planen die nächsten 8 – 10 Wochen („progam increment“) gemeinsam, d.h.  welches Team was umsetzt und wie die Abhängigkeiten zwischen den Teams sind. Das Ergebnis wird am „program board“ visualisiert.

Das „program Increment“ wird von einem „Release Tran Engineer“ (vergleichbar mit einem agilen Coach) unterstützt.

Die Sprint Backlog Items werden in drei Kategorien eingeteilt:

  • Fehlerbehebung (wird vor allem anderen priorisiert)
  • Items vom „big room planning“
  • Themen die ungeplant zusätzlich umzusetzen sind

Die Sprints werden dazu nur zu 30 – 70% „befüllt“ um Raum für Fehlerbehebung und ungeplantes zu lassen.

SAFe arbeitet auf drei Ebenen: „Protfolio Level“ (Rollen: Portfolio Manager, Entrerprise Architect, Epic Owner), darunter die „Program level“ mit Ihren „program increments“ (Rollen: System Architect, Product Manager, „Release Train Engineer“) und „Team Level“ mit den SCRUM-Teams (Scrum Master, Developer, Product Owner).

Zwischen den einzelnen Ebenen und in den einzelnen Ebenen gibt es noch unterschiedlichste Meetings und Events.

Auf den ersten Blick ist zu erkennen dass wir es mit eine überbordendenden Menge an Rollen, Levels und Meetings zu tun haben. Das erhöht das Risiko das dieses Framework sehr unflexibel und schwerfällig wird, ähnlich klassischen Prozessen.

SCRUM@Scale

Jeff Sutherland, einer der Gründer von SCRUM, hat dieses „Meta-Level-Framework“ entwickelt. Es besteht aus einem „Product Owner Cycle“ und einem „Scrum Master Cycle“ sowie  einigen Prinzipien bezüglich Metriken und Transparenz. Für jeden „Cycle“ wurde eine Liste von Fragen/Diskussionen definiert die es zu führen gilt um „normalen SCRUM“ skalieren zu können.

Der Vorteil diese Methode liegt darin, dass es keine festen Vorgaben gibt und somit das eigene agile Framework (auf Basis des „agile mindsets“) mittels der u.a. Fragen entwickelt werden kann. Es ist, (unbedingt mit Hilfe von erfahrenen SCRUM-Coaches!) möglich ein maßgeschneidertes „agile scaled framwork“ zu etablieren.

PO-Cycle:

  • Strategische Vision: Wohin wollen wir mit unserer Firma und unseren Produkten
  • Backlogpriorisierung: Was ist das Wichtigste auf Firmenlevel, Portfoliolevel und im Projekt?
  • Backlogrefinement: Wie verteilen wir die Tasks auf die Teams und wie führen wir die entsprechenden Events dafür durch?
  • Releaseplanung: Wie können wir unsere Auslieferungen planen? Was soll wann geliefert werden?
  • Releasemanagement: Wie synchronisieren wir die Teams um einen “smoothen launch” zu ermöglichen?
  • Product- & Releasefeedback: Wie bekommen wir Feedback über die letzten Release-Features von den Usern/Kunden und wie bekommen wir die Informationen ins Team

SM-Cycle:

  • Cross-Team Koordination: Wie könne wir die verschiedenen Scrum-Teams so koordinieren, das wir dieselben Arbeiten nicht mehrfach durchführen müssen?
  • Laufende Optimierung & Lösen von Impediments: Wie können wir sicherstellen das sich alle Teams Ihrer skills (personal, soft, tech.) bewusst sind und konstant versuchen diese zu verbessern?
  • Wie können wir sicherstellen dass alles, was aus dem Team an Impediments kommt, auch dann gelöst wird, wenn es außerhalb ihres Kompetenzbereichs liegt?

Außendarstellung:

Metriken & Transparenz: Wie können wir messen und feststellen dass wir alles richtig umgesetzt haben und wie können wir sicherstellen dass jeder Zugang zu diesen Informationen hat?

LINKS

(c) AML 2019

Du bist was du siehst – Medienverhalten und unser Charakter

Viele Menschen in unserem privaten oder beruflichen Umfeld geben sich anders als sie tatsächlich sind. Es besteht jedoch die Möglichkeit Ihren wahren Charakter zu erkennen, indem wir uns Ihr Medienverhalten genauer ansehen. Continue reading “Du bist was du siehst – Medienverhalten und unser Charakter” »

Wir leben in einer Stressgesellschaft

Arbeit & Stress

Den Begriff „Stress“ gibt es erst seit 1936. Damals begründete Hans Selye die Stressforschung. Heute ist das Wort in aller Munde. Die Arbeit, die Familie, die Freizeit – selbst das Nichtstun empfinden heute viele als stressig. In Experimenten verabreichen sich viele Probanden lieber selbst Stromstöße, als sich der Langeweile des Alleinseins hinzugeben.

Continue reading “Wir leben in einer Stressgesellschaft” »