Transcript
Anja: Hallo und herzlich willkommen zum INNOQ Podcast. Mein Name ist Anja Kammer und ich spreche heute mit Lena Kraaz darüber, wie man die Orientierungsphase für Teams gestalten kann, die sich neu gebildet haben oder wenn es Umstrukturierungen gab. Hallo Lena.
Lena: Hallo.
Anja: Lena, erzähl doch mal, warum wir heute miteinander über dieses Thema sprechen.
Lena: Hallo. Ja, tatsächlich ist das ein Thema, was uns häufig beschäftigt, dass wir ja aufgrund dessen, dass wir in einem Unternehmen arbeiten, das in vielen verschiedenen Kundenprojekten tätig ist, wir häufig in neuen Konstellationen uns wiederfinden, also in verschiedenen Projekten mit anderen Konstellation, also wir in verschiedenen Gruppen zusammenarbeiten, die Kollegen und Kolleginnen zusammenarbeiten, und schon dadurch immer wieder in einer neuen Gruppe uns finden von Menschen, mit denen wir dann für dieses Projekt eben zusammenarbeiten. Und man kann sich vorstellen, dass das die eine oder andere Herausforderung mit sich bringt. Das ist auch super, das hat auch ganz viele Vorteile. Aber es gibt eben auch bestimmte Herausforderungen, die dabei immer wieder auftreten.
Anja. Und bei deiner täglichen Arbeit siehst du auch diese Herausforderung besonders, denn du bist ja auch dafür zuständig, dass Teams effektiv arbeiten können.
Lena: Genau. Ich arbeite häufig im Projekt als Scrum Master oder Agile Coach. Da kümmere ich mich darum, wie Anforderungen entstehen und wer mit wem sprechen sollte und deswegen fällt mir das tatsächlich oft auf, bzw. habe ich dann oft damit zu tun, einen Weg zu finden, wie diese Teams gut zusammenarbeiten können, obwohl sie zusammengewürfelt wurden, noch nie miteinander gearbeitet haben und auch manchmal sehr verschiedene Arbeitsweisen haben.
Anja: Ja, ich sehe das auch aus meiner eigenen Praxis als einer dieser Personen, die eben zusammengewürfelt werden und in diesen Teams dann reingeworfen werden. Und deswegen haben wir uns auch gefunden, weil wir beide dieses Problem gesehen haben. Also ich habe dieses Problem auch gesehen in den Teams, dass wenn man vorher nicht darüber spricht, wie man so miteinander arbeiten möchte. Wenn man keine Orientierungsphase hat, sondern einfach nur in ein Team geworfen wird und dann fängt man ab Tag eins an, das erste Ticket zu übernehmen, dann weiß man gar nicht, wie die anderen so ticken. Dann passiert es häufig, dass die Arbeit einfach erledigt wird und man sich dann wundert, wie sie erledigt wurde, wenn man einfach nie darüber gesprochen hat, wie man eigentlich gemeinsam zusammenarbeiten will und gemeinsam an Software arbeiten möchte.
Lena: Ja und ich glaube, dass am Anfang oft alle denken, dass man zu vielen Dingen eine gemeinsame Haltung hat und das eigentlich ähnlich sieht. Und das denkt man dann genau so lange, bis einem halt auffällt, dass es doch nicht so ist. Und ich glaube, diese Kommunikation darüber oder, was wir auch gleich vorstellen, das dient sozusagen dazu, das aufzuschreiben und zu sagen, ich stelle mir das eigentlich so vor. Dinge, die man aufschreibt, über die kann man sich dann noch einmal unterhalten und man merkt, wir hatten ja doch nicht das Gleiche.
Lena: Was wir auch gleich vorstellen, das dient sozusagen, dem das auch aufzuschreiben und zu sagen, ok, ich stelle mir das eigentlich so vor und die Dinge, die man aufschreibt, über die kann man sich dann auf einmal unterhalten und man merkt so, ah, wir hatten ja doch nicht das gleiche Bild im Kopf davon.
Anja: Genau, wir haben nämlich einen Workshop erarbeitet. Ein Workshop, den man zu einem Projektstart durchführen kann mit Teams, die eben neu zusammengewürfelt wurden. Oder stellen wir uns halt auch vor, es gab eine Restrukturierung, Umstrukturierung. Sehr viele, also sehr viele Teammitglieder sind neu oder eben neu zugeordnet worden. Und dann lohnt sich so eine Art von Workshop, den wir uns da ausgedacht haben.
Lena: Genau, das ist so ein initialer Workshop, der natürlich bei uns besonders oft zum Tragen kommen könnte, weil wir uns oft in neuen Teams finden. Wenn man irgendwo arbeitet, wo man eigentlich lange Zeit mit demselben Team zusammenarbeitet und lange Zeit in demselben Projekt ist, dann wird sich die Gelegenheit nicht so oft bieten wie bei uns, aber auch da macht es durchaus Sinn, wenn sich an der Konstellation was ändert oder wenn man halt gemeinsam startet, das zu tun.
Anja: Genau, also es ist ja oftmals so, wenn Leute neu in ein Team reinkommen, wenn es jetzt nur Einzelpersonen sind, dann passiert es ja auch häufig, dass sie an den Prozessen, also Kritik haben ist jetzt ein bisschen zu dolle, aber Verbesserungsvorschläge haben. Und das alles kann man gut abfedern oder einsammeln, indem man von vornherein, immer wenn neue Leute ins Team kommen, einfach noch mal neu einen Orientierungsworkshop für das Team macht. Dann sieht man nämlich gleich, ah, die neue Person hat die und die Ideen oder kommt aus der und der Richtung. Alle anderen kommen aus einer anderen Richtung, haben die ganze Zeit anders gearbeitet. Dann kann diese neue Person dann auch in Kontext setzen, ah, deswegen machen die das. Ah, jetzt verstehe ich das. Und dann kommen vielleicht auch weniger Vorschläge oder weniger Kritik.
Oder man weiß, hey, die neue Person hat eine komplett andere Sichtweise, die finden wir gut, vielleicht wollen wir die übernehmen.
Lena: Ja, genau, also das stimmt, was du sagst. Das ist tatsächlich ja oft so, dass eine neue Person reinkommt und dann fragt, warum macht ihr das denn so, wie ihr das macht. Und dann ist es manchmal auch super schwer, das zu beantworten aus dem Stehgreif, weil das halt irgendwas ist, was irgendwie gewachsen ist, auch mit dem Team. Und das stimmt, tatsächlich diese allgemeine Verwunderung, die da manchmal entsteht, kann man mit so einem Workshop halt super abfangen. Ja, stimmt.
Anja: Gut, aber jetzt wollen wir endlich dazu kommen, wie dieser Workshop denn aussehen sollte. Also, ich würde sagen, alle treffen sich gemeinsam in einem Raum, sei es jetzt nun ein virtueller Raum oder ein physischer Raum.
Anja: Und wir haben etwas zum Dokumentieren, also in physischen Räumen, Papier, irgendwelche Pin-Wände, alles, um gemeinsam sozusagen zu dokumentieren, was man sich für das Team wünscht und vorhat. Und in einem virtuellen Raum sei es so ein Online-Whiteboard, das reicht ja dann auch vollkommen aus.
Lena: Genau. Und dann, wenn man diesen Workshop zusammen macht, dann, wie Anja gerade schon gesagt hat, vor Ort oder remote, alles ist möglich. Es ist wichtig, dass alle dabei sind. Es ist die Frage, wer ist alle? Dann muss man nochmal über die Konstellation reden, denn es gibt natürlich das IT-Entwicklungsteam. Es gibt vielleicht Leute, die nicht ganz eindeutig dem zuzuordnen sind, die schon mit dem Team auch arbeiten, aber vielleicht nicht täglich oder die so ein bisschen weiter weg sind. Das muss man dann einfach gucken. Wer macht da mit? Im Grunde genommen würde ich erstmal das Kernteam nehmen und damit würde ich erstmal starten und dann könnte man das sicherlich auch noch ein bisschen ausweiten, je nachdem was Sinn macht.
Anja: Und welche Rollen sind das normalerweise? Also ich denke jetzt an sowas wie jegliche Entwicklungsrollen, jegliche Designrollen …
Lena: Ja und sowas wie ein Product Owner oder Programmleitung oder Projektleitung. Also alle, die irgendwie daran beteiligt sind, das Projektziel sozusagen zu erreichen gemeinsam.
Anja: Aber das ist gut, dass wir darüber sprechen, weil stellen wir uns mal vor, es ist ein PO zum Beispiel, der aber nicht bei einem Daily dabei ist und gar nicht täglich die Arbeitsweise von den Teams oder von dem Team sozusagen sieht und eigentlich nur dazu da ist, um Arbeit abzunehmen. Die Person würde ich zum Beispiel nicht mit einladen, sondern es ist wirklich ein tägliches Miteinanderarbeiten und gemeinsame Prozesse erarbeiten. Dafür ist dieser Workshop da.
Lena: Ja, richtig!
Lena: Ja, genau. Das Gleiche gilt auch, wenn man in einem Team ist, wo es zwar eine Designerin gibt, die arbeitet aber für sechs Teams und hat ab und zu ein bisschen Zeit für das Team, ist aber operativ gar nicht dabei. Auch da könnte man das überlegen. Also wirklich genau, was du sagst. Die, die tagtäglich zusammenarbeiten und darüber reden müssen, wie sie diese Zusammenarbeit gestalten. Okay.
Gut. Über welche Themen spricht man dann bei diesem Workshop? Wir haben uns, wie viele Themen haben wir uns ausgesucht? Nach Neun Themen sieht es aus.
Lena: Neun.
Anja: Das erste Thema sind die Wünsche und Erwartungen der Einzelperson gegenüber dem restlichen Team. Das heißt, welche Anforderungen habe ich zum Beispiel an die Kommunikation, welche Anforderungen habe ich zum Beispiel an die Kernarbeitszeit oder ähnliches. Also, welche Wünsche habe ich bei der Zusammenarbeit und welche Erwartungen stelle ich an andere und welche Erwartungen können andere an mich stellen?
Anja: Das zweite Thema ist das Projektziel. Also einfach nur klären, okay, was glauben alle, ist das Projektziel. Das soll jetzt kein Projekt Kickoff ersetzen, wo das Projektziel noch mal klar fest steht für alle, sondern es ist wirklich die eigene Sichtweise, was ist das Projektziel. Und natürlich ist das Ziel, wenn man darüber spricht, sozusagen ein gemeinsames Verständnis herzustellen. Das ist klar.
Lena: Also genau, was du sagst, eigentlich steht das Projektziel zu diesem Zeitpunkt. In der Regel würde das wahrscheinlich schon feststehen. Man würde aber merken, wie die Sicht da drauf ist. Also man wundert sich oder ich habe mich schon oft gewundert, wenn man nochmal das Ziel reflektiert, was war denn nochmal das Ziel von dem Ganzen, wie unterschiedlich zum Teil die Antworten ausfallen. Deswegen ist auf jeden Fall spannend, das nochmal zu klären am Anfang.
Anja Dann ist es wichtig, in welchen Rollen man sich selbst sieht oder in welcher Rolle man sich selbst in dem Team sieht. Also das ist wirklich eine eigene Beschreibung. Meine Rolle sehe ich als solch und solcher. Das heißt nicht, dass da einfach nur mein Jobtitel steht. Ja, Anja ist Senior Consultant und Lena ist jetzt P-Sternchen. Das geht nicht darum. Es gibt so viele Beispiele, eine Rolle wäre zum Beispiel, ich bin nicht nur Senior Consultant, sondern ich arbeite sehr gern im Backend und in der Infrastruktur, Architektur. Das ist sozusagen meine Rolle oder ich dokumentiere sehr gerne. Solche Rollen zum Beispiel müssen keine offiziellen Rollen sein.
Lena: Genau, oder meine Rolle ist einfach zu moderieren häufig oder die Meetingminutes aufzuschreiben, obwohl das ist nicht mein Jobtitel. Ich bin ja nicht Moderatorin, sondern genau, also das muss nicht gleich der Titel sein und das können auch mehrere Rollen sein, die man in so einem Projekt hat.
Anja: Okay, das nächste Thema des Workshops wäre, sich festzulegen, okay, welche Entwicklungsprozesse und Methoden wollen wir denn anwenden? Also auch, was sind die Erfahrungen der einzelnen Personen und auf Grundlage welcher Erfahrungen würden sie denn die und die Prozesse und Methoden denn bevorzugen?
Lena: Und genau das, was wir eben meinten, diese alltägliche Arbeit, also wie organisieren und strukturieren wir unsere alltägliche Arbeit. Also das ist sowas wie, also wo dokumentieren wir oder was dürfen wir im Team entscheiden oder wie auch immer. Also da kann auch viel bei rumkommen, aber genau, es geht quasi um dieses Daily Work.
Anja: Das nächste Thema sind die Kommunikationskanäle. Also stellen wir uns einmal vor, es wird ein Bug gefunden. In welchem Kommunikationskanal schreibe ich, hey, ich habe einen Bug gefunden? Also mache ich einfach nur ein Ticket auf oder schreibe ich das zuerst in den Teamchat rein oder schreibe ich irgendjemandem eine E-Mail? Das sind so Dinge, die man auf jeden Fall klären sollte. Es kann auch so eine Art Prozess sein, aber da geht es vor allem um die Kommunikationskanäle. Zum Beispiel, wie stelle ich Review-Anfragn?
Gehe ich davon aus, dass jeder Notifications von beispielsweise GitHub oder GitLab bekommt? Oder muss ich die Person nochmal extra in einem Chat anfragen? Hey, ich habe hier eine Review-Anfrage für dich, magst du bitte übernehmen? Das sind so wichtige Dinge.
Lena: Und manchmal gibt es ja vielleicht auch, also kommt immer ein bisschen drauf an, ob man auch remote zusammenarbeitet. Ich habe es auch schon häufig erlebt, dass da auch ganz unterschiedliche Vorlieben oder auch Abneigungen gibt. Ich hatte auch mal eine Kollegin, die hat wahnsinnig gerne telefoniert und die hat mich gerne angerufen und dann Dinge am Telefon tatsächlich geklärt und das wäre für andere wirklich das allerletzte, was sie tun würden, zum Hörer zu greifen und mich anzurufen und so was auch zu klären. Oder auch zu sagen, ja ich habe zum Beispiel ganz oft die Kamera gerne aus oder ich habe sie gerne an, wenn wir miteinander in so einem Videocall sind. Also solche Dinge einfach mal zu besprechen, damit die anderen auch eine Chance haben, das zu verstehen.
Anja: Ja, sehr guter Punkt. Genau, damit die anderen eine Chance haben, das zu verstehen. Ich glaube, das ist generell das größte Ziel von diesem Workshop. Wir wollen einander verstehen, warum sie so handeln, wie sie handeln und uns dann einigen, wie wir am besten miteinander umgehen.
Lena: Dann haben wir Absprachen und Meetings. Das ist so ein bisschen das Thema einfach, also wann machen wir Meetings? Wer muss zum Beispiel in welchen Meetings dabei sein? Wir hatten jetzt das Thema, du hattest das Beispiel gesagt, mit dem PO, der vielleicht zum Beispiel beim Daily gar nicht dabei ist. Es kann auch sein, dass nicht immer alle in allen Meetings dabei sein müssen, weil es einfach Quatsch ist. Oder auch solche Sachen wie, wollen wir Meeting Minutes machen? Wenn ja, wo sind die festgehalten? Oder wollen wir so wenig Dokumentationen wie möglich und uns da eigentlich nicht übernehmen? Wo brauchen wir feste Meetings? Wo machen wir das nur bei Bedarf?
Anja: Auch solche Sachen wie, wollen wir Meetings machen? Ja, wo sind die festgehalten? Oder wollen wir so wenig Dokumentationen wie möglich? Wo brauchen wir feste Meetings? Machen wir das nur bei Bedarf?
Anja: Ja, es gibt auch immer wieder die Diskussion, wir haben zu viele Meetings. Da könnte man sich auch überlegen, ob man so eine Fokuszeit einführt, also sich darauf einigt, eine Fokuszeit zu haben, in der sozusagen gearbeitet wird und eine sozusagen Meetingzeit, in der Meetings geplant werden können. Das könnte man so tun. Ich habe auch mal ein interessantes Beispiel, in einem Team, eine Zeit, eine Stunde am Tag, die sich alle geblockt haben.
Lena: Ich hatte auch mal ein interessantes Beispiel in einem Team, eine Zeit, eine Stunde am Tag, die sich alle geblockt haben und da konnte man, das war sozusagen der Zeit, wo klar war, da können Meetings reingesetzt werden in diese Stunde, weil alle halten sich das frei sozusagen.Das hat aber auch dann nicht immer funktioniert, weil dann zum Teil Einzelne sich in dieser Stunde verankert haben. Wenn dann der PO aber ein Meeting ansetzen wollte, dann waren die Leute schon anderweitig verabredet sozusagen. Was ich damit sagen will, ist, dass bei diesem Thema viele Teams auch struggeln, sage ich mal, und versuchen, irgendwelche Formate zu finden, die für alle machbar sind. Denn Leute wie ich zum Beispiel, meine Arbeit ist häufig, Meetings aufzusetzen oder Meetings durchzuführen. Und eine Entwicklerin zum Beispiel, die macht ja eigentlich, die kann ja nicht entwickeln, wenn wir ein Meeting haben. Das widerspricht sich manchmal so ein bisschen.
Anja: Gut, dann kommen wir zu einem auch sehr wichtigen Thema, Feedbackprozesse. Also es ist für viele sehr wichtig, für viele vielleicht ermüdend, dieses Thema. Aber dennoch ist es genau zu fragen, hey, möchtest du denn eigentlich Feedback haben? Wenn du Feedback haben möchtest, lieber schriftlich oder lieber mündlich,soll es regelmäßig Feedback geben, so jeden Freitag oder einen Freitag im Monat zum Beispiel. Bei INNOQ ist es so, ich glaube einen Freitag im Monat haben wir ein Feedback Friday. Da gibt es so eine E-Mail mit einer Erinnerung. Hey, Feedback Friday, wenn du schon mal Feedback geben wolltest, dann machst du‘s heute.
Lena: Ich glaube, das Feedback-Thema ist für mich immer so, dass Feedback ein Angebot ist. Das kann nur ein Angebot sein, was anderes kann es gar nicht sein. Selbst wenn man Feedback erhält, muss niemand das annehmen. Man kann sich immer entscheiden, was man mit dem Feedback macht. Und man kann sich auch entscheiden, dass man gar keins haben möchte. Also was du gerade gesagt hast, es ist so wichtig darüber zu reden, ob man das haben möchte oder nicht und in welchem Setting, weil das ist kein ganz einfaches Thema. Und manche sagen vielleicht ja, aber bitte nur eins zu eins und von Angesicht zu Angesicht und andere sind da total, je mehr, desto besser. Und es gibt auch immer Leute, die sehr produktiv Feedback geben, sag ich mal, also häufiges Feedback geben. Und das ist halt auch, auch darüber muss man sprechen, ob das gewollt ist.
Anja: Da fühle ich mich an die Nase gefasst. Ich bin ein sehr produktiver Feedbackgeber.
Lena: Ja, es gibt halt da so ganz verschiedene Typen, das meine ich einfach, nur verschiedene Menschen.
Anja: Ja. Was man da aber noch beachten muss, ist, dazu zählt übrigens auch Feedback zum Code. Also auf welche Art und Weise möchte ich Feedback bekommen zum Code? Wird in einem Review erst einmal der Code durchwühlt und dort sozusagen Kommentare hinzugefügt und dann spricht man miteinander oder ist sprechen nicht notwendig oder spricht man direkt sofort miteinander? Also auch Feedback zum Code. Wie Feedback da auszusehen hat, das sollte man vorher besprechen. Aber wir werden gleich auch nochmal richtige, konkrete Beispiele dazu nennen. Kommen wir zum achten Thema dieses Workshops. Und zwar sind das, genau, das sind Prinzipien.
Prinzipien sind im Grunde wenige klare Merksätze, kann man sogar sagen, die für das Team gelten und für die Zusammenarbeit gelten. Die so ein bisschen das zusammenfassen, was in der ganzen Zusammenarbeitsdiskussion dann rausgekommen ist. Das sind kleine Merksätze, die helfen dabei, das Richtige zu tun. Ich habe bei Gregor Hope in dem Cloud Strategy Buch von ihm gelesen, er nennt das prinzipiengetriebene Entscheidungen. Und zwar ist es so, dass wir halt eine größere Strategie haben in dem Fall. Wir haben ein Projektziel, wir haben uns darauf geeinigt, wie wir sozusagen arbeiten wollen und dann erarbeiten wir uns aus dem, was wir sozusagen besprochen haben: wie wollen wir zusammenarbeiten? Prinzipien, die das ganz klar und auf den Punkt zusammenfassen. So Sachen wie Communication is key. Also einfach, wenn wir in dem gesamten Workshop wissen, okay, sehr viel kommunizieren ist besser als weniger kommunizieren, dann ist es für mich so eine Leitlinie. Das heißt, immer wenn ich mich frage, sollte ich jetzt etwas kommunizieren, dann ist die Antwort immer ja, weil communication is key und das ist ein Prinzip bei uns.
Und genau, es sollte aber nur wenige Prinzipien geben, damit man sich die gut merken kann, damit man, wenn man eine ad hoc Entscheidung treffen muss, weil man gerade niemanden fragen kann, man sich die Prinzipien schnell merken kann und aufgrund dessen eine Entscheidung treffen kann.
Lena: Genau und so merkt man vielleicht, also wenn die gelebt werden, die Prinzipien, so als Entscheidungshilfe, merkt man glaube ich auch schnell, wenn ein Prinzip nicht mehr trägt. Dadurch prüft man sich die ganze Zeit auch darauf, ob das funktioniert. Deswegen glaube ich, dass wenn man es schafft, wenige gute Prinzipien zu finden, dass das wirklich helfen kann, Dinge auch gut entscheiden zu können, ohne dass man wirklich zu viel Rücksprache halten muss. Ja, dann kommen wir zum letzten Thema. Das Projekt ist erfolgreich, wenn. Also wir haben das jetzt wieder hier auf Projekt bezogen, weil wir ja sozusagen, wir kommen ja aus dem Projektkontext und das ist so ein bisschen die Frage, wie kommen wir eigentlich zu dem Projektziel. Weniger eine Was-Frage, was müssen wir machen, sondern wie machen wir Dinge, damit wir zum Projektziel kommen? Also ein Beispiel könnte sein, dass wir gutes Nutzerfeedback erhalten oder das für uns ein Ziel ist, dass wir alle etwas lernen wollen innerhalb dieses Projekts. Also es kann um persönliche Erfolge gehen, kann um einen Teamerfolg gehen oder auch was die Kunden betrifft. Genau.
Anja: Also ein Beispiel könnte sein, dass wir gutes Nutzerfeedback erhalten. Oder dass es für uns ein Ziel ist, dass wir alle etwas lernen. Es kann um persönliche Erfolge gehen, es kann um Team-Erfolg gehen.
Lena: Das waren unsere neun Felder.
Anja: Genau, das waren die neuen Felder und wir sagen hier Felder, weil man kann das zum Beispiel auch in so eine Art Canvas gießen am Ende. Macht die Dokumentation so, wie ihr sie interessant findet, aber das Gute ist, wenn man sie irgendwie sozusagen knapp dokumentiert, dass man sie auch immer mal wieder nachschauen kann und nachlesen kann, falls man mal etwas vergessen hat. Ich würde sagen, jetzt gehen wir mal in die konkreten Beispiele, wie so ein Workshop aussehen könnte. Das heißt, wir tun jetzt erstmal so, als wären wir hier gemeinsam ein Team und wir würden jetzt diese ganzen Themen einmal durchackern.
Wie würde so ein Workshop aussehen? Das erste Thema ist ja Wünsche und Erwartungen. Das ist ja etwas sehr Spezielles, sehr Persönliches. Das heißt, jede Person für sich alleine überlegt sich zuerst in einer Arbeitszeit von ein paar Minuten, welche Wünsche und Erwartungen sie selbst hat. Es gibt verschiedene Fragestellungen dazu. Die erste Fragestellung, was erwarte ich von meinen Kolleginnen? Und das können so Dinge sein wie Pünktlichkeit zum Beispiel. Also mir persönlich ist es wichtig, dass alle pünktlich zu den Meetings erscheinen. Das ist etwas sehr Persönliches und jeder kann das anders sehen.
Lena: Das kann auch sowas sein wie, also Diplomatie nenne ich das jetzt, so ein gewisser, auf jeden Fall fällt gerade nicht der richtige Begriff ein, das gibt es auch manchmal in so Kommentarforen, wie man das nennt, also eine Art und Weise, wie man miteinander kommuniziert, dass man
Anja: Code of Conduct.
Lena: Genau, das meine ich. Genau. Das könnte sowas sein, dass man sagt, meine Erwartung ist eigentlich, dass wir alle höflich und mit guten Umgangsformen miteinander kommunizieren. Eine andere Erwartung könnte sein von einer anderen Person. Na ja, ehrlich gesagt, mir wäre es lieber, dass wir alle griffelig miteinander kommunizieren. Eine andere Erwartung könnte sein von einer anderen Person. Ehrlich gesagt wäre es lieber, wir zelebrieren die harte Ehrlichkeit und geben uns direktes, konkretes Feedback, auch wenn es weh tut, weil damit kann ich besser umgehen als mit unausgesprochenen Dingen. Also da können durchaus unterschiedliche Sachen aufgezählt werden. Hier in dem, da geht es jetzt noch nicht darum, dass man sich auf etwas einigt. Es geht erstmal nur darum, zu sammeln.
Anja: Genau, es ist wichtig, weil wenn wir erst einmal sammeln, was die Erwartungen von den einzelnen Personen ist, dann kann ich auch besser mit Konflikten umgehen, falls sie mal passieren. Beispielsweise, wenn es einen Konflikt gibt, weil es jemand einen Konflikt zum Beispiel meiden möchte und die andere Person regt sich darüber auf. Nein, lass uns das jetzt ausdiskutieren. Aber die andere Person möchte das nicht. Dann wissen wir jetzt, warum sie das nicht möchte, weil es da einfach unterschiedliche Erwartungshaltungen gibt, wie man Konflikte angeht.
Lena: Genau und wenn man das jetzt nicht bespricht in dem Workshop, wird man das auch irgendwann über kurz oder lang vermutlich rausfinden, dass die andere Person dort anders tickt, aber dann findet man es halt in einem Moment raus, wo man aufgewühlt ist, wütend, enttäuscht, was auch immer, halt in irgendeinem Konflikt und dann, da ist es dann, kommt es dann als Überraschung sozusagen.
Lena: Und hier, das ist halt die große Chance dabei, die große Gelegenheit vorher schon Dinge zu wissen und die im Hinterkopf zu haben. Dann haben wir noch den weiteren Punkt, ist nicht nur, was erwarte ich von meinen Kolleginnen, sondern was können die eigentlich von mir erwarten? Also was bringe ich mit? Ich bin zum Beispiel, du hattest das gerade gesagt, mit der Pünktlichkeit könnte man schreiben, ich bin zuverlässig. Ihr könnt damit rechnen, ich bin immer, wenn ich sage, ich bin da, dann bin ich auch da. Oder ich teste euren Code sehr gründlich bei Code Reviews. Könnt ihr euch auch drauf verlassen. Solche Sachen könnte man mit reinbringen.
Anja: Oder ich nehme mir immer Zeit für eure Fragen jederzeit. Das kann ja nicht jede Person. Es gibt Personen, die hätten gerne Fokuszeit und es gibt Personen, die lassen sich gern auch stören, Hauptsache sie können helfen. Und ja, das sind so Dinge,
Lena: Dann haben wir so einen Punkt, wann und wo arbeite ich gern. Das ist vielleicht gar nicht immer von Belang, je nachdem, in was für einem Setting ihr arbeitet. Also wenn ihr jetzt fünf Tage die Woche im Büro seid, dann ist klar, wo und wann ihr arbeitet. Wenn ihr jetzt in so einem Hybrid- oder Remote-Setting seid, dann ist es ja schon so, dass die Arbeitszeit natürlich unterscheiden ist. Die Kollegen, die kommen um sieben, die kommen um zehn, um sowas zu klären. Oder gehe ich gerne ins Büro, bin ich eigentlich im Homeoffice? Genau, dass man einfach über solche Sachen einmal spricht im Team.
Lena: Richtig, genau. Wenn ich dann um acht Uhr warte, dass du kommst, Anja, dann könnte ich schon wissen, dass du erst um zehn kommst.
Anja: Denn wenn man sowas schon vorher weiß, ist man nicht enttäuscht, wenn man etwas anderes erwartet hat. Genau. Das nächste Thema, worüber man sprechen sollte, was mache ich gern? Zum Beispiel, ich würde bei diesem Thema sagen, ja, also Dokumentation könnt ihr mir überlassen, weil ich dokumentiere sehr gerne. Da freuen sich alle.
Lena: Da wehrt sich auch niemand. Genau. Andere machen vielleicht, malen gerne Architekturbilder und sagen, da bin ich immer gerne mit dabei. Und das ist so gut, das zu wissen, weil man glaubt gar nicht, was für Sachen, die man selber, also die man selber schwierig findet, dass es häufig dann doch irgendjemanden gibt, der das wirklich gerne macht. Auch sowas wie moderieren oder so. Also was auch immer.
Anja: Das ist so gut. Man glaubt gar nicht, was für Sachen, die man selbst, also die man selber schwierig findet, dass es häufig dann doch irgendwen gibt, der das wirklich gerne macht. Auch sowas wie moderieren oder so. Was auch immer es gibt. Häufig geht sich das gut aus. Und das ist auf jeden Fall hilfreich, darüber am Anfang mal zu sprechen, bevor man sich dann quält, wenn was dokumentiert werden muss.
Lena: Häufig geht sich das gut aus. Und das ist auf jeden Fall hilfreich, darüber am Anfang mal zu sprechen, bevor man sich dann quält, wenn was dokumentiert werden muss und das irgendwie macht, obwohl man das auch einfach hätte Anja überlassen können.
Anja: Genau. Und dann kommen wir auch zum nächsten. Welche Tätigkeiten gebe ich doch dann lieber ab? Also bei mir wäre es so etwas wie Frontendentwicklung. Ah, Frontendentwicklung. Ich meine, ich habe es gelernt, aber das kann lieber jemand anderes machen. Das wäre besser.
Lena: Genau, oder sowas wie, ich möchte gar keine Tickets bitte schreiben. Das finde ich fürchterlich. Oder ich möchte eigentlich gar nichts dokumentieren. Ich habe immer Angst, dass ich irgendwas falsch aufschreibe. Das setzt mich unter Druck. Oder ich möchte keine Meeting-Minutes schreiben. Dann kann ich nämlich gar nicht richtig aufmerksam sein oder kann ich meine Themen gar nicht einbringen. Einfach was macht man weniger gerne? Dann haben wir noch den Punkt, das ist ja auch der letzte Punkt, wobei kann ich anderen helfen? Und das ist nicht zwangsläufig was, was man auch unbedingt super gerne vielleicht machen muss, aber man ist einfach gut da drin.
Also wenn man eine erfahrene Entwicklerin an Bord hat, die sich super mit Infrastruktur und Cloud-Sachen auskennt, dann ist klar, dass diese Person bei diesen Themen helfen kann und beraten kann und man von dieser Person lernen kann. Andere haben schon viel Erfahrung, da machen gerne Per- Programming. Einfach zu sagen, ich weiß, das kann ich gut, das mache ich schon lang, das habe ich gelernt, da könnt ihr zu mir kommen und dann kann ich euch helfen.
Anja: Gut, dann haben wir jetzt den ersten Teil des Workshops fertig gemacht. Das Problem ist hierbei, was hilft uns das alles? Das hilft uns, dass wir darüber gesprochen haben und dass wir im Hinterkopf behalten, wie die anderen ticken.
Das heißt, wir können uns das natürlich aufschreiben, worauf wir uns als Team zum Beispiel einigen können, aber sollten noch im Hinterkopf behalten, dass es trotzdem Unterschiede bei den Einzelpersonen gibt. Also wir könnten uns zum Beispiel als Fazit hier einigen, hey, viele von euch haben gesagt, sie legen Wert auf Pünktlichkeit oder das ist zumindest ein Kompromiss, auf den wir uns einigen können. Also absolute Harmonie kann es halt nie geben. Das, was wir vorschlagen, ist eher so eine Art Kompromiss und ein Framework zu bieten. Das heißt, man kann sich so auf Dinge einigen, die klar geworden sind. Okay, Pünktlichkeit scheint für viele wichtig zu sein. Lasst uns jetzt einen Kompromiss machen für alle. Wir versuchen alle pünktlich zu sein.
Es ist rausgekommen, dass es Konflikte geben könnte potentiell, wenn nicht schnell genug nach Hilfe gefragt wird. Hey, bitte frag doch bitte frühzeitig nach. Und es ist auch nicht schlimm, wenn ihr viel nachfragt, versucht das so zu machen. Und so können wir hier sozusagen als Ergebnis schon einmal unsere Kompromisse oder das, worauf wir uns einigen können, festschreiben und dokumentieren für den ersten Teil.
Lena: Genau. Dann gehen wir weiter zum nächsten. Das Projektziel hatten wir schon gesagt. Vermutlich zu dem Zeitpunkt gibt es das schon. Es gibt höchstens verschiedene Sichten oder Interpretationen, die aber gar nicht falsch sein müssen. Es kann beim Projektziel drei verschiedene Antworten geben, die alle stimmen. Und die alle irgendwie auf das gleiche Projektziel auch einzahlen. Wenn man jetzt merkt, da schreibt jemand, was gar nichts mit meinem Verständnis vom Projektziel zu tun hat, müsste man das vielleicht nochmal thematisieren.
Aber im Grunde geht es darum, die verschiedenen Sichten darauf abzubilden und dann kann man beim Ergebnis sozusagen eine Formulierung festhalten, die man sich nicht in dem Workshop überlegt, die gibt es wahrscheinlich schon irgendwo. Aber dass man so unten nochmal sagt, okay, das ist unsere gemeinsame Sicht auf dieses Projektziel, dass man einen Satz dazu festhält.
Anja: Aber im Grunde geht es darum, die verschiedenen Sichten dann auch abzubilden, und dann kann man beim Ergebnis sozusagen eine Formulierung festhalten, die man sich nicht mit dem Workshop überlegt, die gibt es wahrscheinlich schon. Aber dass man sagt, okay, das ist unsere gemeinsame Sicht auf dieses Projekt.
Anja: Da können wir mal als Beispiel nehmen, zum Beispiel die Ablöse von SAP, um Kosten zu sparen, wäre das Projektziel, welches man beim Projektkickoff schon festgeschrieben hat. Und die Sichtweisen darauf sind komplett unterschiedlich angekommen. Eine Person würde sagen, ja, das Projektziel ist, Kosten einzusparen. Wie man zu dem Ziel kommt, und zwar durch die Ablöse von SAP, ist es erst einmal sozusagen versteckt. Aber ja, Kosten einsparen, das ist eines der Ziele. Genau, und so kann es sozusagen verschiedene Perspektiven auf dasselbe Ziel geben.
Lena: Genau. Vielleicht schreibt noch jemand, das Altsystem soll abgelöst werden. Das stimmt auch. Es ist einfach nur eine andere Sicht darauf. Dann haben wir Rollen.
Anja: Ja. Dann haben wir Rollen. Genau.
Lena: Genau, da ist es so, das hatten wir eben schon gesagt, das ist jetzt nicht unbedingt der Jobtitel, sondern das können, das kann mehr sein, das sind mehr so die Tätigkeiten, die man macht, kann man auch mehrere haben und man kann im Ergebnis so ein bisschen festhalten, also man muss nicht unbedingt festhalten, wenn jetzt Anja als Entwicklerin drin ist, ihre Rolle ist aber klar, sie kümmert sich um die Infrastruktur, könnte man das natürlich als Ergebnis hinschreiben, Anja kümmert sich um die Infrastruktur, aber man kann auch sowas machen, wie zum Beispiel, wir haben uns darauf geeinigt, für Architektur sind alle zuständig. Das ist nicht etwas, was bei einer Person explizit liegt. Oder auch für Tickets schreiben sind alle verantwortlich. Das macht nicht nur eine Person. Solche Sachen könnten zum Beispiel als Ergebnis darunter stehen. Ein bisschen die Rollen. Und die Tätigkeiten unten zusammengefasst. Wer macht was? Man kann das auch sehr genau auftüdeln sozusagen. Ich glaube, das ist aber nicht unbedingt nötig. Wenn man es vor allen Dingen in dieser Canvas-Form macht, hat man auch gar nicht so viel Platz, da so wahnsinnig viel hinzuschreiben, muss man sagen.
Anja: Und das sind natürlich nur Beispiele. Also sind ja nicht immer in allen Teams alle für Architektur verantwortlich, aber das könnte eines der Ergebnisse sein. Zumindest ist das bei INNOQ häufig der Fall.
Lena Ja.
Anja: So, das nächste Thema in dem Workshop, Entwicklungsprozesse und Methoden. Das heißt, jeder schreibt dort wieder auf, was er oder sie an Erfahrung gemacht hat und was er oder sie am liebsten hätte. Bei mir würde ich zum Beispiel da so Dinge reinschreiben wie, Code Reviews sollten bis zum nächsten Tag um 12 Uhr abgeschlossen sein. Das heißt, bei mir ist es immer so, ich mache Code Reviews gerne am Anfang des Tages und am Ende des Tages, dass ich sozusagen alle meine Review-Anfragen abgearbeitet habe und dann weiß ich, okay, ab 12 Uhr kann ich mich um meinen Kram kümmern und muss mich nicht mehr darum kümmern, okay, ich muss gleich noch was reviewen, damit ich andere nicht blockiere. Das ist etwas, was ich selbst reinschreiben würde. Andere könnten etwas komplett anderes reinschreiben.
Lena Ja, genau, also hier könnte auch sowas stehen wie: wollen wir Per-Programming machen oder wollen wir das eigentlich eher nicht? Wie gehen wir vor, wenn jemand einen Bug findet? Kann er dann einfach das Ticket schreiben und schreibt eine kurze Info irgendwo hin oder meldet sich erstmal bei einem PO und es gibt einen Prozess dafür. Auch einen Prozess bezüglich Dokumentation. Wieviel wollen wir eigentlich dokumentieren und wo?
Anja: Wie gehen wir vor, wenn jemand einen Bug findet? Kann er dann einfach das Ticket schreiben und dann muss er sich erstmal melden?
Lena: Oder sagt man eigentlich, was im Code steht, muss zum Beispiel nicht mehr dokumentiert werden, denn der Code ist sozusagen die Dokumentation. Oder brauchen wir doch noch mal irgendwo im Confluence eine Seite dafür. Also solche Sachen würde man hier diskutieren.
Anja: Wichtig, auch als Beispiel finde ich Architekturentscheidungen. Es gibt auch eine Art, Architekturentscheidungen zu dokumentieren, die nennt man ADRs, Architecture Decision Records. Da gibt es manchmal ein Unwissen darüber, wer entscheidet das jetzt, dass eine Architekturentscheidung fertig ist, fertig dokumentiert ist und auch entschieden wurde. Also auch da könnte man sozusagen sagen, ja, ADRs werden im Konsens entschieden oder es gibt immer eine Person, die den Hut aufhat und die führt eine Entscheidung herbei oder so etwas. Das ist auch sehr wichtig. Also wie werden Entscheidungen getroffen, das zu klären? Gut.
Lena: Genau, dann haben wir… Achso, wolltest du noch was sagen zum letzten?
Anja: Ja, also ich würde nur sagen, das ist natürlich erst einmal, was wir gerade besprochen haben, diese Beispiele sind erst einmal nur Wünsche von den Einzelpersonen und dann muss man natürlich auch dokumentieren, worauf man sich dann geeinigt hat. Also wollen wir jetzt Per-Programming machen oder ist das optional? Wann sollten Code Reviews gemacht werden?
Lena: Genau.
Anja: Sagen wir jetzt nun, dass nur so viel Dokumentation wie nötig gemacht wird und dass es wirklich so ist, dass alles, was im Code steht, nicht dokumentiert wird, weil die Präferenzen von Einzelpersonen heißt ja noch lange nicht, dass das gesamte Team dann sich daran halten muss.
Lena: Tatsächlich gibt es, kann es glaube ich, bei diesem Punkt auch wirklich sehr große Unterschiedlichkeiten in den Arbeitsweisen und auch mit in den Wünschen geben. Also dieser Punkt hier gehört glaube ich zu den interessanteren, sage ich mal so.
Anja: Ich finde, man sollte hier auch sagen, Leute, erzählt von euren Erfahrungen, was, also warum habt ihr jetzt diesen Wunsch? Denn wir wissen ja nicht, was in den letzten Projekten, bei denen du warst, schon alles passiert ist und wir wollen uns auch dafür schützen, dass wir irgendwie in eine Sandgrube laufen oder ähnliches. Das heißt, hier einen Erfahrungsaustausch zu machen, was hat für euch funktioniert und was hat gar nicht funktioniert, ist auch superspannend und hilfreich für das gesamte Team, damit sie es besser machen können.
Lena: Ja und ich glaube auch hier ist das Ziel, sich auf etwas zu einigen, aber das Wichtigere finde ich fast, ist, dass man darüber redet und zuhört und die Leute, die Menschen versteht, woher sie kommen, wenn sie irgendwelche Dinge machen oder irgendwie sich verhalten im Projekt, dann hat man eine Idee oder eine Ahnung, warum das so sein könnte, wenn man vorher über solche Themen gesprochen
Es geht auch wieder darum, Überraschungen zu vermeiden und zu wissen, okay, Anja ist kein Fan von Per-Programming, auch wenn wir jetzt als Team gesagt haben, wir wollen das irgendwie machen und finden das gut, ich weiß trotzdem, dass das für Anja eher anstrengend ist. Und allein das zu wissen, das ist ja schon Gold wert.
Anja: Es geht auch wieder darum, Überraschungen zu vermeiden und zu wissen, ok. Am Ende dieses Podcast wisst ihr alle, wie ich gerne arbeite.
Lena: Das ist übrigens alles nur ausgedacht, wenn ich dich als Beispiel nehme. Das meiste stimmt nicht. Ich nehme nächstes Mal einfach jemand anderen als Beispiel.
Anja: Ja, aber ich weiß nicht, ich glaube bisher hat alles gestimmt. Alles gut.
Lena: Thema Kommunikationskanäle. Du hast es schon als Beispiel gesagt, also Thema zum Beispiel Bugs. Wie gehen wir vor, wenn wir einen Bug finden, dann schreiben wir ein Ticket und geben irgendwie in Slack Bescheid oder wir, keine Ahnung, wir müssen das vielleicht auch nochmal extra irgendwo anders hinschreiben, weil wir halt live sind und das irgendwie wichtig ist, wir müssen den vielleicht klassifizieren. Aber die Frage ist halt, in welchen Kanal kommen welche Informationen?
Anja: Wir müssen das vielleicht auch mal extra irgendwo anders hinschreiben, weil wir halt live sind und es irgendwie wichtig ist, müssen den vielleicht klassifizieren. Aber die Frage ist halt hier, in welchen Karten und in welchen Informationen. Hier wird eine Reihe an Fragen gestellt, dann machen wir zusätzlich schon eine Nachricht in Slack oder Teams.
Lena: Wie wird eine Review-Anfrage gestellt? Machen wir einen Pull-Request oder machen wir zusätzlich, schreiben wir noch eine Nachricht in Slack oder Teams? Genau, solche Fragen können hier eigentlich gut geklärt werden. Und was sind die Präferenzen bezüglich Kommunikationskanäle? Möchte eine Person gerne angerufen werden oder lieber vorher Bescheid geben oder fragen, wann man anrufen kann? Genau, solche Dinge. Ja, genau. Ja genau, ich kenne das zum Beispiel, hatte ich das schon mal, dass ich irritiert war auch, dass es eine Kollegin gab, die war zwar da, aber die war in ihrem Tool, was wir genutzt haben zum Schreiben, immer offline. Und das war für mich total irritierend, weil ich dann wirklich mal sagte, sie ist nicht da, aber die Gruppe, die war immer da, und die hatte einen Stillen. Trotzdem sah man das nicht. Das war zum Beispiel was, was ich dann ganz spät erst angesprochen habe, weil ich das eben so komisch fand. Sowas zum Beispiel, das kann ich auch mal an so einem Workshop ansprechen oder erklären,
Ich weiß gar nicht, ob man das bei so einem Workshop ansprechen würde oder klären würde, aber das sind für mich so Sachen, wo mir, glaube ich, so ein Workshop helfen würde, ein bisschen besser die Leute einzuschätzen. Zum Beispiel bei dem Fall, den ich eben beschrieben habe.
Anja: Mir fällt auch gerade ein, vielleicht hilft auch so ein Workshop dabei, das Eis zu brechen. Also man geht ja da schon sehr in die persönliche Richtung und man öffnet sich dann schon sehr oder man müsste sich sehr öffnen. Das heißt, wenn man schon mal über solche Themen gesprochen hat, wie man am liebsten arbeitet und warum man Dinge am liebsten nicht so hat, dann ist das Eis gebrochen und man fragt dann vielleicht mal nach so, du, du stehst da immer offline. Warum? Ach so, deswegen. Also dann spricht man das vielleicht später auch eher an.
Lena: Ja, weil man eben schon mal über dieses Thema miteinander geredet hat. Und ich glaube, das ist einfach eine Chance, da auch den Faden später wieder aufzunehmen. Ja, das finde ich gut, das stimmt.
Anja: Das nächste Thema Absprachen und Meetings.
Anja: Zum Beispiel könnte man so Dinge reinschreiben, wann soll das erste Meeting erst stattfinden, weil davor will man in Ruhe arbeiten oder schlafen oder ähnliches. Beispielsweise mein erstes Meeting bitte erst ab zehn oder Dailys sollten maximal zehn Minuten dauern, wenn es einem wichtig ist.
Lena: Oder auch, ich merke das immer in den Projekten, die unterschiedlichen Arbeitszeiten von Menschen, die Kinder haben und Menschen, die keine Kinder haben. Und das ist so unterschiedlich, wirklich. Also es hängt vielleicht auch gar nicht in erster Linie mit Kindern zusammen, aber daran mache ich es halt auch oft fest, dass es wirklich Menschen gibt, die wirklich wunderbar schon um acht sehr gerne im ersten Meeting sitzen, gar kein Problem. Und andere, die wirklich um zehn halt erst anfangen und für die das viel zu früh ist. Entweder trauen sie sich zu sagen, dass es ihnen zu froh ist oder sie trauen sich eben nicht und fühlen sich aber unwohl dann und quälen sich halt irgendwie da durch.
Anja: Stimmt, man könnte dann auch ansprechen, hey, mittwochs am liebsten keine Meetings, weil da muss ich die Kinder rumkutschieren oder da habe ich andere Verpflichtungen. Also zumindest geht es bei INNOQ so, dass man auch mitten am Tag die Kinder rumkutschieren kann. Hauptsache, man hat die Arbeit erledigt am Ende des Tages. Aber solche Dinge könnte man da halt auch besprechen. Oder man sagt einfach, der meetingfreie Tag, Mittwoch ist wichtig, weil dann können wir alle von morgens bis früh unsere Arbeit machen und werden nicht ständig durch Meetings unterbrochen.
Lena: Genau. Oder bitte Meetings nur, wenn dann, weiß ich nicht, direkt nach dem Daily oder so. Bitte nicht um 11 oder 14 Uhr, wenn es uns komplett rausreißt aus dem, was wir gerade machen.
Anja: Als Ergebnisdokumentation von diesem Bereich könnte man so Dinge reinschreiben, wie alle moderieren zum Beispiel gemeinsam oder eben nicht gemeinsam. Es gibt eine Person, die moderiert und die wird am Anfang ausgelost zum Beispiel. Oder hier könnte man zum Beispiel auch reinschreiben, wie kommunizieren wir als Gemeinschaft, als Team? Also gibt es eine Teamsprecherin, einen Teamsprecher? Oder sind wir alle gleichzeitig ansprechbar durch außenstehende Stakeholder? Das könnte man zum Beispiel hier auch ansprechen.
Lena: Das stimmt, das ist ein guter Punkt. Also dieses, wenn von außen was an uns herangetragen wird, wird das immer an alle herangetragen zum Beispiel oder gibt es ein Außenministerium sozusagen. Ja, okay.
Anja: Das nächste Thema, Feedbackprozesse, da haben wir ja auch schon viel darüber gesprochen. Also da könnten zum Beispiel dann Vorschläge auftauchen wie, hey, wie wäre es mit dem Feedback Friday? Oder, hey, mir ist Feedback wichtig. Ich wünsche mir regelmäßiges Feedback. Solche Dinge könnten dort drinstehen. Und dann könnte man sich dann eben einigen als Ergebnis. Ja, es gibt ein Feedback Friday oder Feedback soll immer mündlich oder mindestens mündlich passieren. Und wie ich schon gesagt hatte, Feedback gibt es ja auch zu Code. Und das ist etwas, was ich auf jeden Fall aufschreiben würde. Worauf man sich auch einigen sollte. Also wie sollte das Feedback zu Code Reviews oder zu Codes sozusagen vermittelt werden?
Lena: Und ich glaube, das Feedback ist ja deshalb so ein großes Thema, weil man halt viel Vertrauen benötigt, um wirklich Feedback gut zu verarbeiten. Also ich sage mal, je besser man sich mit einer Person versteht oder je vertrauter man mit ihr ist, desto eher möchte man Feedback oder traut man sich zu, Feedback zu bekommen von der Person. Und ich glaube halt, dass dieser Workshop der erste Schritt oder ein wichtiger Schritt ist, überhaupt dieses Vertrauensverhältnis im Team überhaupt herstellen zu können, dadurch, dass man sich besser kennenlernt.
Unsere Prinzipien, genau, das hatten wir schon ein bisschen länger besprochen vorhin. Haben wir gesagt, also Entscheidungshilfen, kurze, prägnante Sätze, die uns helfen, in bestimmten Situationen uns daran zu erinnern und dann irgendwie weitermachen zu können.
Anja: Genau. Wir haben gesagt, dass Entscheidungen helfen, kurze, prägnante Sätze und selbstbestimmte Situationen daran zu erinnern und dann irgendwie weitermachen zu können. Dann könnte sowas rauskommen, als wäre es so, Communication ist key, wir wollen alles kommunizieren. Aber Qualität nicht nur Quantität wäre vielleicht etwas, woran man sich in bestimmten Situationen auch gut erinnern würde.
Lena: Oder auch lieber um Verzeihung bitten statt um Erlaubnis. Das könnte auch sein. Oder fail fast. Das ist ja so was ähnliches. Das sind natürlich nie ganze Wahrheiten, die für immer und alles irgendwie gelten. Das ist einfach etwas, was man im Kopf haben kann, wenn man sich gerade nicht ganz sicher ist, in welche Richtung man jetzt laufen will als nächstes.
Anja: Genau, und wenn ich mir so vorstelle, ich bin gerade in einer Softwareentwicklung, ich arbeite gerade an Code und ich überlege so, boah, ich würde am liebsten diesen Code hier perfekt machen, aber das würde jetzt so lange dauern. Vielleicht hilft es mir dann, dass es so ein Prinzip gibt, lieber konsistent statt perfekt. Okay, ich mache es lieber konsistent, überall gleich, es muss nicht perfekt sein. Ich kann es ja irgendwo dokumentieren, wie ich es gerne hätte. Aber wenn das sozusagen das Prinzip ist und ich kann mich noch an den Workshop erinnern, dass das einer der Use Cases war, um dieses Prinzip anzuwenden, dann ist ja alles gut. Es sind wirklich nur wenige Merksätze. Man sollte sich da wirklich auf wenige beschränken, so fünf bis sieben, damit man sich die leicht merken kann. Das zeigt ja auch, wie die Priorität ist, dass die sozusagen die höchste Priorität haben.
Lena: Genau, und ein anderes Beispiel wäre vielleicht noch für communication is key, wenn man sich fragt, ich habe jetzt irgendwie eine neue Information, soll ich das jetzt irgendwie erzählen, soll ich es nicht erzählen, soll ich es irgendwie in den Channel schreiben, dann kann man sich erinnern, ach Mensch, wer hat mir gesagt, stimmt, lieber sage ich mal zu viel kommunizieren in Anführungszeichen als zu wenig, dann okay, ich schreibe es rein. So, ja, genau.
Lena: Und dann haben wir noch, als letzten Punkt, das Projekt ist erfolgreich, wenn
Genau. Und da finde ich die Beispiele am wichtigsten, weil da kann man sich so vieles vorstellen. Du hast das ja gesagt. Also eher so, wie kommen wir zum Ziel? Was sind die persönlichen Erfolge, die ich mitnehmen will? Oder am Ende könnte man als Ergebnis sozusagen auch aufschreiben, was wären Teamerfolge oder Kundenerfolge am Ende, wenn das Projekt endet oder auch währenddessen. Zum Beispiel konstantes Lernen wäre ein persönliches Ziel oder auch ein Teamerfolg. Oder es könnten Einzelpersonen schreiben oder vielleicht viele schreiben. Ja, also wenn die Kundin am Ende mit dem Endergebnis zufrieden ist, dann fühle ich mich wohl oder das ist irgendwie mein, das ist sozusagen dann mein erfolgreiches Projekt. Oder auch, wenn man es schafft, auf Augenhöhe mit der Kundin zu kommunizieren. Wenn man es schafft, ein Vertrauensverhältnis zu bilden, das wäre irgendwie ein Projektziel. Dann wären alle zufrieden und das wäre auch etwas, was konstant bei einem Projekt sozusagen das Ziel vielleicht noch wäre. Oder wenn wir jetzt auch darüber denken, wie es denn weitergeht mit dem Projekt, also wird der Auftrag verlängert? Können wir noch mal ein Projekt dort machen oder können wir das Projekt weiterführen? Das wäre sozusagen auch ein Projektziel. Waren wir so erfolgreich in der Art und Weise, wie wir unsere Arbeitsergebnisse abgeliefert haben, dass unser Auftrag verlängert wird? Und da sieht man auch, je nachdem, welche Personen hier etwas aufschreiben können, diese Ziele auch komplett anders sein können.
Anja: Ich kann mir vorstellen, dass viele eher so persönliche Ziele hier reinschreiben und andere dann doch lieber Ziele reinschreiben in Zusammenhang mit der Kundin und des Erfolgs des Projektes im Allgemeinen. Und das sollte auch vollkommen in Ordnung sein, dass da jeder andere Ziele hat.
Lena: Genau, ich glaube, das ist auch wichtig bei dem Punkt zu sagen. Bisschen anders als bei dem Projektziel am Anfang, da sollte nicht so ganz unterschiedliche Sachen rauskommen. Hier kann das durchaus sein.
Anja: Genau. Oder so Dinge, das Projekt ist für mich erfolgreich, wenn die Software stabil läuft und macht, was es soll. Das ist etwas, was ich ständig von unseren Kolleginnen höre. Ich möchte Software bauen, die richtig gut läuft und genau das macht, was sie soll. Ich möchte nicht einfach nur meine Arbeit abreißen und das war’s, sondern ich will auch, dass es richtig tolle Software ist, die wir da abliefern.
Lena: Genau. Ja, und es ist auf jeden Fall gut, darüber zu reden, was so die persönlichen Erfolgserlebnisse sein werden. Aber als Ergebnis könnte man hier dann sozusagen noch konkret aufschreiben, okay, so als Team, worauf kann man sich einigen.
Anja: Also zum Beispiel könnte man sich darauf einigen, wie ich ja schon gesagt habe, wie INNOQ so drauf ist. Bei uns ist es so, nicht nur die Kundin soll zufrieden sein mit dem Endergebnis, sondern auch wir sollten zufrieden sein mit dem Endergebnis und auch die ganze Zeit zufrieden sein in einem Projekt. Das ist uns vor allem sehr wichtig, dass wir spannende Projekte haben und das könnte als Ergebnis sozusagen aufgeschrieben werden. Und das hilft auch während des Projekts, die ganze Zeit zu schauen, sind wir auf dem richtigen Weg.
Lena: Sind wir auf dem richtigen Weg, dass das Projekt erfolgreich ist? Genau, das ist auch ein Punkt, den man grundsätzlich zu diesem Vorschlag sagen kann. Die Sahne, die man als Ergebnis am Ende hat, sprechen wir jetzt gleich nochmal drüber, wie man das Ergebnis sozusagen aufschreibt. Das ist etwas, das man auch mal wieder verwenden kann, um zu gucken, stimmt das eigentlich noch für uns? Also haben wir jetzt irgendwie vor einem Jahr oder vor einem halben Jahr mal gemacht, ganz zum Anfang. Jetzt haben wir uns so eingegroovt. Passt das noch für uns oder eigentlich nicht und dann ist es glaube ich super interessant, diese Sachen wieder anzugucken. Genau und das ist eben genau der Punkt auch, zu dem wir jetzt kommen würden. Es gibt jetzt, wir sind jetzt alle neun Punkte durchgegangen mit Beispielen und das heißt es gibt jetzt irgendwie ein Ergebnis, es gibt zu jedem Punkt Ergebnisse, also einige Sätze.
Anja: Das ist eben genau der Punkt, zu dem wir jetzt kommen würden. Wir sind jetzt alle neun durchgegangen mit Beispielen. Das heißt, es gibt jetzt ein Ergebnis, zu jedem Punkt Ergebnisse, also einige Sätze. Das kann man jetzt irgendwie, das muss man jetzt irgendwo festhalten. Und man kann das auf so eine Art Canvas machen, wie du vorhin schon gemeint hast. Und das ist ja so eine zurzeit sehr moderne Art, sage ich mal, Sachen auf einen Blick irgendwie lesbar zu machen. Man kann das auch auf ein großes Blatt Papier schreiben und im Büro aufhängen.
Lena: Man kann es auch ins Confluence schreiben. Die Art und Weise, muss jedes Team für sich gucken, gut wäre, wenn es nicht sozusagen in den Analen der Dokumentationshölle verschwindet, sondern halt irgendwo ist, wo man auch mal wieder drauf gucken kann.
Anja: Genau, und dann sollte man sich auch noch die Frage stellen, wollen wir alles dokumentieren, was besprochen wurde, weil da sind ja schon sehr persönliche Dinge dabei, oder nur das, auf was wir uns dann am Ende geeinigt haben. Das ist auch etwas, was das gesamte Team entscheiden sollte. Manche kommen damit klar, dass alles dokumentiert wird, was man da gesagt hat, auch wenn es persönliche Dinge sind, und manche vielleicht nicht. Genau, weil das gehört dem Team sozusagen. Dieses Dokument gehört dem Team und alle haben die gleiche Entscheidungshoheit, was damit passiert, wo das steht, was am Ende da drin steht. Genau.
Anja: Und es ist auch wichtig, dass man Teams nicht anhand dessen, was sie hier besprochen haben und was sie dokumentiert haben, bewertet. Also alles, was rauskommt, ist total valide. Darauf hat sich das Team geeinigt. Und man sollte jetzt nicht über diese, wenn jetzt jedes Team so ein Canvas am Ende erarbeitet hat, über diese Canvas drüber gehen und dann bewerten, ja dieses Team hat das richtig gut gemacht und das Team hat das schlecht gemacht. Das ist totaler Quatsch, weil es ging um den Prozess vor allen Dingen. Es ging um den Prozess, über diese Themen zu sprechen. Und wie das am Ende sozusagen dokumentiert ist und vor allem, was am Ende da drauf steht, das, wie du schon sagtest, gehört dem Team und nur die müssen damit arbeiten. Weil sie wollen ja miteinander effektiv Software entwickeln. Genau. Und es ist nicht dafür da, zum Beispiel so etwas wie einen Projekt-Kick-Off zu ersetzen oder so. Es kann Teil eines Kick-Offs sein. Es kann Teil davon sein, ein Projektziel noch mal festzuhalten, aber es ist nicht der Termin, wo man irgendwie ein Projektziel klärt oder so. Das ist eigentlich nicht dafür da, diese Dinge zu ersetzen oder eine Retro zu ersetzen. Am Ende kann sich das auch alles irgendwie ergänzen.
Lena: Aber an sich ist es einfach nur ein Workshop, der für das Team da ist, um irgendwie miteinander ins Gespräch zu kommen.
Anja: Und jetzt mag es vielleicht einige von euch geben, die sagen, da fehlen dann auch super viele Themen und super viele Punkte. Was ist denn mit den Stakeholdern? Warum habt ihr nicht über die Stakeholder gesprochen? Und dieses Feedback hatten wir zum Beispiel auch, als wir INNOQ intern über diesen Vorschlag gesprochen haben. Und uns ist das auch aufgefallen, stimmt. Es ist ein sehr wichtiges Thema, welche Stakeholder es gibt. Aber auch das ist etwas, was man in anderen Workshops vielleicht erarbeitet. Weil dieses Workshop-Format, was wir uns hier ausgedacht haben, hat wirklich nur mit der teaminternen Kommunikation zu tun und sehr wenig mit außenstehenden Stakeholdern. Klar, wir haben kurz darüber gesprochen, dass es so eine Art Team-API geben kann. Wer ist für Absprachen mit außen verantwortlich? Aber das ist auch etwas, was erstmal intern feststehen muss.
Anja: Was jetzt erstmal nichts damit zu tun hat, wer fragt jetzt etwas an?
Lena: Genau und man kann auch, wenn ihr andere Punkte im Kopf habt, kann man das ergänzen oder auch was wegnehmen. Man kann sagen, ich möchte hier nicht über das Projektziel sprechen. Das gehört hier nicht hin. Das ist völlig in Ordnung. Also je nachdem, welche Punkte euch wichtig sind. Genau.
Anja: Was mich jetzt interessieren würde, wie findet ihr das Ganze? Wie findet ihr diesen Workshop, den wir uns ausgedacht haben? Der kam aus unseren Erwartungen, aus unseren Erfahrungen, wie wir solche Workshops schon durchgeführt haben. Vielleicht habt ihr ja noch Punkte, die ihr uns mitteilen wollt. Dann schreibt uns gerne eine E-Mail an podcast.innoq.com oder benutzt das Kontaktformular auf innoq.com.
Oder wenn ihr Lust habt, dass wir einmal so einen Workshop bei euch im Unternehmen durchführen oder euch zeigen, wie man das am besten durchführt, dann schreibt uns auch gerne eine E-Mail. Das stimmt. Und drunter Feedback auch. Also gebt uns gerne Feedback, wie euch diese Folge gefallen hat. Ich würde sagen, dann sind wir fertig, oder? Super.
Lena: Wir freuen uns über Post. Genau. Ja, prima. Vielen Dank. Hat Spaß gemacht. Ja, das machen wir. Bis bald. Tschüss.
Anja: Hat mir auch Spaß gemacht. Tschüss.