Agiles Servicemanagement – Einblick in die Praxis
Agiles Servicemanagement – Einblick in die Praxis
3. Oktober 2022
Lesezeit: 8 Minuten
In Agiles Servicemanagement – ein Überblick, dem ersten Teil dieser Reihe, haben wir ein Grundverständnis dafür geschaffen, worum es beim agilen Servicemanagement geht, und die dem Framework zugrundeliegende Methoden wie Scrum, Kanban, Lean, ITIL und DevOps vertieft diskutiert.
Im zweiten Teil steigen wir vertieft in das Framework des agilen Servicemanagements ein und zeigen anhand vom Projektbeispielen ganz konkret auf, wie dieses in der Praxis umgesetzt werden kann.
Wichtig zu verstehen ist, dass agiles Servicemanagement nicht darauf abzielt, Agilität in bestehende Best Practices und Prozesse zu integrieren, sondern sich fokussiert, die Werte, Denkweisen und Perspektive zu vermitteln, die Sie brauchen, um Agilität Schritt für Schritt in Ihre Arbeitsweise zu integrieren. So schaffen Sie schaffen Sie höhere Akzeptanz und eine nachhaltige Verankerung in Ihrer Organisation.
Rollen im agilen Servicemanagement
Im agilen Servicemanagement gibt es drei zentrale Rollen: den Agile Service Manager, den Agile Practice Owner und das Agile Service Management Team.
Das Agile Service Management Team (analog zum Development Team in Scrum) besteht aus drei bis neun Experten, die funktionsübergreifend, ohne Hierarchie und selbstorganisiert zusammenarbeiten, um am Ende jedes Sprints ein fertiges Inkrement zu übergeben.
Der Agile Practice Owner (analog zum Product Owner in Scrum) hat Autorität über den Practice-Backlog und ist für die End-to-End-Ergebnisse verantwortlich. Er:sie erstellt, verwaltet und priorisiert einzelne Elemente des Backlogs sowie ihre Anforderungen an den ITSM-Prozess und steuert das Team dahingehend. Ihm:ihr unterliegt das Stakeholder-Management mit dem Ziel den Wert des Endprodukts zu maximieren.
Der Agile Service Manager (analog zum Scrum Master) unterstützt die anderen Rollen dabei, ihren Verantwortlichkeiten und Aufgaben nachzukommen. Seine:ihre eigene Verantwortlichkeit besteht darin, das agile Denken zu vermitteln und sicherzustellen, dass die agilen Werte und Prinzipien sowohl innerhalb des Teams als auch von Stakeholdern außerhalb verstanden und angewendet werden. Wichtig zu verstehen ist, dass er:sie als «Servant Leader» nicht als Organisator, sondern als Coach des Agile Service Management Teams auftritt.
Nur wenn jede dieser drei Rollen ihre spezifischen Verantwortlichkeiten versteht und erfüllt, können Prozessdesign und Prozessverbesserungen erfolgreich ablaufen und das Team harmonisch zusammenarbeiten. Oder anders ausgedrückt: Nur die strikte Einhaltung dieser Regeln gewährleistet dem Team volle Flexibilität.
Agile Prozessentwicklung
Ein agiler Prozess bietet so viel Agilität und Flexibilität wie möglich und gerade so viel Struktur und Steuerung, wie eine Organisation braucht, um ihre Ziele effektiv und effizient zu erreichen. Alle Prozesse sollten das Team befähigen, wertvolle Ergebnisse zu schaffen. Das bedingt, dass die Prozesse leicht zu verstehen sind, den Fokus auf die Zusammenarbeit statt die Prozesseinhaltung legen.
Der Vorteil dieses Ansatzes besteht im sogenannten «Minimum Viable Process» (MVP) oder auch Mikroprozess. Er bezeichnet die minimale Ausführung eines Prozesses, der mit minimalem Aufwand den Bedarf der Kund:innen deckt und Feedback gewährleistet.
Minimum Viable Process (MVP)
So können mithilfe eines schnellen und einfachen Prozesses die notwendigen Kernfunktionen ressourcenschonend bereitgestellt und in der nächsten Iteration durch das Feedback der Stakeholder verbessert werden.
Agile Prozessverbesserung
Ziel der agilen Prozessverbesserung ist es, die Agilität des Servicemanagements über die gesamte Wertschöpfung sicherzustellen. Die zentrale Herausforderung besteht darin, die Balance zwischen «gerade genug» und «nicht zu viel» Struktur zu halten. Practices, Prozesse und Mikroprozess im täglichen Betrieb agil zu halten, ohne sie zu komplex oder zu bürokratisch werden zu lassen, erfordert langfristiges Engagement und Kontrolle.Prozessverbesserungen sind deshalb kein einmaliges Projekt, sondern sollten kontinuierlich und mit einem ganzheitlichen Ansatz betrieben werden. In Zusammenarbeit mit dem Team und den Stakeholdern ist der Agile Practice Owner verantwortlich schleichende Trends zu identifizieren, Prozesse auf agile Werte zu überprüfen, ihre Relevanz zu beurteilen, sicherzustellen, dass gerade genug Struktur vorhanden ist und Effektivität sowie Effizienz zu fördern.
Formale und indirekte Artefakte
In Scrum dienen Artefakte der Orientierung – sie sollten Transparenz schaffen und ein gemeinsames Verständnis aufbauen, um das Team zu unterstützen, die geplanten Aufgaben bestmöglich zu koordinieren. Im agilen Servicemanagement bilden sie gemeinsam den Rahmen rund um die Prozesse.Die nachfolgende Darstellung veranschaulicht, wie die formalen Artefakte durch indirekte Artefakte ergänzt werden und im Zusammenspiel darauf abzielen, die gemeinsame Vision zu erfüllen und so wert zu schaffen.
Der Practice Backlog bezeichnet eine vom agile Pratice Owner erstellte und nach Prioritäten geordnete Liste aller Anforderungen, die für einen Practice relevant sind. Der Backlog dient als alleinige Quelle für alle Änderungen and Practices und ist für alle Stakeholder sichtbar. Im Rahmen des Practice Backlog Refinement wird der Backlog regelmässig verfeinert, um Details, Arbeitszeitschätzungen und Priorisierungen anzupassen.
Eine User Story ist eine Aussage, die aus Anwenderperspektive beschreibt, welche Wünsche an einen Practice gestellt werden. Ein Epic ist eine Sammlung zusammenhängender User Stories, die über einen oder mehrere Sprints hinweg abgearbeitet werden.
Der Sprint Backlog ist eine vom Agile Service Management Team ausgehende Prognose, welche Funktionalitäten im nächsten Inkrement bereitgestellt wird und welche Aufgaben dafür erforderlich sind. Gleichzeitig visualisiert er die gesamte für zu erreichende Sprintziel (also das Ziel des jeweiligen Sprints) notwendige Arbeit sowie deren Fortschritt. Der Backlog ist am Ende jedes Sprints leer und wird für den nächsten neu aufgefüllt.
Ein Inkrement ist ein – gemäss der Definition of Done – abgeschlossener Aspekt der Practice. Dies kann beispielsweise die Verbesserung eines oder mehrere Mikroprozesse sein. Wichtig ist, dass das Inkrement für sich allein wertschöpfend ist. Während des Sprint Reviews entscheidet der Practice Owner, ob das jeweilige Inkrement freigegeben und ausgerollt wird.
Die Definition of Done ist eine Liste von Fertigstellungskriterien, welche vom Agile Service Management Team bei der Erstellung der Practice zu beachten hat. Sie sorgt für ein gemeinsames Verständnis, wann eine Arbeit fertig und das Sprintziel erreicht ist, und steigert so die Qualität der Ergebnisse.
Ein Inkrement ist ein – gemäss der Definition of Done – abgeschlossener Aspekt der Practice. Dies kann beispielsweise die Verbesserung eines oder mehrere Mikroprozesse sein. Wichtig ist, dass das Inkrement für sich allein wertschöpfend ist. Während des Sprint Reviews entscheidet der Practice Owner, ob das jeweilige Inkrement freigegeben und ausgerollt wird.
Die Definition of Done ist eine Liste von Fertigstellungskriterien, welche vom Agile Service Management Team bei der Erstellung der Practice zu beachten hat. Sie sorgt für ein gemeinsames Verständnis, wann eine Arbeit fertig und das Sprintziel erreicht ist, und steigert so die Qualität der Ergebnisse.
Sprint Events
Sprint Events unterstützen im Rahmen des Agile Service Management dabei, eine Regelmässigkeit herzustellen, Transparenz zu schaffen und die Notwendigkeit anderer Besprechungen zu minimieren. Die Dauer eines Sprints wird dabei von Beginn an festgelegt und darf nicht verändert werden. Alle anderen Events haben ein flexibles Zeitfenster und dürfen beendet werden, sobald ihr Zweck erfüllt wurde.
Events im agilen Servicemanagement
Practice Planning Meetings (ohne Zeitvorgabe) dienen der Planung auf strategischer Ebene. Sie erstrecken sich in der Regel über mehrere Sitzungen und verfolgen das Ziel, den Wert einer Practice zu identifizieren, die zugrundeliegende Architektur zu verstehen und die Reihenfolge des Mikroprozesse festzulegen. Am Ende des Planungsmeetings sollten die Ziele und Messgrössen der Practice definiert, Risiken klar und die Integration mit anderen Practices berücksichtigt sein. Im Sinne der Agilität gilt auch hier: der Plan sollte «minimal lebensfähig» und damit gerade «ausreichend genug» detailliert sein.
Im Sprint Planning Meeting (4 bis 8 Stunden) wird das Ziel des Sprints festgelegt. Im Rahmen dessen wird definiert, welches Inkrement des Practice Backlogs im Sprint fertiggestellt wird, wie es erstellt wird und welche Abhängigkeiten bestehen. Zum Ende des Planungsmeetings steht der Sprint Backlog fest. Zudem muss sichergestellt werden, dass das Agile Service Management Team über alle notwendigen Fähigkeiten und Ressourcen verfügt, um das Sprintziel zu erreichen. Das Meeting findet mit dem Agile Process Owner sowie dem gesamten Agile Service Management Team statt und wird vom Agile Service Manager moderiert.
Im Rahmen des Sprints (2 bis 4 Wochen) wird ein Inkrement – so wie im Sprint Planning Meeting vereinbart – basierend auf den Elementen des Sprint Backlogs aufgebaut. Der Sprint wird durch das Sprintziel gesteuert. Das bedeutet, dass während des Sprints keine Änderungen vorgenommen werden dürfen, welche das Sprintziel gefährden würden. Der Agile Service Manager ist dafür verantwortlich, das Agile Service Management Team während des Sprints fokussiert zu halten, Mitglieder wie Stakeholder wenn nötig zu coachen und Hindernisse aus dem Weg zu räumen. Der Practice Owner dagegen stellt sicher, dass die Prioritäten innerhalb des Sprints unverändert abgearbeitet werden.
Das Process Standup (maximal 15 Minuten) findet täglich statt und dient der Planung für die nächsten 24 Stunden. Es bietet Gelegenheit, den Fortschritt zum Sprintziel zu überprüfen, wobei jedes Teammitglied mitteilt, was seit dem letzten Treffen erreicht wurde, was bis zum nächsten Treffen geplant ist und welche Hindernisse dabei im Weg stehen. Hinter dem täglichen Standup steht der Leitgedanke des «fail fast, learn fast». Je früher Sie Abweichungen feststellen, desto schneller können Sie reagieren und desto grösser ist die Chance, Ihr Sprintziel zu erreichen. Lösungen zu diesen Hindernissen erfolgen jeweils im Nachgang an das Standup.
Das Sprint Review (2 bis 4 Stunden) wird zum Ende jedes Sprints abgehalten, um das Inkrement gemäss der Definition of Done zu prüfen und den Practice Backlog bei Bedarf anzupassen. Das Agile Service Management Team führt dabei die erledigten Aufgaben vor und beantwortet allfällige Fragen des Practice Owners, der die Hand über dem Backlog hat, während der Agile Service Manager für die Organisation und Moderation verantwortlich ist. Die wichtigste Entscheidung, die im Rahmen des Reviews gefällt wird, ist die, ob das fertiggestellte Inkrement ausgerollt wird oder nicht. Ausschlaggebend sind dabei neben Abhängigkeiten und dem Wertbeitrag des Inkrements auch die Aufnahmefähigkeit und Veränderungsbereitschaft der Organisation.
Mit der Sprint Retrospective (1,5 bis 3 Stunden) hat das Agile Service Management Team die Gelegenheit, sich selbst zu überprüfen und Verbesserungen für den nächsten Sprint zu planen. Hier werden Fragen besprochen wie: Was haben wir richtig gemacht? Was hätten wir besser machen können? Was haben wir gelernt? Was werden wir beim nächsten Mal anders machen? Die Fragen beziehen sich unter anderem auf die Zusammensetzung und Fähigkeiten des Teams, weitere Stakeholder, die Meeting-Kultur und Kommunikation sowie verwendete Tools. Der Agile Service Manager moderiert das Meeting und stellt sicher, dass alle Mitglieder sich gleichberechtigt beteiligen können.
Das Microprocess Planning Meeting (ohne Zeitvorgabe) fokussiert sich auf eine einzige, genau definierte Aktivität. Analog zu anderen Planungsmeetings werden auch hier – wenn auch im kleineren Rahmen und damit weniger Komplexität – die Ziele, Messgrössen, Verantwortlichkeiten, Risken, Abhängigkeiten und relevante Stakeholder diskutiert. Das Ergebnis sind in der Regel einer oder mehrere Sprints, die sich auf genau diesen Mikroprozess konzentrieren.
Agilität erfolgreich umsetzen
Sie kennen jetzt die Theorie und Tools. Aber wie sieht agiles Servicemanagement in der Praxis aus? Grundlegend gilt es zu bedenken, dass «Agilität» nicht vom Himmel fällt. Fangen Sie einfach an und bleiben Sie einfach. Die agile Denkweise muss erst innerhalb der Organisation etabliert werden, das erfordert Zeit. Steigern Sie die Prozessreife durch kleine Schritte ganzheitlich und organisch, nur so erzielen Sie auf lange Sicht kontinuierliche Erfolge.Agiles Mindset etablieren
Um das Thema «Agilität» innerhalb der Organisation zu verankern, benötigt es zum einen die Unterstützung der Geschäftsleitung. Diese muss dabei unterstützen, die Mitarbeitenden in dieser Hinsicht zu schulen und Freiräume zu schaffen, um agile Arbeitsweisen im täglichen Betrieb auszuprobieren und so schrittweise zu etablieren. Auf lange Sicht sorgen agile Methoden für eine Produktivitätssteigerung. Allerdings kann es zu Beginn zu Produktivitätsverlusten kommen, die von der Organisation ausgehalten werden können müssen.Wenn das Committment der Geschäftsleitung gesichert ist, geht es darum, innerhalb der Organisation ein einheitliches Verständnis von «Agilität» schaffen. Dabei sollten die wichtigsten Begriffe und Prinzipien definiert und entsprechend geschult werden. Wichtig zu verstehen ist, dass das kein einmaliges Vorhaben ist, sondern kontinuierlich vorangetrieben werden sollte, um das agile Mindset wirklich bei allen Mitarbeitenden zu verankern. Dies erreichen Sie mit kleinen Schritten (z.B. Sprints oder Kanban-Boards), sodass die Einführung der Methodik durch die Mitarbeiter:innen mit vorangetrieben, stetig weitergetrieben und akzeptiert wird. So schaffen Sie die Basis, um agiles Servicemanagement effektiv und effizient einzuführen.
Agiles Servicemanagement aufsetzen
Jetzt aber wirklich von der Theorie in die Praxis:Legen Sie den Scope fest
Definieren Sie das Team
Legen Sie die Methodologie fest
Füllen Sie den Practice Backlog
Beginnen Sie mit dem ersten Sprint
In den nachfolgenden Absätzen führe ich Sie durch diese fünf Schritte und zeige Ihnen anhand eines Umsetzungsbeispiels, basierend auf meiner eigenen Projekterfahrungen, worauf es wirklich ankommt.
Zu Beginn der Transition sollte der Scope festgelegt werden. Dabei ist es hilfreich, mit einem Team zu starten, das dem Thema «Agilität» generell eher gegenübersteht, um erste Erfahrungen zu sammeln. Diese Teammitglieder können während des Rollouts in die Organisation als «Change Enabler» unterstützen.
Was Sie als Organisation als Practice definieren, steht Ihnen frei. Gerade zu Beginn bietet es sich aber an, Practices aus ITIL 4 wie z.B. das Incident Management oder das Change Enablement als Practice zu verwenden, da ihr Scope bereits gut definiert ist. Eine andere Möglichkeit besteht darin, einen Service wie z.B. Workplace Collaboration als Practice anzusehen. Je nach spezifischem Bedürfnis lassen sich diese Ansätze auch weiter herunterbrechen. Wichtig ist nur, dass der Scope klar abgegrenzt wird, sodass dafür ein Agile Service Management Team etabliert werden kann.
Wir haben uns für einen ersten Schritt in Richtung Agilität für die Practice «Workplace Services» entschieden. Der Scope umfasst die Hardware wie Arbeitsplatzgeräte, das Betriebssystem, zugehörige Anwendungen und Dienstleistungen wie den Aufbau, den Abbau und den Austausch von Geräten.
Als nächstes geht es darum, für die definierte Practice die entsprechenden Rollen zu besetzen. Vor allem der Agile Practice Owner ist hier von zentraler Bedeutung. Beispielsweise könnte dies in Anlehnung an ITIL 4 der Practice Owner oder aber der Process Owner eines Services sein. In seiner:ihrer Rolle als Agile Practice Owner hat er:sie die Verantwortung über die entsprechende Practice und den damit einhergehenden Practice Backlog.
Des weiteren muss der Agile Service Manager besetzt werden. Diese:r sollte bereits Erfahrungen in der Umsetzung von agilem Servicemanagement und/oder Scrum gesammelt haben, damit er:sie das Agile Service Management Team bei der Umsetzung der Methodik unterstützen kann. Er:sie sollte auch innerhalb der Organisation gut vernetzt sein, um eine gewisse «Power» zu haben, Veränderungen einzubringen.
Zu guter Letzt braucht es natürlich auch das Agile Service Management Team. In dieses Team müssen alle Personen integriert werden, die für die Umsetzung der Practice relevant sind, beispielsweise Tool Administratoren, System Engineers, Process Engineers/Architects, Process Practicioners etc. Alle Beteiligten sollten im Idealfall dediziert für das agile Servicemanagement zur Verfügung stehen. In kleineren Organisationen ist das selten realistisch, daher können diese Personen auch mit anderen Teams «geteilt» werden. Die Kapazität für das Agile Service Management Team muss aber klar vereinbart und eingehalten werden.
Der bisherige Service Owner der «Workplace Services» wird nun die Rolle des Agile Practice wahrnehmen. Als Agile Service Manager fungiert ein externer zertifizierter Agile Service Manager (alternativ käme natürlich auch eine interne Person oder ein zertifizierter Scrum Master in Frage).
Das Agile Service Management Team besteht aus einem System Engineer für das Windows Betriebssystem, einem Technical Writer für die technische Dokumentation, einem Process Architect/Engineer für das Design und die Implementierung von Prozessen inklusive ihrer Dokumentation. Ein Tool Administrator ist für die Implementierung der Practice im ITSM-Tool verantwortlich. Ein Trainer erstellt die Unterlagen für die Schulung der Mitarbeitenden und führt diese eigenständig durch. Ein Software-Paketierungsspezialist ist für die Paketierung der Software verantwortlich. Weitere Experten werden bei Bedarf hinzugezogen.
Nicht alle Personen stehen dem Agile Service Management Team zu 100 % zur Verfügung. Abhängig von den individuellen Fähigkeiten führen manche Personen mehrere Rollen aus bzw. manche Rollen werden von mehreren Personen ausgeführt.
Das Agile Service Management Team besteht aus einem System Engineer für das Windows Betriebssystem, einem Technical Writer für die technische Dokumentation, einem Process Architect/Engineer für das Design und die Implementierung von Prozessen inklusive ihrer Dokumentation. Ein Tool Administrator ist für die Implementierung der Practice im ITSM-Tool verantwortlich. Ein Trainer erstellt die Unterlagen für die Schulung der Mitarbeitenden und führt diese eigenständig durch. Ein Software-Paketierungsspezialist ist für die Paketierung der Software verantwortlich. Weitere Experten werden bei Bedarf hinzugezogen.
Nicht alle Personen stehen dem Agile Service Management Team zu 100 % zur Verfügung. Abhängig von den individuellen Fähigkeiten führen manche Personen mehrere Rollen aus bzw. manche Rollen werden von mehreren Personen ausgeführt.
Bevor es ans Eingemachte geht, muss die auf die Organisation angepasste Methodologie festlegen werden. Das bedeutet, Sie müssen festlegen, welche formellen und indirekten Artefakte sowie welche Spring Events tatsächlich eingesetzt werden. Zu Beginn empfehle ich die Anwendung wie sie «im Buche steht». Sobald Sie erste Erfahrungen gesammelt haben, können Sie diese immer noch entsprechend Ihrer konkreten Bedürfnisse anpassen.
Jetzt muss «nur» noch der Practice Backlog gefüllt und priorisiert werden. Hierfür müssen Sie alle Anforderungen und Bedürfnisse Ihrer Kund:innen sowie auch die der IT-internen Stakeholder dokumentiert und integriert werden. Wichtig ist, User Stories sauber zu dokumentieren, damit im weiteren Verlauf von Anforderungen und Bedürfnissen – und nicht vom Lösungsdesign – ausgegangen wird. Die finale Verantwortung des Backlogs liegt beim Practice Owner.
Wir dokumentieren alle Bedürfnisse der Kund:innen wie es «im Buche steht». Das bedeutet, dass sämtliche Change Requests als User Story erfasst und entsprechend dokumentiert werden. Emergency Changes werden nach Bedarf ebenfalls als User Story erfasst und kurzfristig in den Sprint integriert. Zusätzlich werden «normale» ITIL Practices wie beispielsweise das Change Enablement berücksichtigt.
Dann geht’s los: Setzen sie den ersten Sprint um, sammeln sie Erfahrungen und lassen sie diese in den nächsten Spring einfliessen, um sich kontinuierlich zu verbessern. Sobald die Methodik mit einem Team gut funktioniert, kann diese Herangehensweise auf weitere Teams ausgeweitet werden. Hier kann sich der SAFe-Ansatz als nützlich erweisen, um verschiedene agile Teams zu synchronisieren. Wichtiger als die Methodik selbst ist aber das Mindset. Damit der Change zur agilen Kultur gelingt, empfiehlt es sich, Promotoren oder «Change Enabler» einzusetzen. Dies kann beispielsweise Ihr ursprüngliches Team sein, das seine Erfahrungen weitergibt und so mehr Offenheit und Akzeptanz gegenüber der agilen Arbeitsweise schafft.
Abschliessende Worte
Agiles Servicemanagement in einer Organisation nachhaltig zu etablieren, ist kein Sprint, sondern ein Marathon – pun intended. Aber Sie brauchen viele kleine Sprints, um zum nächsten Etappenziel zu gelangen, denn das Endziel gibt es nicht. Agilität bedeutet auch kontinuierliche Verbesserung und die kann schon per Definition nicht über Nacht erfolgen. Nehmen Sie sich Zeit, starten sie klein und weiten Sie aus, was sich bewährt hat. So erhöhen Sie die Prozessreife Ihrer Organisation schrittweise und sorgen für nachhaltige Produktivitäts- und Qualitätssteigerungen.Im Grunde brauchen Sie nur zwei Dinge: erstens das Committment des Managements und zweites ein Team mit einem Grundverständnis zu und Bereitschaft für agile Arbeitsweisen. Und dann legen Sie einfach los.
Ich empfehle immer, den ersten Sprint nach Lehrbuch durchzuführen – nicht, weil das die beste Methode ist. Die beste Methode ist letztlich die, die auf spezifischen Bedürfnisse Ihrer Organisation abgestimmt ist. Aber es ist eine Version, die sich so oder ähnlich für viele agile Teams bewährt hat und eine einheitliche Basis liefert. Was funktioniert, machen Sie im nächsten Sprint genauso. Was nicht funktioniert, ändern Sie. So schaffen Sie Stück für Stück eine agile Kultur, die Sie schrittweise auf die gesamte Abteilung, den Bereich oder die Organisation ausweiten können.
Ein agiles Team besteht immer aus genau den Experten, die es braucht, um das Sprintziel – in unserem Fall ein Blogartikel über «Agiles Servicemanagement» – zu erreichen. Thomas Scherzinger ist unser zertifizierter Agile Service Manager und Fachexperte rund um die Methodik. Unterstützt wurde er durch das Agile Service Management Team bestehend aus Julia Heumos (Scrum & agiles Mindset), Simon Hoefler (DevOps & ITIL), Alex Grozea (Recherche) und Riad Beqiri (Textarbeit) sowie Practice Owner Melanie Zollinger mit der Definition of Done. Herzlichen Dank an alle Beteiligten.
Autor
Thomas Scherzinger
Thomas' Beratungsschwerpunkte liegen im Einführen und Verbessern von IT-Servicemanagement, im IT-Projektmanagement sowie in der Implementierung und kontinuierlichen Verbesserung von nachhaltigen neuen Dienstleistungen für einen modernen Arbeitsplatz.
Thomas Scherzinger
Thomas' Beratungsschwerpunkte liegen im Einführen und Verbessern von IT-Servicemanagement, im IT-Projektmanagement sowie in der Implementierung und kontinuierlichen Verbesserung von nachhaltigen neuen Dienstleistungen für einen modernen Arbeitsplatz.
