Der vergangene Teil dieser Blogpost-Reihe befasste sich mit den Parallelen und Unterschieden der beiden Rahmenwerke ITIL und Scrum im Hinblick auf die Strategie. Dabei stand auf beiden Seiten das jeweilige übergeordnete Ziel im Vordergrund.
Der erste Teil betont, dass eingeschränkte Blickwinkel problematisch sind. Jede Tätigkeit sollte stets noch unter Beachtung des übergeordneten Zieles ausgeübt werden.
In diesem Teil der Serie liegt der Fokus nun auf etwas anderen Themen als in den vorangegangenen Artikeln. So soll herausgestellt werden, welche kritischen Ankerpunkte in der strategischen Planung angegangen werden müssen, um Scrum in einer (Software-)Produktentwicklung zu etablieren.
Vorteile durch die Einbindung der Führungsebene in die Entwicklungsumstellung
Die Bedeutung und Ziele der Entwicklungsumstellung sollten von Beginn an für alle betroffenen Mitarbeitenden klar sein. Das frühe Involvieren der verantwortlichen Führungspersonen und -gremien ist hierfür unerlässlich. Es gibt sowohl personelle, finanzielle als auch Verhaltensaspekte, die beachtet und vermittelt werden müssen:
Im personellen Sinn sollten zumindest ein Scrum-Master sowie ein Product Owner für eine erste Piloteinführung eingesetzt werden.
Finanziell ist es wichtig zu sehen, dass neben Personalkosten auch weitere Aufwände entstehen. Diese treten z. B. durch die Umstellung der Arbeitsweise auf, denn diese ist auch immer ein Lernprozess für alle Beteiligten. Dies ist insbesondere dann der Fall, wenn die Developer noch wenige, bis keine Berührungspunkte zu agilen Methoden hatten.
Darüber hinaus muss den entsprechenden Verantwortlichen bewusst gemacht werden, dass die Transformation keinen direkten Return on Investment haben wird. Durch die neue Methodik soll die Qualität sukzessiv gesteigert werden. Dies ist ein Effekt des schnellen Kundenfeedbacks. Eine Vergleichbarkeit von auf diese Weise durchgeführten Produktentwicklungen lässt sich nur in Bezug auf vorangegangene Entwicklungen ähnlicher Art durchführen.
Was ist für die Umstellung notwendig?
Mit die größten Umstellungen sind Verhaltensaspekte, die unter den Stichpunkt “Organisational Changemanagement” ITIL entsprechend fallen.
Man muss während der Entwicklung einen geschützten Bereich schaffen, denn diese Änderung ist essenziell für den Erfolg. Was bedeutet das genau? Die Developer sollen vor etwaigen Anfragen, zum Beispiel nach Berichten oder Änderungswünschen, geschützt werden. Dies ist eine Voraussetzung für die Ablieferung hochqualitativer Arbeitsergebnisse.
Der Product Owner ist der Single Point of Contact zwischen Developern und Stakeholdern und hat somit die Verantwortung für das Anforderungsmanagement. Ein willkürliches Abladen von Anforderungen bei den Developern darf es nicht geben. Es kann vorkommen, dass im Sprint umpriorisiert werden muss und zunächst höher priorisierte Punkte somit herabgestuft werden müssen.
Diese hier angeführten Themen benötigen die volle Unterstützung des Managements, unabhängig davon, wie diese im Einzelfall gestaltet ist.
Andernfalls gibt es nur geringe Chancen, dass eine erfolgreiche Einführung von Scrum gelingt.
Die erste Einführung von Scrum
Gerade in der ersten Etablierungsphase kann es zu Unsicherheiten und den klassischen menschlichen Widerständen, zum Beispiel Ignorieren oder Gegensteuern kommen.
Bei der zugrundeliegenden Änderung sollten daher alle relevanten Stakeholder mit einbezogen werden. Transparenz und Begleitung durch den Scrum Master ist notwendig, ebenso wie die Beachtung etwaiger Aspekte der vier Dimensionen bzw. auch der Umweltaspekte wie ITIL es beschreibt, siehe Teil 1 der Reihe. Beispielsweise müssen ggf. Zulieferer mit einbezogen werden, denn diese müssen sich je nach Anforderung auch an den Entwicklungszyklus anpassen. Wie früher schon angeführt, ist die Einführung von Scrum auch ein Entwicklungsprozess. Daher ist es sicher vernünftig, umsetzbare Objectives zu definieren und diese dann im Sinne der strategischen Einführung auch iterativ zu verbessern.
Fazit
Die Einführung von Scrum ist nichts, was überhastet durchgeführt werden sollte. Hier kann ITIL unterstützen. Viele Punkte unterschiedlichster Natur müssen berücksichtigt werden. Das Rahmenwerk im gewählten Kontext soll von einer Innovation in den Zustand der Adoption übergehen, um so ein Vorgehen für eine ganzheitlich hochqualitative und ressourcenorientiere Produktentwicklung zu etablieren.