Hinweis: mit "Play" wird eine Verbindung zu Podcastbude, Media On Work GmbH, Potsdam hergestellt.
Warum liefern Teams trotz Agile-Tools nicht zuverlässig? Nadine Schardt zeigt, wie Priorisierung, Team-Setup, Meeting-Fokus und Konfliktfähigkeit echte Delivery Excellence ermöglichen.
Von Nadine Schardt und Philipp Ebnet
Viele Unternehmen arbeiten agil – und trotzdem werden Deadlines gerissen, Meetings häufen sich und Teams bleiben hinter ihren eigenen Zusagen zurück. Das führt schnell zu Frust, sowohl im Team als auch im Management.
In dieser Folge des Digitalwandlers spricht Philipp Ebnet mit Nadine Schardt, Agile Coach bei CGI, darüber, was Delivery Excellence in der IT wirklich bedeutet – und warum sie nicht durch Tools oder Frameworks allein entsteht.
Delivery Excellence zeigt sich nicht in der Anzahl der Meetings oder im Einsatz von Scrum oder Kanban. Sie zeigt sich daran, ob Teams realistisch planen, verlässlich liefern und gemeinsam Verantwortung übernehmen.
Fehlende Delivery Excellence macht sich häufig daran bemerkbar, dass:
Doch das Problem liegt selten in der Methode. Entscheidend sind Vertrauen im Team, klare Verantwortlichkeiten, saubere Priorisierung und der Mut, Probleme offen anzusprechen. Delivery Excellence entsteht dort, wo Teams kontinuierlich lernen, sich ehrlich hinterfragen und ihre Zusammenarbeit aktiv weiterentwickeln – nicht dort, wo lediglich Prozesse eingeführt wurden.
Die Folge richtet sich an alle, die verstehen möchten, warum agile Arbeit in der Praxis oft hinter den Erwartungen zurückbleibt – und wie Teams nachhaltig leistungsfähig werden.
Zum Nachlesen: das vollständige Gespräch mit Sprecherwechsel
Philipp Ebnet, CGI: Herzlich willkommen beim Digitalwandler. Ich bin Philipp und will heute wissen, wie sich Prozesse kontinuierlich weiterentwickeln und verbessern lassen. Und Antworten auf meine Fragen zu erhalten, habe ich mir heute Nadine Schardt ins virtuelle Studio eingeladen.
Nadine ist Agile Coach und hat bereits in ihrem Psychologiestudium für Fragen wie „Wer sind wir“ und „welche Fähigkeiten haben wir“ gebrannt. Und daher hat sie nach ihrem Psychologiestudium dann noch eine Ausbildung zur Gestalttherapeutin absolviert, Menschen noch besser helfen zu können, die eigenen Bedürfnisse und eigenen Fähigkeiten zu entdecken. Ich sage erstmal Hi Nadine, freut mich, dass du da bist.
Nadine Schardt, CGI: Hallo, schön hier zu sein. Ich freue mich auf das Gespräch und dass das Thema einfach mehr Raum bekommt und hoffentlich andere Menschen auch interessiert.
Philipp Ebnet, CGI: Ja, das hoffe ich doch auch. Ich habe mich natürlich in der Vorbereitung der Folge ein bisschen mit dem Thema Prozessoptimierung beschäftigt und dabei bin ich auf den simplen Satz gestoßen, „every business is a delivery business.“ Dahinter steckt einfach die Idee, dass Kunden, egal welchen Unternehmens, ihr dieses Unternehmen anhand der Lieferqualität bewerten. Also ganz egal, ob das Unternehmen jetzt ein digitales oder physisches Produkt verkauft oder eine Dienstleistung anbietet. Der Kunde bewertet das Unternehmen anhand dessen, wie schnell und zufriedenstellend ich als Kunde diese gekaufte Leistung erhalte und auch wie gut diese Leistung dann ist. Dieser Satz, in diesem Zusammenhang, bin ich auch auf den Hinweis gestoßen, dass eben jedes Unternehmen deswegen Delivery Excellence anstreben sollte. Und du bist ja hauptsächlich im IT-Umfeld unterwegs als Coach. Insofern frage ich dich jetzt mal, was bedeutet denn Delivery Excellence in der IT?
Nadine Schardt, CGI: Ich war schon in verschiedensten Projekten unterwegs in der IT und Delivery Excellence meint in diesem Kontext, dass Produktteams, die in der IT sind, aber auch in anderen Abteilungen sein können, das liefern, was sie liefern können von sich aus. Also von der Umsetzkraft, die ein Team mit sich bringt, von den Skills, die das Team mit sich bringt und was das Produkt auch erwartet, können Teams ja einen gewissen Umsatz machen und Delivery Excellence bedeutet genau das, dass Teams befähigt sind, diese Schwelle zu erreichen. Genau. Und dass sie verlässlich auch das liefern, auf was sie sich committed haben, auf was auch andere schauen und sich verlassen an der Stelle. Genau.
Philipp Ebnet, CGI: Jetzt habe ich ja normalerweise schon ein Team, das schon irgendwie was macht. Das heißt, bevor ich jetzt mit der Frage weitermache, wie ich anfange, würde ich mich erstmal die Frage interessieren, wenn ich jetzt erstmal schauen will, wie gut meine Delivery Excellence im Moment funktioniert, an welchen Kriterien kann ich das denn festmachen, welche Kriterien sollte ich mir da anschauen?
Nadine Schardt, CGI: Da gibt es verschiedenste Facetten. Da ich ja auch aus der Psychologieschiene komme, schaue ich natürlich auch immer, wie gesund das Team ist, ist es eigentlich aufgestellt. Gibt es Konflikte? Können sie die Konflikte ausagieren? Das ist für mich auch ein Teil von Delivery Excellence zu sagen, mein Team ist so performant untereinander, dass sie sich vertrauen und Konflikt ausagieren können. Das ist so das Psychologische. Es gibt aber auch auf der Prozess-Ebene, dass man schauen kann, wenn wir in der IT sind und im agilen Arbeiten wir ja mit Sprints und pro Sprint, also pro zwei, drei Wochen nehmen wir uns ja ein gewisses Aufgabenpaket vor. Und ganz simpel: wird dieses Aufgabenpaket eingehalten. Also das, was wir uns vorgenommen haben, wird es eingehalten, weil das, was ich oft erlebe, ist, dass es das eben nicht tut. Das ist meistens eigentlich der erste Einstieg, ne? So zu schauen, halten wir das, was wir versprochen haben, aber auch wie sieht es mit den Metriken aus? Wenn wir in Jira arbeiten zum Beispiel, gibt es verschiedenste Metriken, die wir uns anschauen können. Wie alt sind die Tickets, die Aufgabenpakete, wie lange brauchen die, bis sie abgeschlossen sind und so weiter. Und das sind meist schon so ganz gute Indikatoren, herauszufinden, wo steht es um unsere Delivery Excellence.
Philipp Ebnet, CGI: Gibt es dann bestimmte Rollen im Team, denen du sagst, die sollte jedes Team haben? Oder nach welchen Positionen im Team schaust du, wenn du Delivery Excellence irgendwo einführen möchtest oder verbessern möchtest?
Nadine Schardt, CGI: Was ich meistens mache, ist eher zu schauen, zu welchem Produkt arbeiten wir. Viele Kunden von uns haben auch immer wieder, also die Frage kriege ich fast jeden in jedem Projekt gestellt, haben wir für die Anforderung des Produktes genau die Menschen in unserem Team, die das umsetzen können? Also matcht das Skillset, derTeammitglieder mit den Produktanforderungen?
Das heißt, wenn ich ein Assessment mache und reingehe in die Firmen, um Delivery Excellence zu prüfen, wie der Stand der Dinge ist und welche Handlungsempfehlungen ich aussprechen würde, dann schaue ich mir sehr ausführlich auch das Produkt an, was gibt es da für Anforderungen und schaue dann demnach, okay, ist das im Team enthalten? Können wir das gut abbilden oder ist da irgendwo eine Fehlstellung zum Beispiel?
Also manche Teams tendieren auch dazu oder manche Firmen, dass in den Teams an sich zu wenig Leute sind, die wirklich umsetzen. Wenn wir in der IT schauen, dann brauchen wir natürlich Entwickler, die die Software oder was auch immer entwickelt werden muss, entwickeln. Und dann ist meist eher zu beobachten, dass ein sehr großer Overhead da ist. Also dass da viele, vielleicht auch Führungskräfte, Teamleiter, Teamleiterinnen und so weiter mit drin setzen. Die aber eigentlich eher versuchen wollen, die Teams so aufzustellen, dass da wirklich eine Durchsatzkraft drin ist. Sprich viele Leute da drin sitzen, die auch dann am Ende des Tages auch umsetzen können. Aber ich schaue halt immer erst was ist das Produkt, was sind die Anforderungen und dann gucke ich, ok passt die Teamkonstellation dazu.
Philipp Ebnet, CGI: Jetzt hast du gerade schon gemeint, dass es bei manchen Produkten dann viel Overhead gibt und viele doch unterschiedliche Rollen benötigt sind. Worauf ich hinaus will ist, was ist denn so die optimale Teamgröße, aber das hängt vermutlich stark vom Produkt ab. Insofern frage ich mal, welche Erfahrung hast du denn mal gemacht, dass ein Team entweder viel zu groß oder viel zu klein war und wie reagierst du auf eine falsche Teamgröße?
Nadine Schardt, CGI: Ja, auch auf jeden Fall eine gute Frage. Also es gibt im Scrum Guide, wenn wir zum Beispiel in der Scrum arbeiten, das ist ja eins von verschiedenen Varianten, wie wir im Agilen zusammenarbeiten können, dann empfehlen die meist so eine Teamgröße von neun Personen, neun bis zehn.
Und natürlich habe ich schon ganz verschiedenste Konstellationen gesehen. Psychologisch bedingt, merkt man aber schon, dass sie sich bei dieser Größe Neun schon was gedacht haben. Weil man merkt, je mehr Leute es werden, desto mehr Kommunikationskanäle haben wir, wir müssen uns mehr abstimmen. Wenn wir überlegen, wir haben 25 Leute in einem Team, wie viel mehr Absprachen ich machen muss, zum Ziel zu kommen, versus ich hab nur neun oder acht mit mir zusammen, dann ist das schon deutlich geringer.
Das heißt, die Kommunikationswege werden mehr, wenn die Teams größer sind. Es wird komplexer. Und wenn wir uns jeden Tag abstimmen, wir jeden Morgen mal stimmen uns ab und sagen, was haben wir uns heute vor, was war gestern, dann dauert das ewig, bis 25 Leute sich abgestimmt haben. Dann hören wir nicht mehr zu, das interessiert uns nicht mehr. Also wir wollen halt schon psychologisch auch betrachtet einen kleinen Fokus haben, um schnell und wendig zu sein, uns anzupassen und so weiter. Deswegen ist es schon idealerweise neun bis zehn. Ich habe aber auch schon gut funktionierende Teams gesehen, die agil und psychologisch wirklich reif waren. Und dann waren das 20 Leute.
Pauschal würde ich sagen, je kleiner, desto besser. Wenn das Team aber ein gewisser Reifegrad hat und das Produkt es hergibt, dann würde ich mir immer wieder auch die Meetings anschauen und gucken, wenn das klappt, dann würde ich erst mal bei dieser Teamkonstellation der Größe bleiben. Wenn Teams zu groß werden und irgendwann kommen so Störfaktoren wie, wir hören nicht mehr zu in den Meetings oder die Meetings dauern 50 Jahre bis sie zu Ende sind und so weiter oder die Metriken werden wieder schlechter, wir reißen die Deadlines und so weiter, dann wäre das so ein typischer Fall von hey, lass uns das Team verkleinern, splitten in zwei, drei Teams oder ne und so weiter.
Philipp Ebnet, CGI: Von wem geht dann dieser Aufruf auf, aus dem Team zu ändern? Gibt es da eine Rolle, die eben drauf schaut, ob die Kommunikation richtig funktioniert oder kann ich auch, wenn ich als einzelner Developer merke, irgendwie funktioniert die Kommunikation nicht so, wie sie sollte, einfach das mal ansprechen? Was ist da so die Empfehlung oder deine Erfahrung?
Nadine Schardt, CGI: Also, die Person, die die Verantwortung dazu hat, draufzuschauen, das bin ich als Agile Coach oder Scrum Master, das wäre auch eine Rolle, ich innehaben könnte. Aber als Agile Coach schaue ich schon darauf, ist das Team, so wie es aufgestellt ist, gut oder muss es geändert werden?
An mich heran treten aber auch oft Entwickler, Product Owner, Projektleiter, Leiterinnen, also die können alle zu mir hinkommen und Beschwerde einreichen quasi und ich schaue dann sehe ich dazu auch Beweisgründe, dass es zu groß ist, beobachte das, bespreche das wiederum mit dem Team. Also, agiles Arbeiten lebt ja auch sehr viel von Ehrlichkeit und Transparenz. Das heißt, es würde nicht lange dauern, bis es auch im Team thematisiert wird. Und dann schauen wir nach einer bestmöglichen Lösung. Aber die Person, die es verantwortet, das bin ich.
Philipp Ebnet, CGI: Alles klar. Jetzt würde mich noch ein bisschen interessieren, wie lange dauert es denn so, ein Team an diese Arbeitsweise heranzuführen oder eben so Delivery Excellence aufzubauen? Also wenn du jetzt in ein Team frisch reinkommst und da eben mal schauen willst, wie da die Situation ist, wie viel Zeit nimmst du dir für so ein Projekt?
Nadine Schardt, CGI: Das kommt immer so bisschen drauf an. Also wir hatten zum Beispiel, ich denke gerade an eine Kundenanfrage, da wurde die Anfrage an uns gestellt, wir arbeiten doch schon agil, aber unsere Teams liefern nicht, was sie liefern sollen, was können wir machen?
Und dann war ich sechs Wochen da und habe die Teams mit einem Assessment analysiert. Dann bin durch die Teams gegangen, habe mir das alles angeschaut und hatte nach sechs Wochen eine ganze Liste von Punkten, wo ich denke, das läuft schief. Und meine Handlungsempfehlung, was würde ich besser machen? Also das heißt, um das Thema Delivery Excellence voranzubringen, wäre es ja schon mal gut, mal so eine Momentaufnahme zu haben. Und das geht meist schon innerhalb von sechs bis acht Wochen, wenn ich da wirklich reinschauen kann. Meistens ist der Engpass immer die Terminfindung mit den Leuten selbst. Und wenn das aber steht, könnte man nach, wie gesagt, sechs bis acht Wochen da schon mal einen Statusupdate haben.
Um aber dann wirklich das Team dahin zu begleiten, wirklich performant zu liefern und dass sie wieder produktiver werden, das kann mitunter halt schon sechs bis zwölf Monate dauern. Je nachdem, wie viel Bereitschaft da ist oder wo die Probleme am meisten liegen. Also ich hatte zum Beispiel mein Team, die waren sehr seniorig, also die hatten vom Skillset her, waren die wirklich sehr, weit. Das Produkt war auch nicht so komplex. Aber die haben sich untereinander gar nicht verstanden. Also da wurde alles über die Führungskräfte geregelt. Konflikte wurden gar nicht angesprochen und wenn war es die Volleskalation. Und da habe ich sechs Monate lang fast nur Teamentwicklung gemacht. Und dann hatte ich nach sechs Monaten das Gefühl, jetzt ist es besser.
Es kann aber auch sein, ein Team fängt frisch an, hat noch nie im agilen Kontext gearbeitet, die Entwickler und Entwicklerin, in dem Team sind, eher juniorig. Und die kennen sich alle noch nicht. Dann kann das schon mal ein Prozess sein, der schon auch mal zwölf Monate dauert, um das Team wirklich adäquat auf allen Ebenen hinzubringen, dass es agil, reif oder reifer ist, dass es wirklich Delivery Excellence erreichen kann. Es hängt halt immer sehr viel ab von wie ist das Team, die Teamkonstellation, wie ist das Produkt, ist es kompliziert oder nicht, wie viel Zeit haben wir. Wie sehr stehen die Führungskräfte hinter dieser Arbeit? Ist das eher bremsend oder das eher unterstützend? Also das sind alle Faktoren, da mit reinspielen können.
Philipp Ebnet, CGI: Jetzt hast du schon einen Punkt angesprochen, wo ich mal anknüpfen würde, gerne, nämlich, dass du auch manchmal mit Teams zusammen arbeitest, die noch nicht mit dieser Arbeitsweise vertraut sind. Wie gehst du dann vor? Also wenn du jetzt eben in ein Team reinkommst, das noch nie agil gearbeitet hat, wie führst du ein Team an dieser agile Arbeitsweise heran? Was sind da so deine best practices, um eben die Leute motiviert zu halten oder diese Arbeitsweise vernünftig zu vermitteln und die nicht gleich abzuschrecken?
Nadine Schardt, CGI: Es gibt nach dem Tuckman das Phasen-Modell, ich weiß nicht du das kennst, das Team-Phase Modell, wo sich Teams entwickeln hin zu High-Performing-Teams und daran orientiere ich mich immer sehr stark. Am Anfang ist es ganz wichtig, erstmal eine Basis zu schaffen, allen Orientierung Klarheit zu geben, also zu klären, wann sind unsere Meetings, warum treffen wir uns zu den Meetings, was haben die für einen Zweck in den Meetings. Also ganz viel Basisarbeit und ganz viel Orientierungsstrukturarbeit.
Und wenn das alles gesetzt ist auf diesem Fundament, fangen dann meist so die ersten Konflikte an. Also die Leute kennen sich schon ein bisschen, wir haben die ersten Meetings gemacht, wir wissen, wann wir uns wo treffen. Und dann trauen sich meistens die ersten mal sozusagen, was sie irgendwie blöd finden oder einander nicht gut finden und so weiter.
Dann geht es sehr viel darum, diese Konflikte auszuagieren. Dann schaue ich, dass die da sein können, wir die lösen können, dass wir die Sachen auf Tisch bringen können. Weil dieses Vertrauen wiederum hilft, auch psychologisch sicher miteinander zu arbeiten, wieder die nächste Stufe von dem Tuckman zu kommen. Also so fange ich meistens an, mit ganz viel Strukturarbeit.
Und parallel immer so häppchenweise, dass ich das agile Arbeiten mit einfließen lasse. Wenn wir über das agile Arbeiten nachdenken, dann ist es natürlich dieser ganze Mindsetbereich. Also, dass agiles Arbeiten auch mit einem anderen Mindset einhergeht als, sagen wir mal, mit einem klassischen Projektmanagement. Aber das ist so was, was braucht halt einfach länger.
Das heißt, ich mache immer parallel zu diesem ganzen Struktur- und Teamentwicklungsaufbau meist so agile Häppchen, die ich immer wieder reinbringe in Form von Mini-Trainings oder ad hoc in den Meetings, dass ich was dazu sage. Und mit den einzelnen Rollen sie coache hin zu, dass sie ihre agile Rolle wirklich einnehmen können. Das sind so die Schritte, ich mache.
Philipp Ebnet, CGI: Was ist so das eine Problem oder die eine Beschwerde, die du am häufigsten gehört hast?
Nadine Schardt, CGI: Wir haben zu viele Meetings.
Ja, schon auch das ganze Thema von: wir schaffen einfach nicht unsere Commitments. Deswegen bin ich auch zu dem Thema Delivery Excellence gekommen, weil ich immer wieder gesehen habe, dass Teams wirklich massive Probleme damit haben, die Commitments einzuhalten, von dem, was sie versprochen haben, zu schaffen. Das demotiviert auch Teammitglieder, wenn sie ständig sich was vornehmen und dann reißen sie das, was sie versprochen haben, nicht immer aus Selbstverschulden, sondern weil vielleicht aus anderen Abteilungen zu viel eingegriffen wird, weil die Arbeitspakete noch zu unklar waren, was auch immer. Es gibt verschiedenste Faktoren, die da einspielen. Aber das sind so die zwei Sachen, die ich am meisten höre. Zu viele Meetings und warum schaffen wir nicht das, was wir uns vorgenommen haben.
Philipp Ebnet, CGI: Dann bleiben wir da doch mal dabei. Was wäre dann so die ideale Lösung, wenn du an das ideale Team denkst und eben diese beiden Probleme bekämpfen möchtest? Wie würdest du da vorgehen? Was würdest du als Lösungsansätze erkunden?
Nadine Schardt, CGI: Also erstmal würde ich wieder auch wie in einem Ansatz von einem Assessment schauen, woran liegt es denn eigentlich? Warum reißen wir die Deadline und warum haben wir so viele Meetings?
Und meistens ist es so, wenn Sie sich über zu viele Meetings beschweren, dann werden die Meetings meistens nicht als solche genutzt, wie sie eigentlich gedacht sind. Also, dass wir wirklich schauen, sind wir alle fokussiert in den Meetings, werden die Meetings als solche auch wirklich genutzt, wie sie gedacht sind, können wir die optimieren, sodass andere Meetings wieder wegfallen können. Können wir Arbeitspakete hinten rüber fallen lassen, sodass auch wieder Meetings wieder verschwinden. Oder arbeitsfreie Blocker im Kalender, wo wirklich jeder fokussiert abarbeiten kann, damit die Meetings auch wieder mehr Sinn machen, wo wir uns sehen. Weil wir brauchen ja auch Abarbeitungszeit, jeder von uns. Das ist das eine Thema.
Und wenn mir Deadlines ständig reißen, würde ich halt einfach schauen, woran liegt es. Ich mir die Metriken anschauen, wie alt sind die Arbeitspakete. Ich würde gucken, in was für einen Zustand sind die Anforderungen, reinkommen in das Team? Haben die eine gute Qualität? Haben die eine schlechte Qualität? Am Ende entsteht vielleicht viel Nacharbeit. Das ist meistens ein Indiz für, am Anfang war es dann doch nicht so ganz klar.
Also ich gucke da auf verschiedenste Faktoren und nehme das Team mal mit rein. dann meistens kommt schon, ja, ich muss immer warten auf XY oder der Fachbereich muss das noch freigeben oder der Product Owner ist nie greifbar oder der Business Analyst arbeitet das nicht sorgfältig aus oder da gibt es wirklich mannigfaltige Faktoren, die da so reinspielen können. Aber ich höre dann viele Gespräche und schaue, woran es dann letztendlich liegt.
Philipp Ebnet, CGI: Jetzt hast du schon ein bisschen das Thema mit zu vielen Commitments angeschnitten oder angesprochen. Weil eine Frage, die ich mir auch gestellt habe, ich vermute jetzt mal, dass wir alle immer gute Arbeit liefern wollen, aber wir haben natürlich immer das Problem mit den Deadlines oder eben Zeitdruck. Wie kann ich denn Delivery Excellence oder eben ein möglichst gutes Produkt, eine möglichst gute Dienstleistung und diesen Zeitdruck, diese Deadlines miteinander vereinbaren? Was würdest du da so empfehlen?
Nadine Schardt, CGI: Ich finde eigentlich auch da wieder aus psychologischer Perspektive ist das total genial, dass wir diesen Zeitdruck haben, weil der uns oft dazu zwingt zu schauen, was ist wirklich nötig und notwendig von dem, was wir umsetzen müssen. Also wenn wir es wirklich nutzen als das, was gedacht ist, dann sorgt es eher für so eine Priorisierung. Zu sagen, ok, von den 500 Sachen, die wir machen wollten, sind eigentlich nur 100 relevant.
Und dann sind wir wieder beim agilen Mindset. Genau das wollen wir erreichen. Dass wir am Ende des Tages nur die Dinge tun, die wirklich für den Kunden Mehrwert liefern. Und diese kurzen Zeitzyklen, die kurzen Meetings zwingen uns eigentlich immer wieder dazu, zu priorisieren, auszusortieren, miteinander zu reden, über Bord zu werfen und so weiter. Also eigentlich ist das eine gute Sache, das übereinzubringen.
Oftmals ist es die Schwierigkeit, genau in diese Priorisierung zu kommen, weil dann kommt dann ein Product Owner oder ein Produktmanager, Projektleiter, was auch immer und sagt, okay, aber alle 500 Sachen sind wichtig. Ist mir egal, diese 500 Sachen müssen jetzt umgesetzt werden, no matter how and what, also nach mir die Sintflut. Und dann kommen eigentlich wir Agile Coaches wieder ins Spiel zu sagen, ja, okay, höre ich gleichzeitig können wir nicht mit einer 500-Items-Priorisierung in den Sprint reingehen. Das sprengt jeglichen Rahmen. Wir müssen uns jetzt hinsetzen und priorisieren. Dazu gibt es auch wieder Methodiken und Unterstützungshilfen, um letztendlich die entscheidende Leute dahin zu bringen, danach wirklich zu priorisieren. Und das ist meist dann eher der schwierige Part, die Leute davon zu überzeugen, dass nicht alles wichtig ist, sondern nur ein Zehntel davon meistens.
Philipp Ebnet, CGI: Genau in dem Zusammenhang kennen wahrscheinlich auch viele dieses berühmte Dreieck von wegen cheap, fast, good und dann kommt der Satz von wegen choose two out of three. Also du kannst nicht cheap, fast and good haben, sondern nur zwei davon. Was ist denn deine Erfahrung damit? Würdest du sagen, das trifft zu oder ändert sich das ein bisschen?
Nadine Schardt, CGI: Ja, das ist tatsächlich oft die Gretchenfrage und da habe ich das Gefühl, das fällt auch meisten Teams wirklich schwer und da sind wir wieder beim agilen Mindset.
Genau dahin zu kommen, ist das, einfach herausfordernd ist, einen Blick dafür zu bekommen, ein Minimum Viable Product zu entwickeln, das MVP, das gut genug ist, dass der Kunde es testen kann, aber ohne irgendwie schöne Schleifen und ohne extra Design-Ausfertigung, dass der Kunde am Ende des Tages zu sehr erschreckt.
Das heißt, wir müssen schon einen Weg finden, dass es gut genug ist. Und das ist oft schwierig, weil auch da in unserem, gerade auch, finde ich, in der deutschen Arbeitskultur, das nicht nur in der Deutschen, in manchen anderen auch, aber ich erlebe das hier halt sehr viel, wollen wir das halt immer bis zur Perfektion ausreizen. Also wir wollen halt das hundertprozentig entwickeln und entwickeln aber dann mit dieser Tendenz immer am Markt vorbei und dann entwickeln wir Produkte, die keiner will und die viel Ressourcen und Geld kosten, um sie letztendlich dann auch zu bewerkstelligen.
Ich habe da keine richtige Antwort drauf, außer dass es einfach schwer ist. Ich habe Teams gesehen, die das hinbekommen haben, die es geschafft haben zu sagen, okay, wir machen dann vielleicht nicht 100 Prozent, sondern 70 und haben verstanden, dass das vollkommen ausreichend ist. Aber da ist es oft schwierig, einen Weg zu finden.
Philipp Ebnet, CGI: Dann habe ich mir noch so ein bisschen notiert als Frage. Bei Agile Working gibt es ja zahlreiche Frameworks oder so Qualitätsmanagementsysteme. Wir alle kennen wahrscheinlich Kanban, Scrum hast du schon ein paar Mal erwähnt, aber es gibt ja auch ganz viele ISO Normen zum Beispiel, an die man sich halten kann. Wie entscheidest du denn welches Framework das richtige ist oder welches Managementsystem für das Team, das du gerade jetzt betreust, eben das ist, das du anwenden solltest. Was sind da die Kriterien, nach denen du das auswählst?
Nadine Schardt, CGI: Ich schaue da auch immer nach, was ist das für ein Unternehmen, wie die Kultur in dem Unternehmen, was haben wir für Produkte und demnach, was für ein Framework oder eine Methodik passt gut zu den Anforderungen, die da sind. Wenn du so diesen Lauf nimmst, dann kommst du am Ende eigentlich beim nuklearen Bild raus. Und auch das kann sich verändern, wenn ein Produkt zum Beispiel entwickelt wird und irgendwann muss es nur noch gewartet werden. Dann haben wir wieder andere Anforderungen, dann kann man vielleicht von Scrum zu Kanban wechseln, weil wir dann eher nur noch das Produkt warten müssen und nicht mehr neue Sachen entwickeln müssen.
Aber so gehe ich meist vor und schaue dann, was dann passend ist. Und ich glaube, das ist halt auch oft ein Schritt, der leider ausgelassen wird, sondern dass es eher so ist, okay, wir wollen jetzt irgendwie agil arbeiten, dann nehmen wir jetzt Scrum. Da aber wirklich zu schauen, was passt da wirklich und passt alles von Scrum. Oder müssen wir vielleicht Scrum-Kanban, also einen Mix machen oder fahren wir nach Safe oder was auch immer. Um halt da wirklich ganz gut zu schauen, was sind die Anforderungen, was braucht es da. Dann sparen wir uns enorm viel Arbeit hinten raus, die wir uns am Anfang machen sollten.
Philipp Ebnet, CGI: Wie gut funktioniert dieser Wechsel, wenn du zum Beispiel sagst, ja ok, jetzt ist der Punkt erreicht, wo wir, wie Du gerade gesagt hast, zum Beispiel von Scrum auf Kanban wechseln können? Wie viel Zeit würdest du für diesen Wechsel noch mal einplanen?
Nadine Schardt, CGI: Wenn das schon ein bestehendes Team ist, was schon zwei Jahre zusammenarbeitet, einen Monat maximal, würde ich sagen. Wenn ich jetzt z.B. wechsle von Scrum auf Kanban. Meistens kennen die ja schon Kanban Boards, weil wir damit in Scrum ja schon arbeiten. Also ist der Wechsel meist gar nicht so groß.
Schwieriger ist es, die Teammitglieder wirklich mitzunehmen. Weil es gibt Menschen, die tun sich gut mit Veränderungen und manche tun sie einfach schwer damit. Das ist beides völlig fein. Und wir finden in Teams natürlich alle Konstellation an Menschen und Präferenzen und Bedürfnissen. Und das ist meist der Part, immer so bisschen länger dauert. Aber sagen wir mal so strukturell und dass das Team eigentlich schon mal in dem Modus arbeiten kann, aber wenn es vielleicht noch nicht hundertprozentig akzeptiert wird, das ist schon relativ zügig, ist das schon da.
Und in dem agilen Arbeitskontext ist es ja alles so schnelllebig und so veränderungsstark eh schon, dass ich das Gefühl habe, dass dadurch die Leute schon so bisschen sensibilisiert sind für stetige Veränderung, was nicht heißt, dass sie es immer gut finden und können. Aber das geht meist recht zügig.
Philipp Ebnet, CGI: Jetzt hast du grad schon ein Thema angesprochen, was ich mir auch öfter als problematisch mal vorstellen könnte. Nämlich das, dass einfach nicht alle immer gut mit Veränderungen zurechtkommen oder manche vielleicht auch einfach, direkt sagen, dass sie keinen Bock haben so ungefähr. Wie schaust du denn, dass du die Menschen mitnimmst, die jetzt nicht hoch motiviert sind, sondern die vielleicht am Anfang ein bisschen skeptisch sind oder Bedenken haben oder sonst was. Also wie nimmst du einfach das komplette Team mit? Was ist da so deine Empfehlung?
Nadine Schardt, CGI: In der Psychologie gibt es ja auch so verschiedene Change Management oder Change Typologien. ich gucke dann schon immer, okay, wie reagieren die einzelnen Teammitglieder auf die Veränderungen? Sind es Skeptiker, sind es Befürworter, was auch immer? Da gibt es so verschiedene Kategorien, die jetzt auch immer in Steine gemeißelt sind. Und dementsprechend gucke ich dann, was braucht dann diese Gruppe, um sie mitzunehmen.
Es gibt aber auch Fälle, und das ist mir tatsächlich so, vor zwei Jahren war ich in einem Projekt richtig bewusst geworden, die tun sich so schwer mit Veränderungen, die können wir nicht mitnehmen. So, Punkt. Und das war für mich richtig hart, weil ich immer versuche, alle Teammitglieder mitzunehmen und zu schauen, dass das Team funktioniert. Und bevor ich darüber nachdenken würde, einen oder eine aus dem Team zu nehmen, muss echt viel passieren.
Ich hab aber dann in dem Projekt schmerzlich erfahren müssen, dass wenn wir zu lange wegschauen und versuchen und versuchen und versuchen, die anderen Teammitglieder auch darunter leiden. Und da waren zwei Teammitglieder in einem Team, die sich enorm schwer getan haben mit diesen ständigen Veränderungen, mit dem agilen Arbeiten. Die brauchten eigentlich eher klassisch Projektmanagement, wo sie ihren 100 % Anspruch wirklich bis zur Perfektion ausarbeiten konnten. Nur das war überhaupt da nicht gefragt.
Und da war das für mich ein riesiges Lernfeld zu sehen: Ne, ab einem gewissen Punkt müssen wir auch sagen, dass dieses Arbeitsumfeld anscheinend nicht mit den Bedürfnissen zusammenpasst, die du hast an dein Arbeitsumfeld und haben dann auch Trennungsgespräche geführt, ne, mit auch der jeweiligen disziplinarischen Führungskraft. Das war ein längerer, härterer Weg, hat mir aber auch nochmal gezeigt, dass es am Ende des Tages aber auch wichtig ist, hinzuschauen, wenn es einfach auch nicht klappt und auch mit allen Mühen, die man reingesteckt hat, auch nicht mehr veränderbar ist.
Philipp Ebnet, CGI: Gibt es dann eine Möglichkeit für mich selber, einfach offen für Veränderungen zu bleiben. Also in der letzten Folge zum Beispiel habe ich gelernt, dass ich da auch relativ leicht im Alltag dran arbeiten kann. Da war die Empfehlung zum Beispiel einfach im Alltag, wenn ich durch die Stadt laufe, einfach mal neue Wege zu gehen, die ich noch nie gelaufen bin, weil ich so dann einfach ein bisschen offen für Neues bleibe oder neue Sachen entdecken kann.
Insofern würde ich die Frage auch mal an dich weitergeben oder dir auch stellen, was sind denn so deine Tipps, wenn ich jetzt selber dafür sorgen möchte, dass ich eben für Veränderungen offen bleibe, nicht irgendwann in diesen Spruch verfalle oder in diesen Status verfalle, von wegen, ja das haben wir schon immer so gemacht und deswegen machen wir das jetzt weiter so. Was kann ich denn persönlich machen, um eben weiter offen zu bleiben?
Nadine Schardt, CGI: Finde ich auch eine gute Frage. Ich denke gerade darüber nach. Ich glaube, was mir als erstes kommt, ist, erstmal zu erkennen, dass ich vielleicht Probleme mit Veränderungen habe. Das klingt so banal. Aber in der Therapie arbeiten wir auch viel damit, dass der erste Schritt getan ist, wenn wir erkennen, dass wir veränderungsresistent sind oder ein Problem damit haben.
Und diesen überspringen wir oft und versuchen es schon zu optimieren, aber erst mal zu sagen, ich merke alle zwei Wochen komme ich an so einem Punkt, wo ich merke, ich werde auf einmal skeptisch, ich lehne mich zurück, ich fange an kritisch drüber nachzudenken oder wie auch immer sich Veränderungsresistenz letztendlich bei dir dann zeigt. Das überhaupt erst mal zu sehen, dass ich das habe, schon mal ein riesen erster Schritt und was ich eben meinte, in dem agilen Kontext ist schon so viel Veränderung, dass es uns das eigentlich schon sehr schult, immer auch bisschen flexibler zu bleiben an der Stelle.
Ich versuche als Agile Coach auch, Meetings immer wieder anders zu machen. Wir haben so ein Feedback-Meeting alle zwei bis drei Wochen, dass ich auch mal wieder ein bisschen anders strukturiere. Jeder muss mal was moderieren und auch rollierend. Ja, also dass ich die schon immer wieder auch so dahin pushe, dass die in der Veränderung bleiben. Was dann oft auch schon die Charaktere zeigt, also die, denen ich ja meisten Konflikte habe, sind dann oft die, die sich da auch im schwersten einfach mit tun, was ja auch fein ist. Also, können sie ja auch wirklich haben. Muss ja nicht jeder damit d‘accord sein oder Lust darauf haben, in so einem Umfeld zu arbeiten.
Philipp Ebnet, CGI: Dann vielleicht noch eine Frage Richtung Ende. Ich meine, wir alle kennen das, manchmal läuft die Arbeit besser, manchmal läuft die Arbeit ein bisschen schlechter. Ob das jetzt darin liegt, dass Streit im Team ist oder dass einfach die Arbeit mir gerade im Moment keinen richtigen Spaß macht oder ich mich schwer tue mit der Aufgabe, die mir gestellt wurde. Was ist denn so dein persönlicher Tipp, um die Motivation zu behalten? Um nicht eben morgens mit Kopfschmerzen oder Bauchschmerzen in die Arbeit zu gehen, sondern um auch in schwierigen Situationen weiter Durchhaltevermögen zu zeigen.
Nadine Schardt, CGI: Was ich gesehen habe und auch für mich persönlich, ist Ehrlichkeit so eins der Sachen, die super wichtig sind in solchen Konstellationen. Also das heißt, wenn ich merke, boah, ich hab grad so einen Durchhänger und grad ist es irgendwie zäh und das Projekt ist anstrengend oder was auch immer. Das ich irgendeine Form eines Ausdrucks davon finde. Also, ich in Teams auch immer wieder dazu ermutige, auch mal zu sagen, hey, es läuft grad einfach nicht gut. Und das ist okay, das darf irgendwie da sein, weil ich merke immer, sobald es dann ausgesprochen ist und angesprochen und es ist irgendwie mal auf dem Tisch, dann verändert sich was.
Schlimm ist es halt immer so, wenn man dann noch so tun muss, als wäre halt alles gut und man ist motiviert und man hat halt total Bock, obwohl man eigentlich gar keinen Bock hat und alles in einem schreit, ey, ich mach nen Laptop zu und hau ab. Das habe ich schon mehrfach erlebt, dass es einen riesigen Unterschied macht.
Also als Beispiel noch mal, vielleicht auch noch mal so als Abschluss: Wir machen ja immer jeden Tag dieses Daily, sogenannte, wo wir uns 15 Minuten lang updaten, was war gestern, was wir heute machen, wo gibt es Probleme, wo gibt es auch was Gutes. Und in einem Team fühlte sich das halt ab einem gewissen Punkt super zäh an und ich hatte irgendwie so das Gefühl, boah, bringt euch das eigentlich noch was? Also irgendwie es fühlte sich an wie: Die machen das halt, weil es auf Agenda steht, aber es bringt uns gar nichts. Weder euch noch mir. Und dann hab ich das irgendwann angesprochen und gesagt, ok, ich hab das Gefühl, das ist nur ein Punkt auf Agenda, das bringt uns gar nichts. Und dann haben die rausgehauen, wie sinnlos sie dieses Meeting gerade finden. Und wir haben gelacht darüber, wie sinnlos es gerade ist und wie lange wir das mitschleifen. Und ab dem Punkt, wo wir gesagt haben, wie zäh und ätzend das gerade ist, dann wurde es besser.
Also das ist nicht immer ein Garant dafür, aber so den Mut zu haben, eine Atmosphäre zu schaffen in einem Team, wo sowas sein darf, ist oft ein guter Katalysator, dann auch vielleicht wieder in so eine motivierte Einstellung zu kommen. Und natürlich auch mal wieder zu gucken, auf was habe ich Bock, was nicht, auf so einer anderen Ebene noch zu gucken.
Philipp Ebnet, CGI: Sich die eigenen Bedürfnisse bewusst werden oder klar machen und eben auch etablierte Prozesse noch mal zu hinterfragen. Das einfach ein wichtiger Punkt. Ja, dann danke dir Nadine für die ausführlichen Antworten. Ich nehme jede Menge mit, habe viel gelernt und vielen Dank, dass du da warst.
Nadine Schardt, CGI: Vielen vielen Dank. Vielleicht noch ganz kurz als Abschied. Das habe ich auch schon oft von Kunden gehört. Wir sind doch schon agil. Wir haben Geld investiert in Transformationen. Wir haben Leute eingestellt dafür und es läuft immer noch nicht und blamen so die Methodik dafür. Und meine absolute Empfehlung ist, lasst mal hinter euren Vorhang schauen und prüfen, ob ihr wirklich schon agil seid oder ob da nicht noch Luft nach oben ist, weil meine Erfahrung ist, genau da, wir Delivery Excellence, sind überhaupt noch gar nicht agil oder noch gar nicht da, wo sie sein könnten und ich glaube halt einfach, dass agiles Arbeiten nach wie vor das schnellste Arbeitsmodell am Markt ist, um Antworten auf KI und diese ganzen neuen Entwicklungen eine Antwort zu haben und das zu etablieren. Also, prove me wrong, dass es nicht mal was anderes gibt, was schneller ist. Deswegen lasst euch da hinter den Vorhang schauen und ja, guckt, dass ihr es verbessern könnt.
Philipp Ebnet, CGI: Genau da schließe ich mich an, wenn ihr euch hinter den Vorhang schauen, wenn du dir hinter den Vorhang schauen lassen möchtest oder auch wenn du Nadine Schardt, CGI wrong proven möchtest, dann verlinke ich dir ihre Kontaktdaten natürlich in den Show Notes und sie freut sich über deine Nachricht und ich sag an der Stelle vielen Dank, dass du zugehört hast und wenn es dir gefallen hat, dann like und subscribe den Podcast gern, damit du keine Folge verpasst. Ich freue mich natürlich schon auf das nächste Mal und bis dahin sage ich Tschau, wir hören uns.
Philipp Ebnet moderiert den CGI-Podcast „Digitalwandler“ und spricht mit Gästen darüber, wie digitale Veränderungen in der Praxis gelingen. Fragen, Feedback oder Themenwünsche können Sie ihm per E-Mail senden oder sich auf LinkedIn mit ihm vernetzen.
