Wie baut man eine agile IT-Organisation auf?

Joel Kaczmarek: Hallo und herzlich willkommen zu einem neuen Innovate-or-Die-Podcast von Digital Kompakt. Mein Name ist Joel Kaczmarek und wer aufmerksam zugehört hat, weiß, dass wir noch gar kein so ein Format hatten. Das ist sozusagen unsere Premiere heute. und beim Thema Innovate or Die soll es in dem Fall konkret um IT gehen. IT-Projektmanagement, das ist ja so ein bisschen das Backbone von ganz vielen Unternehmen, die digitalisieren wollen oder schon sind. Und da habe ich einen hyperkompetenten jungen Mann mit an Bord, der uns da ganz viel zu erzählen wird. Stell dich mal ganz kurz vor, lieber Boris.

Boris Lokschin: Hallo, ich bin Boris Lokschin, ich bin Geschäftsführer von Spryker Systems hier in Berlin und freue mich auf das Format und über die Einladung und dass du uns heute hier besuchst in unseren Räumen.

Joel Kaczmarek: Jetzt musst du natürlich mal was zu Spryker einerseits sagen und dann natürlich danach auch zu deiner eigenen Genese. Also wie bist du zu ihm gekommen, was du tust, was sind so deine Kompetenzen? Fangen wir vielleicht mal mit Spryker an. Wer fleißiger Kassenzone-Hörer ist und der Kollege Graf macht ja bei uns auch das ein oder andere, kennt das schon, aber das kann man glaube ich nicht oft genug erzählen.

Boris Lokschin: Ja, also Spryker ist eine Commerce-Technologie, wir sagen immer Desktop Beyond Shop, also eine neue Art von, wie kann man transaktionales Geschäft enablen, also ein bisschen jenseits von, ich habe ein Standard-Shop-System, was ich versuche vielleicht responsiv zu machen, ein bisschen zu konfigurieren und anzumalen, sondern wie sieht so eine Customer-Journey nach vorne aus, welche neuen Touchpoints habe ich, was kann ich mit Voice, Bots machen, wie funktioniert Commerce im IoT-Kontext, wie kann ich auch ganz normale Retail-Businesses enablen, einfach deutlich schneller zu wachsen, besser zu personalisieren, eine bessere Performance zu haben, Und das eben sehr, sehr modular, sehr unabhängig von dem Frontend und mittlerweile bei eben sehr, sehr vielen spannenden Kunden und Anwendungsfällen im Einsatz, B2B, B2C, alle möglichen Verticals.

Joel Kaczmarek: Ich finde ja immer, ihr habt so ein latentes Verpackungsproblem. Man kriegt das halt nicht in einen Satz gegriffen. Wenn ich mal sage, das ist ein Shop-System, kommt Alex immer und holt seinen Schlagring aus der Hose und sagt, nee. Früher hat man immer gesagt, das ist ein Shop-iOS oder ein Shop-OS, sozusagen wie ein Betriebssystem, wenn man irgendwie Online-Handel betreiben will. Ich habe das Gefühl, selbst das ist irgendwie mittlerweile nicht mehr so, dass das was komplett abdeckt, oder?

Boris Lokschin: Ja, aber das ist ja die Realität auch des Marktes. Wir sagen ja Spryker Commerce OS, ja, wie du gerade gesagt hast, Betriebssystem für Commerce. Und du kannst auch eine Lösung wie SAP nicht in einem Satz erklären, ja. Das ist auch ein Backbone, eine Infrastrukturtechnologie für dein Backend, ja. Das ist am Ende eine Solution, das ist jetzt keine Boxsoftware oder kein Standardsystem, wie der Name schon heißt, Standardsystem versucht eben maximal viel zu standardisieren. Wir versuchen eben maximal viel zu differenzieren und sagen, naja, du kannst eben nicht Wettbewerbsvorteile aus einer Standardlösung ziehen, du musst dich differenzieren, deine Hose oder dein Schuh im Warehouse ist halt nicht differenzierend genug, hat der Wettbewerber auch. Das heißt, du musst dir digitale Kompetenzen auch technologisch aufbauen, die dich eben absetzen vom Markt. Und deswegen, ja, Commerce OS ist der Begriff. Und ich habe ja vorhin auch kurz aufgezählt, der Anwendungsfall für einen Maschinenhersteller, der seine Fahrstühle smart macht, die dann automatisch Ersatzteile nachbestellen und Wartungsfenster schedulen, ist natürlich komplett anders von einem B2C-Online-Fashionanbieter, der grüne T-Shirts online verkauft. Unten drunter sind das sehr ähnliche transaktionale Vorgänge, Produktmanagement, Ordermanagement, Payment etc. Aber das Frontend, die Art und Weise, wie der Kunde damit umgeht, sind halt sehr unterschiedlich. Und deswegen ist die Lösung eben auch so gestrickt, wie sie heute gestrickt ist.

Joel Kaczmarek: Ich glaube, der Kollege Graf legt sonst immer so seine hypothetischen Beispiele im Kochbereich an. Graf Koks AG sagt ja doch immer, es ist ein fiktives Unternehmen zum Verkaufen von Grills. Das ist mein Favorite. Hast du nie gehört von ihm? Nee. Wenn er mal sagt, so denken wir uns mal ein fiktives Unternehmen, zum Beispiel die Graf Koks AG, die irgendwie Grills verkauft, dann Nun ja, anyway, ich drifte ab. Zurück zum eigentlichen Thema. Wir wollen über IT reden. Was ist denn dein Background in dem Bereich? Was hast du bisher so gemacht? Wie bist du dazu gekommen? Wie bist du aufgestellt?

Boris Lokschin: Also für mich ist das die dritte Company, die ich gründe und die ich mit aufbaue. Ich habe sehr früh gegründet, mit 17 meine erste Firma. Da haben wir im weitesten Sinne ein Software-as-a-Service-Shop-System gebaut, das dann drei Jahre später verkauft an unseren größten Kunden zum damaligen Zeitpunkt. Also da so ein bisschen Erfahrung gesammelt mit, wie baue ich eigentlich ein Produkt, wie betreibe ich das, was heißt das eben für ein Commerce-Retail-Unternehmen. Danach eine Agentur gegründet, sehr früh zu der großen Magento-Zeit. Am Ende eine der größten Magento-Agenturen in Europa. Verkauft dann ein amerikanisches, Nasdaq-gelistetes Unternehmen. Das wurde dann der Nukleus für eine digitale Commerce-Einheit. Wir hatten dann knapp 300 Leute, die ich dann am Ende mitmanagen durfte. Mit sehr breitem Portfolio, alle Konkurrenzlösungen, Hybris, Magento, die man hat, ATG, Oracle, also alles. am kleinen, großen, mittleren Rad dann international gedreht und in Summe irgendwie 500 E-Commerce-Projekte jetzt gemacht, gesehen in den letzten, klingt komisch, das zu sagen, mit 33, 15 Jahren Erfahrung. Ja, und ich glaube, da einfach auch so ein paar Dinge jetzt gesammelt und mitgenommen, die wir zum einen natürlich versuchen, jetzt mit ins Produkt fließen zu lassen und zum anderen eben auch in der Beratung oder in der Ansprache der Kunden versuchen, mitzugehen methodisch. Und die, glaube ich, jetzt auch so die Grundlage sein sollen für dieses Format.

Joel Kaczmarek: Okay, ich wollte aber auch gerade sagen, ich habe mit 17 glaube ich N64 gespielt und mich auf mein Abitur konzentriert. Also Hut ab, Respekt. Und ich lerne. Du hast sozusagen, wenn du gerade selber sagst, 500 E-Commerce-Projekte schon von innen gesehen in irgendeiner Form. Also entweder selbst beigewiesen oder selber gemacht. Das ist ja schon ein Brett. Und wir wollen heute das Thema agile IT-Organisationen gerne hervorheben. Agile haben, glaube ich, ganz viele sofort so Scrum im Kopf und irgendwie, ja, okay, IT geht jetzt weg von Wasserfall, wir müssen irgendwie flexibler sein und so weiter und so fort. Das wollen wir ein bisschen genauer verstehen. Das heißt, ich würde sagen, wir fangen mal an, genau, was meint das eigentlich grob und wollen dann natürlich auch so Organisationsformen, Rollen in dem Bereich, vielleicht auch mal ein paar Erfolgsbeispiele durchdeklinieren. Aber mal ganz basic begonnen. Also ich habe jetzt so dieses Thema Wasserfall jetzt mal reingeworfen. So habe Ich habe das noch gelernt in der Informatik, dass das irgendwie überkommen ist. Und das war für mich so im Geiste der Anfangspunkt von Agile. Vielleicht war das jetzt aber auch falsch, dann korrigiere ich mich gerne. Also wenn du sagst so Agile IT, was steckt da für dich da eigentlich hinter?

