Was ist Ihre derzeitige Funktion, was sind Ihre Aufgaben?
Ich bin Leiter des SharePoint-Kompetenzzentrums bei Smals, der gemeinsamen ICT-Organisation der belgischen öffentlichen Sozialversicherungseinrichtungen. Ich bin als Projektmanagerin für die Durchführung der SharePoint-Projekte verantwortlich, die uns von unseren Mitgliedern anvertraut werden.
Wie sind Sie auf AgilePM aufmerksam geworden, was war Ihr ursprünglicher Bedarf?
Die AgilePM-Schulung ist Teil unseres Schulungskatalogs. Ich war auf der Suche nach einer agilen Methode und wusste, dass der SCRUM-Ansatz, der auch bei Smals verwendet wird, im Wesentlichen darauf abzielt, dem Bedürfnis nach Organisation von Entwicklungsteams gerecht zu werden. Wir hatten versucht, diesen Ansatz bei SharePoint-Projekten umzusetzen, aber das war nicht überzeugend gewesen. Ich suchte nach einem umfassenderen Ansatz, der auch das Projektmanagement einbezog und es uns ermöglichen würde, die Vertreter des Fachbereichs besser in unsere Projekte einzubinden und sicherzustellen, dass wir an Dingen arbeiten, die wichtig sind.
Kurz nach der Ausbildung haben Sie erfolgreich ein größeres Projekt geleitet. Können Sie uns den Hintergrund des Doppelprojekts erläutern?
Smals unterstützt und sekundiert Organisationen des Sozial- und Gesundheitssektors – sowie auf Anfrage auch andere öffentliche Dienste – bei ihrem Informationsmanagement, damit sie ihren Nutzern eine effiziente und effektive Leistungserbringung bieten können. Smals stellt seine Kompetenzen zur Wiederverwendung zur Verfügung, um gegenseitige Skaleneffekte und eine höhere Wertschöpfung zu erzielen.
Das erste Projekt, bei dem wir den AgilePM-Ansatz anwandten, betraf eine belgische Sozialversicherungseinrichtung, die zwei Anwendungen, die zuvor in Lotus Notes existierten, in SharePoint-Anwendungen zu erneuern suchte. Es handelte sich um zwei große Pilotprojekte (eine Anwendung zur Verwaltung von Anträgen und ein Portal für die interne Kommunikation), die es ihnen außerdem ermöglichen sollten, ihre Sharepoint-Kompetenzen und ihre Fähigkeiten im Projektmanagement mit Sharepoint weiterzuentwickeln. Wir führten den agilen Projektansatz AgilePM mit diesem Mitglied ein, und alles lief sehr gut, wir waren aus vielen Gründen sehr zufrieden.
Im Anschluss an meine Ausbildung bildete ich einen Kollegen aus, der gegenüber dem Mitglied die Rolle des technischen Architekten/Entwicklers/Coaches übernahm. Ziel war es, dass diese Person eine Reihe von Elementen entwickelt und parametrisiert und gleichzeitig mit dem zu schulenden Team zusammenarbeitet, damit die Mitarbeiter dieses Teams ebenfalls an der Entwicklung des Projekts beteiligt sind.
Wir brieften unsere Gesprächspartner aus dem Business (Business Ambassador) und aus dem technischen Bereich (die Entwickler) bei ein und demselben Kickoff für beide Projekte. Ich erklärte die Methode, welche Rollen und Verantwortlichkeiten jeder hat, wie es funktionieren würde und am Ende des Kick-offs gaben wir dem Business den Auftrag, eine erste Version des Backlogs zu erstellen, indem sie ihre Anforderungen beschrieben und diese nach der MOSCOW-Technik priorisierten. Die Herausforderung bestand darin, 60% des gesamten Projektaufwands als Must zu bezeichnen, was oft schwierig ist (oft erhält man in der ersten Runde 70 oder sogar 80% Must-Anforderungen).
Was waren Ihre Einschränkungen, Ihre Herausforderungen?
Die erste Herausforderung war das Coaching, da ein Teil des Teams nicht mein übliches Team war. Meine zweite Herausforderung bestand darin, sicherzustellen, dass das gesamte Projektteam mitzieht und die Regeln, die Vision und die Herausforderungen versteht. Einer der Entwickler, der ansonsten technisch sehr gut war, war zum Beispiel nicht von der AgilePM-Methode überzeugt, er war anfangs etwas skeptisch, aber er spielte schließlich mit und konnte feststellen, dass dieser Ansatz gar nicht so schlecht funktionierte und dass die Beziehungen zur Geschäftswelt sehr gut verliefen. Die Kunden schätzten übrigens die Arbeit im agilen Modus dank der AgilePM-Methode, die es ermöglicht, das Geschäft viel stärker in das Projekt und in tagesaktuelle Entscheidungen einzubeziehen. Manchmal denkt das Geschäft, dass etwas einfach ist, aber durch die Einbindung erkennt es die tatsächlichen Schwierigkeiten; umgekehrt verstehen die Entwickler die zugrunde liegenden Anforderungen besser. Die AgilePM-Methode ermöglicht einen transparenten Dialog und die richtigen Entscheidungen, ohne dass die Entwicklungsteams sich an Dingen abarbeiten, die für das Geschäft nicht so wichtig sind.
Die Kunden erwarteten, dass das Projekt schnell vorangeht, und wollten schnell Ergebnisse sehen, ohne eine Deadline gesetzt zu haben (was eine Falle sein kann, da man viel länger brauchen kann als nötig). Wir konnten jedoch schnell liefern und innerhalb von drei Monaten waren wir bereit, in Produktion zu gehen. Es gab Probleme mit der Netzwerkleistung, die verhinderten, dass wir wie geplant live gehen konnten, aber wir waren bereit. Wir haben es einfach vorgezogen, abzuwarten und das Netzwerkproblem zu lösen, anstatt ein Tool zu liefern, das als leistungsschwach wahrgenommen worden wäre, auch wenn die Ursache außerhalb des Tools lag.
Wie haben Sie die Methode implementiert?
Nachdem wir das Coaching und den Kick-off durchgeführt hatten, führten wir alle zwei Wochen Sprint Review/Sprint Planning Meetings für jedes der Projekte ein, was bedeutete, dass ein Projekt in der einen Woche bearbeitet wurde und das andere in der nächsten Woche und so weiter. Einer der beiden Business Ambassadors nahm von Amts wegen an den Meetings des anderen teil, um eine gewisse Konsistenz bei den Entscheidungen zu gewährleisten, da wir an der gleichen technischen Plattform arbeiteten. Jeden Tag gab es außerdem ein 15-minütiges Standup-Meeting, an dem das Projektteam (geschäftliche und technische Ansprechpartner) beteiligt war.
Wir hielten jeden Monat ein einstündiges Project Board ab und das reichte aus, um den Projektfortschritt zu verfolgen. Es ist wichtig, während der Project Boards nicht zu sehr auf funktionale oder technische Details einzugehen, sondern sich auf die Projektverfolgung zu konzentrieren. Nachdem diese Struktur für die Überwachung eingerichtet war, lief das Projekt fast wie von selbst!
Am Ende des Projekts führten wir aus der Ferne ein lessons learned durch, und das Feedback des Kunden, das dabei herauskam, war, dass sie anfangs vielleicht nicht ganz verstanden hatten, was beim kick off erklärt worden war und warum wir bestimmte Dinge verlangten, aber im Laufe der Zeit wurde alles klarer, sie verstanden, warum und warum die Bemühungen so intensiv waren. Bei einem nächsten Projekt sollten wir mehr auf diese Dimension achten. Auch der Kunde war sich anfangs nicht bewusst, wie viel Mühe er sich selbst machen musste. Business Ambassador zu sein ist ein Fast-Vollzeitjob und man muss in der Lage sein, den Personen, die diese Aufgabe erhalten, Zeit zur Verfügung zu stellen, damit sie ihr Engagement erfolgreich durchführen können. Es gibt einen bestimmten Besprechungsrhythmus, den man einhalten muss, aber man muss auch tagtäglich Fragen des Entwicklungsteams beantworten, an Tests teilnehmen und so weiter.
Wie hat Ihnen die AgilePM Methode geholfen? Welcher Teil war für Sie am hilfreichsten?
Am hilfreichsten ist meiner Meinung nach immer noch die MOSCOW-Priorisierungstechnik. Es ist ein großer Unterschied, ob man die Anforderungen in eine Reihenfolge bringt (1-2-3-4-5) oder ob man akzeptiert, dass eine Anforderung, die man trotzdem für wichtig hält, letztendlich nur ein „should“ ist, das vielleicht nie implementiert wird … weil andere Anforderungen vorgehen. Die kontinuierliche Priorisierung ist zweifellos DER nützlichste Punkt. Natürlich ist das nicht alles, die Methode als Ganzes ist nützlich.
Haben Sie Tipps für Fachleute in diesem Bereich?
Man muss sich weiterbilden. Ich empfehle, an einer echten Schulung mit einem Experten teilzunehmen und nicht einfach nur zuzuschauen, das Buch zu lesen und Elemente herauszupicken, je nachdem, was einen anspricht. Ich habe an einer Schulung in einer kleinen Gruppe von vier oder fünf Personen teilgenommen und konnte so die Methode gut verstehen, Templates erhalten und meine Fragen stellen. Ich persönlich hätte ohne die Schulung nie das ganze Handbuch gelesen und mir wären die Vorteile der Methode entgangen.
Ein kurzes Wort zum Abschluss?
Vor kurzem habe ich auch an einer DevOps-Schulung teilgenommen und ich sehe, dass die beiden gut zusammenpassen, da die Philosophie und die Kultur ähnlich sind.
Auch zu lesen : AgilePM was ist das? Definition und Schlüsselkonzepte
