Weitere ähnliche Inhalte
Empfohlen
Empfohlen (20)
TOPdesk on Tour 2019, Köln: Agile Servicemanagement
- 1. TOPdesk on Tour TOPdesk on Tour Agile Servicemanagement
- 2. TOPdesk on Tour Felix Hagemann Berater TOPdesk Deutschland GmbH
- 3. Agenda • Theorie: Was ist Agile? • Praktisch: Kanban Pizza • Praxis: Konkrete Ansätze
- 4. TOPdesk on Tour Theorie: Was ist Agile?
- 6. Es geht um Veränderung und Anpassung
- 8. Anpassungsfähigkeit – Das Rad dreht sich schneller ANPASSUNGSFÄHIG NICHT ANPASSUNGSFÄHIG
- 9. Agile ist keine Methodik sondern eine Einstellung Scrum AgilePM (DSDM) Kanban Extreme Programming (XP) Lean Test Driven Development (TDD) Scaled Agile Framework (SAFe) Large Scale Scrum (LeSS) Nexus Design Thinking Lean Startup
- 10. Das Agile Manifest Individuen & Interaktion Funktionierendes Produkt Kundenkooperationen Reaktion auf Veränderung Prozesse & Tools Umfassende Dokumentation Vertragsverhandlung Verfolgen eines Plans Über
- 11. Merkmale von Agile? Kurze Entwicklungszyklen Direkte Kommunikation Selbstorganisierende Teams aus motivierten Mitgliedern Feste Dauer, Kosten und Qualität Transparenz
- 15. TOPdesk on Tour Praktisch: Kanban Pizza • Eine agile Transition
- 16. Runde 1: Erstellen Sie möglichst viele Pizzastücke Pizza Hawaii Rezept: • Tomatensoße und Kruste mit nach oben gefalteter Außenkante. • 3 Scheiben Schinken aus rosa Post-Its geschnitten. • 3 Scheiben Ananas aus gelben Post-Its geschnitten. Regeln • Alle Schnitte müssen mit einer Schere durchgeführt werden - eine Schere pro Team. • Ein roter Marker pro Team für die Tomatensoße. • Ein Ofen pro Team - hält maximal 3 Scheiben auf einmal. Muss 30 Sekunden lang backen, nach Sekunden verbrannt. • Hohe Qualität: viel Sauce mit fest angebrachten Belägen.
- 17. STOP!!! - Messung der Ergebnisse - Fertige Pizzastücke = + 10 Punkte Jedes Stück, welches nicht zu 100% fertig ist, bedeutet Punktabzüge - Nicht fertige Pizzastücke = - 4 Punkte - Übrige Beläge = -1 Punkt
- 18. Sechs Kanban Kernprinzipien Visualiserung des Workflows Begrenzung der Auslastung Steuern Sie den Fluss Feedback Schleifen Klare Prozessdefinition Verbesserung der Zusammenarbeit
- 19. Runde 2: Visualisierung des Workflows & Begrenzung der Auslastung Die Regeln bleiben gleich Dauer: 5 Minuten
- 20. STOP!!! - Messung der Ergebnisse - Fertige Pizzastücke = + 10 Punkte Jedes Stück, welches nicht zu 100% fertig ist, bedeutet Punktabzüge - Nicht fertige Pizzastücke = - 4 Punkte - Übrige Beläge = -1 Punkt
- 21. Runde 3: Neues Rezept und Bestellungen Ab jetzt werden Bestellungen abgearbeitet: - Bestellungen können vom definierten Ort abgeholt werden. - Fertige Bestellungen müssen an einem anderen definierten Ort abgelegt werden.
- 22. Runde 3: Neues Rezept und Bestellungen Neue Rezeptur: Pizza Parma - 3 Stücke Schinken - 7 dünne Streifen Rucola Der Rucola würde im Ofen verbrennen, weshalb er nach dem Backen hinzugefügt wird.
- 23. STOP!!! - Messung der Ergebnisse - Fertige Pizzastücke = + 10 Punkte Jedes Stück, welches nicht zu 100% fertig ist, bedeutet Punktabzüge - Nicht fertige Pizzastücke = - 4 Punkte - Übrige Beläge = -1 Punkt
- 24. Runde 4: Neues Rezept und Bestellungen Sie haben im Team nochmal 5 Minuten Zeit sich zu überlegen, was Sie verbessern können. Anschließend kommt die letzte Runde.
- 25. Zeichnen Sie Ihren Workflow!
- 26. TOPdesk on Tour Praxis: Konkrete Ansätze
- 27. 1. Kanban-Board
- 28. 2. Das Stand-up - Im Stehen, damit es nicht zu bequem ist - Timebox: 5,10 oder 15 Minuten - Kurz fassen - Geschehenes und Geplantes teilen
- 29. 3. Peer-Review - Abwandlung des Vier-Augen-Prinzips - Investition in Wissenstransfer - Einer konfiguriert - Einer kontrolliert - Funktioniert natürlich nicht überall
- 30. 4. Cross funcional Teams - Bildung von autarken Teams - Jedes Mitglied hat seinen eigenen Schwerpunkt - Reduzierung von Liegezeiten über Team-/Abteilungsgrenzen - „Dauerhafte Taskforce”
- 31. 5. Retrospektive - Austausch über: - Die erzielten Erfolge - Die Art der Zusammenarbeit - Kultivierung des Feedback Loops - Schaffung eines geeigneten Rahmens für den Austausch
- 32. TOPdesk on Tour
- 33. TOPdesk on Tour Vielen Dank Besuchen Sie uns gerne in den sozialen Netzwerken und auf unserem Service Excellence Blog https://blog.topdesk.de
Hinweis der Redaktion
- Was davon ist Agil? Beides: Da im Kontext betrachtet, beides die notwendige Reaktionsfähigkeit hat. Es geht nicht um Geschwindigkeit sondern um Anpassungsfähigkeit.
- Die Technolgie entwickelt sich immer schneller und um dieser Veränderung Schritt halten zu können, bedarf es neuer Ansätze.
- Short development methods Sprints / iterations 2-4 weeks in Scrum, Xtreme programming shorter, AgilePM longer Daily standup Shippable services Means of risk management & feedback Direct communication Face to face Team works in one room Working with the customer, part of the team Self-directed teams of motivated individuals No one will tell you HOW to do it Customer / Product owner will prioritize wishes Team decides on the work they pick up Continuous improvement, retrospective, attention for people Fixed time, cost & quality Holds true for project management and development Transparency Visualizing your work Kanban Open backlog Product reviews or similar
- Traditionell: Die Merkmale werden perfekt verarbeitet und erst am Ende ausgeliefert. Wenn dies nicht das ist, was der Kunde will, musst du von vorne anfangen. Agile: Sie zeigen dem Kunden bereits ein unfertiges Produkt (MVP), so dass er eine Vorstellung von der Lösungsrichtung hat und schnelles Feedback geben kann. Es ist nun auch einfach, die Rückmeldung zu verarbeiten.
- Sichtbarkeit: Am Anfang besprechen Sie die Pläne mit dem Kunden. Dann wird eine Zeit bearbeitet, von der der Kunde nichts sieht. Erst am Ende wird das Ergebnis dem Kunden präsentiert. Anpassungsfähigkeit: Ihre Anpassungsfähigkeit wird drastisch reduziert, je weiter Sie dabei gehen. Am Anfang steht alles fest, so dass Anpassungen dauerhaft sind und sich auf viele Dinge auswirken. Geschäftswert: Man liefert nur am Ende etwas Nützliches, also erst dann hat es einen Wert. Risiko: Erst nach Lieferung und Abnahme durch den Kunden wird das Risiko geringer.
- Sichtbarkeit: Sprintrhythmus: Am Ende eines jeden Sprints wird das Ergebnis angezeigt. (Delfin vs. U-Boot) Anpassungsfähigkeit: Das Feedback kann bei jedem Sprint verarbeitet werden. Geschäftswert: Etwas Nützliches wird schnell geliefert, was Wert hat. Risiko: Anpassungen werden schnell vorgenommen, wenn etwas nicht stimmt, so dass die Chance auf Akzeptanz beim Kunden viel größer ist.
- Eines der mächtigsten Werkzeuge aus meiner Sicht ist die Visualisierung von Arbeit, Fortschritt und Zusammenhängen. Trotz Servicedesk oder Tickettool herrscht selten Transparenz. Keiner weiß so recht, woran die Kollegen gerade arbeiten und wie der Fortschritt ist. Probleme und Verzögerungen bleiben so unentdeckt. Agile Methoden wie Kanban und Scrum kennen dafür ein einfaches und effektives Werkzeug: das Taskboard. Wie funktioniert das Board? Entsprechend der spezifischen Arbeitsschritte werden die einzelnen Spalten organisiert und jeder Task, an dem gearbeitet wird, bekommt ein Kärtchen. Ein Task kann ein Ticket, ein Problem, eine Aufgabe im Change oder ein Projekt sein. Wichtig ist, dass relevante Informationen enthalten sind. Dazu gehören: Bearbeiter geschätzter Aufwand Zeitpunkt, an dem der Task an das Board gekommen ist Im Vorfeld ist gemeinsam festzulegen, wie hoch das Work in Progress Limit (WIP) ist: Wie viele Tasks in jeder Spalte / Arbeitsschritt maximal bearbeitet werden dürfen. Die WIP-Limits sorgen dafür, dass die Arbeit auch erledigt wird. Erreicht ein Arbeitsschritt das WIP Limit, dürfen keine weiteren Tasks mehr dort bearbeitet werden. Jetzt sollte reagiert und gemeinsam die begonnen Tasks abgeschlossen werden. Spätestens wenn die ersten Kollegen, aufgrund der WIP-Limits, nichts mehr Neues anfangen dürfen, wird auffallen, dass der Prozess klemmt. Eine sehr wichtige Erkenntnis! Folge mir: www.different-thinking.de Ob das Taskboard nach Scrum, Kanban oder einer Mischung strukturiert wird - ist egal. Wichtig ist für die Transparenz, Kommunikation und das frühzeitige Erkennen von Problemen zu sorgen. Darin liegt der Wert. Das Layout des Board muss zum Arbeitsprozess passen
- Die Karten bewegen sich durch die einzelnen Arbeitsschritte auf dem Board. Das Ziehen der Karten erfolgt im Standup. Entsprechend des tatsächlichen Fortschrittes wandern die Karten mit den Tasks von links nach rechts über das Board. Das visualisiert den Fortschritt und legt Abarbeitungsprobleme offen. Das Team spricht mindestens ein Mal am Tag am Board über jeden einzelnen Task. Jeder beantwortet die drei Grundfragen: Was habe ich getan? Was werde ich tun? Was hindert mich an meiner Arbeit? und bewegt seine Karte weiter. Das Standup ist wichtig. Es sorgt einmal dafür, dass das Team genau weiß wer an was arbeitet. Des Weiteren wird doppelte Arbeit vermieden, denn man kann sehr schnell einhaken und sagen, dass man das schon so oder so gelöst hat. Probleme in der Bearbeitung werden schnell erkannt. Bewegt sich eine Karte in einem Standup nicht bzw. berichtet der Bearbeiter nichts Neues, ist klar, dass es ein Problem gibt. Dieses kann sofort angegangen werden. Standups sollten so früh wie möglich am Tag stattfinden. Gerade wenn Tickets oder andere eher kleinteilige Aufgaben gelöst werden, ist es sinnvoll das Standup zweimal oder öfter am Tag abzuhalten. Das hängt von dem “Synchronisationsbedarf” und der Komplexität ab
- Fehler im IT-Betrieb kosten Geld. Sie treten gern in der Anlaufphase eines neuen Systems bzw. Applikation auf oder nach Änderungen. Um dem vorzubeugen, empfiehlt sich das Arbeiten oder Konfigurieren im Zweier-Team. Idealerweise ein Senior mit einem Junior oder einem Kollegen, mit einer anderen aber ähnlichen Spezialisierung. Wieso ist das produktiv? Auf den ersten Blick kostet es durch den doppelten Ressourceneinsatz mehr. Die Vorteile liegen in folgenden Punkten: Einer konfiguriert, der Zweite überprüft dabei die Konfiguration. Dadurch werden Fehler vermieden und es kommt nicht zu Störungen. Es findet ein nachhaltiger Wissenstransfer zwischen Senior und Junior statt. Das Wissen wird in der Abteilung besser gestreut und die Abhängigkeit von Kopfmonopolen sinkt. Auch die Zusammenarbeit mit einem Kollegen anderer Spezialisierung hat den gleichen Effekt. Der Spezialist muss sein Handeln anders durchdenken. Er muss dem Junior etwas erklären. Dieser denkt über Dinge nach, die der Experte für gegeben hinnimmt. So entstehen neue Perspektiven auf die Arbeit, die zu Verbesserungen führen. Peer-reviews sind eine Investition. Eine Investition in Betriebssicherheit, Kundenzufriedenheit, Wissensmanagement und kontinuierliche Verbesserung. Es fällt Führungskräften schwer, das zuzulassen. Natürlich ist es nicht für jede Aufgabe sinnvoll. Da muss ein Team seinen Weg finden. Es sollte ihm aber auf jeden Fall ermöglicht werden. Spätestens beim nächsten Incident, wenn der Spezialist im Urlaub ist, wird sich die Investition bezahlt machen
- Diese agile Praktik bringt auf lange Zeit gesehen den größten Effekt – ist allerdings nicht so leicht umzusetzen! Insbesondere bei Scrum wird von “cross-functional teams” gesprochen: Das Team verfügt über alle Skills, um seine Aufgaben zu erledigen. Die Anzahl der Schnittstellen und damit Konfliktpunkte wird so stark minimiert, dass das Team autark agieren und Ergebnisse liefern kann. Das bedeutet die Auflösung der Kompetenzsilos in der IT-Abteilung. Kein Netzwerk- oder Backupteam mehr! Die Teams werden entsprechend der angebotenen Services oder nach Kunden strukturiert. Sie haben die Verantwortung für den Betrieb und Weiterentwicklung des oder der Services. Ob Teams entlang der angebotenen Services oder der betreuten Kunden aufgebaut werden, hängt von den individuellen Voraussetzungen ab. Als Dienstleister mit für Kunden maßgeschneiderten, betreuungsintensiven Diensten, werde ich ein oder mehrere Teams für die einzelnen Kunden aufbauen. Stelle ich standardisierte Dienstleistungen zur Verfügung, dann ist es sinnvoller, die Teams nach den Services aufzubauen. Achtung: “cross-functional” bedeutet nicht, dass jeder im Team die gleichen Fähigkeiten hat. Es bedeutet, dass die notwendigen Spezialisten mit Ihrem Expertenwissen im Team vertreten sind. Man könnte es wie folgt definieren: Ein “Cross-Functional” Team ist eine Gruppe von einzelnen Experten. Jeder hat sein Spezialgebiet. Alle Skills zusammen ermöglichen dieser Gemeinschaft – als emergentes Team – ein gemeinsames Ziel zu erreichen.
- Ein Werkzeug der ständigen Verbesserung sind Retrospektiven. Jenseits eines großen Continual Service Improvement Prozess (CSI) bieten sie die regelmäßige Möglichkeit, die kleinen Dinge der täglichen -Arbeit zu verbessern. Taskboards und Standups erzeugen im Arbeitsprozess Transparenz und es werden Probleme sichtbar. Das Ziel produktiver und effizienter zu arbeiten, lässt sich am besten in vielen kleinen Schritten realisieren. Änderungsimpulse, die von außen kommen sind viel weniger effektiv, als wenn sie im Team oder Menschen selbst entstehen. Die intrinsische Motivation ist viel stärker. Um diesen Prozess in Gang zu bringen und am Laufen zu halten, empfehle ich regelmäßige Retrospektiven. In einer Retrospektive betrachtet das Team eine vergangene Zeitperiode. Eine Woche, zwei Wochen, einen Monat oder ein Vierteljahr. Die einfachste Methode stellt vier Fragen: Was war gut? Was wollen wir öfter machen? Was wollen wir weniger oft machen? Was wollen wir gar nicht mehr machen? Die Fragen zielen darauf ab, gute Verhaltensweise zu fördern und im Team zu verankern. Schlechte Verhaltensweisen sollen identifiziert und zukünftig vermieden werden. Es gibt viele Variationen der Retrospektive. Im Buch “Getting Value out of agile Retrospectives” findest Du viele schöne Beispiele. Durch die Betrachtung eines kurzen Zeitraums und die konkrete Arbeit in einem Team, sorgen Retrospektiven für die kontinuierliche Verbesserung. Entscheidend ist, dass in jeder Retrospektive konkrete Aufgaben mit einem Verantwortlichen und Termin definiert werden. Diese können beim nächsten Mal kontrolliert und deren Wirkung überprüft werden. Binde Deine Nutzer und Kunden immer wieder in die Retrospektive mit ein. So bekommst Du direktes und ergebnisorientiertes Feedback. Du erfährst Ihre Probleme und Wünsche. Das nenne ich Service! Gleiches gilt für die Führungsebene und Stakeholder. Wird die Erwartung an die IT erfüllt oder nicht?