Boris Lokschin: Ich glaube, vielleicht um noch einen Schritt zurück zu gehen, also A, das agile Phänomen ist ja auf die IT übergeschwappt aus anderen Industrien, insbesondere Automobilfertigung, so wird ja immer Toyota als Beispiel genannt. Wichtiger zu verstehen ist, wofür ist das und warum gibt es das überhaupt, warum ist das überhaupt wichtig. Weil Methodik erfüllt ja immer einen Zweck, das ist ja kein Selbstzweck, dass ich sage, was dafür alles doof ist, lass uns mal agil arbeiten, sondern du willst ja irgendwas enablen damit oder irgendwas verhindern, was vorher nicht gut geklappt hat. Und was man da einfach, glaube ich, gelernt hat im Markt ist, das ist, glaube ich, keine große Überraschung, dass der Markt sich so schnell weiterentwickelt. Du hast einfach deutlich mehr und in deutlich kürzeren Abständen zu reagieren auf Veränderungen. Veränderungen können alles sein. Veränderungen können sein, Wettbewerbssituationen. Veränderungen können sein, technologische Entwicklungen, was habe ich jetzt im Commerce-Umfeld an? vielleicht Touchpoints, an Devices. Als ich angefangen habe 2001, gab es nur den Desktop 15, 17 Zoll. Das war das einzige, worum wir uns gekümmert haben. Kein Mobile, keine mehreren Betriebssysteme, keine Tablets, Fablets, Uhren, Wearables, Bots, Voice etc., Uhren, Brillen. Und das ist jetzt nur ein einziges Beispiel, nur ein einziges Frontend-Beispiel. Das heißt, es kann technologische Veränderung sein, es kann Wettbewerbsveränderung sein, es kann Investitionsfähigkeit sein für ein Unternehmen. Und du willst in irgendeiner Art und Weise sicherstellen, dass du entweder aus kaufmännischer Sicht nicht zu große, nicht zu langwierige Wetten eingehst, die so ein bisschen am Markt vorbeidesignen. Du willst sicherstellen, dass du irgendwie schnell genug adaptieren kannst an Themen, dass du irgendwie die richtigen Trends zum richtigen Zeitpunkt mit dem richtigen Risikoprofil aufgreifst. Dafür, glaube ich, ist diese ganze Agilität entstanden oder hat Einzug gefunden in diese IT-Organisation. Man hat einfach gemerkt, das, was ja bis vielleicht vor 10, 12 Jahren IT war, einen wesentlichen EDV noch damals genannt, Backbone, so klassisch Warenwirtschaft zum Beispiel. Ich habe meine große EDV-Abteilung, die managt eigentlich meine Warenwirtschaft. Das ist halt eine große kaufmännische Applikation, die standardisierte, ganz wichtig, Business-Prozesse enabelt, die sich nicht häufig verändern und auch nicht häufig verändern dürfen. Finance, HR, Supply Chain, das sind Dinge, da greifst du in die Lager, da greifst du nicht irgendwie zehnmal pro Tag ein und deployst irgendwelche Neuerungen, sondern da willst du ja eigentlich, dass das funktioniert. Irgendwann habe ich mir gedacht, alles, was so kundenzentrisch passiert, also da, wo ich eben nicht im Hintergrund im Maschinenraum werkele, sondern was entlang des Kunden passiert, da gibt es eben genau diese Veränderungen. Der Kunde kauft anders ein, anderes Verhalten, andere Wettbewerber, andere Kundenakquisitionskanäle. Das geht nicht mehr, dass ich da zwei, drei Jahre für großes, siebenstelliges Geld an dem Projekt arbeite. Da brauche ich eine neue Form von Methodik, neue Organisationen, neue Rollen. Und dieses Verständnis ist noch nicht bei allen so da, erschreckenderweise. Man trifft sehr viele Kunden, die heute immer noch 2018 unterwegs sind und versuchen, ihre IT eher sehr klassisch zu strukturieren, klassisch zu inzentivieren. Und auch logischerweise, wenn man das tut, dann auch mit dem entsprechenden Outcome. Das, glaube ich, ist so der Starting Point für diese Diskussion.

Joel Kaczmarek: Gut, also habe ich schon mal als erstes Learning, wenn wir irgendwie sagen, es geht um agile IT-Organisationen, dann ist auch eine Unterstreichung unter Organisation, also ich höre da Kulturwandel raus, sozusagen als Denkmodell, was du damit auch siehst, wenn es um Agile geht?

Boris Lokschin: Absolut, das ist allerwesentlich. Das wesentlichste Merkmal ist vielleicht tatsächlich, dass das eher nicht mehr eine Cost-Center-Organisation sein kann. So eine klassische IT-Organisation ist eben wirklich ein Cost-Center. Es wird auch so gemessen, der ITV-Leiter darf dann irgendwie x Prozent von dem Umsatz ausgeben, muss für jede Confluence-Lizenz ein Business Case rechnen und wenn er ein bisschen weniger Geld ausgibt für Hardware, Software, dann ist er gut und kriegt seinen Jahresbonus. In der digitalen Welt ist das absolut das Gegenteil. Da ist allen klar, IT ist der Business Enabler, häufig das eigentliche Asset. Es ist nicht das Produkt im Warehouse. Es ist die eigentliche Technologie, Plattform, App, whatever. Damit geht es natürlich anders um. Du investierst anders. Du gehst anders ran. Die Leute, die dort arbeiten, haben einen ganz anderen Stellenwert. Du bezahlst die Leute anders. Du schaffst eine Umgebung, eine Arbeitsumgebung, die ganz, ganz anders aussieht als in einer klassischen IT-Organisation. Du hast bestimmte Diskussionen gar nicht, du redest nicht mit denen über Hardware, du redest nicht mit denen, erklärst denen nicht, warum sie keinen Mac haben dürfen. Du hast ganz andere Diskussionen, welches Müsli du denen hinstellst vielleicht morgens und ob der Hund mit ins Office kommen kann und ob die Netflix-Mitgliedschaft Teil des Arbeitspaketes und so. Das sind so Dinge, die dann auch Implikationen haben, so aufs Org-Chart und HR und Recruiting und Co., ja.

Joel Kaczmarek: Also mal zum Durchatmen für Leute, die jetzt vielleicht so im KMU-Bereich sind, Familienunternehmen, sagen wir mal Süddeutschland. Wenn du jetzt sagst, du leitest irgendwie eine agile IT-Agentur, dann hast du dich wirklich damit zu beschäftigen, ob du deinen Mitarbeitern Netflix-Abos gibst und wie du die inzentivierst? Also ist das mittlerweile wirklich so ein Status, dass die Leute sich das aussuchen können und dass solche Sachen dann relevant werden?

Boris Lokschin: Es ist definitiv ein Arbeitnehmermarkt. Es ist auf jeden Fall so, dass sich diese Leute aussuchen, wo sie arbeiten, anhand von verschiedenen Parametern. Es ist definitiv so, dass es ein großes Kapazitätslimit gibt an verfügbaren Profilen. Es ist auch wirklich eher Pull und nicht Push. Das merkt man auch bei großen, also nicht nur bei den kleinen Unternehmen. Du merkst halt, es ist nicht so viel inbound. Da bewirbt sich keiner. Keiner von diesen Leuten ist arbeitslos und keiner von ihnen sitzt zu Hause und schickt zehn Bewerbungen raus. Sondern du gehst auf die Leute zu, du versuchst sie zu begeistern. Und das tust du, indem du eine coole Aufgabe hast, indem du eine coole Company hast, indem du auch eine coole Umgebung hast. Und klar ist das in kompetitiven Standorten, wie vielleicht Berlin, deutlich schwieriger, als wenn du vielleicht irgendwo in Süddeutschland bist. Auf der anderen Seite musst du dann eben auch überlegen, wie attraktiv bist du. Es kann gut sein, dass du natürlich regional oder lokal Leute findest, wo eine Netflix-Mitgliedschaft nicht das Ausschlaggebende ist. In Berlin, das kann ich für uns sagen, wir rekrutieren natürlich sehr viel Talent als Tech-Company und auch sehr viel international. Das ist das Standard. Da kommen Leute und fragen dich, hast du eine Fitness-Mitgliedschaft? Darf auch meine Freundin dieses Abo nutzen? Wie sieht es mit Netflix aus? Darf mein Hund mitkommen? Selbst das belächelte Müsli-Beispiel ist schon quasi Standard für Hygiene. Da brauchst du gar nicht mit ankommen. Und am Ende des Tages kann man dann eben darüber lächeln. Aber wenn das der Markt so fordert Und wenn das die Leute happy macht, wenn das darüber entscheidet, ob du den besten Developer bekommst oder den 157. besten, dann gibst du die 5-Euro-Netflix-Mitgliedschaft wahrscheinlich auch gerne aus.

Joel Kaczmarek: Okay, krass. Also War for Talents ist voll im Gange. Bevor wir jetzt mal vertiefen, damit Leute wirklich mal verstehen, was bedeutet eigentlich eine agile IT-Organisation, kannst du nochmal rauskehren, warum siehst du eigentlich einen Handlungsdruck? Also why change, sagen ja dann gerne mal die Leute. Warum besteht Notwendigkeit dazu, sich an dieser Front zu verändern?

