Happy Birthday lieber Podcast, Happy Birthday to you. Ja meine Lieben, der Podcast wird am 18. April ein Jahr alt und das wollen wir feiern. Drum gibt es diese Woche jeden Tag eine neue Folge. Das nenne ich doch mal einen Geschenke-Regen. Genießt die Folgen und auf ein schönes weiteres Podcast-Lebensjahr. Hallo und herzlich willkommen zu einer neuen Folge vom Podcast Software Testing. Ich bin euer Host Ritschi und hier wieder live vor Ort auf der OUP 2024 in München. Bei mir zu Gast
Ina Einemann. Sie hat hier das Vortragsthema "Komm mir nicht mit Fachlichkeit". Das hat mich natürlich interessiert, was da dahinter steckt. Wir sprechen dabei, wie wir gute Anforderungen erheben können, welche Methoden es dafür gibt, wie wir alle Beteiligten dazu zusammenbekommen und warum
Scrum nicht das Allheilmittel ist. Ja und wie immer an dieser Stelle freue ich mich natürlich über euer Feedback direkt an mich an [email protected] und wenn euch der Podcast gefällt, dann hinterlasst doch bitte ein Like auf YouTube oder eine Bewertung auf Apple oder Spotify. Ich danke euch schön und wünsche euch viel Spaß bei der Folge. Hallo Ina, schön, dass du da bist. Hallo Richard, schön, dass ich hier sein darf.
Ja, finde ich super. Wir sind ja hier auf der OUP 2024 in München, wieder mal zu einer richtigen Zeit. Die große OUP. Ich weiß nicht, warst du schon öfter hier? Ich war schon einmal hier vor Ort und während Corona online dabei und bei der Sommer-OOP war ich. Das war ja eine andere Location. Genau, da war sehr, sehr kurz und diesmal habe ich ein bisschen mehr Zeit eingeplant. Die Sommer-OOP war meine erste und da habe ich schon gehört, das ist nicht so das richtige
Format, aber ist okay. Ja und jetzt sind wir wieder im richtigen Setting hier. Ja genau und doch, es macht auch Spaß wieder hier zu sein und ich finde es auch schön, wenn man so ein bisschen Zeit hat, auch mal andere Vorträge mitzumachen. Jetzt hier Mitte zum Beispiel aufzunehmen, dass man nicht nur einfach anreist, also aufnimmt oder einen Vortrag hält und wieder abreist. Genau, sehr schön jetzt. Netzwerken kann auch. Genau, das gehört ja dazu.
Sehr schön. Ja, ich habe dein Abstract im Vorfeld gelesen und da ist ja schon sehr provokant drin, so bleib mir weg mit Fachlichkeit und dann so das Thema, ja Scrum ist vielleicht doch nicht so das goldene Ei. Ja, genau. Also es gibt vielleicht noch ein bisschen was, was man besser machen kann daran. Ja, und da habe ich mir gedacht, das ist immer schön, dass man da mal auch mal den kritischen Blick drauf werfen und was kann man
denn besser machen. Darum habe ich dich auch gerne eingeladen hier. Ja, würde ich sagen, starten wir einfach rein. Ja, sehr gerne. Bleib mir weg mit Fachlichkeit. Warum? Komm mir nicht mit Fachlichkeit. Ach, komm ich weg. Genau. Der Sinn ist ja der gleiche. Genau, ja also es geht ja in die Richtung, dass sich Scrum sehr, sehr auf Delivery fokussiert
und den Discovery-Bereich einfach völlig außer Acht lässt. Also Scrum geht einfach von einem fertigen Backlog aus, dass da die priorisierten Anforderungen drin sind und das Scrum-Team dann fröhlich umsetzt und da natürlich auch Feedback bekommt, aber irgendwie wie kommen jetzt eigentlich diese Anforderungen wirklich in das Backlog? Klar steht Verantwortlichkeit drin, der Product Owner
ist ja auch extra vage gehalten. Scrum-Rant sagt ja auch selber, also ich meine in den 19 Seiten kann man nicht komplett alles abdecken und keine Probleme mehr im Projekt haben, aber ja da den Fokus drauf zu setzen, wie kriegen wir überhaupt ein gutes Backlog, welche Methoden können uns da unterstützen und auch wie kriege ich sehr, sehr schnell Feedback von meinem Kunden, weil da eigentlich ja gegensätzliche Ziele verfolgt werden. Wir wollen einerseits sehr, sehr schnelles
Feedback. Scrum fokussiert sich aber sehr auf das auslieferbare Produkt-Inkrement, was natürlich auch einen Qualitätsanspruch hat, wenn ich das ausliefern will, dann muss es auch qualitativ fein sein und das widerspricht sich ja mit ich will super schnell Feedback haben und da einfach den Fokus drauf zu setzen, wie schaffe ich das schnell Feedback zu bekommen, wie bin ich meinen Kunden ein, wie bekomme ich das hin, dass ich da jetzt noch nicht das qualitativ mega durchgebaut
habe, ausliefer und dann erst erfahre, ja aber ich will es gar nicht haben, also der Kunde braucht es nicht, es hat keinen Nutzen. Also wirklich sich auf den Outcome zu fokussieren und nicht nur auf dem Output. Okay, also ein zu starker Fokus ist bei dem Thema, was liefert dann Scrum und du willst den Fokus auf das Davorlegen. Ja, genau. Was kommt dann eigentlich überhaupt rein ins Backlog?
Was kommt rein, genau, aber da natürlich jetzt kein Mini-Wasserfall aufzubauen, so zu sagen, so jetzt testen wir das und dann geben wir diese Ideen ein, sondern das wirklich als gemeinsames
Team zu betrachten, was gemeinsam lernt, wie der Kunde tickt. Also wirklich zu überlegen, ja also welche Ideen haben wir, was könnte dem Kunden hilfreich sein, welche, was für eine Wirkung hat auch dieses Feature, also nicht einfach nur zu gucken, jetzt noch ein Feature, noch ein Feature, noch ein Feature, sondern auch zu schauen, setzt er das wirklich ein und was löst sein Problem und das gemeinsam als Team zu üben oder zu lernen, weil wir wollen ja,
genau, also die Innovationen kommen halt auch oft aus dem technischen Bereich, also da jetzt nicht einfach die Fachlichkeit im Fachbereich zu lassen, der da mit dem Kunden spricht, sondern wirklich in Kombination mit dem Team zu einem guten Ergebnis zu kommen und
gemeinsam coole Ideen zu brainstormen. Dafür muss aber das, also auch das technische Team, die Entwickler, ja ein Input oder also einen Einblick haben, welche Probleme hat überhaupt der Kunde, also was könnte ihm hilfreich sein, welche Probleme möchte ich lösen und deswegen kommen wir nicht mit, das ist natürlich gerundschweigend, klar kommen wir genau, kommen wir ganz viel Fachlichkeit, ich möchte eine Fachlichkeit verstehen, wir müssen aus
diesem, ja von diesem fachlichen Bereich kommen, sonst verstehe ich dein Problem nicht und setze einfach nur um. Dann bin ich einfach nur, also jetzt ganz böse gesagt, "Guck, manki, nimm mir das nächste Backlog-Item, setz es um, ist mir egal, ich verstehe es fachlich nicht." Und dass man da aber hinkommt, als Team gemeinsam den Kunden zu verstehen und zu lernen und dann auch fachlich getrieben, also Domain-Driven-Design spielt da auch rein, fachlich getrieben umzusetzen.
Ich finde, das setzt ja an einem ganz wichtigen Punkt an, weil also das ganze Agile möchte ja eigentlich den Kundennutzen nach vorne stellen. Ja, genau. Es muss für den Kunden sein, wir wollen nichts zum Selbstzweck machen, wir wollen, dass alles nur den Kundennutzen einzahlt, aber sich kümmern darum, was der eigentlich will,
tut man dann im Prozess relativ wenig. Genau, also klar sind da diese Feedback-Loops auch drin, es gibt ja auch, also klar, es steht ja auch so im Scrum Guide, dass im Review der Stakeholder dabei ist und Feedback gibt, dass es auch ein Arbeitstermin ist, in dem dann wieder
mit dem Backlog, dass das wieder gemeinsam überarbeitet wird. Erstmal erlebe ich wenige Teams, die das wirklich so leben, also nicht mal diese paar Sachen, die dort drin stehen, werden so umgesetzt und dann ist es halt mit diesen unterschiedlichen Zielen, wenn ich das ja schon auslieferbar gebaut habe, ist es ja schon qualitativ im besten Falle sehr hochwertig. Und da ist einfach wirklich ein Verständnis, okay, wir wollen vielleicht das schon was
verproben, ohne direkt in die Entwicklung zu gehen. Also wie kann ich mit einem Papierprototypen, kann ich mit einem Interview, wie kann ich Ideen auslotsen, ohne direkt in die Entwicklung zu gehen. Aber jetzt nicht, wie gesagt, das jetzt vorgeschaltet als eigenes Team, sondern
als gemeinsames Team zu lernen. Also klar sind das dann UX-Experten und Co., die da, also ich möchte, die Entwickler haben genug zu tun, ich möchte jetzt nicht, dass die auch noch Interviews die ganzen Tag führen, aber dass die mitlernen, was der Kunde überhaupt möchte, also dass sie, ja, Teil des, also das einfach Teil des interdisziplinären Teams ist. Ja, also das ist, ich glaube, das hat ja auch eine besondere Wichtigkeit, weil an diesem Thema arbeiten wir uns in der Softwareentwicklung
ja schon seit Jahrzehnten ab. Wie kriege ich das, was im Kopf dessen ist, der sich was vorstellt, zum einen in irgendeine Form, dass ich das in das Team reinbringe, also dieser Transfer von der fachlichen Idee hin hin zu einer technischen Umsetzung. Das ist eben dieser Medienbruch, an dem wir uns ja schon über, mit UML abgearbeitet haben, mit allen Requirements-Modellen, mit Business-Analysen, mit allem. Jeder versucht da irgendwie diesen
Gap dahin zu lösen. Genau, genau. Und oft wird es dann halt noch weiter auseinandergezogen. Also ja, UML ist wahrscheinlich auch schnell, also noch schnell genug zu lernen, aber wir setzen dann halt eher auf Methoden wie Event-Storming oder Story-Mapping, wo man wirklich gemeinsam in einem Raum mit Stickys mal schnell ins Tun kommt, dass man selbst schnell die Events stormt oder die Tätigkeiten stormt. Was mache
ich jetzt hier eigentlich als Benutzer? Also da gar nicht erstmal UML lernen muss, sondern wirklich ich komme direkt ins Tun. Die Entwickler und die User sind in einem Raum und sprechen miteinander und alleine durch diese Interaktion wird da schon ein gemeinsames Verständnis aufgebaut. Also damit starten wir super gerne, also solche Workshops überhaupt erstmal, um in diese Fachlichkeit reinzukommen, um irgendwie ein Big Picture zu bekommen. Aber
dann ist halt die Schwierigkeit, das kontinuierlich beizubehalten. Also nicht nur einmal, wir haben jetzt, also ich glaube, das kann sich jeder gut vorstellen, am Anfang diesen Kick-Off und das ist halt ein super Start, aber dass man dann auch kontinuierlich überlegt, wie
integriere ich dieses kontinuierliche Discovery in meinen Prozess? Und das ist halt nicht immer einfach nur getan mit "Ich arbeite die obersten Backlogs ab und habe dafür ein Verständnis", sondern ich lerne auch über den Kunden weiterhin über die Domäne und was er braucht und in welchem Problemraum er da unterwegs ist. Lass uns da nochmal am Anfang bleiben bei diesen Workshops, so Events, Storming, Story Mapping hast du gesagt. Kannst du die zwei Methoden nochmal ein bisschen im Detail für
uns, weil nicht jeder kennt die. Wie funktioniert so etwas? Also der Start ist eigentlich erstmal identisch. Man näht wirklich alle Beteiligten, also User, Product Owner, Business Owner und die Entwickler, die technische Perspektive, dass man alle Perspektiven in einem Raum hat. Also ich sage wirklich auch in einem Raum, weil ich da ein großer Fan bin, diese Workshops wirklich physisch an einem Stelle und Ort durchzuführen. Ich finde nicht, dass die gleichen Diskussionen entstehen, wenn man
das digital macht. Kann es durchaus probieren, aber es ist meiner Meinung nach nicht annähernd das gleiche Ergebnis, weil wir einfach wirklich, wir nehmen dann Stickys. User Story Mapping ist so, dass wir die Tätigkeiten sammeln, erstmal auf einer sehr hohen Flughöhe und dann immer kleiner runterbrechen. Also wenn wir jetzt einfach, keine Ahnung, als Beispielprozess irgendwie morgens aufstehen nehmen, dann würde jetzt die oberste Reihe ist, ich gehe ins
Badezimmer, ich esse was und ich verlasse das Haus. Also wirklich sehr hohe Flughöhe. Dann wird nochmal so runtergebrochen, was man vielleicht im Badezimmer macht. Also ich ziehe mich an, ich ziehe mich aus, ich gehe duschen. Und dann nochmal wirklich die einzelnen Tätigkeiten, also wirklich nochmal kleiner, ich gehe in die Dusche, ich nehme mir Shampoo
in die Hand. Also dann wirklich ganz, ganz fein granular. Und das kann ich jeweils untereinander sortieren und also erstmal sammeln, dass ich ein gemeinsames Verständnis habe, so das ist der Überprozess und da gehören diese Tätigkeiten zu. Und dann kann man sehr gut die innerhalb ihrer Spalte, nenne ich es mal, priorisieren, damit man einfach ein gemeinsames Verständnis hat. Ich brauche auf jeden Fall, wenn ich das Haus verlasse, dass ich mich
angezogen habe. Vielleicht kann ich darauf verzichten, dass ich mal an dem Tag meine Haare gewaschen habe. Das priorisiere ich eher runter. Das ist jetzt nicht so wichtig, das nutze ich nicht so oft. Also nackt gehe ich nicht aus dem Haus, um das auf diesen Beispielprozess zu mappen. Und dann so priorisiere ich jede Tätigkeit für sich hoch, versuche aber wirklich von vorne bis hinten einmal das gesamte Produkt, dass ich da durchgehe, dass ich wirklich dann
einen kompletten Durchstich habe. Und dann hat man eigentlich seinen Backlog direkt zweidimensional aufgebaut. Also man sieht dann, was man nach oben gezogen hat, was wir definitiv als erstes umsetzen, hat schon direkt einen Task, ist dann eigentlich so eine User Story, man kann das teilweise zusammenziehen. Und dann gehe ich halt die nächste Ebene an, wenn ich die Ebene umgesetzt habe. So hat man halt wirklich auch ein gemeinsames Verständnis, was es hier
jetzt wichtig ist. Also Storymapping arbeitet sehr gut in ein fertiges Backlog. Event-Storming startet ähnlich, aber da starten wir vom Kleinen und sammeln Events, die fachliche Events, die in der Anwendung passieren. Kommen auch noch weitere Farben an Stickys dazu, die dann die Personen, die externen Systeme, die Commands und sowas beschreiben. Und dann
kann ich sehr genau meinen Prozess modellieren und danach auch schneiden. Und Event-Storming zahlt sehr darauf ein, dann einen guten Service-Schnitt und da aufbauend ja auch einen guten Teamschnitt zu finden. Und das nutzen wir sehr, sehr gerne, um überhaupt zu starten, auch bei großen
Projekten, um wie gesagt direkt einen guten Teamschnitt zu finden. Oder wenn wir Altanwendungen übernehmen und modularisieren wollen, um dann mit Event-Storming eine gute Modularisierung, also dann halt technisch getrieben, dahin zu kommen. Was ist denn so ein Beispiel für so ein Event? Rechnung wurde verschickt oder Auftragsbestätigung wurde verschickt. Also es ist in der Vergangenheit formuliert, weil bei einem Event geht man davon aus, das ist passiert. Also es kann
nicht mehr schiefgehen. Also die Rechnung ist definitiv verschickt worden. Später kommen nämlich noch die Commands, die sind dann im Präsens formuliert. Und da merkt man, okay, es gibt jetzt einen Happy Pass, aber es kann halt auch mal was schiefgehen. Und deswegen
dann formuliert man genauer den Prozess. Aber im ersten Moment, bei dem ersten Big Picture Workshop ist man auf einer höheren Flughöhe unterwegs und da sind dann auch erst mal nur die Events dabei, um einfach genau dieses gemeinsames Verständnis zu bekommen, was passiert überhaupt in der Anwendung. Und jetzt, also so wie ich es verstehe, bei diesen Workshops, also da geht es ja schon ganz massiv um die Fachlichkeit, das Big Picture auch, das Ganze dann runterzubrechen
oder aufzubauen. Da sind jetzt, quasi so wie ihr das macht, auch dann die Techniker schon mit dabei. Also das ganze Team, die dann auch das schon verstehen können, was denn da eigentlich passiert. Genau. Also im besten Falle ja. Klar gibt es immer mal, dass zu dem Zeitpunkt noch gar nicht steht, welches Team jetzt die Entwicklung übernimmt. Wie gesagt, es ist ja auch um den guten Teamschnitt zu finden. Also vielleicht ist noch gar nicht klar, wie und wer das jetzt
übernimmt. Aber uns ist schon wichtig, dass da definitiv die technische Expertise dabei ist. Und ja, also so, wenn hier schon mal ein, zwei, drei Entwickler stehen, die sollten definitiv dabei sein. Man kann nachher die Event-Storming Map oder auch die Story Map benutzen, um dann wieder in die Fachlichkeit reinzukommen. Also das kann natürlich auch dann erläutert werden. Aber was das wirklich wertvolle ist und deswegen bin ich auch kein
Fan von den virtuellen Workshops, sind halt wirklich die Diskussionen dabei. Und da zu merken, okay, jetzt hier haben die beiden Usern ein anderes Verständnis von der Begrifflichkeit und da gibt es Unterschiede, wie die das definieren. Und diese Diskussion mitzubekommen, das ist eigentlich das Wertvolle. Wenn man da nachher nur noch einmal durchgeführt wird, hat das auch einen Wert, aber nicht den gleichen. Das ist ja, also ich finde, das ist ja mal ein guter Aufschlag. Auch gerade hier mit
den Technikern, das ist ja das, was wir auch wollen. Aber du hast ja vorher noch was Spannendes gesagt. Und zwar, dass dann auch im Regelbetrieb, wenn das dann alles in der Umsetzung ist, immer wieder da auch wieder den Feedback-Mechanismus zu schaffen oder das wieder mal aufzumachen. Wie macht ihr denn das? Genau, also das, da gibt es, also man kann natürlich immer mal wieder, weil wir ja die einzelnen Prozesse dann genauer modelliert haben, auch immer wieder auf diese Teile raufschauen
beim Event-Storming. Also gerade das Process Modelling, da kriegt man mich dann so langsam in das digitale Tool, dass man das dann vielleicht auch auf Miro und sowas macht, weil das ist sehr, sehr mühselig, das alles mit Zettelchen hin und her zu kleben. Und dann kann man sich diese Teile natürlich auch immer noch mal wieder gucken, passt dieses Modell noch, was wir da gemacht haben, entspricht das noch der Fachlichkeit, löst das noch unsere Probleme?
Also da regelmäßig immer noch mit dem User in Interaktion gehen. Aber da nutzen wir auch gerne andere Methoden, also dass man wirklich, ja wie gesagt, Interviews macht, dass wir ein Gamba-Walk, also dass man wirklich vor Ort schaut, wie wird denn jetzt die Software eingesetzt, dass man Verständnis bekommt, wo könnten da vielleicht die Probleme sein, wo macht er ein Workaround, den ich sonst gar nicht weiß. Also mit dem Anwender quasi.
Genau, ja, ja, dass man dann wirklich vor Ort ist und einfach noch mal mitkriegt, wie das dann wirklich genutzt wird und das halt immer noch mal hier und da einplant. Also das ist halt die Schwierigkeit und was halt auch irgendwie zum fachlichen Kontext und zum Team-Partner,
also natürlich nicht jede Anwendung kann man einfach vor Ort sich anschauen. Vielleicht habe ich auch manchmal, wo ich eher den End-User schlecht zu greifen kriege, aber vielleicht kriege ich irgendwie eine Abfrage im System hin, dass man darüber so eine Art, ja, Fragebogen-Interview-Technik hat, ja, dass so den End-User so weit wie möglich in meinen Prozess einbinden und dass er offen für diese Experimente ist.
Das ist, also das finde ich auch, ist ja total schön, das Ding mal zu sehen, wie wird denn das eigentlich genutzt, weil da merkt man erstmal, was dann eigentlich der End-Anwender auch wirklich dann so fabriziert und die haben ja manchmal ihre Workarounds im Alltag, mit denen die dann irgendwas umschiffen oder die Zeit totschlagen oder sonst irgendwas, einfach zu ihrer Lösung zu kommen. Das kriegt man im Entwicklungsteam ja gar nicht so.
Richtig und da so ein Verständnis für zu entwickeln. Und dann ja auch, dann haben ja auch, das meinte ich vorhin mit, aus der Technik kommen dann ja auch viele Innovationen oder die Ideen, die haben dann ja auch Wissen, was machbar ist und können entsprechend einfach, also ja, dann sagen, okay, du nutzt das Feature gar nicht oder so, also jetzt verstehe ich erst, wie es eigentlich gedacht war und machen dann einfach eigene Vorschläge und also haben
dann Ideen, wie man es umsetzen kann. Und dann gerade da ist es halt hilfreich, dass dann ja die verschiedenen Perspektiven drauf tauchen. Was empfiehlst du denn da für einen Zeitraum? Also jetzt ist ja, die machen da ihre Sprints und machen da so vor sich hin. Wie oft sollte man denn da so einen Feedback-Loop auch mit integrieren? Man kann ja nicht ständig beim Kunden sitzen oder beim End-Anwender. It depends, typische Berater-Antwort.
Ach schön, da war ja immer ein Euro für jedes Mal, wenn ich das höre. Noch nie gefallen wahrscheinlich der Begriff hier im Podcast. Ja, aber es ist wirklich, so viel wie nötig. Also wir wollen, ich hatte ja vorhin schon gesagt, keine Angst, die Entwickler sollen jetzt nicht die ganze Zeit beim Kunden rumhängen, die haben genug zu tun. Aber gerade dann ist es ja umso wichtiger, dass sie sich auf die richtigen Dinge fokussieren und wir
nichts bauen, was keiner braucht. Und wie gesagt, die brauchen entsprechende Unterstützung von Fachexperten oder von UX-Designern, die dann zum Team dazugehören und das kontinuierlich mitmachen. Aber so ein normales Scrum-Team, also wenn da so ein, zwei Personen schon diesen fachlichen Fokus haben und dann nach Bedarf jeweils die Unterstützung von den Entwicklern kriegen, aber halt auch da gemeinsam dann auch beim Review zeigen, was sie gelernt haben
im letzten Sprint oder beim Daily sich austauschen, welche Experimente sie jetzt angehen. Das ist ja dann das kontinuierliche Lernen, auch ohne dass der Entwickler das jetzt selber die ganze Zeit machen muss. Das wäre schon der Invest, dass die ganze Zeit so ein, zwei Personen auch diese Brille aufhaben parallel und diese Sachen anstoßen und dann auch mal gerne größere Sachen planen, wie jetzt fahren wir mal alle gemeinsam vor Ort und schauen
uns das mal an. Das macht man ja nicht ein bisschen, sondern unsere Kollegen waren dann auch mal wirklich in den Produktionshallen, schauen sich das wirklich an, wie die Software im Einsatz ist. Das ist dann ein größerer Block, wo man ein bisschen mehr Zeit einplanen muss, aber es gibt auch immer so einen Schub, wo dann wirklich danach neue Ideen kommen, neues Verständnis. Ich glaube, das ist auch ein wichtiger Punkt,
das zu argumentieren. Also ich kenne einige Entwickler, die finden sowas super, die wollen das, aber es gibt natürlich einige, die sagen, komm, lass mich in Ruhe damit. Ja, der Vortrag war ja gestern und da gab es auch viel Rückfragen in Richtung, ja, sehe ich und verstehe ich, aber ich habe Kollegen, die interessiert das nicht, die wollen sich
ganz tief in die Technik einwillen, die wollen die Fachlichkeit gar nicht so verstehen. Also da finde ich es unglaublich wichtig, ein gemischtes Team aufzubauen, weil du halt einmal auch wirklich diese neugierigen fachlichen Kollegen da drin hast. Also ich, wie auch nicht jeder sich tief ins Backend eingraben kann oder ein mega Frontend-Experte sein kann, finde
ich es da halt auch wichtig, dass es Experten jeweils gibt. Ich glaube nicht, dass jeder alles, oder es kann auch einfach, dafür ist es viel zu breit, was eine Person da leisten müsste, aber es ist halt wichtig, trotzdem dieses Verständnis zu haben, so okay, es ist wichtig, dass wir das Richtige bauen und dafür gibt es diese Leute in meinem Team und die sind genauso wichtig, die verhindern, dass ich irgendwas baue, was keiner benutzt.
Also eigentlich darüber kriegt man auch diese Skeptiker, weil keiner möchte was bauen, was keiner benutzt. Auch wenn es noch so viel Spaß macht und es technisch herausfordernd ist, aber wenn es danach keiner nutzt, damit kriegt man sie dann eigentlich. Dann sehen sie schon den Wert, okay, wenn ich es nicht selber machen muss, aber ich verstehe, dass es wichtig ist, das abzuklären. Ja, ich glaube, das muss man schon bedacht bedenken, dass
man die auch da ihrer Stärke dann auch mit einsetzt und mitnimmt. Genau, ja. Und also da würde ich wie jedes interdisziplinäre Team einfach schauen, dass einfach alle Sachen vertreten sind. Ja klar, wenn man jetzt nur so ein technisches Nerd-Team, nenne ich es jetzt mal, ein bisschen provokant hat, dann wird es ein bisschen schwierig. Dann fehlen da vielleicht noch so ein paar Skills, die man zum Team hinzufügen müsste. Also, dass
man da einfach eine Mischung hat. Also die gemischten Teams haben wir bei uns jetzt auch. Die ticken nicht alle gleich, meine Kollegen. Was würdest du denn gerne dann nochmal ausprobieren? Also wo du sagst, du hast jetzt so viel Erfahrung auch mit diesen Workshops und mit der Begleitung, hast du so eine Idee, wo du sagst, das nächste Mal probiere ich das? Was probieren? Also ich finde immer, das ist nicht nur ein Probieren, aber ich bin halt wirklich ein Fan von diesen
Gamba-Walks. Es ist halt auch immer sehr, sehr aufwendig, das zu organisieren, je nach Umfeld. Aber da will ich halt, dass man da vielleicht wirklich noch mehr den Fokus drauf legt, sobald das möglich ist, dass man das auch wirklich für das ganze Team organisiert
und da gemeinsam hinfährt. Also, dass man, ja, das ist halt oft das Aufwendigste und dass man da das nicht aus den Augen verliert, sondern da wirklich sagt, nee, das ist sehr, sehr wichtig und das machen wir auf jeden Fall so und so oft, dass wir da hinfahren. Je nach Umfeld, je nach Fachlichkeit, aber ja, da würde ich gerne noch mehr den Fokus drauf setzen, weil ich da immer merke, dass danach wirklich eine andere Energie herrscht.
Und was wir letztens auch in einem Team gemacht haben und was man viel häufiger auch, ist halt wieder das gleiche Thema, muss man fest einplanen, war so ein kleiner, interner Hackathon, wo einfach dann, nachdem die Kollegen die Fachlichkeit, ja, den Problemraum und sowas verstanden haben, sich dann selber mal überlegen konnten, was für Features würdet ihr denn
umsetzen und die auch dann einfach, ja, runtergehackt haben. Und da kam super Feedback von den Kunden, was da auf einmal für Probleme gelöst wurden, was, ja, die gar nicht jetzt so im Fokus hatten und auch nicht wussten, dass das so schnell umsetzbar ist. Also klar muss dann hier und da, um es wirklich auslieferbar zu bekommen, nochmal nachgearbeitet werden. Aber das, also das fördert auch nochmal dieses, wirklich die Innovation, die Ideen auch aus dem technischen
Raum wieder zurück in die Fachlichkeit zu kriegen und das öfter einzusetzen. Das war auch cool. Ja, super. Vielen Dank für diese Inspiration. Das finde ich, da war ganz ein Blumenstrauß drinnen von Dingen, die man gut umsetzen kann und die man mal ausprobieren kann. Also kann ich auch nur jeden, der das hört oder sieht, einfach inspirieren, motivieren, das mal zu tun und mal zu schauen, was da rauskommt, das Experiment zu starten. Ich glaube, das kann viel bringen.
Gerne. Ina, ich danke dir sehr, dass du hier Rede und Antwort gestanden hast zu dem Thema. War ganz schön. Ich habe selber auch gut was mitgenommen davon. Das ist für mich immer so ein Indikator, dass es gut ist. Ich danke dir schön. Ich wünsche dir noch ganz viel Spaß auf der Konferenz. Danke schön, dir auch. Danke, dass ich hier sein durfte. Ja, gerne. [Musik]