MENÜ

Erfolge mit Agile PM!

Praktische Erfahrungen; Smals Belgien
Von: Orlando Heijmerink op 2 August 2021.
Einlesen: 6 Minuten.

Mit dieser erfolgreichen Anwendung des Agile PM-Ansatzes können Sie lesen, dass Scrum und der Agile PM-Ansatz gut zusammenarbeiten können. Gerade die Kombination mit einigen Aspekten des Projektmanagements macht hier den Unterschied. Hier war nämlich das Monitoring durch ein Project Board hilfreich. Darüber hinaus hat ihnen die MOSKAU-Priorisierungstechnik am meisten geholfen. 

Das knüpft an die Erfahrung meiner Kollegin an Natasja Spaans, die in ihrem vorherigen Blog über den Mehrwert eines „Geltungsbereich Governance Board“. Es scheint auch ein Bedarf an einer Koordinierungsstelle zu bestehen, die die Koordinierung in Bezug auf Umfang, Prioritätensetzung und Budget organisiert.  



Erfolge mit Agile PM. Praktische Erfahrungen; Smals Belgien

Smals ist die gemeinsame IKT-Organisation der öffentlichen Sozialversicherungsträger in Belgien. Sie realisieren innovative IKT-Projekte und Dienstleistungen im Bereich Beruf, Familie und Gesundheit für soziale Sicherungs- und Pflegeeinrichtungen und bieten ihnen ein breites Spektrum an IKT-Dienstleistungen an.

„IKT für die Gesellschaft“ ist für Smals nicht nur ein Slogan; Sie beteiligen sich an Pionierarbeit im Bereich E-Government und E-Health in Belgien und sind ein wichtiger Akteur bei der digitalen Transformation der sozialen Sicherheit und des Gesundheitswesens. Sie sind auch an der Entwicklung der G-Cloud, der belgischen Regierungs-Cloud, aktiv.

Karin Picart
Karine ist Projektleiterin & Teamleiterin bei Smals. Sie ist Spezialistin für kollaborative Tools und verantwortet das SharePoint-Kompetenzzentrum von Smals.

Was ist Ihre Aufgabe bei Smals?

Ich bin verantwortlich für das SharePoint Competence Center bei Smals, der gemeinsamen ICT-Organisation der belgischen öffentlichen Sozialversicherungsträger. Als Projektleiter bin ich für die uns von unseren Mitgliedern anvertrauten SharePoint-Projekte verantwortlich.

Wie haben Sie AgilePM kennengelernt und was war Ihr erster 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 – hauptsächlich für Software-Entwicklungsteams gedacht ist. Wir hatten schon früher versucht, diesen Ansatz auf SharePoint-Projekte anzuwenden, aber er war nicht überzeugend. Ich war auf der Suche nach einem globaleren Ansatz, der auch das Projektmanagement integriert, der es uns ermöglicht, Geschäftsvertreter besser in unsere Projekte einzubeziehen, um sicherzustellen, dass wir an den wichtigen Dingen arbeiten.

Schon kurz nach dem AgilePM-Training haben Sie dies erfolgreich auf wichtige Projekte angewendet. Können Sie den Hintergrund dieser Projekte erläutern?

Das erste Projekt, bei dem wir den AgilePM-Ansatz anwandten, betraf eine belgische Sozialversicherungsanstalt, die zwei Anwendungen, die zuvor in Lotus Notes existierten, in SharePoint-Anwendungen umwandeln wollte. Dabei handelte es sich um zwei große Pilotprojekte (eine Request-Management-Anwendung und ein internes Kommunikationsportal), die es ihnen auch ermöglichen würden, ihre SharePoint- und Projektmanagement-Fähigkeiten weiterzuentwickeln. Wir haben den AgilePM-Ansatz implementiert und es lief sehr gut; wir waren aus vielen gründen sehr zufrieden.