Boris Lokschin: Machen wir mal das Konterbeispiel dazu. Angenommen, ich habe einen Wasserfall-ähnlichen Ansatz und ich setze mich heute hin und ich möchte ein E-Commerce-Projekt machen. So, und jetzt gehe ich einen Wasserfall mal von vorne nach hinten durch und ich fange an mit der Planungsphase. Ich mache mir Gedanken über Anforderungen, die trage ich zusammen, meistens über Copy-Paste von irgendwelchen Feature-Listen oder sowas wie, aber jetzt, ich möchte den Checkout haben wie bei Zalando und die Suche haben wie bei dem und dem. Dann entsteht meistens eine 500, 600, 700 Zeilen Excel-Tabelle, häufig RFP genannt, Request for Proposal. Diese Tabelle nehme ich dann, nachdem sie ein paar Monate durch ist. Da habe ich meistens auch irgendwelche Berater schon engagiert, weil ich das selber nicht gut kann. Die schreiben mir das Ding zusammen, sagen mir, dass das irgendwie das Must-Have ist. Dann nehme ich diese Tabelle, nachdem sie eben fertig ist, versuche mir einen Dienstleister oder einen Hersteller zu suchen, der dann in mehreren Spalten gemessen wird daran, wie hoch der Abdeckungsgrad ist zu dieser Standard-Funktionalität. Erstmal unabhängig davon, ob das jetzt ein richtiges Vorgehen ist oder nicht. Dann wähle ich den Partner aus, dann wird eben neun bis zwölf Monate implementiert. Dann wird danach nochmal, wenn das fertig ist, nochmal ein paar Monate getestet. Dann wird das ausgerollt und dann sind meine eineinhalb bis zwei Jahre rum. Warum ist das ein Problem? Weil in der Zeit mit sehr großer oder mit an Sicherheit grenzender Wahrscheinlichkeit sich ja alles und alle Business-Hypothesen und Annahmen drumherum verändert haben. Wenn wir selber mal so Persönlich zurückdenken, wie sieht das iPhone 10 vs. iPhone 8 aus? Zwei Jahre zurück, wie schnell kommt so ein Thema wie Voice in den Markt? Wie verändert sich unser Einkaufsverhalten? In welcher Geschwindigkeit stirbt stationäre Fläche weg? Wie schnell möchte ich versuchen, mein Geld zurückzubekommen? Wie viel steigen Mietpreise, Recruitingpreise für gute Leute? Um mich herum hat sich alles verändert in einem vergleichsweise sehr kurzen Zeitraum. Und die klassischen Risk-Management-Methoden auf diese Weise, ich versuche ja Risiko zu managen. Ich will ja das Gefühl davon haben, dass ich A, nichts vergessen habe, B, dass ich all das, was da drin steht, auch für mich notwendig ist und dass das zehn Berater gesagt haben, dass dieses Feature relevant ist. Ich will das Gefühl haben, dass ich nicht übers Ohr gehauen wurde, weil ich habe ja sechs Angebote eingeholt und das mit allen diskutiert. Diese Risk-Management-Methoden erzeugen aber ein viel größeres Risiko und das ist eben Zeit. Ich habe in der Zeit, in der ich das getan habe, am Markt vorbeidesignt, weil Technologie, Wettbewerb, Anforderungen des Kunden haben sich einfach mega stark verändert, weil auch Wettbewerber, die digital schneller, affiner sind, natürlich auch wieder neue Messplatten setzen und neue Standards dem Kunden beibringen, dass irgendwie neue Themen auch relevant sind. Das heißt, es ist primär eine Risikomanagement-Maßnahme, wenn man das mal ganz vereinfacht sein möchte. Ich möchte mein Risiko managen, am Markt vorbeizudesignen, also anforderungsseitig, Anforderungen häufig auch zu implementieren, von denen ich gar nicht weiß, ob mein Kunde sie wirklich braucht, weil die meisten, die das tun, haben ja gar keinen Beleg dafür, dass inkrementell bestimmte Funktionalitäten jetzt die Conversion oder den Umsatz erhöhen. Sie sagen einfach nur, aber der hat das doch auch, dann nehme ich das auf, nochmal 5-Mann-Tage ins Angebot, nochmal 10, nochmal 15. Das heißt, es wird nur teurer, es dauert länger, Und das ist so ein bisschen, glaube ich, der Kulturwandel. Ich möchte eigentlich heute anstatt einer großen Wette in zwei Jahren, 20 kleine Wetten in zwei Jahren machen. Das hat nichts mit Kosten zu tun erstmal primär. Das ist keine Cost-Saving-Maßnahme, das ist eine ROI-Optimierungsmaßnahme. Ich möchte meine Wahrscheinlichkeit, oder wie der Florian Heinemann sagen würde, in so einer Portfolio-Strategie, genauso wie ein Fondsmanager nicht auf eine Aktie setzt, auch wenn sie gut aussieht, ich möchte eigentlich auf 20 kleine Titel setzen, wohl wissend, dass nicht alle davon und nicht alle Pferde ins Ziel kommen werden. Ich möchte einfach viele, viele kleine Bälle in der Luft haben, um auch in der Lage zu sein, die Themen, die halt nicht performen, die Funktionalität, die nichts bringt, auch wieder auszutauschen und wieder auf ein neues Thema zu setzen. Das kann ich natürlich nicht machen, wenn ich in so einem riesigen Block eine große Investition tätige und dann methodisch sie auch so implementiere. Ich kann ja nicht nachsteuern, der Tanker ist dann on the way. und dann merke ich, meine Annahme, dass Responsive Design die mobile Strategie ist, Scheint nicht mehr so die Ware zu sein. Ich hätte eigentlich eine Web-App bauen müssen. Aber vor zwei Jahren, als ich das Ding geschrieben habe, war das noch total der Hype. Ich kann nicht mehr darauf reagieren. Ich habe diese Entscheidung getroffen und ich bin quasi dazu verdammt, sie jetzt runter zu exekutieren. Und deswegen ist das häufig problematisch. Ich möchte mein ROI optimieren. Ich möchte Risiko minimieren. Ich möchte mich selbst in die Lage versetzen, einfach auf neue Themen und Trends und Veränderungen des Markts schneller zu reagieren.

Joel Kaczmarek: Würdest du sagen, ich meine, was du gerade beschrieben hast, finde ich total nachvollziehbar. Ich habe auch an ganz viele Firmen gedacht, wo ich so dachte, ja krass, in was für kurzer Zeit, die sich eigentlich wie gedreht haben. Also die Geschwindigkeit ist ja wirklich riesig, riesig hoch. Würdest du denn sagen, die ganzen KMUs oder vielleicht auch manchmal kleine Familienunternehmen draußen, die vielleicht ein hochprofitables Geschäft gerade haben, die aber genau in so eine Innovationsphase rein müssen, Müssen die sich denn wirklich darüber Gedanken machen, wie sie IT selbst agil bauen können oder könnte man sowas sonst auch outsourcen? Das wäre das, was ich als erstes denken würde.

Boris Lokschin: Ja, du kannst es outsourcen. Also es ist jetzt erstmal nichts damit zu tun, ob du es in-house machst oder nicht. Du kannst auch mal ganz klassisch natürlich zu einer Agentur gehen und die Agentur bitten, in einer agilen Art und Weise mit dir zu arbeiten. Das hat Vor- und Nachteile. Vorteil ist natürlich, klar, wenn auch die agil arbeiten, dann profitierst du von all den Dingen. Nachteil ist natürlich, dass die Voraussetzung ist, dass man selbst so ein bisschen umdenkt. Angefangen von so Themen wie, vergebe ich den Auftrag? Agilität und so Risk-Management-Methoden à la Festpreisprojekt beißen sich halt. Es ist schwierig zu sagen, naja, du Agentur, du musst eigentlich agil sein. Ich möchte auch immer wieder meine Anforderungen ändern können und meine Annahmen ändern und sagen, das doch nicht und das wieder raus. Gleichzeitig hast du aber einen fixen Vertrag. mit einer fixen Timeline, mit einer fixen Scope, mit so einem festen Preis zu liefern. Das funktioniert natürlich nicht. Das heißt, ich brauche irgendein agiles Konstrukt, einen Arbeitsmodus. Häufig wird das dann über einen Teampreis gemacht, dass die Agentur dir sagt, okay, da arbeiten jetzt fünf Leute für dich, die kosten dich das pro Monat. Was sie anforderungsmäßig machen, das ist die Variable, also Scope ist die Variable. Das Team ist konstant, deren Output ist konstant. Das ist natürlich für so einen klassischen Mittelständler oder für ein kleines Unternehmen deutlich schwerer zu greifen, weil de facto die Agentur sagt, naja, wir wissen nicht, was du nächsten Monat bekommst. Fairerweise weißt du das ja auch nicht, du willst ja agil sein. Und in einem normalen klassischen Konstrukt ist Scope fix und alles andere wird dann angepasst, Preis und Team und Zeit. Wie lange brauche ich, um diesen Scope zu bauen? In einer agilen Welt ist es genau umgekehrt. Die Zeit ist meistens konstant. Das ist die harte Konstante. Wir sagen auch, Nichts wird morgen günstiger sein als heute. Das müssen die Leute einfach verstehen. Es gibt kein Incentive zu warten. Du willst eigentlich Dinge schneller raushaben, schneller validieren, schneller dem Kunden vorsetzen. Und deswegen würdest du dann eher die Zeit als Konstante setzen und die Variable ist dann der Scope. Was ich dann tue, das ist flexibel. Da will ich darauf reagieren. Von daher, ich kann es outsourcen, ich kann es einer Agentur geben. Ich muss mich dann eben darauf einstellen, dass der Arbeitsmodus ein anderer ist, dass der Budgetmodus oder Budgetiermodus ein anderer ist, kommen dann so Softwarefaktoren ins Spiel, dass es da natürlich viel mehr darauf ankommt, welchen Trust habe ich, wie sind die Leute, mit denen ich da arbeite, welche Rollen habe ich im Gesourced versus bei der Agentur. Das habe ich natürlich nicht ganz so stark, wenn ich einfach knallhart einen Vertrag schreibe und sage, hey, das Ding muss in drei Monaten fertig werden, kostet 100.000 Euro. Dann haben die einfach zu liefern, ist mir eigentlich relativ egal, wer da hinter den Kulissen arbeitet, ob sie nett sind, ob sie gut kommunizieren, was für Tools sie nutzen, ob ich da Einblick habe in die Entwicklung. Ich habe halt viel weniger Touch auf das Thema, erwarte eigentlich eine Blackbox, die mir dann hingestellt wird. Von daher, ich kann das machen, das funktioniert gut, aber ich muss mich eben entsprechend anpassen.

