Transform2agile

Transform2Agile - Agile Transformation im Service

Ich möchte auf dieser Seite im Laufe der Zeit immer wieder Gedanken zum Thema:

Anwendung von agilen Konzepten für Helpdesks,
Customer Service Teams und
Lösungen für Kooperationen in globalen virtuellen Teams

darlegen. Ab und zu werden wir zum besseren Verständnis auch zum Ursprung in der Entwicklung zurückgehen und die Brücke zum Service schlagen und generelle Fragen zur agilen Arbeitsweise klären.

Was bedeutet “agile” ?

Leider denken viele, wenn sie agile Organisation hören, dass die Mitarbeiter von Aufgabe zu Aufgabe springen, und viele Aufgaben gleichzeitig erledigen.
Genau das Gegenteil ist jedoch der Fall.
Ich wurde vor kurzem gefragt, wenn du eine Minute Zeit hättest die Basis agiler Konzepte vorzustellen, was würdest du sagen?

Challenge accepted:

Selbstorganisierte crossfunctional Teams
übernehmen die Verantwortung
für Aufgaben, die sich das Team selber aus einem Pool, der Backlog genannt wird heraussucht
Verpflichtung der Teammitglieder, die selbstgewählten Aufgaben zu erledigen
Erst wenn eine Aufgabe erledigt ist wird die nächste begonnen. Untersuchungen zeigen, dass man sonst zuviel begonnenen und zuwenig abgeschlossene Aufgabe am Ende hat.
Das Team wird nicht zu 100% verplant, es muss eine Reserve für unerwartete Situationen bestehen
Regelmäßiges Feedback durch den Kunden bzw. Stakeholder, um immer wieder zu überprüfen, ob der gewählte Weg richtig ist z.B. in Reviews
Regelmäßiger Austausch im Team am Sprintende (Projektdurchlauf), in der Retrospektive, um aus Fehlern, aber auch neu gefundenen Lösungen zu lernen und diese in die nächste Iteration mitzunehmen
Team ist somit selbstoptimierend
Optimale Länge um das Risiko gering zu halten, ohne aufwendiges Risikomanagement zu betreiben, beträgt maximal 4 Wochen, die meisten Sprints bewegen sich im Rahmen von 2-3 Wochen, da man im Falle eines Fehlers, wenig Arbeitszeit und Geld vernichtet hat.
Aufgabe der Führungskräfte ist Hindernisse (Impediments) zu beseitigen, sowie die Methodenkompetenz zu coachen.
Für alle gilt: Transparenz, Überprüfung und Anpassung sind Pfeiler
Werte die im Team gelegt werden müssen: Mut, Respekt, Commitment, Offenheit, Fokus
Stop starting, start finishing! We don´t pay specialists to tell them what to do, we pay them that they tell us what to do. We manage work not people.
Lean Management Konzepte, Automatisierung wo immer möglich, Constant Improvement
Veränderte Gewichtung von KPIs. Kundenzufriedenheit, Mitarbeiterzufriedenheit, Velocity zeigen den Erfolg von kundenzentrierten Services besser als Ticketmenge, Average Handling Time.

Wenn “Velocity” ein KPI ist, bedeutet das, dass agile Teams schneller sind?

