Schlagwort-Archive: schulung

Scrum Master Tipps: Der Umgang mit „schwierigen“ Teammitgliedern in Scrum

EINLEITUNG

Scrum-Teammitglieder können „schwierig“ sein. Es gibt manchmal welche die nörgeln,  welche die generell denken alles besser zu wissen, welche die meinen „Scrum ist wieder so ein Modewort. Welche Sau wird als nächstes durchs Dorf getrieben?“, welche die bewusst nicht im Team arbeiten wollen, welche die einfach gar nichts machen und so weiter…

Natürlich wird in agilen Frameworks wie Scrum empfohlen das Problem auf den Tisch zu packen („Transparenz“) und mit Hilfe der Gruppe gemeinsam einen Lösungsweg zu finden („Selbstorganisation“, „Reflektion“, „Commitment“, „Mut“).

Jedoch kann dies auch nach hinten losgehen, die Person baut eine starke Abwehr auf, was das Konfliktpotenzial noch mehr erhöht („Druck erzeigt Gegendruck“), oder fühlt sich im Extremfall sogar gemobbt.

Natürlich, eine reflektierte, offene, reife  Person sollte kein Problem haben mit Unterstützung des Teams Lösungswege zu vereinbaren. Aber wenn die angesprochene Person solche Werte hätte wie gerade erwähnt, würde sie  kein Quengler, Querulant oder ähnliches sein.

SCHLAU MACHEN

Bevor wir die Konfliktsituation gleich ins Team geben, sollten wir uns vorher ein Bild verschaffen, WARUM unsere Kollegin oder unser Kollege so agieren. Durch diese Erkenntnis können wir herausfinden, was es braucht, damit das Teammitglied sich freiwillig ändert, sofern das Verhalten schlecht für das Team und die Teamergebnisse ist. Denn: Nicht jeder Konflikt oder jede „Störung“ muss auch gelöst werden.

WERTEARBEIT

Ich bediene mich zur „Motivforschung“ gerne der „Wertearbeit“.

Jeder Mensch wird von nur einigen wenigen Werten „angetrieben“. Tun wir etwas bei dem wir uns richtig wohl fühlen, bedienen wir unsere inneren Werte, fühlen uns gut dabei und schöpfen Kraft und Energie daraus. Viele Menschen betreiben Hobbys um Ihre Werte zu bedienen, weil diese in Ihrem Job  oft zu kurz kommen.

Tun wir etwas bei dem wir „so ein komisches Bauchgefühl“ haben oder uns richtig unwohl fühlen, dann arbeiten wir gegen unsere inneren Werte. Wir fühlen uns unwohl und verlieren Energie.

Jeder Mensch hat eine ganz eigenen Kombination innerer Werte die Ihn antreiben, sozusagen die inneren Richtungsgeber. Und da jeder Mensch ein individuelles Wertesystem hat, kollidieren diese oft miteinander.

Wenn wir also Kollegen haben die sich dauern querstellen, tun die dies, weil sie das in diesem Moment gut finden.  Sie bedienen in dem Moment einen oder mehrere Ihrer Werte. Das dies aber dann dummerweise den Werten anderer zu wieder läuft, passiert oft. Und somit haben wir viel Stoff für Konflikte.

Leider sind uns unsere Werte in der Regel oft nicht bewusst, oder wir denken sie zu kennen, jedoch kennen wir nur einen „Überbegriff“ und nicht die tatsächlichen Werte.

Wenn wir diese Werte nun kennen lernen, verstehen wir plötzlich auch warum wir in vielen Situationen so sind wie wir sind und haben damit das Potenzial uns eigenverantwortlich und bewusst weiterentwickeln zu können.

Also hilft es ungemein die Werte der Person, die als „schwierig“ gilt, zu kennen, um zu sehen, warum sie so handelt wie sie handelt.  Wir können keine Menschen dauerhaft ändern, das muss von der Person selber gewollt sein. Um dies jedoch zu unterstützen, haben wir, mit der Kenntnis ihrer Werte, die Möglichkeit aufzuzeigen, wie  auch ein geändertes Verhalten diese Werte bedienen könnte. Und was sich gut anfühlt, wird eben gerne getan – also der erste Schritt zur Änderung.

PRAXIS

Um nun die personenbezogenen Werte herauszufinden, gibt es einige Möglichkeiten. Eine der effektivsten ist (neben Beobachtung und Gesprächen, also dem „Tagesgeschäft des Scrum Masters“) das Tool „Moving Motivators“ einzusetzen.

