Agile Projekte im Auftraggeber-Dienstleister Verhältnis – Teil 3: Prozess

Als das Scrum-Framework vor ca. 20 Jahren erstmals vorgestellt wurde, lag der Fokus auf der internen Software-Entwicklung. Auch heute sind der Scrum-Guide oder auch andere agile Frameworks darauf ausgerichtet, dass sämtliche Tätigkeiten in der gleichen Unternehmung abgewickelt werden. Für Projekte zwischen Auftraggebern und Dienstleistern bieten agile Frameworks häufig keine fertigen Lösungen, Best Practices und Antworten, wie agile Projekte durchzuführen sind. Und somit ergeben sich in agilen Projekten in diesem Setup einige zusätzliche Herausforderungen, welche zu berücksichtigen sind. In dieser Blogpost-Serie möchte ich drei Bereiche vorstellen, welche eben solche Herausforderungen und Spannungen verursachen können. Welche Herausforderungen sind in Namics Projekten aufgetreten? Wie konnte diesen begegnet werden? Basis für die drei Blogposts ist meine Präsentation am Agile Breakfast von swissICT am 29. November 2016.


Thema: Prozess

Potenzielle Herausforderungen:

In Bezug auf den agilen Prozess, in unserem Fall ist es häufig der Scrum-Prozess, sehe ich es besonders kritisch, wenn gewisse Teile – Meetings oder andere Artefakte – von Aussen in Frage gestellt werden. Dies können wichtige Stakeholder wie z.B. die Sponsoren oder die Geschäftsleitung des Kunden sein. Da die Scrum Meetings durchaus einen grösseren Kostenanteil ausmachen können, sind diese immer wieder Ziel von Einsparungsbestrebungen.

T3Bild1

Was den agilen Projekt-Prozess ebenfalls stören oder beeinträchtigen kann, sind bestehende Prozesse beim Auftraggeber oder beim Dienstleister, die mit Projekten in Konflikt geraten können. So haben einige unserer Kunden relativ starre Projektantragsprozesse, bei welchen jeweils schon vor Projektstart ein klar definierter Scope eingereicht werden muss, um das Projektbudget sicherstellen zu können. Und so muss auch jedes Teilprojekt, ist es noch so klein, neu offeriert und beim Kunden intern beantragt werden. Danach müssen die verschiedenen Teilprojekte natürlich auch bei der Verrechnung berücksichtigt werden. Solche nicht-agilen Unternehmensprozesse können für ein agiles Projekt einiges an Mehraufwand und Hürden bedeuten.

Mögliche Lösungsvorschläge:

Um zu verhindern, dass der Scrum-Prozess in- und ausserhalb des Teams angezweifelt wird, ist es wichtig, dass man das agile Know-how immer wieder auffrischt und verbreitet. Aus meiner Sicht ist es wichtig, dass auch das Projektumfeld immer wieder auf die Vorzüge des agilen Vorgehens aufmerksam gemacht wird und ein „agiler Mindshift“ stattfinden kann. Dabei hat der Scrum Master eine sehr wichtige Rolle. Seine Aufgabe ist es, den Prozess zu schützen und immer wieder den Sinn der einzelnen Meetings, Artefakte und Vorgehensweise in den Vordergrund zu stellen. Es ist entscheidend, dass sich das ganze Team (und wenn möglich auch die Stakeholder) bewusst sind, weshalb gewisse Prinzipien eingehalten werden sollten.

Die ständige Sensibilisierung von Team und Umfeld kann in einigen Fällen sogar helfen, die starren Unternehmensprozesse aufzuweichen. Dies wird aber sicherlich nicht in allen Fällen gelingen. So muss man sich mit gewissen äusseren Vorgaben Umständen abfinden, diese Prozesse im Projektalltag berücksichtigen und so gut wie möglich mit ihnen leben.

Je nach Situation ist es auch vorstellbar, dass wir als Dienstleister den Product Owner so coachen können, dass dadurch die agile Transformation von gewissen Unternehmensprozessen beim Kunden vorangetrieben werden kann.

 

Teile 1 und 2 der Blogpost-Serie:

Agile Projekte im Auftraggeber-Dienstleister Verhältnis – Teil 1: Auftragsvergabe

Agile Projekte im Auftraggeber-Dienstleister Verhältnis – Teil 2: Rollen

 

Hinterlasse eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *

*

*

Du kannst folgende HTML-Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>