Joel Kaczmarek: Okay, also ich lerne wirklich eine Verkehrung des Prozesses eigentlich, wie man ihn vielleicht bisher kannte. Also Scope versus Zeit ist ganz interessant. Das ist generell Zeit bei dir, der Kern ist sozusagen dieses Themas, ist ja wirklich mal der erste interessante Zugang. Da sollten wir jetzt mal konkret werden. Also wenn du sagst, das ist ein Organisationsthema auch, wie genau sieht eigentlich Agilität aus organisatorischer Sicht aus?

Boris Lokschin: Vielleicht können wir das anhand der Rollen so ein bisschen durchgehen. Also ich muss natürlich, wenn ich agil sein will und irgendwie Dinge baue, ist das glaube ich keine große Überraschung, dass ich da am Ende irgendeine Form von Entwicklungsteam habe. Das kann natürlich in der Größe und in der Struktur sich sehr unterscheiden. Das kann anfangen mit irgendwie ein paar wenigen Entwicklern, drei, vier, fünf Leute, vielleicht Frontend, Backend, je nach Technologie. Und kann dann eben unendlich groß werden, wenn ich anfange, das zu schneiden. Ich habe vielleicht ein nächstes Team, das sich um sowas kümmert wie die mobile Applikation. Das dritte Team kümmert sich um die App. Das vierte Team kümmert sich vielleicht um ein Land. Also ich kann entweder entlang von Technologiegrenzen oder entlang eben auch bis hin zu sogenannten Capabilities schneiden. Ich kann sagen, naja, das eine Team kümmert sich jetzt nur um das Thema PIM. Das andere Team ist eben auf sowas wie Content Management drauf oder auf PIM wäre Produktinformationsmanagement, auf dem Teil, der sich um vielleicht Produktverwaltung kümmert, Produktsuche, Filter, Katalog, sowas. Ich habe ein Grundteam, das sind erstmal Entwickler und dann so die entwicklungsnahen Rollen, sowas wie vielleicht Qualitätssicherung, Testing. Ich habe sowas wie vielleicht DevOps, irgendwie jemand, der sich so ein bisschen auch um Hardware Deployment kümmert. Und dann, glaube ich, so die entscheidendste Rolle einfach auch aus meiner Erfahrung ist das, was man Product Manager oder Product Owner nennen würde. Das ist eigentlich derjenige, der eben die Frage des Was beantwortet. Was macht das Team? Der die Anforderungen oder den Scope steuert, priorisiert und abliefert. Manche Firmen gehen so weit, dass das eigentlich der CEO light ist. Weil das ist kein Business Analyst. Es gibt bei Beratungen so eine Rolle, die heißt BA Business Analyst. Das ist meistens jemand, der dann zu Anforderungsworkshops fährt, dem Kunden zuhört. und versucht das aufzuschreiben in einer für einen Entwickler verständlichen Sprache, also so eine Art Übersetzer. Und bei dem PO geht es wirklich darum, das ist halt der, der es auch exekutiert. Es ist derjenige, der das Business verstehen muss, so eine Mischung aus Business und Tech-Skills, meistens sehr analytisch, sehr smart. Der muss das Business kennen, der muss genau wissen, hey, wir verkaufen hier Schuhe, wir verkaufen hier Software, wir bauen hier einen Marktplatz für Autoersatzteile. Er muss technisch genug verstehen, um sich von den Entwicklern auch nicht vorführen zu lassen. Er muss in der Lage sein, Tasks runterzubrechen und er muss vor allem permanent repriorisieren. Er ist sozusagen der Filter, er sammelt Anforderungen ein, er sagt 9 von 10 mal Nein, weil er die primären KPIs für dieses Projekt oder Produkt kennt, das heißt, er läuft rum und das nennt sich dann Demand Management, Abteilungen, Einkauf, Marketing, Sales, die kippen dann alle Anforderungen ein, welche Feature die sich wünschen, meistens komplett lose, losgelöst von irgendwas. und er ist dann oder sie ist dann derjenige, der dann eben zu filtern hat und sagen hat, okay, das machen wir, das machen wir nicht, in den meisten Fällen werden Dinge nicht gemacht und in welcher Reihenfolge machen wir sie, wie releasen wir sie, wer macht das und einfach dafür Sorge trägt, dass das einfach auch an den Start kommt. und das ist eine sehr kritische Rolle, weil logischerweise sind diejenigen, es können auch mehrere sein, wenn das Team unten drunter größer ist, häufig das Bottleneck. Also wenn es nichts zu tun gibt für die Entwickler, dann sitzen die halt rum und spielen Pingpong. Das möchte man eigentlich nicht. Das heißt, derjenige ist die ganze Zeit unter Strom. Und die Qualität des POs oder des PMs entscheidet eben wirklich über das, was da rauskommt. Wenn die Anforderungen murk sind, wenn sie nicht aligned sind mit den Business-Prios, dann kommt halt nichts bei raus. Deswegen sind diese Rollen auch oder ist diese Rolle auch sehr, sehr schwer zu besetzen, sehr schwer zu finden. Noch schwerer als gute Entwickler tatsächlich, weil diese Leute, wie gesagt, ein Mix sind aus Business-Tech, also ein bisschen Entrepreneurial. Idealerweise möchte ich eigentlich jemanden haben, der so ein bisschen unternehmerisch auch denkt und nicht einfach nur so Anforderungen und Tickets runterschreibt. Das ist, glaube ich, so die entscheidendste Rolle in diesem ganzen Konstrukt.

Joel Kaczmarek: Aber das klingt ja in der Tat schon fast wie eigentlich eine CEO-Aufgabe oder CPO, wenn man hat, also ein Product Officer. Also eigentlich eine hohe strategische produktnahe Verantwortung. Heißt das in der Konsequenz, dass so eine Rolle, und wenn ich dich richtig verstehe, müsste es eigentlich davon mehrere geben? Also hast du einen Product Owner oder hast du einen für sozusagen unterschiedliche Produktbausteine?

Boris Lokschin: Du hast normalerweise einen für unterschiedliche Produktbausteine. Wie gesagt, das orientiert dich natürlich sehr stark auch an der Teamgröße und auch an deiner Ambition am Ende des Tages und auch an der Fähigkeit. Und da kommt so Methodik so ein bisschen zusammen mit Technologie. Idealerweise bist du in der Lage und das ist ja ein bisschen dieses Thema mit Agilität. Du möchtest ja eigentlich viele Dinge parallel machen und nicht sequenziell. Wasserfall ist ja sequenziell und du möchtest ja eigentlich parallel Dinge raushauen. Du möchtest ja nicht erstmal die eine Wette machen und dann die andere, sondern du willst ja eigentlich zehn Pferde gleichzeitig ins Rennen schicken. Und umso mehr du das tust, umso mehr Teams unten drunter du hast, umso größer deine Lieferfähigkeit, Outputfähigkeit deines Teams, umso mehr brauchst du natürlich an POs und die sind dann genau diejenigen, die dann an den sogenannten CPO oder VP Product reporten würden. Und der hat tatsächlich eine sehr hohe strategische Bedeutung. Ja, je nach Company-Typ natürlich. Bei so einer Company wie uns, wir sind eine Product-Company, ist das natürlich eine der zentralsten Rollen. Weil unser Business ist ja das Produkt. Wenn du eine E-Commerce-Company bist, in den meisten Fällen müsste das genauso sein. Der ist das Business, das Hauptasset müsste die Plattform sein. Das, was im Warehouse ist, ist halt austauschbar. Bei ganz vielen E-Commerce-Modellen heute ist das eben nicht so. Da ist es immer noch eine sehr klassisch retail-geprägte Organisation. Da ist immer noch der Einkäufer irgendwie der König und sein Einkaufsgeschick entscheidet über Marge. Und wenn du so auf die Online-Pure-Player guckst, hier im Berlin-Hamburger Raum, die sehr erfolgreich sind, da ist es, glaube ich, der CTO, der CPO, der Marketing-BI-Mensch. Das sind, glaube ich, die Kernrollen, die am Ende über Erfolg und Misserfolg entscheiden. und nicht derjenige, der eben Sortimentshandling macht. Weil am Ende kann es dein Sortiment sein, du kannst zum Marktplatz werden, du kannst andere verkaufen lassen. Das ist eher dein sekundärer Teil.

