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:
Herzlich willkommen zu einer neuen Folge von HR IT-Talk, mein Name ist Michael Scheffler. Lass uns mal weitermachen im Text. Ich habe verstanden „es gibt nicht das Non plus Ultra zwischen den verschiedenen PEM-Ansätzen“, um jetzt mal Tacheles zu reden, wie kann man denn identifizieren, welche Projektvorgehensweise wirklich die beste ist für mich ganz spezifisches Projekt?
Ludwig Wartlsteiner:
Also im ersten Schritt würde ich sagen, muss man sich natürlich erstmal anschauen, vielleicht gibt es sogar organisatorische Vorgaben diesbezüglich. Wenn es wirklich um die Frage geht „was passt zu mir besser?“. Manche Unternehmen z. B. besitzen schon eine eigene Projektmanagementmethodik, bei Großkonzernen ist das z. B. öfters der Fall.
Michael Scheffler:
Vor allem im Automotive-Umfeld findet man die öfters mal vor.
Ludwig Wartlsteiner:
Absolut. Es gibt teilweise auch schon die Vorgaben, dass in Scrum-Teams gearbeitet werden soll. Ich kenne da ähnlich wie du einen Autobauer aus München, der bspw. die Vorgabe gemacht hat „wir müssen hier in Scrum-Teams arbeiten“. Das ist natürlich erstmal die erste Frage. Gibt es da irgendwas, was mir vorgegeben wird? Im zweiten Schritt würde ich mir ansehen, welche Art von Projekt eigentlich vorliegt. Bei einer kleinen Standard-Cloudlösung, die ich einführen würde, würde ich vielleicht wirklich anders vorgehen als bei einer großen Kaste Individualentwicklung, wo ich wirklich eine Softwarelösung auf der grünen Wiese selber erstmal entwerfe. Vielleicht grundsätzlich gesagt: Bei fest definierten Rollouts, bei glasklar definierten Anforderungen, bei Lösungen, die wirklich sehr gut gescoped werden können, würde ich eher die klassische Projektmanagementvorgehensweise präferieren, weil sie wirklich ein Stück weit mehr Sinn macht.
Wenn die Anforderungen hingegen im Vorfeld nicht so ganz definiert werden können, wenn ich vielleicht auch mit viel Volatilität rechnen muss, wenn ich vielleicht schon weiß „wir müssen das Projekt starten, aber manche Anforderungen kommen erst im Laufe des Projekts klar definiert rüber“, dann würde ich wirklich die agile oder zumindest die hybride Methode vorziehen. Dann wiederum, innerhalb der Agilität, wenn es größere und längere Projekte werden, würde ich wirklich Scrum oder eben auch SAP Activate Agile nehmen, um das dann eben irgendwie abzufedern.
Das ist so der zweite Schritt oder die zweite Frage, die ich mir stellen würde und dann im dritten Schritt, das ist ehrlich gesagt sehr, sehr wichtig und das wird oftmals ein bisschen ignoriert, ich würde mir auch ansehen, ob die Organisation oder das potentielle Projektteam das auch wirklich leisten kann. Einfach mal ohne oder mit unterschiedlich repräsentierten agilen Reifegraden und Skills und ohne weitere Erklärungen agil drauf los arbeiten, ich glaube das wird nicht gut gehen. Das wird nicht funktionieren. Gerade wenn es vielleicht ein großes Projekt ist, das gleich mal mit einer Truppe anzugehen im komplett agilen Scrum-Setup ohne große Vorerfahrung, ohne dass die Skills da sind, sondern dass man es mal ausprobiert, das glaube ich ist nochmal ein Happen, der ein bisschen zu groß ist.
Michael Scheffler:
Oder man holt sich professionelle Unterstützung wie jetzt durch deine Person z. B.
Ludwig Wartlsteiner:
Absolut. Wir selber sind ja auch ganz oft als Projektleiter in Projekten tätig, auch Stand alone, gar nicht mal unbedingt wenn wir die Implementierungsprojekte machen und ich selber, aber auch viele meiner Kolleginnen und Kollegen, sind ja auch oftmals in der Projektleiterrolle oder auch der Scrum Master Rolle.
Agiles SuccessFactors-Projekt bei ProSiebenSat.1: Kundennähe und schneller Fortschritt mit Scrum
Michael Scheffler:
Kannst du uns vielleicht nochmal ein idealtypisches Projekt nennen oder von einem idealtypischen Projekt berichten, in welchem wir als Projekt0708 agil vorgegangen sind? Warum hatte sich der Kunde für die Projektmethodik entschieden und was war die Motivation dahinter? Das ist sicherlich spannend.
Ludwig Wartlsteiner:
Sehr gerne Michael. Ein richtig schönes Beispiel, wo wir wirklich auch sehr agil vorgegangen sind, ist der das SuccessFactors-Projekt bei ProSiebenSat.1. Da waren wir vor allem in den letzten ein, zwei Jahren wirklich sehr aktiv unterwegs gemeinsam mit dem Kunden. Dort ging es u. a. um die Erweiterung oder auch um die Individualisierung des Standards der Cloudlösung von SAP SuccessFactors. Das Besondere ist, der Kunde selbst war hier eigentlich schon sehr, sehr agil unterwegs und arbeitet grundsätzlich auch schon sehr agil. Demnach war auch die Wahl schnell getroffen, nämlich dass wir mit Scrum letzten Endes gemeinsam im Projekt arbeiten werden. So waren wir auch ebenfalls in einer sehr agilen Arbeitsweise dort eigentlich unterwegs.
Das Ganze ist dann so auch abgelaufen, dass wir als Projekt0708 gemeinsam mit dem Kunden auch komplett in zweiwöchigen Sprints immer gearbeitet haben, wirklich nach der Scrum-Framework-Lehre eigentlich, wirklich nach der reinen Lehre und die Motivation dahinter war eigentlich auch, dass man den Endanwendern eigentlich dann möglichst früh im Projekt schon eine Partizipation ermöglicht, dass man sie möglichst früh nochmal einbindet und auch das Feedback der Organisation eigentlich möglichst zeitnah einholt und dann umsetzt. Natürlich ist es auch immer wichtig in solchen Projekten auch ein gewisses Momentum dadurch zu erzeugen. Das haben wir uns dann auch zunutze gemacht mit Hilfe des Scrum-Frameworks, dass wir einfach versucht haben möglichst schnell auch die ganze Organisation zu begeistern, mitzunehmen, auch für das Projekt mit aufzugleisen und dann einfach gemeinsam zügig voranzuschreiten.
Erfolgsfaktoren im agilen SuccessFactors-Projekt bei ProSiebenSat.1
Michael Scheffler:
Jetzt muss man wissen, ProSiebenSat.1 ist ja ein Referenzkunde von uns. Das Projekt, das du gerade angesprochen hast, findet sich auch z. B. auch auf unserer Homepage. Ich selbst war jetzt nicht so involviert, aber ich habe da auch tolle Insights bekommen. Was waren denn deiner Meinung nach letztlich die Erfolgsfaktoren des Vorhabens?
Ludwig Wartlsteiner:
Wenn ich mal das so zusammenfasse, was vor allem insgesamt von unserem Team reflektiert wurde, was wirklich auch gut bei diesem Projekt gelaufen ist, da kann man wirklich sagen, dass einer der großen Erfolgsfaktoren einfach war, dass die vielzitierten agilen Rollen eigentlich auch wirklich gut besetzt waren. Wir hatten sowohl in der Personalie des Product Owners als auch des Scrum Masters wirklich zwei tolle Leute bei ProSiebenSat.1 mit dabei, die das auch sehr forciert haben, die ihre Rolle extrem gut abgedeckt haben und die auch wirklich gut erfüllt haben. Ich glaube auch eine der wesentlichen Punkte dahinter war, dass sie sich die jeweiligen Kapazitäten auch sehr stark eingeplant haben.
Da hat man einfach schön gesehen, so ein Scrum Master oder auch ein Product Owner, das ist nichts, was mal nebenbei mit so ein, zwei, drei Stunden die Woche nebenher läuft, sondern das ist auch wirklich Arbeit, vor allem, wenn man es richtig gut machen will, aber es zahlt sich dann auch dementsprechend natürlich auch aus. Das war einer der wesentlichsten Erfolgsfaktoren. Der zweite wesentlichste Erfolgsfaktor war dann auch die, ich nenne es einfach mal, Entscheidungsfreudigkeit, die in dem Projekt wirklich vorhanden war. Das war wirklich auch schön mit anzusehen, dass da auch schnelle und auch sehr gute Entscheidungen getroffen worden sind.
Das ist auch wichtig, weil man muss sich mal vorstellen, wenn wir wirklich alle zwei Wochen Sprints haben und Sprint Review Sessions haben, in denen dann auch Ergebnisse vorgestellt werden, indem man sich das gemeinsam anschaut „was ist umgesetzt worden? Was ist der Mehrwert von diesem Sprint?“, dann kommen da ja auch gewisse Ergebnisse raus, mit denen man da umgehen muss. Beispielsweise diese Optimierungswünsche, die vielleicht seitens der Stakeholder da rauspurzeln. Wie gehen wir damit um? Tun wir die wirklich nochmal ins Backlog? Definieren wir die jetzt schon aus? Welche Prio haben die nochmals? Welche Sachen muss man erstmal weg argumentieren und möchte man jetzt gar nicht so sehr mit reinnehmen ins Backlog. Zusätzlich natürlich dann auch „welche Dinge muss man vielleicht erstmal intern klären, bevor man sie wirklich ins Backlog mit reinnehmen kann?“.
Gerade diese Sachen, da hat insgesamt das Projektteam wirklich geglänzt mit schnellen Entscheidungen, mit wirklich tollen Entscheidungen und insofern würde ich sagen, das war wirklich der zweite, ganz, ganz große Erfolgsfaktor.
"Bewusste Lücken" im Scrum-Framework: Herausforderungen und Ergänzungsbedarf
Michael Scheffler:
Wir haben jetzt sehr viel über Scrum gesprochen als Projektmethodik im Speziellen und über Stärken und Voraussetzungen. Mich würde mal interessieren, siehst du auch Schwächen oder Lücken in dem Framework? Du sagst ja selber „Scrum ist ein Framework“, was siehst du da? Wo sind die Schwächen des Systems?
Ludwig Wartlsteiner:
Ich glaube Schwächen würde ich es vielleicht gar nicht mal unbedingt nennen, aber ich würde vielleicht den Begriff „bewusste Lücken“ vorbringen. Scrum liefert ja wirklich ein grandioses Framework, mit einer Anleitung, wie ich selbst als Projektteam mich zu organisieren habe und wie ich vorangehen kann im Projekt und definiert auch das allgemeine Vorgehen. Aber was Scrum und eigentlich die anderen agilen Methodologien natürlich nicht wirklich liefern, sind auch so die „softeren“ Themen dahinter. Bspw. Führungsthemen oder auch Themen rund ums Konfliktmanagement. Die sind extrem wichtig diese Punkte, aber da liefert jetzt Scrum erstmal out of the box nicht wirklich eine ganz, ganz konkrete Antwort an der Stelle.
In der Theorie arbeiten ja alle Projektmitglieder extrem konstruktiv und self enabled an ihren Themen, aber was passiert eigentlich, wenn das mal nicht so funktioniert? Wie geht man z. B. damit um, wenn Ergebnisse vielleicht mal nicht stimmen oder kontinuierlich nicht ganz stimmen? Wie geht man mit dem Thema Wissenstransfer innerhalb von einem Team z. B. um? Dass die juniorigeren Kolleginnen und Kollegen auch immer mit aufgegleist und ausgebildet werden quasi. Da kommt es auch wirklich darauf an, dass z. B. auch der Scrum Master wirklich gute Moderations- und Interventionstechniken beherrscht, um auch gemeinsam mit dem Team gegensteuern zu können, wenn mal etwas aus dem Ruder läuft oder wenn vielleicht mal etwas nicht funktioniert.
Das macht man natürlich vor allem in den Retro-Sessions, aber es kommt eben auch drauf an, dass man mit einem gewissen Toolset auch an solchen Themen arbeiten kann. Weil du gesagt hast „Lücken an der Stelle“, eine weitere Lücke ist natürlich auch das nirgends im Scrum Guide, nicht nur Scrum, sondern auch sogar in den anderen agilen Methoden, wird eigentlich genauer beschrieben wie diese „Erhebung“ der ganzen Requirements oder auch das Backlog-Management genau ablaufen soll. Wie beschreibe ich z. B. als Kunde oder als PO meine Anforderungen effizient und wie kommuniziere ich diese auch effizient? Das sind so Sachen, wo Scrum erstmal nicht alles out of the box mitliefert.
Agile Unterstützung: Gemeinschaft und Ressourcen für Projektleiter
Michael Scheffler:
Das sind ja doch einige Herausforderungen, die du jetzt hier geschildert hast. Wie sieht es damit aus, wie kann ich darauf reagieren oder ich als Projektleiter, werde ich da alleine gelassen oder kann ich mich da irgendwie mit einer Community austauschen?
Ludwig Wartlsteiner:
Also keine Angst, du wirst da nicht komplett alleine gelassen, weil du hast das Stichwort auch gerade genannt, nämlich Community. Man muss dazu sagen, Scrum hat als konkretes Beispiel an der Stelle genannt, nicht vergessen da etwas mit reinzunehmen, das möchte ich nochmal dazu sagen. Es ist nicht so, dass Scrum eine Flanke offengelassen hat und gesagt hat „hier müssen wir was nacharbeiten“, sondern das Scrum-Framework hat bewusst auch solche Themen offengelassen. Nämlich mit dem Hintergrund, dass Teams einfach selber für sich beschließen sollen, was für sie da am besten passt, wie sie mit Konflikten z. B. umgehen wollen, wie sie auch mit dem Thema Requirements bspw. umgehen wollen und sagt einfach „Scrum als Framework ist da kompatibel mit vielen anderen Themen, die ihr euch selber einfach zurechtlegt“.
Wie man sich da selber helfen kann, wenn man noch nicht so viel Erfahrung hat, das Stichwort hast du gerade auch schon genannt, nämlich Community. Es gibt wirklich extrem viele gute Leute da draußen, die schon seit Jahren, teilweise vielleicht sogar schon seit Jahrzehnten agil arbeiten und das Schöne ist, diese Leute sind auch sehr kommunikativ und teilen auch sehr viel von ihren Erfahrungen, wirklich auch im positiven Sinne in der Community da draußen, in den Blog-Posts, auf den Websites, auf den einschlägigen Seiten und insofern kann man sich da extremst viel an Tipps, Tricks und verschiedenen anderen Tools nochmal holen und ist da wirklich nicht auf sich alleine gestellt.
Um es vielleicht konkret zu machen, es gibt ganz viele Blogs, die ich selber auch letztens nochmal gelesen habe, die mich wahnsinnig begeistert haben, wo drin steht, wie ich z. B. auch als Scrum Master je nach Situation als eine Art Facilitater agieren kann, aber auch als Coach in der anderen Situation oder vielleicht auch manchmal wie ich ein guter Leader bin und vielleicht auch mal vorweg marschiere und die andere somit unterstütze und enable. Es gibt wirklich super viel Content da draußen, der eigentlich komplett for free ist und auf den man wirklich zurückgreifen kann.
Das ist vielleicht ein Aspekt dieses Führungsthema bzw. auch das Thema Konfliktmanagement, wie man da vielleicht auch sich selber nochmal ein bisschen Wissen abzapfen kann von der Community. Auch zum zweiten Punkt, den ich vorher genannt hatte, nämlich, dass das Thema Requirements Management oder auch Backlog Management nicht wirklich von Scrum vorgegeben ist, auch da ist quasi Scrum sehr kompatibel mit ganz vielen verschiedenen Tools, die man da einfach auch verwenden kann und womit man Anforderungen ziemlich effizient beschreiben kann. Ich möchte da auch ein Beispiel nennen. Ich arbeite z. B. selber sehr gerne mit Epics und User Stories. Wie kann man sich das vorstellen?
Ein Epic ist quasi eine Art übergeordnetes Arbeitspaket oder ein übergeordneter Vorgang und die User Stories sind eigentlich nochmal die verschiedenen einzelnen Anforderungen runtergebrochen von diesem übergeordneten Epic. Das ist fast schon eine Art kleiner Leiter, die man sich an der Stelle vorstellen kann. Damit kann man wirklich Anforderungen recht simpel, aber effizient beschreiben, kommunizieren, auch für alle transparent machen und so das Ganze eigentlich auch gut durchführen. Vielleicht bringe ich auch einfach mal ein Beispiel von so einer User Story, wie die grundsätzlich aufgebaut ist, das ist nämlich ziemlich spannend.
So eine User Story ist eigentlich immer im Dreiklang aufgebaut. Der Dreiklang besteht immer aus dem Thema Person, dann Funktionalität und als Drittes der Nutzen. So ist eigentlich, der Name sagt es schon, das Ganze wie eine kleine Story, wie eine kleine Geschichte aufgebaut. Ich bring mal ein Beispiel. Als ein bestimmter Nutzer möchte ich eine bestimmte Funktionalität haben, um den und den Nutzen zu erreichen. Das Schöne ist eigentlich, dass man damit beschreiben kann, übergeordnet jetzt, wenn man sich in so eine IT-Lösung reindenkt „welches Rollenverständnis habe ich dahinter? Welche Rolle möchte was sehen können, möchte welche Funktionalität haben, aber auch für welchen Nutzen?“ und so habe ich z. B. auch als Entwickler immer Vorlieben, nicht nur „was ist gewünscht und wer wünscht es?“, sondern auch „was ist das übergeordnete Ziel dahinter?“ oder eben dieser übergeordnete Nutzen.
Das kann auch nochmal wirklich wichtig sein, damit ich mich einfach besser in die Lage versetzen kann, warum diese Anforderung überhaupt entstanden ist. So kann man eben auch mit diesen verschiedenen Epics oder auch mit diesen verschiedenen User Stories das ganze wirklich gut beschreiben. Es gibt aber auch noch ganz viele andere Methoden und auch viele andere Tools, um sich selber auch mit Scrum oder in anderen agilen Frameworks wirklich gut zu tracken oder seinen Alltag gut zu gestalten. Es gibt z. B. sog. Burndown-Charts oder Burnup-Charts, da geht es vor allem darum den Projektfortschritt oder auch den Sprintfortschritt immer zu messen und zu gucken „wie viele Sachen habe ich schon abgearbeitet bzw. wie viele Anforderungen stehen sogar noch aus?“, auch da kann man wirklich sehr, sehr viele Tools verwenden, die sich mit Scrum wunderbar verheiraten lassen.
Das finde ich auch das Schöne an dem Ganzen, dass man da sehr, sehr flexibel ist. Aber, das ist natürlich ein wichtiger Punkt an der Stelle, Flexibilität heißt natürlich auch, dass man sich gemeinsam als Team auch wirklich auf einen guten Mix erstmal einigen muss. Man muss für seine Situation, für sein Projekt als Team auch wirklich den Mix an Tools selektieren, mit dem man am besten arbeiten kann, mit dem man am effizientesten arbeiten kann und mit dem man sich auch wirklich selber wohlfühlt, weil – das möchte ich schon an der Stelle vorbringen – es bringt einfach nichts erstmal bekannte Tools einzuführen, weil sie vielleicht auch von vielen anderen genutzt werden oder weil die sehr populär sind, aber wenn ich selber nicht wirklich davon überzeugt bin vom Mehrwert oder wenn ich vielleicht auch nicht gut damit umgehen kann, wenn es mir vielleicht nicht so gut liegt das Projektteam, dann bringt das Ganze eigentlich nichts.
Man muss wirklich selber da ein bisschen was investieren an Gedanken und gucken, welche konkreten Tools und welche konkreten Tipps und Tricks einem da am meisten helfen.
Projekt0708 Activate Methodik: Unsere Weiterentwicklung von SAP Activate
Michael Scheffler:
Also nochmal quasi sehr spezifisch auf die Kunden und Projektsituationen das konkrete Setup zu klären? Das ist jetzt die Herausforderung?
Ludwig Wartlsteiner:
Absolut, genau. Man muss sich einfach wirklich überlegen „wie wollen wir Anforderungen konkret beschreiben in unserem Projekt? Mit welchen Tracking-Tools möchten wir arbeiten usw.?“, das sind auch nochmal ganz wichtige Fragen.
Michael Scheffler:
Hast du dein Lieblings-Setup?
Ludwig Wartlsteiner:
Ja, ich habe tatsächlich wirklich ein Setup, das ich gerne mit den Epics und den User Stories auch arbeite. Ich arbeite auch sehr, sehr gerne mit Burndown-Charts. Das sind mit meine favorisierten Tools, die ich auch sehr, sehr gerne hernehme und bin eigentlich bisher ganz gut damit gefahren. Und hier haben wir selber auch ein Set an Best Practices entwickelt oder ein Set an Tools entwickelt, mit denen wir eigentlich ganz gerne bei Projekt0708 immer wieder in unsere agilen Projekte gehen und mit denen wir auch gut arbeiten. Grundsätzlich sind wir da eigentlich relativ flexibel.
Das wichtige ist immer, dass man sich gemeinsam einfach mit allen Stakeholdern und vor allem auch in unserer Situation mit dem Kunden einmal zusammensetzt und sich am Anfang überlegt, wie man das genau aufziehen möchte, welche Tools man verwenden möchte und wie man im Projekt vorgehen möchte.
Michael Scheffler:
Oder welches Setup der Kunde gerne nutzt.
Ludwig Wartlsteiner:
Oder das natürlich, genau. Gibt sehr viel. Man lernt natürlich auch selber immer wieder gerne mit dazu und die Möglichkeiten sind wirklich vielfältig an der Stelle.
Michael Scheffler:
Ludwig, da wir gerade über eigenes Setup sprechen, wir hatten ja vorhin schon über SAP Activate gesprochen. Kannst du uns und unseren ZuhörerInnen noch etwas über die projekt0708 Activate Methodik berichten? Wir haben ja auch für uns selber ein eigenes Modell geschaffen in Anlehnung an SAP Activate, was war denn da die Motivation und warum haben wir das getan bzw. wie haben wir das ausgestaltet?
Ludwig Wartlsteiner:
Wie du bereits gesagt hattest, es gibt ja schon sehr, sehr viel von SAP Activate, was im Standard mit dazu kommt. Ich bin auch in der letzten Folge schon ein bisschen darauf eingegangen, was da alles schon mitkommt. Wir haben uns aber trotzdem dazu entschlossen das Ganze nochmal – ich möchte sagen – ein bisschen detaillierter auszubauen und haben da eigentlich unseren eigenen Projekt0708 Best Practice an der Stelle weiterentwickelt. Warum das Ganze?
Gerade beim Thema Testing und auch beim Thema Hypercare haben wir eigentlich gemerkt, dass der Standard von SAP Activate zwar wirklich schon herausragend ist, aber dass wir da gerne noch ein bisschen detaillierter auch mit reingehen wollen und haben z. B. nochmal auch bei dieser iterativen Vorgehensweise am Schluss der ganzen Iterationen nochmal einen dezidierten großen Abnahmetest immer eigentlich mit eingeplant. Oder auch z. B. einen bestimmten Integrationstest, den wir gerne nochmal mitmachen würden. Warum das Ganze?
Auch wenn wir da teilweise schon sehr agil unterwegs sind bei dem Thema, gerade auch bei der hybriden Vorgehensweise ist es uns trotzdem nochmal wichtig, dass wir am Schluss von so einem Projekt nochmal alles gemeinsam mit dem Kunden abnehmen, dass wir nochmal alles auf Herz und Nieren überprüfen und auch wirklich gucken, dass das Ganze „ready for go live“ ist. Also das ist ein Punkt, den wir nochmal detaillierter im Vergleich zum Standard von SAP Activate für uns ausformuliert haben.
Ein weiterer Punkt ist auch bspw., dass wir in der Hypercare Phase gemerkt haben, dass wir da unsere Kunden noch mehr immer unterstützen möchten, um wirklich auch diesen Switch vom Projekt zum operativen daily business nochmal einfacher, effizienter zu gestalten und auch den Übergang gemeinsam mit dem Kunden besser zu gestalten.
Erfahrungsgemäß ist es nämlich so, wenn eine Organisation mit irgendwas Großem live geht und das Ganze streut an alle Endanwenderinnen und Endanwender, dann fällt allen erstmal der große Stein vom Herzen und viele sind dann sofort wieder in anderen Projekten oder das Ganze verläuft sich vielleicht sogar auch und da haben wir einfach gemerkt, dass wir fast schon diese Spannung und auch diesen Fokus und auch das Momentum aufrechterhalten wollen und gleich direkt danach vielleicht schon die ersten CRs angehen möchten oder auch den Supportprozess noch besser begleiten möchten und einfach nochmal mehr Mehrwert für den Kunden schaffen wollen an der Stelle.
Das sind mal so zwei kleine Beispiele, wo wir den Standard von SAP Activate sogar nochmal für unsere Zwecke ein bisschen detaillierter ausformuliert haben.
Praxistipps für eine erfolgreiche Agile Transformation
Michael Scheffler:
Lass uns doch mal zum Abschluss der heutigen Episode für unsere HörerInnen ein paar Praxistipps sammeln, Empfehlungen geben. Hast du da was in petto? Ganz konkrete Punkte, die du ihnen mitgeben möchtest, wenn man sich für die agile Transformation entscheidet?
Ludwig Wartlsteiner:
Der wichtigste Tipp am Anfang ist natürlich auch, da haben wir schon ein paar Mal drüber gesprochen heute, ist die richtige agile Methode auszuwählen. Soll es wirklich Scrum sein oder nimmt man vielleicht doch eher ein hybrides Modell? Ich glaube wir haben auch hoffentlich ganz gut herausgestellt, wann welches Sinn macht. Aber, das ist immer ganz, ganz wichtig, wenn man sich für eine agile Methode entscheidet in so einer Art agilen Transformation, wenn man vor allem erst sehr klassisch unterwegs war und dann agil werden möchte, ich finde einer der wichtigsten Punkte ist es, dass man sich selbst auch messbare Ziele steckt. Das wäre auch wirklich ein großer Tipp von mir. Was möchte man denn mit Agilität erreichen wollen? Warum möchte man agil sein?
Ich hoffe das hat auch einen Hintergrund, weil Agilität ist ja kein Selbstzweck. Wir machen das ja nicht, weil uns langweilig ist und weil wir mal was Neues ausprobieren wollen, sondern wir verfolgen ja hoffentlich auch immer ein Ziel. Ein gutes Ziel kann sein „wir wollen schneller das erste Kundenfeedback erhalten“ oder „wir wollen im Nachgang von Projekten 30 Prozent weniger Change Requests haben“ oder sowas. Wirklich offensiv sich selber auch auf einer Metaebene Ziele setzen, was man mit diesem agilen Projekt erreichen will, vielleicht auch im Gegensatz zu einem klassischen.
Als weiteren Tipp würde ich sagen, unbedingt die Verantwortlichkeiten und Rollen gut definieren und auch wirklich dann konkret besetzen. Es kann nicht jeder alles machen, weil dann macht ggfls. keiner was und alle sind in einem Chaos, also wirklich ein ganz, ganz wichtiger und großer Tipp. Bitte auch alle Rollen festlegen, die in agilen Teams vorhanden sein müssen. Diese agilen Teams sollten auch dann wirklich kontinuierlich und konstant in diesen Rollen agil arbeiten dürfen, um da auch Lerneffekte zu generieren und selbst irgendwie besser zu werden, sodass es auch wirklich von der Lernkurve her noch nach oben geht.
Einen vierten Tipp würde ich noch gerne mitgeben, die agilen Kompetenzen des Projektteams immer weiter zu fördern. Wenn es natürlich schon eingefleischte Vollprofis sind, dann ist es was anderes, aber gerade wenn das Skilllevel eher so Beginner oder Mitte ist, also fortgeschritten, dann würde ich auf jeden Fall immer wieder versuchen da viel zu coachen, viel mit zu fördern und teilweise vielleicht auch wirklich mit auszubilden. Scrum-Kurse, muss ich auch wirklich dazu sagen, das ist nicht einfach nur Geldmacherei oder Selbstzweck, sondern die machen wirklich auch Sinn, um die Methodik sich nochmal gut anzueignen und die Projektmanagementskills da zu verbessern.
Ich kann, du hast es ja vorhin schon erwähnt, wirklich aus eigener Erfahrung sprechen als Scrum Master, der selber auch die Zertifizierung und die Kurse durchgegangen ist, ich habe nochmal super viel dazugelernt bei dem Ganzen. Was natürlich auch ein ganz wichtiger Tipp von meiner Seite wäre das agile Mindset in der Organisation zu fördern. Ich habe schon ein Stück weit vorher angerissen, würde es aber gerne nochmal sagen, dieses proaktive Betreiben des Erwartungsmanagements gegenüber den Endkunden und der Organisation. Ab wann ist mit welchen Ergebnissen zu rechnen und ab wann nicht? Das müsste man nochmal transparent an der Stelle machen. Auch quasi das Team selbst ist in diesem Zuge auch wirklich wichtig zu nennen, denn Agilität ist auch da nochmal ein wahnsinniger Kultur- und Mindset-Change.
Agilität setzt viel mehr auf Selbstständigkeit, auf eigenständige Arbeitsweisen von eigentlich jedem einzelnen Teammitglied. Jedes Teammitglied ist selbst auch ein Stück weit verantwortlich das Projekt voranzutreiben etc. und das muss natürlich auch irgendwo gefördert und begleitet werden. Das fällt natürlich nicht einem automatisch so einfach so mal in den Schoß. Was auch noch wirklich extrem wichtig ist, würde ich gerne noch als Tipp mitgeben, man muss sich wirklich gut überlegen, wie man diese agilen Teams in diese oftmals eher klassischen Organisationen nochmal einbettet.
Wie spielt das zusammen mit der Gesamtorganisation? Unsere Unternehmen denken einfach oftmals noch extrem klassisch. Man muss sich z. B. auch so eine Frage stellen, jetzt ganz pragmatisch gedacht „wie reporte ich ans Management?“. Die werden sich bestimmt nicht nur alle vier Wochen in die Sprint Reviews setzen und dann auch noch am besten für vier Stunden und dann sich ihr Update holen, also da würden einige auf dem ein oder anderen Stuhl schon nervös werden. Es ist aber nochmal im Ernst wirklich wichtig, dass man da auch irgendwie eine Art und Weise „Schnittstelle“ schafft zwischen der agilen und klassischen Organisationsweise und dass man da einfach guckt, dass man gewisse Updates, Managementreports etc. auch irgendwie mit einbettet, sodass natürlich auch da alles irgendwie geliefert wird, was einem von außen herangetragen wird ans Team. Das ist nochmal sehr wichtig.
Zu guter Letzt, das wäre mein letzter Tipp, der mir spontan einfällt, bei der agilen Transformation sich erstmal an überschaubaren Projekten ausprobieren und dann von da an immer weiter entwickeln. Evolution statt Revolution.
Michael Scheffler:
Ludwig, das war ja eine ganze Latte von ganz praktischen hilfreichen Tipps, danke dafür. Von meiner Seite sind wir auch durch mit meinen Fragen. Ich bin ein gutes Stück schlauer geworden. Ich hoffe Sie, liebe ZuhörerInnen, auch. Falls Sie Fragen haben, kommen Sie immer gerne auf uns zu. Ludwig oder ich stehen Ihnen da jederzeit zur Verfügung. Da bleibt mir nichts mehr anderes zu tun als dir zu danken, Ludwig, erneut super toller Input, alles Gute.
Ludwig Wartlsteiner:
Vielen lieben Dank Michael, vielen lieben Dank an unsere Zuhörerinnen und Zuhörer. Ich hoffe es war kurzweilig, ich hoffe man konnte was lernen und ich freue mich schon auf das Wiedersehen, bis dann.
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.