Hiermit können wir sehen welche (Motivations)Werte die Person hat und ob diese durch die aktuelle Situation bedient oder unterdrückt werden. Aus dem Ergebnis können dann gemeinsam Maßnahmen in Richtung Änderung abgeleitet werden.

Natürlich gibt es auch die Möglichkeit durch echte Wertearbeit (Systemisches Wertecoaching) in einer Kurzzeittherapiesitzung die Werte herauszuarbeiten. Dafür nutze ich gerne meine Wertetabelle als Grundlage.

Außerdem: Die Werte einer Person zu kennen, zum Beispiel des Vorgesetzten oder eines Entscheidungsträgers, hilft ungemein weiter im Berufsalltag. Wenn wir ein Vorhaben oder bestimmte Ziele so verpacken,  dass die Werte dieser Person bedient werden, können wir dadurch in der Regel mit Ihrer Unterstützung rechnen.

FAZIT

Ein guter Scrum Master kennt die Werte jedes einzelnen seiner Teammitglieder. Dies ist natürlich mit viel Arbeit verbunden, aber genau so etwas macht einen guten Scrum Master aus. Einfach nur das Framework zu kennen ist einfach nicht genug um ein Team effektiv zu unterstützen und es zu langfristiger „high performance“ und Zufriedenheit im Beruf zu führen.

SCHLUSSWORT

Natürlich sind „Moving Motivators“ und die „Wertearbeit“ nur ein kleiner Teil von Lösungsansätzen im Umgang mit „schwierigen“ Teammitgliedern. Wer mehr darüber erfahren möchte, dem empfehlen wir den Besuch des Seminars „Scrum Master 2.0 (R)“

(c) 2019 AML

Microtrainings – Sinn oder Unsinn?

Allgemeines

Microstrainings sind Minni-Workshops, die in der Regel zwischen 15 und 60 Minuten dauern können. Sie eignen sich um schnell und kompakt Wissen zu einem speziellen Thema zu vermitteln.

Wann

Diese Art der Wissensvermittlung lässt sich einfach und unkompliziert in unterschiedlichem Kontext einbauen.

Ich nutze diese gerne um Scrum-Teams schnell verschiedene Kommunikations- und Konfliktlösungstool beizubringen. Die Microtrainings nutze ich aber auch um „große“ Schulungen vor- und nachzubearbeiten.

Sie eignen sich außerdem auch perfekt um Beispielsweise neue Produkte für Verkaufsteams, oder interessante Programmiermethoden und/oder –lösungen vorzustellen.

Microtrainings benötigen nicht viel Zeit und lassen sich Scrum-Events, wie einer Retrospektive, gut nachlagern. Auch als Vorbereitung für Scrum Master-Teams, wenn diese eine große, agile Veranstaltung organisieren  sollen, sind sie ideal.

Rentabilität

Als Vorbereitungsmaßnahme vor Kursen unterstützen sie einen einfacheren Wissenstransfer während des Kurses und nachgelagert geschickt eingesetzt,  können sie das Wissen noch vertiefen.

Auch als niedrigschwelliges Einstiegangebot zum Kennenlernen einer Dienstleistung oder eines Wissensthemas eignen sie sich optimal.

Durchführung

Organisatorisch ist der Aufwand oft gering. Die Vorbereitungen sind in der Regel nicht so umfangreich wie bei einem 2-Tageskurs. Und sie können auch mal spontan, einfach mit Flipchart & Stift, abgehalten werden.

Aus meiner Praxis empfehle ich eine Gruppengrüße von 4 – 6 Teilnehmern, vor allem wenn ich nach der Inhaltsvermittlung noch einen Frageblock einplane. Bei mehr Teilnehmern werden sonst die Diskussionen oder Fragen zu umfangreich und sprengen die time box.

Sollen mehr Teilnehmer einer Gruppe geschult werden, dann mache ich auch mehrere Termine.

Microtrainings können auch modular, aufeinander aufbauend, durchgeführt werden. Durch die kleine Gruppengröße ist eine Umsetzung oft auch einfach am Arbeitsplatz oder in der Mittagspause möglich. Oft werden keine speziellen Kurs- oder Meetingräume benötigt.

Die besten Erfahrungen habe ich, wenn ich mit meinem tragbaren Minni-Whiteboard mit den Teilnehmern eine Microtraining  im Park oder einfach irgendwo  im Freien veranstalte.

Aufbau