Anfangs eher nicht, da die Methode erst angenommen werden muss und am Anfang auch immer wieder Fragen aufkommen.
Mit der Zeit kann es durchaus sein, dass das Team performanter wird als ein konventionelles Team.
Dadurch, dass das Team erfahrener wird, fokussierter arbeitet und die Hindernisse benannt (->Transparency!) und entfernt werden (z.B. Rolle Scrum Master bei SCRUM) werden, können Aufgaben schneller erledigt werden.
Die “Velocity” wird meistens nicht in Zeit, sondern in Vergleichswerten gemessen.
Dafür gibt es z.B. das Planning Poker als mögliche Methode. D.h. es wird der Schwierigkeitsgrad und der Aufwand von verschiedenen Aufgaben verglichen und in Beziehung zueinander gesetzt.
Mit der Zeit, weiß das Team, wieviele Tasks mit welchem Schwierigkeitsgrad und Aufwand innerhalb eines Sprints erfolgreich erledigt werden können. Ein Anstieg der “Velocity”bedeutetsomit, dass entweder schwerere Aufgaben in einer Sprinteinheit erledigt werden können oder mehr kleinere Tasks bewältigt werden können.
Eine kurze Beschreibung zu Planning Poker gibt es hier: Beschreibung
Die “Velocity” erkennt man dann an der Anzahl Punkte, die im Sprint erreicht wurden.
Mit der Zeit lernt das Team dadurch auch besser den Aufwand von Aufgaben einzuschätzen und zu planen, sodass die Sprint Plannings immer realistischere Planungen erlauben und der Output der Inkremente immer näher an der Erwartungshaltung des Teams und der Stakeholder ist.

Was ist der Unterschied zwischen Nexus und SAFE ?

Nexus ist für ein Produkt gedacht, dass mehrere Entwicklungsteams (3-9) benötigt.
SAFE hat die ökonomische Sicht auf die Wertströme und optimiert diese. Dabei kommen auch Verfahren wie Scrum oder Design XP zum Zuge.
SAFE wird z.B. für multiple Produkte genommen z.B. einem Portfolio. Natürlich funktioniert es auch mit einem einfachen Produkt, bei dem man z.B. Scrum verwendet. Dafür lohnt sich die Komplexität und der Überbau nicht. Daher SAFE eher für Multiproduktumgebungen mit parallelen Streams.

Wie stellt man ein Support Team agil auf, wenn die Frameworks sich primär an Entwickler wenden?

Das Team muß geschult werden um das notwendige Know-How zur Lösungsentwicklung zu haben
Die Teammitglieder sollte über verschiedene Skill Schwerpunkte verfügen
Schaffen einer Sicherheitskultur, d.h. wenn die Teammitglieder etwas probieren und es nicht klappt, sollte keine Angst vor Konsequenzen haben müssen
Musterlösungen und Prozesse schaffen Handlungsrahmen und geben Sicherheit
Dem Team immer mehr Aufgaben geben und es entscheiden lassen, wie es die Aufgaben löst
Immer wieder die Mitarbeiter bestärken, denn nicht immer liegt die Lösung offen vor ihnen
Erfolge feiern und hervorheben um diese als Basis für zukünftige Herausforderungen zu nutzen
Wenn die Prozesse sitzen und die üblichen Aufgaben selbständig erfüllt werden können, der Gruppe eröffnen, dass sie sich weiterentwickelt hat und woran man das erkennt
Ehrliche Anerkennung und Lob unterstützen den Prozess
Die Eigenverantwortung immer stärker betonen
Aufgaben die regelmäßig anstehen identifizieren, Häfigkeiten und Prozesse stellen die Basis der Aufgaben dar.
Aufgabenarten allgemein halten, z.B. Arbeit im Ticketsystem, tägliche Aufgaben, Support Postfach, Floorwalker
Reserven für überraschende Aufgaben einplanen dem Team beibringen z.B. Pareto 80 Prozent geplant und 20 Prozent für nicht planbares.
Sollte keine Überraschung eintreten, kann diese Zeit für Weiterbildung genutzt werden
Um die Teamentwicklung zu unterstützen belohnt man das Teilen von Lösungen mit dem gesamten Team, was gleichzeitig die regelmäße Pflege einer Wissensdatenbank unterstützt
Workshops zur agilen Methodik
Bei der Umsetzung coachen und auf die Einhaltung der zeitbegrenzten Ereignisse (timeboxed events) achten
Wichtig ist, dass die Mitarbeiter sich die Aufgaben aus dem Backlog selber holen. Am besten immer nur eine und wenn die Aufgabe fertig ist oder aufgrund einer Klärung hängt, kann unterdessen eine kleine weitere Aufgabe genommen werden oder ein Kollege unterstützt werden
Die Gruppe ist verantwortlich fü die Abarbeitung der gewählten Aufgaben. Jeder einzelne verpflichtet sich bei der Wahl eienr Aufgabe, diese für die Zielerreichung der Gruppe zu erledigen

