Agil oder Wasserfall – welche Projektmethodik eignet sich am besten, um SAP-Projekte zum Erfolg zu führen?
Diese Fragestellung diskutiert projekt0708 Geschäftsführer Michael Scheffler in dieser zweiteiligen Podcast-Episode zusammen mit Ludwig Wartlsteiner, Senior Consultant bei projekt0708.
Im ersten Teil versuchten sich die beiden Experten an einer Definition was agile Projekte eigentlich ausmacht und wie sich diese ausgestalten lassen. Aber auch die Tatsache, dass das gute alte Wasserfall-Modell nach wie vor eine Daseinsberechtigung besitzt wurde herausgearbeitet. In der aktuellen, zweiten Folge werden Insights zu einem realen Kundenprojekt geliefert, welches komplett agil und sogar zu 100%remote durchgeführt wurde. Abschließend werden konkrete Tipps für die Projektpraxis gegeben.
Ergänzende Informationen zu dieser Episode:
„Wie ProSiebenSat.1 sein Personalmanagement ganzheitlich neu aufstellt – SAP-SuccessFactors Einführung mit einzigartigem Job Portal“, Vortrag DSAG Personaltage 2022: https://www.projekt0708.de/fileadmin/inhalt/DSAG_Personaltage/DSAG_Personaltage_2022-Vortrag_P7S1_p78_final_Vortrag_22_06_22_14_30.pdf
„Individuelle Bewerberoberflächen mit SAP SuccessFactors Recruiting“, projekt0708 Success Story mit der ProSiebenSat.1 Media SE: https://www.projekt0708.de/prosiebensat1-jobportal-1.html
https://wirtschaftslexikon.gabler.de/definition/agilitaet-99882
https://www.bearingpoint.com/de-de/insights-events/insights/studie-agile-pulse-2020/
https://www.kienbaum.com/de/publikationen/agilitaet-in-der-digitalen-arbeitswelt/
DAS INTERVIEW ZUM NACHLESEN
Michael Scheffler:
Ein funktionierendes Projektmanagement stellt für jedes Unternehmen einen wesentlichen Erfolgsfaktor dar, um Projekte in Time, Budget und Quality abwickeln zu können. Dies gilt insbesondere für IT und somit auch für SAP-Projekte, die in einer sich immer schneller wandelnden Arbeitswelt gespickt von sich ändernden Rahmenbedingungen und Anforderungen umgesetzt werden müssen. Die Antwort auf all diese Herausforderungen lautet oftmals Agilität.
Aber trifft dies wirklich auf jede Art von Vorhaben, auch im SAP-Umwelt zu? Um dieser Frage auf den Grund zu gehen, habe ich Ludwig Wartlsteiner, Senior Consultant bei Projekt0708 befragt. Seine Antworten und Hilfestellungen waren so zahlreich, dass wir nicht nur in der heutigen Podcast-Folge darüber sprechen, sondern noch eine zweite Episode zu diesem Thema aufnehmen werden. Damit herzlich willkommen zu einer neuen Folge von HR IT-Talk, mein Name ist Michael Scheffler.
Michael Scheffler:
Servus Ludwig. Willkommen zurück bei HR IT-Talk. Du bist ja quasi schon Stammgast hier in diesem Podcast-Format. Wir hatten, ist jetzt schon eine Weile her, eine dreiteilige Serie zum Thema New Work aufgenommen, wo du uns sehr kompetent etwas zu dem Thema berichtet hast. Kannst du uns bitte dennoch dich und deine Person vorstellen für all die ZuhörerInnen, die diese Folge nicht gehört haben.
Ludwig Wartlsteiner:
Ja, sehr gerne. Aber zunächst einmal, Michael, vielen Dank, dass ich heute wieder mit dabei sein kann. Ich freue mich auch schon sehr auf die heutige Folge. Ich glaube wir haben auch gute Inhalte mit dabei. Vielleicht wirklich erst ein paar Worte zu mir nochmal. Manche sind ja heute das erste Mal mit dabei. Ludwig Wartlsteiner mein Name, ich bin Senior Consultant bei Projekt0708 und ich bin bei uns grundsätzlich im Bereich HR Transformation angesiedelt. Heißt übersetzt so viel wie, ich selbst bin eigentlich kein Techi, sondern ich begleite unsere Projekte und vor allem auch unsere Digitalisierungsprojekte eigentlich immer wieder in Form von verschiedenen Tätigkeiten rund um diese eigentlichen Implementierungsarbeiten. Beispielsweise ich bin ganz viel im Projektmanagement dabei, Prozessmanagement, Change Management und habe dementsprechend oft Projektleiterrollen inne. Zu mir selbst ein bisschen auch, ich bin eigentlich wirklich auch aus dem HR-Bereich von meiner Ausbildung her gekommen, bin seit insgesamt ungefähr fünf Jahren mittlerweile im Bereich HR-Consulting tätig und davon seit ca. 2 ½ Jahren bei Projekt0708. Kannst du es glauben, Michael, schon 2 ½ Jahre ist es wieder her, dass ich gekommen bin.
Michael Scheffler:
Das ging schnell, Wahnsinn.
Ludwig Wartlsteiner:
Aber hallo. Insofern freue ich mich auch heute auf die Inhalte, denn genau zu dem Thema Projektmanagement bzw. Projektleitung haben wir ein bisschen was auch mitgebracht, ne?
Agil oder waterfall, welche Projektmethodik ist die bessere für SAP-Projekte?
Michael Scheffler:
Genau. Und dann lass uns gleich mal zur Sache kommen. Ludwig, agil oder waterfall, welche Projektmethodik ist die bessere für SAP-Projekte?
Ludwig Wartlsteiner:
Ja Michael, du kommst natürlich gleich zur Sache, stellst schon mal die wichtigste Frage gleich am Anfang. Ich muss dich da aber leider ein bisschen einbremsen. Ich gebe dir an der Stelle die klassische Berater-Antwort. Es kommt darauf an. Ich muss auch echt dazu sagen, da unterscheide ich mich vielleicht auch von vielen anderen, ich bin kein Purist dazu. Ich bin keiner, der pauschal in egal welcher Situation eins von beiden immer bevorzugt. Entweder „wir machen alles agil“ oder „agil ist irgendwie doof, klappt nicht, ist zu anspruchsvoll, wir machen es klassisch“, sondern ich finde wirklich man muss es situations-, kunden- und organisationsabhängig machen.
Michael Scheffler:
Dann lass uns nochmal einen Schritt zurückgehen. Kannst du mir und unseren ZuhörerInnen erläutern was eigentlich ein agiles Projekt ist, eine agile Projektmethodik? Den Begriff hat jedes Projektmitglied, jeder SAP-Experte, jede SAP-Expertin schon Tausend Mal gehört, aber was genau verbirgt sich dahinter? Kannst du uns das bitte definieren?
Ludwig Wartlsteiner:
Sehr gerne. Ich versuche mich mal an einer knackigen Definition. Grundsätzlich ist Agilität für mich persönlich eine gewisse Flexibilität, die man an den Tag legen kann. Sowohl von Organisationen, aber auch von Personen. Sogar nicht mal nur das, sondern auch von Strukturen und Prozessen. Für mich steckt dahinter eigentlich im Kern die Fähigkeit, dass man flexibel auf unvorhergesehene Ereignisse und auch vor allem neue Anforderungen reagieren kann. Beispielsweise ist man in Bezug auf Veränderungen nicht nur reaktiv unterwegs und agiert eigentlich dann, wenn ich vor einer konkreten Herausforderung stehe oder wirklich etwas Unvorhergesehenes passiert, sondern man geht als Haltung grundsätzlich erstmal von einer sich verändernden Umwelt aus und versucht diese auch wirklich proaktiv zu gestalten.
Die größten Unterschiede zwischen agilen Methodiken und dem klassischen Wasserfallmodell
Michael Scheffler:
Okay. Worin liegt deiner Meinung nach der größte Unterschied zwischen agilen Methodiken und dem guten alten, klassischen Wasserfallmodell?
Speaker 2: Finde ich auch echt klasse, dass du diese Frage so nochmal stellst, weil sie ist wirklich auf den ersten Blick nicht so einfach und offensichtlich zu beantworten. Vor allem für viele, die jetzt neu bei dem Thema Agilität sind, da tut man sich oftmals ein bisschen schwer, was Agilität eigentlich konkret heißt und was der Unterschied zum Wasserfallmodell ist. Viele verbinden z. B. mit dem Thema Agilität so etwas wie Schnelligkeit und weniger starre Strukturen, also dass man schneller ein Projekt abschließt und währenddessen sich weniger mit den ganzen „planerischen und konzeptionellen“ Aufgaben aufhält.
Michael Scheffler:
Klingt ja schon mal gut.
Ludwig Wartlsteiner:
An sich ja. Das ist ein bisschen auch Wunschdenken, also schneller und weniger Struktur, aber das ist dann auch oftmals die Erwartungshaltung und das Verständnis von agil und ich sage es mal ein bisschen überspitzt und salopp „ihr seid agil, also quasi ohne Projektplan und ihr legt gleich los im Projekt“. Das ist es aber genau eben nicht bzw. teilweise würde ich sogar sagen, dass das Gegenteil der Fall ist. Meiner Meinung nach kann man den größten Unterschied von agil gegenüber klassisch am besten mit dem Wort dynamisch beschreiben und weniger mit Schnelligkeit.
Michael Scheffler:
Das musst du uns näher erläutern. Was meinst du mit dynamisch?
Ludwig Wartlsteiner:
Wenn ich sage „Schnelligkeit“ dann meine ich oftmals die Implementierungsgeschwindigkeit. Hier muss man aber sagen, dass man mit einer agilen Methodik nicht unbedingt schneller ist als mit einer klassischen, also dass das Projekt dadurch nicht unbedingt schneller fertiggestellt wird. Beispiel, das kommt so ein bisschen auch aus dem Taylorism, je öfter ich natürlich was nach einem Schema A mache, desto schneller werde ich. Das heißt unter Umständen, dass man im klassischen Projektmanagement vielleicht sogar schneller ist, gerade wenn ich dieselben Aktivitäten immer und immer wieder mache oder denselben Typus Projekt. Was ist das Besondere von Agilität stattdessen? Das ist nicht das repetitive Abarbeiten von Projektaufgaben, sondern dass man den ganzen Endkunden, also z. B. als Dienstleister oder als IT-Abteilung gegenüber der HR-Abteilung, dass man da einfach schneller die ersten Ergebnisse zeigen kann. Man kann dynamischer auf das erste Feedback oder die erste veränderte Situation reagieren. Somit reagiert man eigentlich auch ein bisschen flexibler auf Anforderungen, die spontan mal wieder hochkommen können oder die sich auch ändern können.
Gerade auch nochmal zum zweiten Punkt, der Struktur, nicht nur Schnelligkeit, sondern auch Struktur, da lässt sich auch sagen, dass wirklich viele agile Methodiken wie z. B. das allseits bewährte Scrum, das ja viele auch rudimentär zumindest kennen, dass die extrem strukturiert sind. Gerade bei Scrum ist ja wirklich diese zyklische Vorgehensweise sehr stark mit ganz klar definierten Events und Artefakten vorgegeben. Die sollen auch rigoros eingehalten werden. Auch in dem Scrum Guide selber, der ja veröffentlich ist und der eigentlich auch kostenlos von jedem eingesehen werden kann, da ist wirklich nochmal sehr deutlich beschrieben „macht das genau so oder es ist nicht Scrum“ (lacht), also wirklich sehr streng als Projektmanagementmethode. Es sind aber auch nicht nur diese ganzen Events und Artefakte, sondern es sind auch die Rollen, die wirklich stark eingehalten werden sollen. Es braucht wirklich und das erleben wir immer wieder in unseren Projekten, das ganze agile Rollenkonzept mit den verschiedenen Projektrollen mit einem Agil Coach oder einem Scrum-Master, je nachdem für welche agile Methode man sich entscheidet, um sich dann auch mit dieser Agilität professionell zu beschäftigen und das auch umzusetzen, zu leben und zu begleiten.
Eine wichtige Aufgabe ist da auch das gerade hier die weniger erfahrenen Projektmitglieder in der Agilität nochmal ein Stück weit mit gecoacht werden, mitgenommen und unterstützt werden. Das ist auch das, was da auch wichtig ist in Bezug auf diese Struktur und warum es ein bisschen Mythos ist, dass es keine Struktur gibt. Es ist z. B. nicht damit einfach getan, dass man den klassischen Projektleiter nimmt, dem das Label Scrummaster verpasst und jetzt haben wir daily meetings und das war es dann, nehmen nur noch Post-Its her und somit sind wir agil. Damit ist es leider nicht getan.
Was bedeutet Agilität in Digitalisierungsprojekten?
Michael Scheffler:
Das Thema Scrum sollten wir gleich nochmal vertiefen. Wenn wir nochmal eine Flughöhe nach oben steigen und jetzt über agile Projektmethodiken sprechen. Ich in meiner Lebensrealität, in unseren Projekten, bei den Kunden, werde sehr oft auf das Thema „agil“ angesprochen. Es ist fast schon ein bisschen schwammig und ich frage dann immer „was heißt für euch agil?“. Ich erlebe da ganz viele Wahrheiten. Wenn wir mal auf unsere Projekte gucken, kannst du nochmal konkret darauf eingehen, was Agilität für dich in unseren Digitalisierungsprojekten bedeutet und vor allem auch, wann eine agile Vorgehensweise auch Sinn macht. Nicht jedes Projekt ist gleich oder vergleichbar. Was kannst du dazu sagen?
Ludwig Wartlsteiner:
Finde ich nochmal gut, dass du da die Sinnfrage nochmal stellst. Es ist tatsächlich auch immer ein bisschen situationsabhängig, ob man den agilen Weg auch gehen sollte. Meiner Meinung nach entfaltet sich Agilität am besten im Kontext von geringer Planbarkeit. Ich starte ein Projekt und weiß eigentlich noch nicht so ganz genau „was ist das Endergebnis? Wie soll das Endprodukt aussehen?“. Mit Endprodukt meine ich jetzt auch nicht ein konkretes Produkt, sondern es kann auch eine Dienstleistung sein, das kann ein IT-Produkt irgendwo sein, das kann aber auch eine Softwarelösung sein.
Das ist sehr vielfältig, was ich unter Produkt verstehen kann. Jedes Mal, wenn diese Anforderungen im Vorfeld noch nicht zu 100 Prozent festgelegt werden können, sondern während des Projekts sich ein Stück weit ergeben, dann macht es wirklich auch Sinn auf Agilität zu gehen. Gerade in den zyklischen Vorgehensweisen kann ich immer wieder ganz schnell die ersten Ergebnisse schon mal generieren, kann die zeigen, bspw. in Form von einem MVP und kann dann eigentlich die Endkunden fragen „geht das in die richtige Richtung? Wollen wir so weitermachen? Sind wir vielleicht an der ein oder anderen Stelle auch mal falsch abgebogen?“. Das ist auch insofern wichtig, dass man das in petto hat, weil viele Kunden oder Abteilungen möchten heutzutage viel früher die ersten Ergebnisse sehen.
Ich glaube das ist gerade das, was wir Michael, immer wieder in unseren Projekten erleben, dass da die Geduld teilweise zurecht nicht mehr da ist, ein halbes Jahr zu warten, bis man die ersten Sachen im System sehen kann. Das macht auch wirtschaftlich sehr viel Sinn. Gerade nach dem Motto „fail early, fail cheap“, kann man früher nochmal intervenieren mit einer zyklischen Herangehensweise, kann früher nochmal gegensteuern und sieht eigentlich gleich „sind wir mit den Ergebnissen on track oder müssen wir noch ein bisschen daran schrauben?“. Man nennt das Ganze auch ein Stück weit „time to market“, das ist wie eine Art agile Kennzahl, an der man ablesen kann, wie schnell man bspw. die ersten Ergebnisse da bereitstellen kann, an den Markt bringen kann quasi. Markt im Sinne von, das kann auch eine interne HR-Abteilung sein.
Du hast schon ein Stück weit die Sinnfrage gestellt „wann macht Agilität Sinn?“ und ich glaube das genau in diesem Kontext Agilität das beste an der Stelle entfaltet. Einfach in der schnelllebigen Vuka-Welt, wo wirklich die Anforderungen sich ggfls. bei manchen Themen schnell ändern oder neue hinzukommen, dass man da schnell und dynamisch und flexibel drauf reagieren kann und diese Unplanbarkeit mit reinnimmt in die Projektmanagementmethodik.
Michael Scheffler:
Das bedeutet, wenn ich dich richtig verstehe, die gute alte Wasserfallmethodik ist ein Auslaufmodell?
Ludwig Wartlsteiner:
So habe ich das nicht gesagt (lacht). Klar, Agilität hat ganz klare Vorteile in den Bereichen, die ich vorher genannt habe, aber ich muss ganz klar dazu sagen, aber...das Berater-Aber. Ich finde auf gar keinen Fall, dass das Wasserfallmodell ein Auslaufmodell ist, weil es eignet sich immer noch in bestimmten Situationen hervorragend als Projektmanagementmethodik. Die Anforderungen sind relativ stabil, können auch am Anfang von dem Projekt relativ sauber und auch klar definiert werden. Man kann mit einem Fachkonzept das Ganze ganz gut beschreiben. Das ist dann auch erstmal abgenommen von allen und vielleicht hat das Projekt auch einen kleineren Zeithorizont, wo sich die Anforderungen gar nicht so stark und schnell ändern werden.
Wenn man z. B. von ein paar Monaten Realisierungszeit ausgeht oder vielleicht nur ein paar Wochen, dann könnte es auf jeden Fall Sinn machen, lieber auf die klassische Projektmanagementmethode zu setzen. Wenn man ein konkretes Beispiel mal nimmt, ich habe bspw. eine SAP-Fiori-App, die ich irgendwie als Eigenentwicklung im Bereich Self Services entwickeln möchte mit meinem Team und ich weiß genau, was die tun soll, ich weiß genau, was das Ziel ist. Ich weiß genau, was für Bedürfnisse sie erfüllen soll und gerade hier bietet sich das sogar tatsächlich eventuell mehr an die klassische Vorgehensweise zu präferieren. Also wirklich erst ein kompaktes Fachkonzept zu erstellen, dann in die Realisierung zu gehen, anschließend ins Testing usw. usf. So wie wir es kennen, das klassische Projektmanagement a la Carte.
Um es nochmal zusammenzufassen: Wenn die Anforderungen klar und stabil sind, in vielleicht sogar einem kurzen Projekt, dann macht die klassische Vorgehensweise auf jeden Fall mehr Sinn, weil – ich sage es mal so von der anderen Seite her – Der Kern von Agilität ist ja dieses schnelle Reagieren auf neue Anforderungen. Wenn das nicht gegeben ist, dann entfaltet sich ja das ganze agile Konzept an der Stelle gar nicht. Das, womit Agilität am meisten glänzt, fällt dann ggfls. ein Stück weit weg. Man muss aber auch dazu sagen, so schwarz-weiß, wie wir es gerade gemalt haben, ist es natürlich nie. Darüber hinaus gibt es noch Graustufen oder Stufen dazwischen. Man kann auch eine Art hybride Vorgehensweise wählen, auch da gibt es ganz klasse Konzepte, die man wirklich gut hernehmen kann. Man kann bspw. die Konzeptionsphase oder die Scoping-Phase im klassischen Sinne abarbeiten, kann dann aber auch während der Realisierungsphase eher in Iterationen denken, dass man bspw. in zwei, drei Iterationen die Realisierung vornimmt und kann dann für Sachen wie Testing, Go-Live, Hyper Care Support dann auch wieder ins klassische switchen. Da gibt es ganz gute Modelle, wo man gerade auch diesen Mittelteil von so einem Projektlebenszyklus auch wirklich agil oder zumindest in Iterationen gestalten kann.
Save the date: Let’s transform retail. Das Retail-Community-Event am 08. September in München. Unter dem Motto „Handel im Wandel – die Weichen im HR richtig stellen“ und „keine Digitalisierung ohne Technik“ fokussiert Projekt 0708 gemeinsam mit Branchenexperten und Spezialisten die Digitalisierung und Transformation im Groß- und Einzelhandel. Keynotes, Impulsvorträge und Podiumsdiskussionen von renommierten Speakern gehen der Frage nach, wie sich das Personalwesen entwickeln muss, um die Herausforderungen der Gegenwart und Zukunft zu meistern. Erhalten Sie exklusive Einblicke in ausgewählte Use Cases im Bereich Retail und Consumer Products und kommen Sie endlich mal wieder mit gleichgesinnten der Branche ins Gespräch. Jetzt alle weiteren Infos erhalten und zum Event anmelden unter www.projekt0708.com. Auf einen kreativen und tollen Austausch mit Ihnen freuen sich die KollegInnen von Projekt0708, SAP, EHI und viele mehr.
Michael Scheffler:
Mir fällt noch ein sehr gutes Argument für die Old-School-Variante, die Wasserfallmethodik ein.
Ludwig Wartlsteiner:
Lass hören.
Michael Scheffler:
Und zwar in vielen Organisationen und bei unseren Kunden wird sehr stark im Budget und in Timelines gedacht, d. h. im Vorfeld eines Projektes muss zuvor der Projektsponsor grünes Licht geben und erwartet zurecht natürlich Details, was das Vorhaben kosten wird. Das kollidiert ja ein wenig mit der agilen Vorgehensweise oder wie schätzt du das ein?
Ludwig Wartlsteiner:
Absolut richtig. Da muss man auch wirklich ehrlich sein, das ist eine Herausforderung, die viele Organisationen und viele Abteilungen auch wirklich haben. Eigentlich, streng genommen, hast du absolut Recht, sobald man eine Timeline und ein fixes Budget im Vorfeld hat, ist man eigentlich schon nicht mehr agil. Es ist ein interessanter Zwiespalt, der spiegelt sich ein bisschen auch in den wissenschaftlichen Studien wider, was da draußen an Agilität und agilen Konzepten bereits bei den Unternehmen kursiert. Ich möchte an der Stelle mal zwei zitieren, die du bestimmt auch noch im Nachgang bereitstellen kannst.
Einerseits gab es 2020 während der Coronakrise eine umfangreiche Studie, die aufzeigte, dass mittlerweile ungefähr zwei Drittel, also 62 Prozent der Unternehmen in den letzten paar Jahren agile Methoden in irgendeiner Form schon eingeführt haben. Die haben quasi in einer Art Projekt oder Pilot oder vielleicht für ganze Abteilungen oder vielleicht was Größeres schon mal agile Konzepte und Arbeitsweisen mit eingeführt. Im selben Jahr gab es noch eine andere Studie von Kienbaum und Stepstone, die besagt hatte, dass weniger als 10 Prozent der Firmen in Deutschland auch quasi als gesamte Organisationen wirklich komplett agil vom Setup her arbeiten, d. h. natürlich es ist eine extreme Herausforderung, diese klassischen und agilen Arbeitsweisen, Methodiken, Aufbauhierarchien etc. so zu verheiraten, dass es auch klappt. Insofern, das merken wir immer wieder ganz oft bei Kunden, ist das Thema Agilität oft noch so eine, ich nenne es mal „graue Materie“, die ab und an ein bisschen in den Organisationen rumwabert und manchmal sich vielleicht wie ein Fremdkörper anfühlt in einer sonst sehr stark klassisch ausgerichteten Organisation. Man sieht schon, das Ganze ist nicht so einfach an der Stelle, genau wie du es auch dargestellt hast.
Einführung von Agilität in kleinen Schritten
Michael Scheffler:
Aber wie kann man denn jetzt als Projektteam oder als agiles Projektteam damit umgehen? Das sind schon große Herausforderungen.
Ludwig Wartlsteiner:
Du meinst quasi mit diesem Zwiespalt?
Michael Scheffler:
Ja ganz genau.
Ludwig Wartlsteiner:
Ich würde mal behaupten, letzten Endes ist es ja wirklich wie bei jedem Wandel. Es fordert auch einen gewissen kulturellen Wandel. Ich glaube wir müssen uns da ein Stück weit von dieser vorwiegend von der Industrialisierung geprägten Welt und Mindset auch ein Stück weit verabschieden, zumindest in manchen Bereichen. Dazu gehört wahrscheinlich auch, dass man immer im Vorfeld von Projekten fast schon wie mit so einem Endprodukt sagen kann „Produkt A braucht so und so lange, kostet so und so viel, Punkt.“. So einfach geht es einfach nicht mehr, wie es vielleicht früher irgendwo mal der Fall war. Dieser ganze organisatorische Wandel kommt natürlich auch nicht über Nacht. So ehrlich muss man sein.
Meine persönliche Empfehlung ist schon mal an der Stelle, das Thema Agilität in kleinen Schritten bei sich schon mal einzuführen, vielleicht auch in kleineren Projekten, die ein bisschen überschaubarer sind, die auch managbar sind, das schon mal agil zu machen, dabei zu lernen, Lerneffekte zu generieren und aber auch gleichzeitig, das ist auch ganz wichtig, das Erwartungsmanagement wirklich proaktiv an den Rest der Organisation zu betreiben. Wirklich auch aufklären.
Was genau bedeutet das jetzt, wenn wir teilweise sogar wirklich als agile Insel hier unterwegs sind. Was heißt das in Bezug auf Timeline und Budget? Transparent machen, dass es im Vorfeld eine Veranschlagung gibt, aber dass die irgendwo ein moving target sein muss und man im Vorfeld nicht alles schon transparent machen kann und nicht im Vorfeld alles definitiv centgenau festlegen kann. Dass man da auch das Bewusstsein schärft, dass sich die Rahmenbedingungen einfach immer schnell ändern können und schnell ändern werden und letzten Endes das Ganze eh nur initiale Werte sein können. Vielleicht ist es auch wirklich besser mehr in Kontingenten und Ausbaustufen grundsätzlich in Projekten zu denken als dieses klassische Projektmanagement, wo man im Vorfeld erstmal alles aufwändig scoped und alles versucht zu beziffern.
Scrum - eine konkrete, agile Projektmethodik
Michael Scheffler:
Gut, habe ich soweit verstanden. Dann würde ich gerne mal ein bisschen eine Etage tiefer gehen, d. h. wir haben bisher sehr allgemein über Agilität gesprochen, jetzt hast du vorhin schon einen Begriff fallen lassen, nämlich das Thema Scrum, was ja eine konkrete, agile Projektmethodik darstellt. Auch diesen Begriff hat sicherlich jeder der ZuhörerInnen schon einmal gehört, nicht nur im SAP-Umfeld ist das ein sehr bekannter und beliebter Ansatz. Wie grenzt sich denn Scrum von anderen agilen Projektvorgehensweisen ab und wie darf man sich das ganz praktisch vorstellen? Du bist ja auch Scrum-Master, soweit ich weiß, d. h. du bist da ja tief im Saft. Was bedeutet das?
Ludwig Wartlsteiner:
Finde ich zunächst mal klasse, dass du nochmal hervorhebst, dass agil nicht immer automatisch Scrum heißen muss. Es gibt nämlich ähnlich wie im klassischen Projektmanagement auch ganz viele verschiedene Methodiken da an der Stelle. Scrum kann man sich grundsätzlich erstmal als ein Framework vorstellen, das wirklich eine sehr starke, aber muss ich persönlich auch sagen, sehr gute Struktur erstmal vorgibt. Bspw. geht man in den zwei- bis vierwöchigen Sprints vor, man hat bestimmte Events, wie z. B. ein Meeting zur Planung des anstehenden Sprints oder eine Sprint-Review, sprich dass man die Ergebnisse des Sprints gemeinsam inspiziert usw. Da gibt es sehr gute und sehr viele Events, die da stattfinden. Was Scrum meines Erachtens nochmal differenziert zu vielen anderen agilen Projektmanagementmethoden ist, dass es ein gutes und klar definiertes Rollenkonzept eigentlich mitbringt. Es sagt ganz klar, welche Rollen im Projekt repräsentiert sein müssen und welche Verantwortung die haben und was die jeweiligen Rollen liefern müssen.
Insofern wird einem bei Scrum schon wirklich ein sehr umfangreicher Methodenkoffer mit an die Hand gegeben. Davon kann man vieles direkt auch umsetzen. Um es vielleicht auch da konkreter zu machen, Scrum eignet sich immer ganz gut für größere und für längere Projekte, weil es auch wirklich sehr gut skaliert. Ich kann mir mein Projektteam relativ flexibel „zusammenstecken“ mit den verschiedenen Rollen, habe auch bis zu zehn Entwickler immer mit dabei und selbst dann muss es gar nicht das Limit sein. Wenn es mehr Entwickler und mehr Rollen werden bzw. wenn man hier von ganzen Abteilungen mit 40, 50 Leuten spricht, die alle auf Scrum gehen sollen, dann skaliert das sogar insofern ganz gut, weil es gibt auch dann wieder Methodiken, um verschiedene Scrum-Teams aufzuziehen und wie die dann auch wieder miteinander interagieren können etc. Es ist extrem skalierbar. Es gibt aber eben nicht nur Scrum, wie du gesagt hast, sondern es gibt auch weitere, was ich noch gerne immer nenne, ist Kanban. Das verbinden viele auch vom Namen her mit dem Kanban-Board. Das kennen wir alle.
Michael Scheffler:
Schon mal gehört.
Ludwig Wartlsteiner:
Das ist dieses klassische „ich nehme meine Post-Its und verschiebe es eigentlich zwischen den drei Hauptsäulen“, sprich „To-Do“, „in progess“ und „done“, oftmals auch auf einer Meta-Planwand oder auf so einer Pinnwand und manage eigentlich so meine To-Dos oder meine Anforderungen oder die Sachen, die ich auch irgendwie zu tun habe.
Michael Scheffler:
Also kennt man, setzen wir auch bei Projekt0708 intern sehr gerne und sehr häufig ein. Auch gerne software-unterstützt. Ist auf den ersten Blick recht simpel, wobei es meiner Erfahrung nach sehr viel mehr braucht, um Projekte erfolgreich durchzuführen.
Ludwig Wartlsteiner:
Stimme ich dir vollkommen zu. Bin ich vollkommen bei dir. Es wird ganz gerne als leichter, agiler Einstieg verkauft, stimmt aber auch nur so bedingt. Wenn man es so nutzt, wie du gerade angesprochen hast, dass man intern so ein Stück weit seine To-Dos managed, so ein bisschen Tracking von verschiedenen Punkten macht, dann passt das auch ganz gut, aber ich sage mal so ganze komplexe Projekte nur mit Kanban zu managen, das geht, da gibt es ja auch wirklich ganz gute Konzepte dazu, aber das ist schon sehr anspruchsvoll, weil es wirklich extremst auf die Eigenständigkeit der jeweiligen Akteure setzt und beispielsweise auch vom Rollenkonzept her gar nicht besonders viel vorgibt, anders als Scrum. Da muss man es fast schon selber in irgendeiner Form nachliefern oder sich selber überlegen, wie man da kollaborieren möchte. Es gibt aber auch sogar eine hybride Vorgehensweise zwischen den beiden, also Scrum und Kanban wird dann zu Scrumban.
Michael Scheffler:
Das habe ich jetzt noch nicht gehört.
Ludwig Wartlsteiner:
Ist auch nochmal ein schönes Modell, dass man quasi diese Struktur, die Rollen, die Events, die Artefakte von Scrum nimmt und quasi mit dem Kanban-Board verbindet. Das ist eine interessante Geschichte, kann man sich auf jeden Fall nochmal angucken und das verbindet auch ein Stück weit das Beste von zwei Welten. Aber Kanban alleine bei größeren Projekten als Anfänger für agile Projekte, da würde ich eher von abraten. Das ist einfach ein Stück weit zu anspruchsvoll.
Zu guter Letzt würde ich auf das Thema Design Thinking eingehen, weil ich persönlich bin extrem angetan von diesem agilen Konzept. Ich bin ganz, ganz großer Design Thinking Fan und ich versuche es kurz zusammenzufassen. Bei Design Thinking steht eigentlich allgemein gesagt dieser Kreativprozess im Vordergrund. Also dass man wirklich mal komplett auf der grünen Wiese ein Produkt oder eine Dienstleistung entwirft oder auch bestimmte identifizierte Probleme mit neuen und frischen Konzepten lösen möchte oder vielleicht auch erstmal die Pain Points grundsätzlich sammelt. Das ist wirklich nochmal ein richtig, richtig tolles Konzept, um grundsätzlich auf der grünen Wiese nochmal zu denken und das auch nochmal anders aufzugestalten. Man schaut da auch ganz besonders auf den Endanwendernutzen. Der steht auch bei Design Thinking sehr stark im Fokus und versucht quasi sich daran vor allem zu orientieren. Da kommen auch ganz viele bekannte Methoden, die man vielleicht aus anderen Bereichen kennt, immer wieder zum Einsatz.
Beispiel im Marketing: Das Thema Personas und Customer Journeys und Storytelling, das ist ja jetzt omnipräsent, gerade das Thema Storytelling ist ja sehr präsent heutzutage im Marketingbereich. Das sind Sachen, die kommen ursprünglich teilweise aus dem Design Thinking. Deswegen bin ich auch ein ganz großer Fan davon.
SAP Activate - ein agiler Ansatz
Michael Scheffler:
Sehr interessant, Ludwig. Das waren jetzt auch die gängigsten agilen Methoden, die ich selbst kenne, bis auf Scrumban, das war mir jetzt neu in der Tat. Ich persönlich mache ich ja inzwischen schon sehr lange SAP-Projekte ganz unterschiedlicher Komplexitätsgrade. Von mehrjährigen weltweiten SAP-Einführungsprogrammen bis hin zu kleineren Implementierungsprojekten oder Softwareentwicklungen. Früher war ja da im SAP-Umfeld die ASAP-Methode (acellerate SAP) das Maß aller Dinge. Ein klassisches Wasserfallmodell, was so in diese verschiedenen Projektphasen unterteilt wurde, von Project Preperation, Business Blueprint, Realisation, Final Preperation bis hin zu Go-Live und Support, das ist jetzt heutzutage nicht mehr ganz so State-of-the-Art und was wir zunehmend bei unseren Kunden vorfinden und was auch die SAP selbst inzwischen propagiert, ist ja SAP Activate. Das wiederum ist jetzt ein agiler Ansatz. Kannst du unseren ZuhörerInnen dieses Modell im Detail erläutern? Was steckt dahinter?
Ludwig Wartlsteiner:
Sehr, sehr gerne. Ich muss auch gestehen, ich war sehr überrascht, als ich mir vor ein paar Jahren SAP Activate dann auch angeschaut habe, wie viel da auch wirklich bereitgestellt wird, das ist echt toll, was die SAP da geleistet hat.
Michael Scheffler:
Ein riesiger Fundus.
Ludwig Wartlsteiner:
Absolut, stimme ich dir zu. Grundsätzlich ist es so, dass SAP Activate ein von der SAP bereitgestelltes Projektmanagement, also eine Methodologie eigentlich fast schon ist. Die ist inhaltlich schon extrem an Softwarelösungen von der SAP interessiert. Die ganzen Projektphasen etc., da findet man sich teilweise sehr inhaltlich stark wieder in den verschiedenen Softwarelösungen. Ganz konkret, es gibt z. B. auch ein SAP Activate für SuccessFactors-Module etc., wo die wirklich nochmal drauf gemünzt sind. Und, jetzt wird es ganz spannend, das Besondere ist, dass es diese SAP Activate Methodologien auch in verschiedenen Ausprägungen gibt. Es gibt sie z. B. theoretisch auch für das klassische Projektmanagement, es gibt es aber auch für das agile Projektmanagement. Bei dem Modell, was du gerade genannt hast, bei dem agilen SAP Activate ist es so, dass man inhaltlich das Ganze nochmal sehr stark an den jeweiligen Lösungen ausgelegt hat und gleichzeitig aber auch agile Projektmanagementmethoden mit reingenommen hat.
Man kann sich das so vorstellen. Es ist das Projekt in so einer ganz rudimentären Art und Weise, eigentlich schon fast ein bisschen vorgeplant, die Projektphasen sind schon vorgeplant, die Elemente, die dann agil sind, sind auch gekennzeichnet. Insgesamt ist es ein Stück weit ein hybrides Modell, d. h. ich habe ein Stück weit auch das Beste aus zwei Welten in Form von gewissen klassischen Projektmanagementphasen und auch eher dann agilen Elementen und kann so eigentlich schon ziemlich startklar mein Projekt dann eigentlich beginnen mit dieser Projektmanagementmethode. Das ist wirklich eine gute Geschichte.
Ich kann es auch gerne nochmal an einem anderen Beispiel ein bisschen konkreter machen. Es gibt die Möglichkeit dann wirklich ein SuccessFactors Employee Central Projekt mit SAP Activate vorzuplanen. Das sähe dann so aus, dass man die ersten Phasen, die Scoping-Phasen und die Konzeptionsphasen eher so im klassischen Milieu ansiedeln würde, sprich das sind eher die klassischen Projektmanagementmethoden und in der Realisierungsphase wäre man dann in drei Iterationen, ähnlich wie Sprints unterwegs und würde das in drei Iterationen implementieren. So kann man ein Stück weit die Anforderung bedienen, dass viele Kunden früh die ersten Ergebnisse sehen wollen und dass man in einer ersten Iteration z. B. schon mal wirklich den Endanwendern da die ersten Entwicklungen bereitstellen kann. Man muss aber auch und das ist das Schöne, nicht gleich irgendwie 100 Prozent seines Teams auf Scrum z. B. umstellen oder umpolen. Das ist insofern nochmal eine gute Methode, um gerade Organisationen, die die ersten Male vielleicht agil arbeiten, so ein Stück weit ein ganz gut managbares und ganz gut verdaubares Projektmanagementset an die Hand zu geben mit agilen Elementen ohne dass es gleich der ganz große agile Wurf sein muss.
Michael Scheffler:
Spannend finde ich auch, dass die SAP sogar eine ganze Reihe von Zertifizierungen im Bereich SAP Activate anbietet. Das ist wirklich ein riesiger Kosmos. Bspw. können sich Interessierte zum SAP Certified Associate SAP Activate Project Manager weiterbilden und in diesem Zusammenhang die ganze Methodik aneignen. Jeder, der sich dafür interessiert, dem verlinke ich auch einen weiterführenden Blog zu dem Thema in den Shownotes. Gucken Sie gerne mal darein.
Hat Ihnen dieser Podcast gefallen? Dann freuen wir uns sehr über fünf Sterne bei iTunes. Feedback zu dieser Folge oder Themenvorschläge für künftige Episoden gerne per Mail an podcast@projekt0708.com.