Joel Kaczmarek: Es gibt so ein schönes Buch, das heißt, ich glaube, von Ori Breffman, Der Seestern und die Spinne. Und da erklärt er so Organisationskonzepte relativ ähnlich, glaube ich. Der sagt, es gibt halt Spinnen, die haben einen Kopf und wenn du den Kopf abschlägst, sind die ganzen Beine nutzlos, die fetteln sich zusammen und es ist platt. So und beim Seestern ist es eigentlich so, der hat gar kein zentrales Gehirn, sondern jeder Arm arbeitet eigentlich für sich, hat sozusagen ein Funktionsprinzip, aber kein zentrales Gehirn. Als Beispiel hat er dann so anonyme Alkoholiker, traurigerweise auch sowas wie Al-Qaida, also dass du so Zellenvorgänge hast. Verstehe ich das dann richtig, dass eine moderne, agile IT-Infrastruktur, also jetzt auf der personellen Seite, auf der organisatorischen, dann so ein Stück weit wie ein Seestern funktioniert, dass du eigentlich fünf Arme hast, die fairerweise schon irgendwo zusammenlaufen, wie du gerade gesagt hast, Head of Product oder VP Product oder, oder, die aber an sich für sich genommen sozusagen relativ autark arbeiten, dass man diesen Zeitgewinn hat?

Boris Lokschin: Das wäre das ultimative Ziel. Also wenn du in der Lage bist, diese Breite zu erzeugen, also Breite heißt einfach auch personell, du brauchst nicht fünf Product Owner auf einem Drei-Mann-Developer-Team, es sei denn, du hast irgendwas super Spezielles als Applikation vielleicht, aber normalerweise hast du eine gewisse Ratio von einem Product Owner auf vielleicht vier, fünf, sechs Leute, je nach Komplexität dessen, was du da baust. Das heißt, wenn du dir erlauben kannst, budgetär und auch von deiner Ambition, diese Breite zu haben in deinem Entwicklungsteam, dann hast du mehr Product Owner. und dann kommst du genau an den Punkt, naja, eigentlich, wenn ich richtig schnell sein möchte, wenn man so liest, naja, da gibt es Firmen, die machen 10 Deployments pro Tag, 20, 30 Deployments pro Tag, dann machen die das und können das natürlich machen, weil genau wie du sagst, jede Säule, das Team, was sich um Product kümmert oder um das Produktmanagement, ist natürlich in der Lage, end-to-end lieferfähig zu sein von, ich habe Anforderungen aufgenommen, ich habe sie implementiert, getestet, ich habe sie live gebracht, ohne das Team, das parallel an dem Content-Management-Baustein arbeitet, irgendwie irgendeine technische oder methodische Abhängigkeit zu bringen. Trotzdem versuchst du dann natürlich in irgendeiner Art und Weise auf Produktebene das eben zu synchen, dass es nicht komplett autark läuft, entweder zu synchen und zu steuern über so Metriken, also wir bauen ja Feature nicht aus Feature-Wegen, sondern wir bauen Feature, weil wir die Conversion-Rate verbessern wollen, die Warenkorbgröße, die Abbruchquote senken wollen, die Funnel Size erhöhen wollen. Also gibt es da irgendeine Business-Implikation, über die der Product Manager als CEO Light eben auch nachzudenken hat. Er ist eben nicht nur der Schreiber von Tickets, sondern er überlegt sich, für wen mache ich das? Wer ist der Stakeholder? Er überlegt sich, woran messe ich Erfolg? Er überlegt sich, was ist die Metrik, die ich beeinflussen möchte? In so einem Fall kommst du eben zu dem hoffentlich Idealbeispiel dessen, dass wie dieser Seestern mit einem sehr, sehr dünnen Steuerungslayer oder Synchronisationslayer, vielleicht viel eher auf Produktseite, eigentlich primär autark arbeiten kannst und dann natürlich über so Strategie und so Themen steuerst. Das muss aber nicht so weit gehen, geht auch bei den allermeisten fairerweise nicht oder noch nicht so weit. Die meisten strugglen ja schon damit, überhaupt eine agile Organisation mit einem kleinen Team aufzubauen. Und auch das kann ja agil sein. Du kannst ja irgendwie vier Developer haben, ein Produkt oder ein QA. Und du möchtest trotzdem, dass diese Jungs nicht an sechs-Monats-Projekten denken, sondern dass die alle zwei Wochen Sprint für Sprint Dinge raushauen. kommerziell verwertbar haben, dass du nicht einfach sechs Monate lang Code baust, der aber kommerziell nicht verwertbar ist, weil er ist noch nicht getestet, er ist noch nicht dokumentiert, weil das kommt ja alles später, kommt ja erst in sechs Monaten. Du möchtest eigentlich, dass inkrementell jedes Feature, was du geliefert hast, einsatzfähig ist, dass du sofort das in die Produktion geben kannst, dass das live ist. Dazu gehört auch natürlich, dass es eben dann End-to-End oder in Agilität heißt es häufig Done-Done, so ein Done-Done-State, nicht so Done im Sinne, Code ist geschrieben, so Hände weg. Sondern hey, es ist dann, dann, es ist getestet, es ist Code-reviewed, es ist abgenommen von dem Business-Stakeholder, der es bestellt hat, dieses Feature, so raus damit. Und das machst du dann eben nicht einmal pro sechs Monate, einmal pro zwölf Monate, sondern in den meisten agilen Methodiken, aller Scrum machst du das alle zwei oder drei Wochen, sogenannten Sprints. Also das ist so der Starting Point. Und wenn du dann wächst und dann versuchst, das weiter zu beschleunigen, kommst du irgendwann von, das ist eben der besagte Evolutionsschritt von, hey, ich mache es nicht mehr einmal pro Quartal, einmal pro sechs Monaten, ich mache es jetzt aber auch nicht mehr alle zwei Wochen, sondern plötzlich bin ich in der Lage, weil ich parallel arbeiten kann, zehnmal pro Tag. Releases rauszuhauen. Das heißt also in zwei Wochen hundertmal statt einmal. Und da sieht man auch sozusagen diese exponentielle Dimension dessen, wie groß der Schritt nochmal ist, weil von einmal pro Quartal auf alle zwei Wochen ist ein viel kleinerer Schritt als eben dieser zweite. Und das ist auch der große Unterschied für viele Firmen, die wir auch zum Beispiel in der täglichen Beratung sehen, die sehr stark noch träumen davon, aus dieser Wasserfallwelt in eine zwei, drei Wochen Release-Welt zu kommen. Und übersehen dabei, dass das eigentlich etwas ist, was sie methodisch hätten vor fünf, sechs, sieben Jahren schon aufbauen müssen, als das irgendwie ein Wettbewerbsvorteil gewesen wäre und ihre digitalen Wettbewerbe heute eher auf einem Modus sind von zehn Diplomats pro Tag. Also sprich, die Fähigkeit, die sie versuchen zu erschließen, ist eigentlich schon Schnee von gestern.

Joel Kaczmarek: Ja, krass. Kannst du doch mal spezifizieren, wie ich Konflikte dabei verhindere? Also man wird ja da oft in so Branches denken, wenn ich mich nicht täusche. Also man macht quasi andere Arme, andere Äste auf an so einer Software, an so einem Code. Wie verhindere ich, wenn ich zehn Deployments pro Tag habe, dass davon nicht jeden Tag zwei oder drei miteinander konfligieren?

Boris Lokschin: Also dafür, das ist sozusagen die gute Nachricht, in den meisten Fällen oder zumindest bei den modernen Lösungen, die man einsetzt, ist das Tooling dafür schon gesetzt. Das ist nichts, worüber ich mir als Produkt-Owner oder Geschäftsführer oder Marketingverantwortlicher Gedanken machen muss. Es gibt sozusagen Tools wie Git. Zum Beispiel, das ist eine Verwaltung für Code und die Code und Versionen von Code gut managt. Es gibt Tools für Deployment und das Lösen von Konflikten und das Auflösen von Modulabhängigkeiten, die mir das alles abnehmen. Sondern in den meisten modernen Tools ist das quasi schon gesetzt und jeder moderne Entwickler, für den ist das quasi gesetzt. täglich Brot, also das ist jetzt kein Skill, es ist doof, wenn ich diese Skills nicht habe, dann ist es vielleicht auch eher ein Kriterium, Leute nicht zu nehmen. Aber das ist tatsächlich ein Standardproblem, was schon hunderte Male gelöst wurde. Ich muss diese Konflikte eher managen auf konzeptioneller Seite. Ich muss verhindern, dass der Produktmanager, der sich im Feature A kümmert, irgendwas baut, was konfliktiert mit dem, was der andere da an seinem Schreibtisch tut.