Ein Microtraining ist im Grunde wie ein „normaler“ Kurs aufgebaut:

  • Begrüßung & Fokussierung der Teilnehmer: Nach einer kurzen, wertschätzenden  Begrüßung hole ich sie zuerst aus ihrem (Arbeits)Alltag weg von ihren Gedanken, in den Raum. Dazu habe ich eine große Anzahl agiler Spiele in meinem Methodenkoffer die ich situativ anwende, d.h. je nach Stimmung und mentalem Zustand der Teilnehmergruppe.
  • Sinn der Trainingssession: Danach erkläre ich den Sinn und vor allem das Ziel der Trainingssession, also was das konkrete Ergebnis des Microtrainings sein soll.
  • Informationsvermittlung: Nun beginnt die eigentlich Vermittlung der Inhalte der Trainingssession. In der Regel nutze ich dabei gerne einen Mix aus vorbereiteter Präsentation (Flip Charts oder  PowerPoint) und während der Session entsteht in der Regel auch ein oder mehrere neue Plakate auf dem Flip Chart Board, der Planwand oder auf einem White Board.
  • Übung: In der Regel baue ich danach eine Übung ein, in der die Teilnehmer das Gelernte erleben könne.  Wenn wir etwas selber erleben, bleibt es haften. Von reiner Theorie, also Frontalvorträgen, bleiben in der Regel nur 10% bis 15% hängen.
  • Feedback: Nach der Veranstaltung lass ich mir auch gerne ein Feedback geben zum Inhalt und zum Rahmen der Veranstaltung.  Auch hier gibt es mannigfaltige Möglichkeiten zu messen wie zufrieden die Teilnehmer sind.
  • Abschluss: Auch hier platziere ich eine wertschätzende Verabschiedung.
(c) 2019 (AML)

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

Teilnehmerfeedbacks

Seminar: IT-Teams führen und motivieren:

"Der Kurs hat mir zu einem unerwartet neuen Blick auf meine Mitarbeiter als Individuum verschafft. Die Umsetzung des Gelernten führt zu erkennbar gestärkter Akzeptanz meiner Position als Führungskraft, zu offenerer Kommunikation im Team und zu einer Reduktion von Konfiktpotenzial..." (Matthias R. advanto Software GmbH)

Seminar: Agiles Projektmanagement mit SCRUM

"Wirklich gutes Seminar / Training mit Alexander Loitsch in Hamburg. Die Inhalte wurden sehr gut kommuniziert. Die kleine Teilnehmergruppe hat ebenso wie Alexander Loitsch mit seinen Kompetenten Skills und Praxiswissen zu einem sehr kurzweiligen und hoch interessanten Seminar beigetragen.

Ich bin mir sicher, dass wir das vermittelte Wissen nun schnell und effektiv in unser Unternehmen bringen werden. Fazit: Sehr gut – Inhalte Praxisorientiert & auf den Punkt gebracht – sehr empfehlenswert!" (Oliver Brokowsky – Geschäftsführer BCOB GmbH- Hamburg).

Seminar: Agiles Projektmanagement mit SCRUM

"Das SCRUM-Seminar bei Dr. A. M. Loitsch würde ich jedem weiter empfehlen. Das Material wurde gut verständlich vermittelt. Es wurde auf meine Probleme eingegangen und alles am Beispiel meines Projektes erläutert. Außerdem haben viele nützliche Tipps und Tricks das Seminar gut ergänzt..." (Roman S. Complevo GmbH)

Seminar: SCRUM- Agiles Softwareentwicklung im Team

„Das SCRUM Training war sehr informativ. Besonders gut haben mir die Teambuilding-Aspekte gefallen. Ich kann den Kurs nur weiterempfehlen. (Rainer M.)“


Seminar: IT-Teams führen und motivieren:

"Kompetente Seminargestaltung mit exemplarischen Beispielen aus der Praxis unter Berücksichtigung und Einbeziehung der inviduellen Berufssituation der Teilnehmer. Sehr empfehlenswert. (Ralf Greiser, GEMALTO"


Agiles Projektmanagement mit SCRUM

"Das Seminar war für mich wirklich sehr spannend, da ich mit dem Thema bisher noch keine Berührungspunkte hatte. Die Inhalte waren fast alle neu für mich und ich werde mich in Zukunft mehr damit auseinandersetzen. Viele Praxisbeispiele gab es sowohl zur Veranschaulichung von den Themen als auch bei Fragen von Seminarteilnehmern. Wir haben viel gelernt und das auch mit viel Spaß. Die Stimmung während des Seminars war sehr angenehm und ausgeglichen und ich habe mich sehr wohl gefühlt. Ich kann das Seminar wirklich sehr empfehlen. (Vanessa C.)"


Mehr Bewertungen unter "Freelancermap".

-  (c) 2018 -  AML -