Beispiel für eine Gruppe mit 3 Schichten

Die Frühschicht füllt zu Dienstbeginn das Backlog, evtl. haben auch Führungskräfte ebenfalls Einträge vorgenommen
Die Kollegen übernehmen die ersten Aufgaben, die sie bis Mittag erledigen möchten in den “work in progress”-Bereich des “Taskboards”
Kollegen die später kommen, picken sich weitere offene Aufgaben heraus oder unterstützen bei den bisherigen
Da die zweite Schicht um 13 Uhr beginnt, ist die Verantwortung für die Frühschicht die Abarbeitung aller Tasks die bis 12 Uhr eingetroffen sind.
Die zweite Schicht analysiert nach Ankunft das Backlog und in einem zweiten Daily Standup erfolgt eine Übergabe durch die Frühschicht, es werden evtl. Reste der Frühschicht noch erledigt. Hauptfokus ist um 100 Prozent zu erreichen alles ab 13 Uhr (inkl. Resten der Schicht davor) bis 18 Uhr
Um 18Uhr erfolgt die Übergabe an die Spätschicht mit einem weiteren Daily Standup. Die Spätschicht versucht die restlichen Aufgaben zu erledigen und das Backlog für den nächsten Tag vorzubereiten z.B. wenn die monatliche Bereinigung zwecks Datenschutz ansteht
Eine Review findet indirekt statt, durch die Bestätigung des Anwenders oder Kunden, daß sein Anliegen zur Zufriedenheit gelöst wurde
Alle 4 Wochen hat das Team eine Retrospektive. Hier wird besprochen was besonders gut lief, neue Erkenntnisse um Bearbeitungen zu verbessern, Optimierungsbedarf, die Monatszahlen für das Team werden präsentiert usw.
Eine wichtige Änderung die das Team im nächsten Monat umsetzen möchte wird vom Team beschlossen.

Wo ist denn nur das “Increment” geblieben?

Manch einer mag nun das “Increment” vermissen. Erinnern wir uns, Scrum erfordert am Ende eines Sprints ein “veröffentlichbares Produkt”. (Scrum Guide 2017) oder zumindest ein “Increment”, dass der “Definition of Done” entspricht (Scrum Guide 2020)
Wir haben mit einem Service ein immaterielles Produkt, dass erst bei der Erbringung beim Kunden entsteht. D.h. die Lösung von Service- oder Incidenttickets ist bei Abschluß unser Increment.
Daher kann man wie bei anderen Produkten auch eine "Definition Of Done" anwenden und die Qualität überprüfen.

Kann man auch Trainer in einem Customer Service Center agil organisieren?

Der Start

Vorstellung des Konzeptes
Erklären welche neuen Verantwortungen hinzu kommen, aber auch die Freiheiten
z.B. das ganze Team erklärt sich für die Erledigung der Aufgaben des Sprints verantwortlich (Commitment)
Etablierung von Scrum Master und Product Owner
Es wird immer eine Aufgabe fertiggestellt bevor eine neue angefangen wird.
Es wird von den Bearbeitern nicht an mehreren Aufgaben gleichzeitig gearbeitet =>Fokussierung schafft Geschwindigkeit und reduziert Fehler

Das Product Backlog

Das Backlog stellt eine Liste mit allen anstehenden Aufgaben dar
Die wichtigsten Themen sollten in der Liste oben stehen
Themen sollten in kleinere Einheiten zerlegt werden (z.B. User Guide in verschiedene Themenblö.cke oder Übersetzungen in Kapitel1, Kapitel2 usw.) Hinweis: Dieser Prozess wird “Refinement” genannt.
Das Backlog liegt in der Verantwortung des Product Owners.(Master Trainer ?)