Nach meiner Ausbildung habe ich einen meiner Kollegen zum Architekten/Entwickler/technischen Coach für den Bauherrn ausgebildet. Ziel war es sicherzustellen, dass die Herangehensweise an die Projekte auf Kundenseite gut verstanden wird und maximales Engagement gefördert wird.

Für beide Projekte haben wir unsere geschäftlichen (Business Ambassador) und technischen (Entwickler) Kontakte zum gleichen Kick-off gebrieft. Ich erklärte die Methode, die Rollen und Verantwortlichkeiten jedes Einzelnen und wie es funktionieren würde. Am Ende des Kick-offs gaben wir dem Unternehmen die Aufgabe, eine erste Version des Backlogs zu erstellen, indem wir seine Anforderungen beschreiben und diese nach der MoSCoW-Priorisierungstechnik priorisieren (Must have, Should have, Could have, Won't have diesmal). Die Herausforderung bestand darin, 60 % des gesamten Projektaufwands als Must-haves zu bezeichnen, was schwierig sein kann (oft bekommen wir 70 oder sogar 80 % der Anforderungen in der ersten Runde als Must-haves).

Was waren Ihre Einschränkungen und Herausforderungen?

Die erste Herausforderung war die des Coachings, da ein Teil des Teams nicht mein übliches Team war. Die zweite Herausforderung bestand darin, sicherzustellen, dass das gesamte Projektteam die Regeln, die Vision und die Themen befolgt. So war beispielsweise einer der technisch sehr guten Entwickler vom AgilePM-Ansatz nicht überzeugt; er war anfangs etwas skeptisch. Aber am Ende hat er mitgespielt und konnte die Logik der Herangehensweise sehen und die Beziehung zum Unternehmen lief sehr gut. Die Kunden schätzten auch die agile Arbeitsweise dank AgilePM, die das Unternehmen deutlich stärker in das Projekt und in die täglichen Entscheidungen einbindet. Es ist nicht ungewöhnlich, dass das Unternehmen etwas für einfach hält. Aber durch ihre Beteiligung verstehen sie die Aufgabe und ihre Herausforderungen besser. Umgekehrt haben die Entwickler ein besseres Verständnis für die zugrunde liegenden Bedürfnisse. Der AgilePM-Ansatz ermöglicht es, einen transparenten Dialog zu führen und die richtigen Entscheidungen zu treffen, ohne dass die Entwicklungsteams in Dingen hängen bleiben, die für den Kunden/das Geschäft nicht sehr wichtig sind.

Die Kunden erwarteten, dass das Projekt schnell voranschreitet (und Ergebnisse liefert), ohne eine Frist zu setzen (was eine Falle sein kann, da es viel länger als nötig dauern kann). Wir konnten jedoch schnell liefern und innerhalb von drei Monaten waren wir bereit, live zu gehen. Es gab einige Probleme mit der Netzwerkleistung, die uns daran hinderten, wie geplant live zu gehen, aber wir waren bereit. Wir zogen es vor, zu warten und das Netzwerkproblem zu beheben, anstatt ein Tool zu liefern, das als minderwertig empfunden worden wäre, obwohl die Ursache außerhalb des Tools lag.

Wie haben Sie AgilePM implementiert?

Nach dem Coaching und Kick-off haben wir für jedes der Projekte alle zwei Wochen Sprint Review/Sprint Planning Meetings eingerichtet, d.h. ein Projekt wurde in der einen Woche behandelt, das andere in der nächsten und so weiter. Jeder der beiden Unternehmensbotschafter nahm an den Sitzungen des anderen teil, um die Konsistenz der Entscheidungen zu gewährleisten, da wir an derselben technischen Plattform arbeiteten. Außerdem gab es täglich ein 15-minütiges Stand-Up-Meeting mit dem Projektteam (kaufmännische und technische Kontakte).

Wir organisierten ein monatliches Projektboard von einer Stunde und das reichte aus, um den Fortschritt des Projekts zu verfolgen. Es ist wichtig, in Projektbeiräten nicht zu sehr auf funktionale oder technische Details einzugehen, sondern sich auf die Projektnachbereitung zu konzentrieren. Nachdem diese Überwachungsstruktur erst einmal eingerichtet war, lief das Projekt fast wie von selbst!

Am Ende des Projekts führten wir eine aus den Lektionen gelernte Übung aus der Ferne durch. Das Kundenfeedback war, dass sie am Anfang nicht wirklich verstanden haben, was beim Kick-off erklärt wurde und warum wir nach bestimmten Dingen gefragt haben. Mit der Zeit wurde jedoch alles klarer, sie verstanden, warum und warum wir so intensiv gearbeitet haben. Für ein zukünftiges Projekt werden wir diesem Aspekt mehr Aufmerksamkeit schenken.

Der Auftraggeber war sich auch zu Beginn der Arbeiten nicht bewusst, was er von seiner Seite verlangen würde. Unternehmensbotschafter zu sein ist fast ein Vollzeitjob und es ist wichtig, dass ihnen die Zeit gegeben wird, diese wichtige Rolle zu erfüllen. Es gibt mehrere Meetings, an denen Sie teilnehmen müssen, und Sie müssen auch bereit sein, täglich Fragen und Bedenken des Entwicklungsteams zu beantworten, an Tests teilzunehmen usw.

Wie hat Ihnen der AgilePM-Ansatz geholfen? Gab es ein bestimmtes Element, das Ihnen am meisten geholfen hat?

Am nützlichsten ist meiner Meinung nach die MoSCoW-Priorisierungstechnik. Es besteht ein großer Unterschied zwischen der Anordnung der Anforderungen in einer Reihenfolge (1-2-3-4-5) und der Annahme, dass eine Anforderung, die Ihnen wichtig ist, nur ein "Sollte" ist, das möglicherweise nie umgesetzt wird, da andere Anforderungen an erster Stelle stehen. Kontinuierliche Priorisierung ist wahrscheinlich der nützlichste Aspekt. Natürlich ist dies nicht der einzige Punkt, der ganze Rahmen ist nützlich.

Haben Sie Ratschläge für andere Projektprofis in der Branche?

Sie müssen geschult werden. Ich empfehle, sich von einem Experten schulen zu lassen und es nicht nur auszuprobieren, sondern das Buch zu lesen und nur die Elemente herauszusuchen, die Sie ansprechen. Ich habe in einer kleinen Gruppe ein Training absolviert und das hat mir ermöglicht, die Methode gut zu verstehen, Vorlagen zu erstellen und meine Fragen zu stellen. Ohne die Schulung hätte ich persönlich nie das gesamte Handbuch gelesen und wichtige Vorteile der Methode verpasst.

Ein paar Worte zum Schluss?

Vor kurzem habe ich auch einen DevOps-Kurs besucht und kann sehen, dass die beiden gut zusammenpassen, weil die
Philosophie und Kultur sind ähnlich.

Quelle: APMG International, QRP-Entwickler, APMG International AgilePM, Agiles Geschäftskonsortium

DPDF Herunterladen

Mit dieser erfolgreichen Anwendung des Agile PM-Ansatzes können Sie lesen, dass Scrum und der Agile PM-Ansatz gut zusammenarbeiten können. Gerade die Kombination mit einigen Aspekten des Projektmanagements macht hier den Unterschied. Hier war nämlich das Monitoring durch ein Project Board hilfreich. Darüber hinaus hat ihnen die MOSKAU-Priorisierungstechnik am meisten geholfen. 

Das knüpft an die Erfahrung meiner Kollegin an Natasja Spaans, die in ihrem vorherigen Blog über den Mehrwert eines „Geltungsbereich Governance Board“. Es scheint auch ein Bedarf an einer Koordinierungsstelle zu bestehen, die die Koordinierung in Bezug auf Umfang, Prioritätensetzung und Budget organisiert.  



Erfolge mit Agile PM. Praktische Erfahrungen; Smals Belgien

Smals ist die gemeinsame IKT-Organisation der öffentlichen Sozialversicherungsträger in Belgien. Sie realisieren innovative IKT-Projekte und Dienstleistungen im Bereich Beruf, Familie und Gesundheit für soziale Sicherungs- und Pflegeeinrichtungen und bieten ihnen ein breites Spektrum an IKT-Dienstleistungen an.

„IKT für die Gesellschaft“ ist für Smals nicht nur ein Slogan; Sie beteiligen sich an Pionierarbeit im Bereich E-Government und E-Health in Belgien und sind ein wichtiger Akteur bei der digitalen Transformation der sozialen Sicherheit und des Gesundheitswesens. Sie sind auch an der Entwicklung der G-Cloud, der belgischen Regierungs-Cloud, aktiv.

Karin Picart
Karine ist Projektleiterin & Teamleiterin bei Smals. Sie ist Spezialistin für kollaborative Tools und verantwortet das SharePoint-Kompetenzzentrum von Smals.

Was ist Ihre Aufgabe bei Smals?

Ich bin verantwortlich für das SharePoint Competence Center bei Smals, der gemeinsamen ICT-Organisation der belgischen öffentlichen Sozialversicherungsträger. Als Projektleiter bin ich für die uns von unseren Mitgliedern anvertrauten SharePoint-Projekte verantwortlich.

Wie haben Sie AgilePM kennengelernt und was war Ihr erster 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 – hauptsächlich für Software-Entwicklungsteams gedacht ist. Wir hatten schon früher versucht, diesen Ansatz auf SharePoint-Projekte anzuwenden, aber er war nicht überzeugend. Ich war auf der Suche nach einem globaleren Ansatz, der auch das Projektmanagement integriert, der es uns ermöglicht, Geschäftsvertreter besser in unsere Projekte einzubeziehen, um sicherzustellen, dass wir an den wichtigen Dingen arbeiten.

Schon kurz nach dem AgilePM-Training haben Sie dies erfolgreich auf wichtige Projekte angewendet. Können Sie den Hintergrund dieser Projekte erläutern?

Das erste Projekt, bei dem wir den AgilePM-Ansatz anwandten, betraf eine belgische Sozialversicherungsanstalt, die zwei Anwendungen, die zuvor in Lotus Notes existierten, in SharePoint-Anwendungen umwandeln wollte. Dabei handelte es sich um zwei große Pilotprojekte (eine Request-Management-Anwendung und ein internes Kommunikationsportal), die es ihnen auch ermöglichen würden, ihre SharePoint- und Projektmanagement-Fähigkeiten weiterzuentwickeln. Wir haben den AgilePM-Ansatz implementiert und es lief sehr gut; wir waren aus vielen gründen sehr zufrieden.

Nach meiner Ausbildung habe ich einen meiner Kollegen zum Architekten/Entwickler/technischen Coach für den Bauherrn ausgebildet. Ziel war es sicherzustellen, dass die Herangehensweise an die Projekte auf Kundenseite gut verstanden wird und maximales Engagement gefördert wird.

Für beide Projekte haben wir unsere geschäftlichen (Business Ambassador) und technischen (Entwickler) Kontakte zum gleichen Kick-off gebrieft. Ich erklärte die Methode, die Rollen und Verantwortlichkeiten jedes Einzelnen und wie es funktionieren würde. Am Ende des Kick-offs gaben wir dem Unternehmen die Aufgabe, eine erste Version des Backlogs zu erstellen, indem wir seine Anforderungen beschreiben und diese nach der MoSCoW-Priorisierungstechnik priorisieren (Must have, Should have, Could have, Won't have diesmal). Die Herausforderung bestand darin, 60 % des gesamten Projektaufwands als Must-haves zu bezeichnen, was schwierig sein kann (oft bekommen wir 70 oder sogar 80 % der Anforderungen in der ersten Runde als Must-haves).

Was waren Ihre Einschränkungen und Herausforderungen?

Die erste Herausforderung war die des Coachings, da ein Teil des Teams nicht mein übliches Team war. Die zweite Herausforderung bestand darin, sicherzustellen, dass das gesamte Projektteam die Regeln, die Vision und die Themen befolgt. So war beispielsweise einer der technisch sehr guten Entwickler vom AgilePM-Ansatz nicht überzeugt; er war anfangs etwas skeptisch. Aber am Ende hat er mitgespielt und konnte die Logik der Herangehensweise sehen und die Beziehung zum Unternehmen lief sehr gut. Die Kunden schätzten auch die agile Arbeitsweise dank AgilePM, die das Unternehmen deutlich stärker in das Projekt und in die täglichen Entscheidungen einbindet. Es ist nicht ungewöhnlich, dass das Unternehmen etwas für einfach hält. Aber durch ihre Beteiligung verstehen sie die Aufgabe und ihre Herausforderungen besser. Umgekehrt haben die Entwickler ein besseres Verständnis für die zugrunde liegenden Bedürfnisse. Der AgilePM-Ansatz ermöglicht es, einen transparenten Dialog zu führen und die richtigen Entscheidungen zu treffen, ohne dass die Entwicklungsteams in Dingen hängen bleiben, die für den Kunden/das Geschäft nicht sehr wichtig sind.

Die Kunden erwarteten, dass das Projekt schnell voranschreitet (und Ergebnisse liefert), ohne eine Frist zu setzen (was eine Falle sein kann, da es viel länger als nötig dauern kann). Wir konnten jedoch schnell liefern und innerhalb von drei Monaten waren wir bereit, live zu gehen. Es gab einige Probleme mit der Netzwerkleistung, die uns daran hinderten, wie geplant live zu gehen, aber wir waren bereit. Wir zogen es vor, zu warten und das Netzwerkproblem zu beheben, anstatt ein Tool zu liefern, das als minderwertig empfunden worden wäre, obwohl die Ursache außerhalb des Tools lag.

Wie haben Sie AgilePM implementiert?

Nach dem Coaching und Kick-off haben wir für jedes der Projekte alle zwei Wochen Sprint Review/Sprint Planning Meetings eingerichtet, d.h. ein Projekt wurde in der einen Woche behandelt, das andere in der nächsten und so weiter. Jeder der beiden Unternehmensbotschafter nahm an den Sitzungen des anderen teil, um die Konsistenz der Entscheidungen zu gewährleisten, da wir an derselben technischen Plattform arbeiteten. Außerdem gab es täglich ein 15-minütiges Stand-Up-Meeting mit dem Projektteam (kaufmännische und technische Kontakte).

Wir organisierten ein monatliches Projektboard von einer Stunde und das reichte aus, um den Fortschritt des Projekts zu verfolgen. Es ist wichtig, in Projektbeiräten nicht zu sehr auf funktionale oder technische Details einzugehen, sondern sich auf die Projektnachbereitung zu konzentrieren. Nachdem diese Überwachungsstruktur erst einmal eingerichtet war, lief das Projekt fast wie von selbst!

Am Ende des Projekts führten wir eine aus den Lektionen gelernte Übung aus der Ferne durch. Das Kundenfeedback war, dass sie am Anfang nicht wirklich verstanden haben, was beim Kick-off erklärt wurde und warum wir nach bestimmten Dingen gefragt haben. Mit der Zeit wurde jedoch alles klarer, sie verstanden, warum und warum wir so intensiv gearbeitet haben. Für ein zukünftiges Projekt werden wir diesem Aspekt mehr Aufmerksamkeit schenken.

Der Auftraggeber war sich auch zu Beginn der Arbeiten nicht bewusst, was er von seiner Seite verlangen würde. Unternehmensbotschafter zu sein ist fast ein Vollzeitjob und es ist wichtig, dass ihnen die Zeit gegeben wird, diese wichtige Rolle zu erfüllen. Es gibt mehrere Meetings, an denen Sie teilnehmen müssen, und Sie müssen auch bereit sein, täglich Fragen und Bedenken des Entwicklungsteams zu beantworten, an Tests teilzunehmen usw.

Wie hat Ihnen der AgilePM-Ansatz geholfen? Gab es ein bestimmtes Element, das Ihnen am meisten geholfen hat?

Am nützlichsten ist meiner Meinung nach die MoSCoW-Priorisierungstechnik. Es besteht ein großer Unterschied zwischen der Anordnung der Anforderungen in einer Reihenfolge (1-2-3-4-5) und der Annahme, dass eine Anforderung, die Ihnen wichtig ist, nur ein "Sollte" ist, das möglicherweise nie umgesetzt wird, da andere Anforderungen an erster Stelle stehen. Kontinuierliche Priorisierung ist wahrscheinlich der nützlichste Aspekt. Natürlich ist dies nicht der einzige Punkt, der ganze Rahmen ist nützlich.

Haben Sie Ratschläge für andere Projektprofis in der Branche?

Sie müssen geschult werden. Ich empfehle, sich von einem Experten schulen zu lassen und es nicht nur auszuprobieren, sondern das Buch zu lesen und nur die Elemente herauszusuchen, die Sie ansprechen. Ich habe in einer kleinen Gruppe ein Training absolviert und das hat mir ermöglicht, die Methode gut zu verstehen, Vorlagen zu erstellen und meine Fragen zu stellen. Ohne die Schulung hätte ich persönlich nie das gesamte Handbuch gelesen und wichtige Vorteile der Methode verpasst.

Ein paar Worte zum Schluss?

Vor kurzem habe ich auch einen DevOps-Kurs besucht und kann sehen, dass die beiden gut zusammenpassen, weil die
Philosophie und Kultur sind ähnlich.

Quelle: APMG International, QRP-Entwickler, APMG International AgilePM, Agiles Geschäftskonsortium

DPDF Herunterladen

Von Orlando Heijmerink

Meine Mission ist es, alle dazu zu bringen, den Leitfaden zu ändern. Ich möchte den Menschen ermöglichen, mehr Einfluss auf ihr eigenes Arbeitsumfeld zu nehmen, damit sie selbst Änderungen zum Erfolg führen können. Dazu stelle ich dem Kunden die richtigen Fragen, organisiere die Interaktion und überrasche meine Kunden weiterhin.

Schreiben sie ein Kommentar

Die Email-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert * *

Möchten Sie jeden Monat inspirierende Tipps und Informationen erhalten?

Melden Sie sich für unseren Newsletter an und erhalten Sie jeden Monat inspirierende Tipps und nützliche Informationen.
Newsletter-Fußzeile

Lagant Partner

Es ist unsere Aufgabe um Kunden zu helfen, ihre zu bekommen Ambitionen ändern in Erfüllung gehen.

26-Stationsplatz
3818 LE Amersfoort

Unser Standort in Amersfoort liegt direkt gegenüber dem Haupteingang des NS-Bahnhofs und ist daher mit öffentlichen Verkehrsmitteln gut erreichbar.
Wenn Sie mit dem Auto anreisen, parken Sie am besten im Q-Park P+R Barchman Wuytierslaan, etwa 5 Gehminuten von unserem Büro entfernt.

[E-Mail geschützt] +31 (0)41 322 4106
8.9
 152 Bewertungen
Van AetsveldSLIM-FörderprogrammAnleitung ändernIPMA KompaktPRINCE2 Kompakt
Diese Website wird zu 100 % mit nachhaltiger Energie betrieben, die aus kohlendioxidfreier und umweltfreundlicher Wasserkraft gewonnen wird.
© 1991-2024 Lagant | Alle Rechte vorbehalten