Joel Kaczmarek: Jetzt lass uns mal ein bisschen über Organisationsformen sprechen. Also du hast Scrum gerade schon angerissen, vielleicht vertiefen wir das nochmal, aber es gibt ja noch weitere, auch vielleicht miteinander kombinierbare Möglichkeiten, um eine Organisation auf sowas einzustellen. Lass uns mal mit Scrum beginnen, dass wir vielleicht nochmal Besonderheiten von sowas rauskehren und den Leuten das irgendwie

Boris Lokschin: Genau, es gibt insbesondere in der Agilität verschiedene Methodiken, die alle unterschiedlichen Ursprungen und unterschiedliche Ziele haben, aber viele Gemeinsamkeiten sharen. Es gibt dann vielleicht so ein paar, so ein Scrum ist wahrscheinlich das bekannteste. Es gibt auch sowas wie Extreme Programming, es gibt sowas wie Kanban, eher so eine Task-Methodik. orientiertere Methode. Der ein oder andere nutzt das vielleicht sogar schon implizit bei sich im Büro, in dem man so Bretter hat. Da steht dann irgendwie in Planung, in Progress, dann. Das ist so eine Kanban-ähnliche Form. Und dann gibt es natürlich, und das ist glaube ich der wichtigste Punkt an der Stelle, diese Scrum-Methodiken, für die es auch Zertifikate, Schulen und Bücher gibt oder Kanban-Methodiken, sind meistens so Basis-Leitfäden. Also ich habe kein Unternehmen gesehen, was quasi Scrum in seiner Grundform implementiert. Das macht man normalerweise nicht, sondern es ist meistens ein Guide, der auch sehr stark über Prinzipien steuert, also welchen Stellenwert hat das Team? zum Beispiel, wie wichtig ist Kommunikation. Da gibt es so Formen, die daraus fließen, wenn ich sage, Kommunikation ist wichtig, dann habe ich methodische Implikationen, dann habe ich sowas wie Stand-Ups, dass das Team einmal pro Tag sich fünf Minuten Zeit nimmt an so einem gemeinsamen, visualisierten sich darüber zu unterhalten, wie wir vorankommen, was es für Blocker gibt, wer was wie auflösen kann. Es gibt sowas wie Retrospektiven, dass man sich einfach in gewissen Abständen hinsetzt und sagt, hey, was haben wir gelernt in den letzten zwei Wochen? Was hat gut funktioniert? Was blockt uns? Was müssen wir als Team verbessern, um unsere eigene Prognose zu halten? Wir haben ja committed oder versprochen, wir sind ja accountable jetzt, wir sind ja end-to-end lieferfähig. Das heißt, wir haben quasi dem Business versprochen, dass wir diese Anforderung umsetzen. Wir fühlen uns dazu auch verantwortlich, Wir adjustieren uns jeden Tag an diesem Brett stehend und am Ende der Zeit wollen wir irgendwie schauen, dass wir in so einer Retrospektive das mal analysieren und gucken, was können wir für den nächsten Sprint verbessern. Das sind so Dinge, die dann herausfließen, aber mehr eben aus diesen Prinzipien. Das heißt, wenn ich daran glaube, dass Kommunikation wichtig ist, dass Menschen wichtiger sind als irgendwie Tools und Prozesse, Dann kommt es halt sehr stark darauf an, wie ich das implementiere. Und die allermeisten Unternehmen starten natürlich so ein bisschen nach Lehrbuch. Es gibt auch so Agile Coaches, heißen die dann, die einem so ein bisschen beibringen, hey, es braucht diese Rolle, es braucht einen Scrum Master, der das Ganze hier orchestriert. Die dann aber sehr, sehr schnell Die für sich richtige Konfiguration und auch die für sich richtigen Tools und Praktiken herausfinden. Einfach mal um so ein Beispiel zu nennen. Der eine sagt, hey, Kommunikation ist wichtig und täglich Sync ist wichtig. Und das machen wir, indem wir an einem Brett stehen oder an einem Brett uns unterhalten. Und das andere Unternehmen sagt, das machen wir in einem Slack-Channel und erfüllt auch seinen Zweck. So, das muss jede Company für sich finden. Und manche gehen dann sehr weit. Man hört ja auch so in der Branche, gibt ja immer wieder so von Unternehmen, Zalando und Co, ja, die announcen dann so ihre Organisationsmodelle, die ja meistens alle darauf abziehen, eben noch schneller zu werden, noch produktiver, noch mehr Themen gleichzeitig rauszuhauen. Und das sind dann sozusagen die ultimativen Beispiele von so Weiterentwicklung, wo sich jemand hinsetzt und sagt, wie können wir das Team noch effizienter steuern, wie können wir Leute noch besser rotieren, noch besser einsetzen, mehr Accountability geben, dass die Leute sich noch verantwortlicher fühlen für ihre Versprechen, ja.

Joel Kaczmarek: Wenn ich mir so meine Vorbereitungen, die ich auch von dir mitgefüttert bekomme, mal anschaue, dann waren da so heiße Buzzwords drin wie Raki, Move, Radical Agility, Holacracy. Das sind so ein paar der Buzzwords, die es so rund um Organisationsgestaltung und Kommunikation gibt, die, glaube ich, vielen Leuten irgendwie unterkommen. Kannst du dazu mal so ein bisschen einen Überblick geben, was das eigentlich ist, was die Funktionsweise dahinter ist, welche Absicht das hat, dass man mal so ein grobes Gefühl bekommt, wie sowas eine Rolle spielen kann?

Boris Lokschin: Genau, also das sind jetzt einfach ein paar Beispiele, zwei davon jetzt sowas wie Radical Agility, das war glaube ich der Begriff, den Zalando seinem Modell gegeben hat, was die glaube ich mittlerweile auch wieder weiterentwickelt haben, wo tatsächlich die Idee war, hey, wie können wir die Teams noch autarker schneiden, wirklich diese End-to-End-Verantwortung, wie können wir sicherstellen, dass die Teams weniger Abstimmungsbedarf haben, untereinander schneller Dinge rausbekommen. Move ist, glaube ich, der Name, den sich das About-You-IT-Team gegeben hat, wo die auch versuchen, quasi den gleichen Zweck zu erreichen, auch verbunden damit, dass Leute die Möglichkeit haben, in verschiedene Bereiche reinzuschnuppern, dass man an Leuten nicht verliert, weil sie irgendwie kein Interesse haben an einem Thema, in dem sie arbeiten oder das Unternehmen verlassen. Raki ist wiederum was ganz anderes. Es gibt diesen Begriff der Raki-Matrizen, also Raki mit C geschrieben. Das steht dann meistens für sowas wie Responsible, Accountable, Consult und ist informed, also die vier Buchstaben. Das ist meistens ein Versuch, eine Matrix-Organisation, also wenn ich sage, ich habe jetzt keine Hierarchie, ich habe jetzt nicht Projektleiter, unter ihm ist der Teamlead, unter dem Teamlead der Developer, Developer Reporter, ein Teamlead, Teamlead an den Projektleiter, Projektleiter verantwortet Budget, Zeit, Teamleiter verantwortet irgendwie technischen Output, Developer schreibt Code. So, das wäre eine sehr, sehr hierarchische Organisation. Häufig habe ich eben sowas wie eine Matrix. In einer Matrix ist es so, ich kann vielleicht das als Beispiel mal sagen, wie das bei uns organisiert ist. Wir haben sogenannte Pools. Die Pools gibt einen großen Pool Engineering. Da ist QR, Developer, solche Rollen drin. Es gibt einen Pool für Controlling, das sind klassischerweise Projektleiter, PMO-Profile enthalten, Architekten und dann eben Product Manager und Technical Writer. Das sind so die fünf Pools. Und aus diesen fünf Pools wird quasi jeder, wir nennen das Technology Stream, gestuft. Das heißt, wenn wir uns überlegen, wir wollen morgen jetzt investieren in Voice, wollen wir jetzt irgendwelche Voice-Features bauen, dann setzen sich diese fünf Pool-Owner zusammen. stuffen diesen Pool, sagen, okay, welcher Architekt geht da rein, wie viele Developer braucht es, wer ist der Technical Writer, wer ist der Produktmanager. Und dann sind die quasi in so einer Matrix drin, weil es gibt quasi keine klare Hierarchie, sondern es gibt eine Zahl von Leuten, die sozusagen horizontal geschnitten werden eben von diesen Pools. Und ich kann diesen Pool jederzeit umhängen, ich kann ihn auflösen, ich kann ihn immer signen. Und dann gehst du klassischerweise durch und sagst, okay, ich kann jetzt nicht hierarchisch das vergeben, wer wofür verantwortlich ist, aber ich kann so eine Raki-Matrix anwenden. Ich kann sagen, du bist accountable da und dafür, du bist responsible da und dafür. Du musst bei dem Thema informiert sein, du musst bei dem Thema mitberaten. Beraten wäre zum Beispiel so, dass du kannst sagen, der Architekt, Der hat eine Consulting-Funktion für etwas, wie etwas implementiert wird. Er ist aber nicht accountable dafür, weil am Ende trifft er keine Budget-Decision. Er kann das nicht overrulen. Wenn ihm der Projektleiter sagt, naja, auf dem Stream ist aber nicht so viel Geld oder nicht so viel Zeit, schöne Lösung hast du dir da ausgedacht, passt aber nicht, ist nicht pragmatisch genug, dann hat er halt Pech gehabt, mal ganz doof gesagt. Das wäre so ein klassisches Raki-Modell, um eben eine Matrix-Organisation zu handeln. Und dann gibt es die besagten Scrums, Kanbans etc., die dann eher versuchen, auf unterschiedliche Art und Weise Anforderungen entweder in so zwei, drei Wochen Releases zu bekommen oder dann in einem Kanban-Modus eher so Task-basiert eine Aufgabe durch so einen Workflow zu schieben.