Sprint Planning

Im Sprint Planning wird der Aufwand geschätzt und der Sprint beginnt in dieser Phase
Man kann den Aufwand mit Punkten bewerten (Planning Poker)
Man lernt mit der Zeit was an Aufwand realistisch für einen Sprint geplant werden darf
Was beschlossen wurde kommt in das Sprint Backlog
Was dort ist, wird vom Product Owner (weiterhin aufbereitet um immer exakter und granularer die Aufgaben bereitzustellen)
gemeinsames Sprintziel (Motto) festlegen
Das Team entscheidet und verpflichtet sich gemeinsam zur Bearbeitung
Auch wenn Bearbeiter sich Aufgaben selbst zugewiesen haben, bleibt das ganze Team verantwortlich und muss sich kümmern, wenn die Zielerreichung gefährdet ist.
Zeitrahmen: 8 Stunden bei einem 4 Wochen Sprint; 4 Stunden bei einem2 Wochen Sprint (Timeboxed)

Daily Scrum / Daily Standup

Tägliches Treffen / Meeting zur gleichen Zeit am gleichen Ort
Verbindlich für alle
Kurzer Austausch, was werde ich heute bearbeiten
Wo sehe ich ein Problem
Zeitrahmen: 15 Minuten (timeboxed)
Meetings zur Klärung von Fragen oder Problemen für einzelne Teilnehmer im Anschluss möglich, jedoch nicht in diesem Format

Taskboard / Kanbanboard

Folgende Spalten
To-Do (=Sprint Backlog)
Work in Progress (WIP)
Ein Limit für WIP, Grenzwert für gleichzeitig bearbeitbare Tasks
Impediment / Hindernis =>Hier sollte der Scrum Master hinschauen
Done

Burndown Chart

Visuelle Darstellung des Fortschritts
Zeigt die verbleibende Arbeit

Review

Gemeinsame Vorstellung der Arbeit aus dem Sprint
Vorschläge für weitere Aufgaben, die dann wieder Eingang ins Product Backlog finden.
Hier wird auch beschlossen ob eine Arbeit zurückgewiesen wird für Nacharbeiten

Retrospective

Product Owner, Scrum Master, Trainer Team sind Teilnehmer
Es wird besprochen was lief in dem Sprint gut
Was lief nicht gut im Sprint
Was wollen wir vom Guten übernehmen?
Was wollen wir besser machen und wie?
Das Team sollte die Maßnahmen finden und beschließen
Diese werden dann in den nächsten Sprint übernommen.
Optimalerweise ist ein High Prio Thema dabei

Neuer Sprint beginnt nach der Retrospective

Erstes Event ist das Sprint Planning

Was ist der Unterschied zwischen KPI und KVI?

KPI´s sind Kennziffern, die z.B. die Anrufmenge zeigen, die First Time Resolution und andere Werte. Häfig weisen die KPIs 2 Kennzeichen auf,
der Mitarbeiter hat oft nur wenig oder gar keine Möglichkeit Einfluss auf diese Werte zu nehmen. Ein Kundensupport hat nicht die Möglichkeit vorab zu entscheiden, wann und wieviele Kunden anrufen.
Maximal wird der KPI hingenommen, der Wert gibt zwar Aufschluss über die Anzahl der Anrufer, mehr auch nicht. Daraus wird kein zufriedenerer Kunde resultieren und auch kein Lernprozess erfolgen.
Beim KVI wird erarbeitet, welcher Wert dem Kunden geliefert wird und wodurch, diese Werte sind direkt durch die Mitarbeiter beeinflussbar und daher bieten sie Orientierung und erfordern auch einen Lernprozess zur weiteren Verbesserung.
Die Akzeptanz der KVIs steigt, wenn die Mitarbeiter bei der Einführung beteiligt werden und diese mit kreieren.

Ist Agile Coach das Gleiche wie ein Scrum Master?

Gemeinsam ist beiden Rollen, dass sie bei der Umsetzung der Methode unterstützen und Methodenwissen einbringen. Dementsprechend müssen beide über sehr gutes Methodenwissen verfügen.
Der erste Unterschied liegt darin, dass der Scrum Master um seiner Rolle gerecht zu werden sich auf das Scrum Framework konzentrieren muss, daher reicht es wenn er nur da über tiefes Wissen verfügt. Vom Agile Coach hingegen wird weitreichendere Methodenkompetenz bzgl. agiler Methoden erwartet und auch die Kombination dieser Methoden um die Effizienz zu verbessern.
Bei diesen Methoden kann es sich z.B. um XP, Lean Agile, Kanban, SAFe, Design Thinking, LeSS handeln und auch DevOps weist agile Elemente auf.
Eine weitere Unterscheidung ergibt sich aus der Firmenzugehörigkeit, der Scrum Master ist häufiger interner Mitarbeiter. Der Agile Coach wird für den unabhängigen Blick von außen und um Hindernisse zu lösen bei denen das Team festgefahren ist, eher von extern eingekauft.

Muss ich unbedingt agile Methoden anwenden um ein erfolgreiches Team zu bekommen ?

Agile Methoden bringen den besten Effekt, wenn es um komplexe Aufgabenstellungen geht.
Was einfach so geplant werden kann, weil es einfach überschaubar ist kommt man auch mit üblichen Methoden zum Ziel.
Da wäre der Aufwand z.B. bei Scrum mit den Events einfach zuviel Zeit für zuwenig Benefit.
Was hilfreich ist, ist z.B. das Taskboard. Da man so sieht wer welche Aufgabe bearbeitet und direkt diesen Bearbeiter ansprechen kann und so die anderen Kollegen nicht unterbrechen muss.

Warum ist das Schätzen des Aufwands für die Sprint Backlog Items so wichtig?

Das Development Team kann daraufhin entsprechend Zeit einplanen um das Sprint Backlog nicht zu überfüllen oder zuwenig auszuwählen
Der Product Owner kann besser abschätzen, was ihn das neue Feature / Produkt kostet
Es hilft zu erkennen ob ein gemeinsames Verständnis bzgl. der anstehenden Arbeit und Komplexität vorherrscht. Somit ein Mittel für mehr Transparenz

Fortsetzung folgt...
bei Fragen bitte Franz.Mertens (at) transform2agile.de kontaktieren.

Impressum:
Franz Mertens
Spezialist für Prozessoptimierung, Transformationsprojekte und Schwachstellenanalyse in Organisationen und ITSM-Konzepten
Wittener Weg 10
90425 Nürnberg

Ausgewählte Zertifizierungen:

ITIL 4 Master
ITIL4 Strategic Leader (SL)
ITIL4 Managing Practitioner (MP)
ITIL3 Expert
Scrum Fundamentals Certificate
Professional Scrum Master (PSMI+II)
Professional Scrum Product Owner (PSPOI+II)
Professional Agile Leadership (PAL I)
Scaled Professional Scrum (SPS) (Nexus)
Certified SAFe 5 + 6 Agilist
Accredited OKR Coach
Certified Professional Requirements Engineer @ Agile Primer
Certified Professional For Requirements Engineering Fundamental Level
Fachkraft für agile Führung (IHK)
PRINCE 2 Foundation (Projektmanagement)
CObIT 4.1 Practitioner

Weitere Zertifizierungen entnehmen Sie bitte untenstehenden Business Netzwerken:
LinkedIn Profil: Franz Mertens bei LinkedIn
Xing Profil: Franz Mertens bei Xing

Vortrag Linuxtag ERLUG2022

Vortrag inkl. Videofiles mit Codebeispielen Linuxtag ERLUG2023