Joel Kaczmarek: Kannst du mal den Unterschied sagen zwischen Responsible und Accountable, was du bei dem Raki zum Beispiel gerade gesagt hast? Wie unterscheidet sich das? Das klingt ja für einen Laien jetzt erstmal verhältnisweise ähnlich.

Boris Lokschin: Ja, also Accountability ist quasi die höchste Form. Also ich kann halt Accountable sein, aber ich muss nicht derjenige sein, der es umsetzt. Also so ein klassisches Beispiel ist, hatten wir jetzt gerade gestern nochmal diskutiert, wenn ich zum Beispiel der Projektleiter bin auf einem Stream bei uns, da bin ich natürlich Accountable für Time and Budget. Ich bin derjenige, der am Ende gefragt wird und der den Kopf hinhält dafür, dass mehr Budget ausgegeben wurde oder dass es länger gedauert hat. Aber ich bin ja nicht selber derjenige, der den Code schreibt. Das heißt, ich kann ja gar nicht responsible sein. Responsible, also derjenige, der das enforcen kann, ist dann natürlich der Teamlead. Der steuert ja das Team. Oder der Produktmanager, weil er gibt dir die Anforderungen vor. Ich kann halt als Projektleiter hingehen und sagen, ich bin accountable für die Zeit. Und ich sehe Leute, ein klassisches Beispiel wäre, die Zeitbuchungen sind nicht gut. Die Leute buchen nicht die Arbeitszeit in Tickets. Wenn die Arbeitszeit nicht gebucht ist kann ich natürlich keinen Fortschritt erkennen. Ich kann jetzt nicht sehen, wie viel Geld habe ich denn verbraucht und wie sieht denn mein zeitlicher Fortschritt aus. Ich kann mich aber als Projektleiter ja nicht hinsetzen und für Entwickler Zeit nachbuchen in deren Aufgabe. Das weiß ich ja gar nicht. Das heißt, meine Aufgabe ist es, das zu flaggen. Meine Aufgabe ist es, das einzutreiben. Meine Aufgabe ist es, das so oft zu raisen, bis das gemacht wird. Weil am Ende kommt irgendjemand aus Management und fragt mich, hey, wie stehen wir denn hier? Wie kommen wir voran? Sind wir noch im Budget, im Time? Meine Aufgabe ist es aber nicht, das zu tun. Da ist eben jemand anders für responsible und macht das entsprechend. Genauso umgekehrt wie als Projektleiter habe ich dann vielleicht ein C oder ein I. Ich bin informiert über technische Probleme. Ich bin eingeladen in so ein Stand-up. Ich verstehe ja vielleicht inhaltlich gar nicht so genau, was dort passiert. Ich kann es nicht genau beurteilen. Aber ich habe trotzdem eine Informationspflicht. Ich habe das I bei mir in der Raki-Matrix. Ich bin informiert, ich muss teilnehmen, ich muss das lernen. Aber ich habe da jetzt nichts inhaltlich beizusteuern. Ich kann ja nicht sagen, Leute, aber programmiert das doch so oder macht das doch auf diese Art und Weise.

Joel Kaczmarek: Mir geht es natürlich darum, diese ganzen Buzzwords, die da so rumfliegen, diese Systeme, dass wenn man vielleicht als KMU, was noch nicht so da eingetaucht ist, mit konfrontiert wird, das grob versteht, Wir hatten jetzt irgendwie Holacracy noch, hatte ich noch genannt und das ist, glaube ich, auch was, was man mal erwähnt haben sollte. Also stammt ja so aus dieser Ecke der Soziokratie, glaube ich, abgeleitet, war eine ganze Zeit lang sehr, sehr angesagt. Magst du da auch mal ein, zwei Sätze zu sagen, ehe wir mal die Überleitung machen, was ja eigentlich der Grundgedanke hinter all diesen Ansätzen ist?

Boris Lokschin: Genau, also mal ganz vereinfacht gesagt, bei vielen holokratischen Modellen steckt so ein bisschen die Idee dahinter, dass man eben diesen ultimativen Weg beschreitet und wirklich jegliche Form von Hierarchie auflöst. Dass da irgendwie vielleicht so ein bisschen utopisch oder so ein bisschen träumerisch. die Idee dahinter steht, dass du irgendwie komplett sich selbst organisierende Organisationen hast, wo nicht mehr der Titel, nicht mehr die Position, ob du jetzt CEO bist, gibt es dann quasi gar nicht. Da hat jeder den gleichen Schreibtisch, da hat jeder das Gleiche zu sagen. Du hast dann irgendwie Pools, Circles oder wie auch immer, die Teams organisieren. Das ist so ein bisschen ein Versuch, sehr komplexe Org-Charts zu bekämpfen meistens, mit ganz vielen Hierarchiestufen, Approvals, Richtungen hoch und runter. Da gibt es auch ein paar bekannte Firmen, die das ja weltweit versuchen für sich zu implementieren. Ich glaube, das bekannteste wird wahrscheinlich Zappos sein in den USA, die von Amazon gekauft wurden, so ein bisschen das Zalando der USA, die ja sehr medienwirksam das gemacht haben und dann mit ganz viel, teilweise auch Pain, das umgestellt haben. Da gibt es unterschiedliche Sichtweisen zu, Meinungen zu, wie gut oder schlecht das funktioniert, für wen das passt, aber Ich glaube, man kann sich wirklich mal merken, wenn man seine Organisation mal komplett auf links drehen wollen würde, was für die meisten logischerweise sehr, sehr schwierig ist, dann würde man wahrscheinlich so ein Modell wählen. Auch im Dienstleisterumfeld gibt es, wir haben zum Beispiel einige Partner, die so organisiert sind, einige Agenturen, die auf diese Art und Weise arbeiten und versuchen sozusagen auch Komplexität, Abstimmungsbedarf, Freigaben und auch viel Politik einfach damit zu bekämpfen, dass das einfach aufgelöst wird.

Joel Kaczmarek: Was ich ja so versuche oder so ein bisschen ausgemacht habe als das Momentum, was sie alle so ein Stück weit verbindet, ist ja eigentlich Verantwortlichkeit unter dem Strich. Also wenn du sagst, es geht darum, irgendwie zehn Deployments pro Tag zu haben, der Kernrisikofaktor ist Zeit, das heißt, ich habe irgendwie Risikomanagement trifft auf irgendwie Produktivität, dann ist ja eigentlich das Gefühl von Verantwortlichkeit, und das steckt ja bei so einem Raki irgendwie auch sozusagen wortwörtlich sogar mit drinnen, doch gefühlt so wahrscheinlich das,was am zentralsten ist, oder? Also eigentlich musst du doch schaffen,dass so eine IT-Struktur selber laufen kannund jeder weiß, was er zu tun hatund wo sein Bereich anfängt und wo er aufhört.

Boris Lokschin: Absolut. Also das ist sehr, sehr schwierig, das sozusagen diktatorisch zu managen. Du musst natürlich so ein gewisses Set an Values vorgeben. Du musst irgendwie, allem muss schon klar sein und das ist auch das, wo der Abstimmungsbedarf dann noch notwendig ist. Worauf sollen gewisse Dinge einzahlen? Du kannst dich dann eben zusammensetzen und sagen, hey, unsere Targets eben für das nächste Quartal sind die und die. Ja, wir müssen jetzt hier primär an der Conversion Rate arbeiten. Mal ganz vereinfacht gesagt und dann versucht das jeder für sich dann runterzubrechen und zu sagen, okay, ja, ich bin in dem Bereich oder dem Teil des Systems und in der Applikation, was kann ich mit meinem Team denn dafür tun, ja, und werde auch am Ende daran gemessen, wie war mein Wertbeitrag eben zu so einer Metrik, zu so einem KPI. Und idealerweise möchtest du natürlich, dass sobald allen klar ist, in welche Richtung es gehen will, willst du dich nicht hinsetzen und denen irgendwie die Lösung und die Aufgabe für den Teil des Systems vorgeben, sondern du möchtest eigentlich, dass sie maximal einfahren, wo sie das tun, vielleicht teilweise auch bis hin zu Research. Das heißt, naja Leute, ich weiß gar nicht, was wir genau am Checkout machen müssen, aber ihr als Team, ihr ohnt diesen Checkout, ihr ohnt das Design, die Technologie, ihr könnt alles machen, auch die Metriken, die Analytics-Komponente, Schaut euch das an, analysiert das, kommt mit Vorschlägen und macht das, was ihr meint, was den höchsten Impact hat auf diesen KPI oder was am meisten darauf einzahlt. Wenn du das hinkriegst und so Teams hast, die dann eben sehr, sehr autark sind und sich auch, und das ist, glaube ich, das zweite Thema, die auch ein hohes Gefühl haben an Accountability. Accountability sieht man am einfachsten in der Realität an sowas wie Lieferfähigkeit. Also wenn ich ein Team habe, was sozusagen das auch so empfindet, als das ist mein Stück Produkt, mein Stück Software, mein Stück Plattform, mein Stück Projekt und hinter den Commitments steht zur Timeline, zu Deadlines, zu dem, was ich da verspreche und auch alles daran setzt, das zu schaffen und sagt, hey, ich fühle mich schlecht, ich habe eigentlich irgendwie dem Business versprochen, das zu machen. und Und es ist nicht so wie in so einer klassischen Organisation, wo sehr häufig einem Austreten leicht fallen, weil Ziele, Methodiken, selbst das Tooling und das Vorgehen einem vorgegeben wurden. Da kam jemand zu mir und hat gesagt, so Joel, bau das mal so. Und mit dem Tool bis morgen und du hast maximal zwei Tage Zeit, weil ich habe das so geschätzt. Das ist natürlich so ein Modell, in dem du dich minimal accountable fühlst, weil du hast ja alle Türen offen, um dahinter zu sagen, ich habe es nicht geschätzt, ich habe es nicht analysiert. In der Entscheidungsfindung war ich nicht verwirrt. Ob die Maßnahme richtig war, hat mich auch keiner gefragt. Mit dem Tool hätte ich gleich sagen können, dass ich das nicht schaffe. Und wer die Schätzung macht, weiß ich auch nicht. Ich habe natürlich mein Bestes gegeben. Ich habe richtig Gas gegeben und alles rausgeholt, aber ich habe nur 40% geschafft. Und genau das willst du nicht. Du willst eigentlich sagen, hey Joel, du hast doch selber entschieden, was du tust. Du hast gesagt, wie du das baust. Du hast selber die Zeit geplant. Du hast gesagt, hey, ich habe dich nicht gefragt. Du hast mir gesagt, in zwei Wochen wird das fertig sein. Dann sei doch auch so gut. Sei doch mal so accountable. Und fühle dich mal so verantwortlich. es auch zu liefern und auch mögliche Probleme aus dem Weg zu räumen. Wenn irgendwas unterwegs passiert, worauf du keinen Einfluss hast, heb die Hand, ich versuche dir zu helfen. Aber ansonsten, wenn du mir am Montag sagst, das kommt und ich sonst zwei Wochen nichts von dir höre, dann gehe ich doch fest davon aus, dass das, was du mir versprochen wirst, auch umgesetzt wird. Und eigentlich möchtest du ja genau das. Und das hat vielleicht auch so einen kleinen Bogen. dann wieder zurück zu diesem Recruiting-Thema. Das hat natürlich auch wieder viel mit Identifikation zu tun. Hast du Leute, die Dienst in der Vorschrift machen? oder hast du Leute, die einfach Lust darauf haben, die das auch cool finden, die Spaß daran haben, die das auch ein Stück weit als ihr Baby sehen. Und je besser du diese Bereiche quasi managen kannst, umso mehr Output schaffst du und umso mehr Accountability hast du da drauf.

Joel Kaczmarek: Was siehst du als Faktoren, die du für den Aufbau von so etwas benötigst? Was sind da so zentrale Aspekte, die man auf der Uhr haben sollte, wenn man so etwas für sich entwickeln will?

Boris Lokschin: Ich glaube, es hat sehr, sehr viel damit zu tun, was eigentlich die Aufgabe ist. Also ganz einfach gesagt, wie spannend ist das? Das ist, wie gesagt, ein Arbeitnehmermarkt. Die Leute suchen sich das aus. Das heißt, du musst dir erstmal überlegen, hey, wie kriege ich das richtige Talent da bei mir rein? Worauf haben die Leute Lust? Technologisch, inhaltlich, konzeptionell? Ist das irgendwie eine spannende Aufgabe oder nicht? Das, glaube ich, hat eine sehr starke Strahlkraft und einen sehr starken Pull-Effekt. So, dann Setup, Umgebung, ja, kann ich alles aus dem Weg räumen, was dieser Rockstar-Developer, den ich da jetzt geschafft habe, irgendwie anzuziehen, was er braucht, von Umzug, ja, über Office, über Equipment. Das sind halt immer so diese kleinen Dinge, die leider eben auch den digitalen Transformationswilligen so schwer fallen, ja. Das merken wir sehr stark, Leute fallen aus der Gehaltsbandbreite, du kannst nur ein Dell haben, iPhone geht auch nicht und irgendwie T-Shirts zum Office kommen geht nicht und rasier dich doch mal, ja, und nee, dein Hund hat hier nichts zu suchen. Und Müsli gibt es auch nicht und an einem Kaffeeautomaten hängt so ein Münzeinwerfergerät. Das ist so traurig, aber wahr, das kommt halt häufig vor.

Joel Kaczmarek: An solchen Banalitäten scheitert das dann echt?

Boris Lokschin: Das scheitert ganz, ganz häufig und das ist wirklich, wirklich traurig. Das sehen wir sehr, sehr häufig, teilweise auch zum Beispiel für Profile, die wir weitergeben in Unternehmen, wo du hinterher fragst, hast du den eingestellt? So, nee. Warum denn nicht? Ja, aber der passt nicht in Geizbandbreite. Was heißt das denn? Und dann lernst du, ja, der wollte 4.000 Euro mehr, als du für die Rolle hattest. Und dann sagst du, 4.000 Euro mehr, das sind irgendwie 300 Euro pro Monat brutto, 150 Euro netto. Deswegen hast du diesen Rockstar-Developer. Also was optimierst du denn? Welche Metrik hast du denn damit optimiert? Du gewinnst ja digital nicht, indem du deine Downside optimierst, sondern indem du nur die Upside optimierst. Du hast ja zwar 150 Euro gespart, kriegst aber eben einen Developer, der 100 Mal schlechter ist. Das kann es doch nicht gewesen sein. Das war doch die falsche Metrik, an der du geschraubt hast. Oder eben wirklich sowas wie teilweise wirklich auch Hardware. Wir haben Leute, die sagen, hey, warum haben wir nicht? Wir geben keine Macs raus, wir geben kein iPhone raus oder Fitnessmitgliedschaft oder irgendwelche Candybars. Ist nicht. Häufig auch mit dem Argument natürlich in einem Corporate Environment, das müssen wir dann für alle machen. Wenn wir das jetzt hier erlauben, wenn hier Kaffee for free ist, dann muss ich das überall machen. Wenn die Jungs eine Fitness-Mitgliedschaft kriegen, dann muss ich das hier über 10.000 Leute ausrollen. Teilweise berechtigt, teilweise nicht. Das ist eine Argumentation, die vielleicht ein Stück weit nachvollziehbar ist, aber spielt ja gar keine Rolle. Es hilft ja nichts, wie man so schön sagt. Damit schießt du dich ja einfach schon per Definition ins Ausland. Finde halt ein Setup, vielleicht ist das ein Greenfield, vielleicht musst du was ausgründen, was das erlaubt. Und in der Realität ist es wirklich so, dass diese Gründe und das vielleicht auch so ein bisschen als Aufruf, das sind Dinge, die sehr, sehr leicht zu fixen sind.sind Dinge, die auch monetärsehr, sehr einfach sind, ja. Also es ist jetzt nichts, was irgendwieMillionen von Euros verschlingt, ja. Das merken wir auch hier bei uns teilweiseschlage ich auch die Hände über den Kopf zusammen,was da so die Requests sind, ja,von irgendwie New Hires, ja. Popcorn Friday und Smoothie Dienstagund sonst was, so. Aber dann am Ende bestellst du halt für 29 Eurodiese Popcornmaschine bei Amazonund denkst dir so, wenn das das ist,was jetzt darüber entscheidet,das ist doch viel besser,als wenn die Leute alle 10.000 Euro mehr verlangenfür den Geistgespräch,jetzt mal ganz einfach formuliert, ja. Also da glaube ich, tun sich viele keinen Gefallen, weil sie sich da einfach künstlich aus schon sowieso schweren Start voraussetzen. Ich habe nicht den besten Standort, ich habe nicht die allercoolste Brand, ich habe vielleicht auch nicht das allerheißeste Projekt, was ich anzubieten habe und dann on top mache ich es mir noch zusätzlich schwer. Ich glaube, das kann man schon nochmal ein bisschen optimieren.