Dieses Transkript wurde maschinell erstellt. Wenn dir ein Fehler auffällt, schreib uns gerne zu diesem unter redaktion@digitalkompakt.de.
Joel Kaczmarek: Hallo und herzlich willkommen zu einem neuen Blackbox Tech Podcast von digitalkompakt. Mein Name ist Joel Kaczmarek und ich habe schon Entzugserscheinungen vom guten Johannes. Grüß dich Johannes.
Johannes Schaback: Hallo Joel.
Joel Kaczmarek: Viel zu lange haben wir nicht gesprochen über Technologie.
Johannes Schaback: Oh ja und ich bin auch total aufgeregt. Ich glaube, ich muss gleich schon wieder auf Toilette.
Joel Kaczmarek: Sehr schön. Ich bin wieder in seinem bunten Visual-Meta-Büro. Jetzt hat sich einiges verändert. Ihr habt total geile Stifte und bunte Sachen auf dem Tisch. Ihr werdet immer professioneller, ich sehe schon. Und heute wollen wir über etwas reden, was sehr, sehr viele Menschen beschäftigt, nämlich Softwareentwicklung und da im Speziellen agile Softwareentwicklung. Was heißt denn das eigentlich? Ja, bei agil denkt man so an Speedy Gonzales, beweglich. Dem wollen wir uns heute widmen. Und wir beide machen jetzt hier wieder nicht eine Zweimann-Show, sondern wir haben einen hochkompetenten Experten mit dabei.
Johannes Schaback: Hochkarätig sogar.
Joel Kaczmarek: Alles zusammen, der 13 Mal mehr Ahnung hat als wir davon. Und wie ich lernen durfte, dich auch schon beraten hat mit deinem Unternehmen.
Johannes Schaback: Ja, alles, was ich weiß, weiß ich von Anton. Anton, stell dich bitte vor.
Anton Skornyakov: Anton Skraniakov, Agila Coach seit sechs, sieben Jahren. Ich habe früher mal selbst Startups gebaut, dann anderen Startup-Gründern geholfen und mit deren Fragen immer mehr zum Experten geworden für Agile Softwareentwicklung.
Johannes Schaback: Und heute bist du Freelancer und berätst Unternehmen in Sachen Agile Softwareentwicklung.
Anton Skornyakov: Genau, häufig Scrum, Kanban, Lean Startup, solche Sachen.
Joel Kaczmarek: Da wirst du bestimmt jede Woche, kriegst du gefühlt einen Abwerbeversuch, ob du nicht bei ihnen anfangen willst, oder?
Anton Skornyakov: Ja, tatsächlich gibt es so durchschnittlich jeden Tag einen Anfang.
Johannes Schaback: Das Thema ist nämlich in der Tat hochrelevant. Ich kann gar nicht über den Klee Anton loben, weil bei uns auch vor gefühlt vier Jahren ein Punkt erreicht wurde. Da waren wir so, ich schätze mal 20, 30 Entwickler. Und wir einfach einen Zustand des allgemeinen Frusts erkannten. Die Entwickler fühlten sich nicht mehr gewertschätzt, die entwickelten, die arbeiteten natürlich die ganze Zeit an etwas, aber sie fühlten sich nicht gewertschätzt. Gleichzeitig die Leute im Unternehmen, die etwas einforderten von den Entwicklern, hatten immer das Gefühl, dass die Entwickler immer an der falschen Sache arbeiteten. Oder dass sie immer irgendwie nicht schnell genug waren oder dass es nicht genau das war, was sie sich vorgestellt haben. Und es war irgendwie Frust und auf allen Seiten war Frust und alle waren sauer aufeinander. Und dann haben wir Anton gebucht und in der Tat extrem viel gelernt. Ich halte agile Softwareentwicklung mittlerweile für das wichtigste Instrument eines guten Unternehmens. Tech-Managers, das genau zu verstehen und nicht nur im Buch, sondern es auch zu leben. Und das ist auch das, was ich versuchen wollen würde, heute rüber zu bekommen. Wie kann ich anfangen, mich damit zu beschäftigen? Was sind die Einstiegspunkte? Ich will es verstehen. Und wie kann ich meine Organisation fitter machen und deutlich effektiver und effizienter? Lass uns doch einmal diese Symptome, beginnen wir damit. Ich habe das Gefühl, schon häufig in Unternehmen diese Symptome zu sehen. Wie siehst du das? Also ist das in der Tat so, dass immer alle Leute dich anrufen mit, bei uns brennt es, bitte komm Feuer löschen oder wie ist das?
Anton Skornyakov: Nee, in Wahrheit ist häufig das Symptom so etwas wie, na, unsere Entwickler sind nicht so gut beim Schätzen. Können sie uns mal irgendwie einen Tag helfen? Das ist ja schon sehr sophisticated. Ja, ja, genau. Also in der Regel werden Probleme, es sind ganz, ganz kleine Symptome, über die man anfängt, dann mit dem Unternehmen zu sprechen und dann rausfindet, ah, okay, so funktioniert es. Und dann ist das, was ich dann häufig feststelle, okay, entweder die Stakeholder, also solche Leute, die etwas von den Entwicklern erwarten, kriegen alle zwei, drei Monate mal was zu sehen. Oder die Deadlines, die denen versprochen werden, sind irgendwie über mehrere Monate gerissen. Und sie wissen eigentlich gar nicht. Der ganze Tag ist für sie eine Blackbox. Sie wissen überhaupt nicht, wann kommt da was raus. Sie geben Anforderungen rein und irgendwann kommt es zurück. Und die Entwickler selbst sind auch nicht zufrieden. Häufig wissen sie gar nicht. Also wenn man sie fragt, warum macht ihr das, was ihr da macht? Der typische normale Entwickler weiß es dann nicht. Das sind so typische Symptome von einem Unternehmen, das mehr Agilität braucht.
Johannes Schaback: Wie gehst du dann vor? Also du gehst jetzt in das Unternehmen rein. Was sind die Fragen, die du stellst? Was machst du?
Anton Skornyakov: Ich will jetzt gar nicht so richtig Eigenwerbung machen, aber am Anfang Wenn ich damit anfange, dann versuche ich, ein Unternehmen zu verstehen, wie es Software entwickelt, vom gesamten Weg, von wo die Anforderung geboren wird, also ist es eine Idee vom Kunden oder von irgendeinem Manager, bis zu dessen Auslieferung und wie das Unternehmen lernt, ob diese Anforderung halt auch Mehrwert gebracht hat oder nicht. Und wenn man diesen ganzen Weg entlangläuft, dann kann man einfach verstehen, was kann schieflaufen, was kann nicht.
Joel Kaczmarek: Ich meine, man muss ja vielleicht mal dem geneigten Laien auch mal plastisch machen, wie komplex Software eigentlich auch ist. Also du hast ja auch schon angedeutet, so eine Blackbox. Ich erinnere mich mal, ich habe mal in einem Potsdamer Unternehmen gearbeitet, der hat immer so visualisiert, der hat immer versucht mal klarzumachen, wie komplex das eigentlich ist. Und er hatte so dieses Beispiel, wenn du einen Versicherer nimmst, so einen normalen, sondern gar nicht mal groß, und würdest den gesamten Software-Code, den der in seinem Unternehmen hat, ausdrucken, hätte das die Höhe eines 24-stöckigen Gebäudes. Und jetzt überlegt man sich halt, wie gehe ich hin, organisiere ein Team von vielleicht wie bei Johannes 30 Leuten, das versucht, einen Roman, der gestapelt hochhaushoch ist, sozusagen zu verändern, zu verbessern. Und dann auch nicht technische Entscheider, die das nicht durchdringen, die gar nicht wissen, was da passiert.
Johannes Schaback: Zumal es ja am Anfang auch immer super läuft. Du bist irgendwie fünf Entwickler oder vielleicht sogar nur ein, zwei Entwickler und es läuft super rund. Alle sitzen an einem Tisch, jeder hört alles mit, die Abstimmung ist perfekt, die Kommunikation ist Unmittelbar, jeder weiß sofort, woran der andere gerade arbeitet, was der Stand ist. Das ist super erquickend und inspirierend, den anderen immer zu sehen und sofort zu wissen, wie der Stand ist. In dem Moment, wo dann ein, zwei, drei Leute dazukommen, insbesondere bei den Entwicklern, merkt man dann schon, oh, oh, oh, die Leute, man muss nicht plötzlich anfangen, sich nicht mehr gegenseitig auf den Füßen zu treten. Die Software wird immer komplexer, weil natürlich einfach mal Code geschrieben wird, wie Joel schon gerade sagte. Das ist schon ein unglaublich komplexes Thema. Und ich frage mich auch immer, ist das Schwachpunkt der Mensch? Oder ist die Software wirklich einfach so komplex oder sind wir einfach nur unfähig? Also ich finde das ganz, also ich finde das schon interessant.
Anton Skornyakov: Also da gibt es jetzt so ganz viele Punkte, die ihr gerade angesprochen habt. Also typischerweise fängt so ein Startup damit an, die sind zehn Leute, die sitzen im besten Fall in einem Raum und die haben halt wahnsinnig viele implizite Beziehungen. Sie brauchen gar nicht irgendwelche großartigen Prozesse oder Funktionen. oder es ist auch völlig egal, wer CEO ist, der kriegt halt trotzdem hartes Feedback von jedem kleinsten Mitarbeiter. Aber wenn es größer wird, dann ist es halt in der Regel so, da gab es halt den einen Entwickler, der war am Anfang halt derjenige, der mehr sagen wir mal, die Webseite programmiert hat, also Frontend, und jetzt haben wir aber drei Frontender, und jetzt kommt die Frage, wer leitet denn die Frontender? Dann gibt es jetzt plötzlich einen Leiter des Frontends und plötzlich eine Frontend-Abteilung, die optimiert jetzt dieses ganze Frontend. Und so gibt es plötzlich ganz viel Fokus, Und das ist dann so, als wenn man jetzt von einem anderen Bereich ein Beispiel nehmen würde. Angenommen, wir hätten jetzt eine Produktion von Möbeln, die immer wieder auf Anfrage anders sein sollten. Es kommen immer wieder Kunden, die fragen verschiedene Arten von Möbeln an. Und wir haben jetzt eine spezialisierte Abteilung für Holzzuschnitt, eine andere spezialisierte Abteilung für das Design, eine dritte spezialisierte Abteilung für das Zusammenbauen dieser Holzstücke, die bereits geschnitten worden sind und eine vierte Abteilung, die das testet, ob die Möbel überhaupt stabil sind, ob sie sich leicht zusammenbauen lassen etc., Wenn wir so eine Organisation haben und immer wieder verschiedene Möbel zusammenkommen, dann gibt es immer wieder diese Komplexität. Und in diesem Sinne Komplexität ist, dass man nicht vorhersehen kann, ob alles richtig laufen wird. Das heißt, der Designer wird vielleicht ein richtig gutes Möbelstück designt haben und er wird halt sein Design optimieren. Es wird halt ein toller Designer werden. Aber das Möbelstück, was er designen wird, wird vielleicht aus zu teurem Holz bestehen. Oder es wird vielleicht sich total schwer zusammenbauen lassen. Oder es wird halt wahnsinnig schwer zu testen sein, weil es einfach unbequem ist, drauf zu sitzen. Oder auch einfach, weil es sehr leicht kaputt gehen kann und deshalb allein schon das Testen das Möbelstück beschädigt und man es dem Kunden hinterher nicht verkaufen kann. Und wenn diese vier Leute oder diese vier Abteilungen in vier verschiedenen Räumen sitzen und quasi nur ihre Aufgabe optimieren, dann kommt halt dabei nicht das Optimum raus für das Unternehmen. Und das ist halt das, was typischerweise schiefläuft, wenn man halt diese einzelnen Bereiche versucht zu optimieren. Deshalb ist der Weg, agil zu entwickeln, zusammenzusitzen in sogenannten cross-funktionalen Teams, die halt alle Fähigkeiten haben, um so ein Möbelstück oder in Software so ein Feature zu entwickeln, um diese impliziten Beziehungen weiterhin bestehen zu lassen.
Joel Kaczmarek: Okay, also das ist schon mal so ein Take-away, was wir mitnehmen können von agiler Softwareentwicklung, dass man versucht, nicht so unterschiedliche Elfenbeintürme parallel zu bauen, dass du so eine kleine Burg baust, die aber auseinanderfällt, sondern dass man eigentlich versucht, die an einen Tisch zu setzen, dass man miteinander kommuniziert an unterschiedlichen Stellen des Produkts.
Anton Skornyakov: Genau.
Johannes Schaback: Das heißt also auch viel mit Kommunikation zu tun scheinbar oder ich meine nur, dass die nebeneinander sitzen, collocated sagt man ja auch manchmal, ist jetzt ja kein Automatismus.
Anton Skornyakov: Nee, aber das ist tatsächlich eine von den wichtigsten Sachen, die sich aus der Geschichte ergeben hat. Also das allererste Wertepaar aus dem Agilen Manifest, wo sozusagen Agil herkommt, heißt auch Individuen und Interaktionen über Prozesse und Werkzeuge. Also weil eben die Individuen und die Interaktionen, das ist, was am Ende des Tages entscheidend dafür ist, ob die Software, die wir bauen, gut funktionieren wird. Und wenn die Interaktionen es brauchen, sollten sie stattfinden und wenn die Prozesse dem nicht dienlich sind, dann sollten die geändert werden.
Joel Kaczmarek: Was ist denn eigentlich so deine Zielgruppe? Vielleicht kannst du uns mal so ein bisschen sagen, arbeitest du eher mit Startups, eher mit Corporates, eher mit Mittelstand, querbeet? Weil ich würde natürlich gerne mal rausschälen, sind die Probleme immer die gleichen, egal welche Größe man hat oder verändern die sich in der Softwareentwicklung auch?
Anton Skornyakov: Ich arbeite tatsächlich querbeet und was mich besonders freut, ist in letzter Zeit immer mehr auch mit gar nicht IT-Bereichen. weil dieses ganze Thema Agile hat ganz viel, also es hat nicht nur was mit Software zu tun, sondern hat ganz viel mit dem Begriff Wissensarbeit zu tun. Und was heißt Wissensarbeit? Das heißt, der größte Teil von dem Mehrwert, den wir erbringen, wenn wir acht Stunden vor Ort sind, ist eben nicht, dass wir den Code geschrieben haben oder dass wir den Stuhl zusammengebaut haben, sondern dass wir was gelernt haben. Und da gibt es eine gute Metapher, für die ich da nutze, ist, Kennt jeder vielleicht Ikea-Regal zusammenbauen. Stell dir mal vor, ich habe mir so ein Ikea-Regal gekauft und ich habe da so eine Anleitung, eine visuelle mit irgendwie 25 Schritten und ich baue das Ikea-Regal zusammen. Das dauert vielleicht zwei Stunden. Und wenn ich mich jetzt frage, wie lange würde es dauern, das gleiche Regal direkt im Anschluss noch einmal zu bauen, wie lange würde das dauern? In der Regel dauert es viel weniger als 50 Prozent der Zeit, weil man all das gelernt hat auf dem Weg. Wie hat das ausgesehen, dieser Prozess? Man macht ja einen Schritt, dann schaut man in diese Anleitung und kontrolliert. Ist das Zwischenprodukt, sieht es immer noch genauso aus, wie es auf dem Bild aussieht? So etwas hat man übrigens nicht, wenn man Software baut, weil man immer wieder neue Ikea-Regale zusammenbaut quasi und das niemand vorher gemacht hat.
Johannes Schaback: Genau, und die sind auch ein bisschen komplexer noch als Ikea-Regale.
Anton Skornyakov: Ja, genau.
Joel Kaczmarek: Aber heißt jetzt deine Metapher, dass das sozusagen kundenübergreifend, egal welche Größe ich habe, immer dieselben Probleme sind?
Anton Skornyakov: Die Art von Problemen ist dieselbe. Die tatsächlichen Anforderungen, die jeder Kunde hat, sind ganz unterschiedlich, weil es unterschiedlicher Markt ist, unterschiedlicher Quellen von Variabilität. Das, was die Komplexität ausmacht, ist, dass es eine Unvorhersehbarkeit gibt, die systematisch ist, die man nicht wegmachen kann, weil es verschiedene Kundenanfragen gibt, weil der Wettbewerb was macht, weil der Markt sich verändert. auf der Marktebene, aber es gibt auch ganz viele unvorhergesehene Dinge auf der Implementierungsebene. Wir bauen ja Software in der Regel mit neuen Werkzeugen, die sich permanent updaten. Also jedes Werkzeug, mit dem man Software baut, ist wiederum Software und es updatet sich. Jeder kennt das von seinem iPhone, da gibt es halt jeden Monat ein neues Update, weil mal wieder irgendeine Sicherheitslücke entdeckt worden ist. Das heißt, man kann nicht darauf verzichten. Und das passiert mit zehn Werkzeugen pro Woche. Und wenn man so einen großen Laden bedient, dann hat man permanent auch mit Werkzeugveränderungen zu tun.
Johannes Schaback: Was ich interessant finde, ist, weil ich auch auf diese Historie zurückgreifen will und kurz mal das Wissensmanagement nochmal an die Seite zu stellen. Arbeiten mit dem Unbekannten, das finde ich total einen ganz, ganz spannenden und zentralen Gedanken. Du musst dir letztendlich eine Wette eingehen, dass du irgendwie einen Plan bauen kannst. Und vielleicht kannst du nochmal erzählen, wie war das früher, also in den 60er Jahren, als man Software gebaut hat, also mit den Lochkarten und so. Wie hat man damals Software entwickelt und warum ist das heute so anders?
Anton Skornyakov: Tatsächlich, wenn man die Veteranen fragt, würden sie sagen, es gab auch früher gute Beispiele von agiler Entwicklung, nur man hat es nur nicht so genannt. Tatsächlich gibt es aber insbesondere in sehr großen Unternehmen, das gibt es auch heute noch, man kann es halt Wasserfall nennen, einen Prozess, wo es darum geht, erst einmal werden alle Anforderungen aufgenommen.
Johannes Schaback: Also was muss die Software können?
Anton Skornyakov: Was muss die Software können? Da werden ganz große Lastenhefte geschrieben. Dann werden Architekten befragt. Ja, was für eine Architektur kann denn diese Anforderungen aufnehmen? Dann werden die einzelnen Gewerke gefragt, wie kann denn das Design so aussehen, dann wird das Design erstellt etc. Das ist im Grunde genommen Wasserfall oder ein Projektmanagement.
Johannes Schaback: Weil sozusagen jeder Schritt nach dem anderen kommt und du kannst nicht beispielsweise implementieren, bevor du nicht geplant hast oder du kannst nicht den Architekten befragen, bevor du nicht das fette Lastenheft geschrieben hast.
Anton Skornyakov: Genau. Und dieses Vorgehen macht in ganz anderen Zusammenhängen total Sinn. Also wenn ich zu Weihnachten Einkäufe tätigen will, zehn Stück, und ich habe verschiedene Läden, die ich anlaufen will, dann will ich das total gut planen, damit ich dann den 24. Dezember schaffe. Aber die Herausforderung, die wir bei Softwareentwicklung haben, ist nicht die, wie passt das hintereinander, sodass es perfekt ist, sondern ist die, bauen wir überhaupt das Richtige? Und funktioniert es, wenn wir es zusammengebaut haben? Das ist die größte Herausforderung.
Johannes Schaback: Ich dachte immer, die Herausforderung von Softwareentwicklung wäre, möglichst schnell viel Wert zu generieren. Also möglichst schnell die Zeit, die wir haben, zu verwenden, um möglichst wertvolle Software, also ROI-driven Software zu entwickeln.
Anton Skornyakov: Und woher wissen wir, was Mehrwert generiert?
Johannes Schaback: Das weiß ich nicht.
Anton Skornyakov: Genau, und das ist halt der Punkt. Das ist die Natur von Wissensarbeit, von der ich vorhin gesprochen habe. Bis wir das Ergebnis sehen, wissen wir eigentlich nicht, wie viel Mehrwert es geschaffen hat.
Johannes Schaback: Weil ich vorher nicht weiß, wenn ich jetzt sage, wenn wir Feature X bauen, das ist mir Y-Wert. Weil ich kann jetzt schon sagen, ich werde Y-Revenue damit machen. Das kann ich nicht sagen.
Anton Skornyakov: Das ist der Punkt, oder? Das ist die eine Unbekannte. Es gibt aber an ganz vielen Ebenen noch viel mehr Unbekannte. Wenn ich den Entwickler frage, wie lange wird das dauern, dann kann er sagen, okay, ja gut, ich glaube, das wird jetzt fünf Tage dauern, wenn ich das so und so mache. Während er das aber implementiert, wird er mitkriegen, dass er an fünf anderen Stellen doch andere Entscheidungen treffen muss, weil so wie er es ursprünglich dachte, es doch nicht geht. weil er mit neuen Werkzeugen arbeitet, weil er etwas umsetzt, was noch nie jemand vorher umgesetzt hat. Und auch die Schwierigkeit ist, wenn man von außen drauf guckt und nicht die Software versteht, dann denkt man ja, okay, es gibt ja schon Facebook. Warum bedeutet das denn, wenn ich das noch einmal implementiere, dass jemand seine E-Mail-Adresse wiederkriegen soll? Warum ist das denn so anders bei dieser Webseite als bei einer anderen?
Johannes Schaback: Also jetzt beim Login zum Beispiel.
Anton Skornyakov: Genau, beim Login. Angenommen, ich habe mein Passwort vergessen. Ich möchte ein neues Passwort besorgen. Ist das jetzt wirklich was anderes hier auf dieser Seite wie auf der anderen? Na klar, gibt es eine ganze Menge Sachen, die sich wiederholen. Aber die Integration von diesem Ding, was sich wiederholt, in das, was bereits besteht, ist echt neu. Und da gibt es ganz viele Tricks oder ganz viele Dinge, die schieflaufen können.
Johannes Schaback: Und das ist auch die Gefahr, wenn ich das richtig verstanden habe, aus den Geschichtsbüchern, die übermittelt wurden in meinem Studium, dass im Waterfall im Grunde man am Anfang, sagen wir mal im Monat 1, Annahmen getroffen hat und geplant hat und sich einen Wolf geplant hat. Und dann im Monat 10 war man vielleicht soweit, die erste Zeile kurz zu schreiben und dann plötzlich mal gemerkt hat, ach du Scheiße, der Markt, die Kundengruppe, an die wir das verkaufen wollen, die gibt es gar nicht mehr. Ja.
Anton Skornyakov: Und selbst angenommen, es gilt alles noch. Es gibt die Kundengruppe, sie wollen alles noch. Was in der Regel wir herausfinden, ist, wir haben da fünf Leute, die arbeiten unabhängig voneinander anhand von diesem Plan und dann im letzten Monat versuchen, die Sachen zu integrieren. Und oh mein Gott, der Frontender hat etwas gebaut, ausgehend von einer Schnittstelle, die der Backender aber anders gebaut hat. Und die jetzt umzubauen, kostet richtig Zeit. Und dann explodieren wahnsinnig viele Projekte. Das ist halt das Typische. Weil wenn man agil arbeitet, dann passiert diese Zusammenarbeit, jetzt in diesem konkreten Beispiel von Frontender und Backender, permanent, jeden Tag.
Johannes Schaback: Dieses Manifesto, du hast es vorhin nochmal erwähnt. Was ist dieses Agile Manifesto?
Anton Skornyakov: Im Grunde genommen ist das Agile Manifesto zwei Sätze mit vier Wertepaaren und zwölf Prinzipien dazu. Und das Besondere daran ist, dass diese Dinge aufgestellt worden sind von sonst wirklich großen IT-Gurus, die sonst eigentlich die ganze Zeit nur widersprechen und ganz unterschiedlicher Meinung sind. Vor 2001 gab es den Begriff Agi noch gar nicht. Es gab nur den Begriff leichtgewichtige Entwicklungstechniken. Und die verschiedenen Vertreter von verschiedenen leichtgewichtigen Entwicklungstechniken sind in Utah auf so einen Ski-Resort gefahren und am letzten Tag haben sich zwei von denen von einem Flipchart gestellt und nachdem die ganz viel diskutiert haben, haben die dieses Agile Manifesto hingeschrieben. Und am nächsten Tag haben alle drauf geguckt und gesagt, ja, genau das. Und alle haben sich geguckt und gesagt, wow, wir sind alle gleicher Meinung. Das muss was ganz Besonderes sein. Und tatsächlich ist es so, die haben danach einfach das auf eine Webseite gestellt und einfach ganz viele Leute haben gesagt, ja, genau das. Das ist sozusagen das Manifest. Und das Manifest ist, wir arbeiten und wir entwickeln selbst Software und helfen anderen Leuten dabei, Software zu entwickeln. Und dabei haben wir herausgefunden, dass Individuen und Interaktionen wichtiger sind als Prozesse und Werkzeuge. Funktionierende Software wichtiger ist als vollständige Dokumentation. Zusammenarbeit mit dem Kunden ist wichtiger als die Vertragsverhandlung. Und das Anpassen an die Veränderung ist wichtiger als den Plan zu befolgen. Und auch die Dinge, die sozusagen weniger wichtig sind, sind wichtig. Die haben eine Bedeutung. Auf die kann keiner verzichten. Aber das auf der linken Seite, also das, was sozusagen das, was wichtig ist, ist einfach wichtiger. Das ist im Grunde genommen die Priorität. Und das ist ein ganz wichtiges Leitmotiv.
Johannes Schaback: Und was hat das jetzt mit unserem Wasserfall gemacht? Also ich meine, das ist jetzt ja noch recht abstrakt, aber was ist dann passiert?
Anton Skornyakov: Das Agile Manifesto hat einen ganz einfachen Namen gegeben. Die Entwicklung hat schon vorher existiert. Also Scrum existiert seit 92. Extreme Programming hat schon davor existiert. Vielleicht sind die Gründer von Extreme Programming die Gang of Four. Ich kenne den Begriff gar nicht so richtig genau. Aber was sich im Grunde genommen etabliert hat heutzutage ist, also ihr habt ja auch schon in einem anderen Podcast zum Beispiel über den Gitflow gesprochen und darüber, dass wir heute Continuous Integration machen etc. Und viele, viele Dinge, die heute überhaupt gar nicht gefragt werden, das sind heute Standardwerkzeuge von jedem, der entwickelt, die gab es früher nicht. Und die machen diese Arbeit, die agile Arbeit, so, dass man jeden Tag im Grunde genommen eine völlig neue Version der Software herausbringen kann oder wie Amazon jeden Tag 20.000 neue Versionen der gleichen Software herausbringen kann. Möglich. Früher war das gar nicht möglich. Diese Werkzeuge zu schnellen Zusammenarbeit machen heute eben das Zusammenarbeiten von mehreren tausend Leuten gleichzeitig überhaupt möglich.
Johannes Schaback: Und das kommt daher, weil es glaube ich nicht zu verstehen ist, ist, dass früher die Leute in diesem Wasserfall, das sich über mehrere Monate, manchmal sogar Jahre hinweg zog, eben diesen einen fetten Prozess durchgezogen haben, von der Planung hin zur Implementierung, Lastenheft, Bipapo, Implementierung, Testing oder Integration, Testing. Und da korrigiere ich mich falsch, aber ja, was jetzt Ultima Ratio ist, diesen Wasserfallprozess innerhalb weniger Stunden oder innerhalb weniger Tage durchzuführen. Und dann ganz, ganz schnell immer Planung, Implementierung, ausrollen, testen, planen und das sozusagen ganz schnell zu wiederholen und dann immer ganz schnell Feedback zu haben.
Anton Skornyakov: Ist das richtig? Also wenn du es innerhalb von wenigen Stunden machst, wird es sowieso schwierig, überhaupt Wasserfall zu nennen. Es gibt so ganz viel Kritik und ich habe das auch schon ganz blöd erlebt. Also wenn man glaubt, dass agil einfach nur Wasserfall in ganz, ganz klein bedeutet, dann läuft das in der Regel schief. Agil bedeutet in der Regel wirklich eine Veränderung des Mindsets. Denn dieses Anpassen, dieses Lernen, das kann nicht mehr bei irgendeinem Projektmanager stattfinden. Das muss in der Mannschaft passieren, die in dem einen Raum sitzt, von dem wir vorher gesprochen haben. Und das bedeutet, diese Mannschaft, die in dem einen Raum sitzt, die braucht wirklich das Verständnis, warum machen wir das? Sie haben eine echte Endkundenaufgabe vor sich, zum Beispiel die Aufgabe, neue Kunden auf die Webseite aufmerksam zu machen. Und sie wissen, naja, hat unsere neue Feature mehr Kunden auf die Webseite gelockt? Und wenn das nicht der Fall ist, was können wir daraus lernen? Und diese Gruppe lernt. Nicht irgendein übergeordneter Manager, also der kann vielleicht auch lernen, aber vor allem die Gruppe. Und das ist ein ganz anderes Denken. Die Macht, also die Kontrolle darüber, was gemacht wird in einem agilen Unternehmen, ist woanders. Die Kontrolle darüber, wohin fahren wir mit unserem Schiff, ist weiterhin bei dem großen Management. Aber es vertraut deutlich mehr auf die Mannschaften, die viel unabhängiger agieren. Und dadurch passiert einfach sehr viel. Man muss verstehen, dieses Modell von Man ist der Manager und sagt, was passiert, erlaubt keine Selbstorganisation. Top down. Am Anfang von so einem typischen Training gibt es eine ganz einfache Übung, die wir machen. Ich frage so 20 Teilnehmer, bitte sie darum, sich aufzustellen in einer Reihe von links nach rechts, wo links die Person ist, die von sich glaubt, dass sie am wenigsten Erfahrung hat mit Agilität und rechts die Person mit der meisten Erfahrung in Agilität. Und in der ersten Runde frage ich eine Person, ob sie Manager sein möchte. Und diese Person kriegt die Aufgabe, diese 20 Leute aufzustellen innerhalb von einer Minute. Und sie scheitert natürlich. Und probiert irgendwie die Leute zu fragen, was meinst du? Das kann überhaupt nie in einer Minute funktionieren. Danach stellt man die gleiche Aufgabe einfach der Gruppe insgesamt. Stellt euch einfach selbst auf. Und man kriegt mit, das geht innerhalb von 30 Sekunden. Weil einfach jeder mitdenkt. Weil jeder
Johannes Schaback: Die Selbstorganisation.
Anton Skornyakov: Ja, die Selbstorganisation. Und das ist ein ganz einfaches Beispiel. Sehr einfaches Beispiel. Aber wenn man ein klares Ziel den Leuten gibt und es ermöglicht, sich selbst zu organisieren, ist die Effektivitätsgewinn zehnfach.
Johannes Schaback: Ich habe ein ähnliches Beispiel. Ich glaube, das hast du auch gemacht. Du kriegst die Aufgabe, möglichst schnell 100 Bälle von einem Topf in den anderen zu transportieren unter der Maßgabe, dass jede Person in der Gruppe, also sagen wir mal zehn Teilnehmer, den Ball einmal anfassen muss und es ohne zu werfen übergeben muss in die Hand des nächsten Teilnehmers. Und das muss möglichst schnell passieren. Und dann tritt man, glaube ich, in Gruppen gegeneinander an und guckt, wer am schnellsten ist. Ich hoffe, ich habe das richtig wieder. Ich will jetzt auch nicht die Lösung verraten, weil das Interessante nämlich war, dass am Anfang die Leute irgendwie hochgucken zu einem Manager. Bei uns war das so. Und dann fragt man, okay, wie soll man das organisieren? Und dann kam eigentlich ein okayes Ergebnis heraus. Aber beim zweiten Mal wurde eben die Maßgabe gestellt, jetzt muss man auf den Manager, halt dich mal zurück, lasst euch mal selbst organisieren. Und dann kam eine völlig obstruse Idee von einer Person, also einem Teammitglied. Und es war, ich glaube, zehnmal schneller, was Wahnsinn war. Ich will jetzt nicht sagen, wie die Lösung war, weil es wirklich interessant ist.
Joel Kaczmarek: Toll, danke schön.
Johannes Schaback: Aber ihr müsstet es mal ausprobieren. Das ist in jedem Fall eine Übung. Und das war wirklich eye-opening. Also das war Wahnsinn. Also die Organisation der Arbeit zurückzugeben ins Team, das ist Wahnsinn.
Joel Kaczmarek: Gut, aber da musst du mir jetzt mal helfen, Anton, zu verstehen, wenn jetzt ein Manager zuhört, hat das irgendwie verstanden? Wir haben ja jetzt schon ein paar Takeaways auch gehabt, diese Interdisziplinarität, die Unvorhersehbarkeit etc. pp. Was für eine Ableitung sollte ich daraus für meinen Managementstil jetzt sozusagen ziehen? Also die Logik wäre ja eigentlich, Personen zählen nicht mehr so krass, sondern es kommt auf den Prozess an und wie dieser Prozess von den Personen gestaltet wird, um diese Selbstorganisation anzuregen. Was sollte ich da tun? Was für eine Attitüde sollte ich mitbringen?
Anton Skornyakov: Also ich glaube, das Wichtigste ist, dass man versucht, die Grundlagen der eigenen Entscheidungen als Managertransparent zu machen. So, dass nicht nur ich selbst meine Entscheidungentreffen kann, sondern jeder in meiner Mannschaftdie Entscheidung selbst genauso getroffen hätte. Also Worauf basiere ich meine Entscheidungen? Zum Beispiel jede Woche auf neuen Besuchen auf meiner Webseite. Und ich übergebe dann, nachdem ich all diese verschiedenen Indikatoren, die ich wirklich messe, die wirklich stattfinden, keine künstlich erdachten Ziele, sondern wirklich stattfindende Indikatoren, also die man empirisch messen kann, wenn ich die Dinge alle transparent gemacht habe und die Verantwortung für das Erreichen hoher Werte meinem Team gegeben habe, dann wechselt, also das ist meine allererste Aufgabe, weil wenn mein Team es eigentlich gar nicht versteht, wo ich hin will, gibt es gar keine Chance, dass sie es erreichen können. Also ich brauche, ich muss eine Richtung geben und ich muss sicherstellen, dass sie es sehen, woran ich erkenne, dass es gut läuft. Und wenn das der Fall ist, dann kann ich langsam weggehen aus der Rolle von. ich sage ihnen, was sie zu tun haben und gehe hin eher in die Rolle von. was braucht ihr eigentlich noch, um noch besser diese Ziele erreichen zu können. Und das ist eine Veränderung, ein Mindshift in dem Denken als Manager, die einerseits ein bisschen auch Angst machen kann, weil es eine echte persönliche Veränderung ist, aber andererseits wahnsinnig, ja, wahnsinnig viel Kräfte freisetzen kann. Weil man plötzlich viel, viel mehr erreicht und man merkt, wow, ich brauche überhaupt nicht mehr zwölf Stunden zu arbeiten, ich kann eigentlich ganz normal arbeiten. Und die Leute freuen sich viel mehr, die Leute identifizieren sich. Die identifizieren sich, die arbeiten länger und fühlen sich weniger dabei gestresst.
Joel Kaczmarek: Also man hat wahrscheinlich auch weniger Micromanagement dann als Manager. Absolut.
Johannes Schaback: Und du hast ein Buy-in. Die Leute identifizieren sich, glauben dran und wissen, wir sind aligned in dem, was wir erreichen wollen.
Joel Kaczmarek: Genau. Hast du eigentlich schon mal diesen Entwicklungsansatz, dieses Agile auch auf andere, komplett andere Disziplinen angewandt? Also jemand, der jetzt zuhört, hat mit Software vielleicht gar nichts zu tun, aber sagt Projektmanagement oder irgendwie Produktion funktioniert sowas da auch?
Anton Skornyakov: Also es gibt eine ganze Menge von den Bereichen, von zum Beispiel die Kontrolle übergeben. Das hat ganz viele Anwendungspunkte, die völlig unabhängig von Produktentwicklung sind. Das, was wir vorhin kurz angedrissen haben, diese Komplexität, diese verschiedene Variabilität, die ist nämlich überhaupt nicht gleich. Je nachdem, von welchem Bereich man spricht. Es gibt Bereiche, da gibt es kaum Variabilität. Und da bietet sich so etwas wie Scrum oder Agilität im vollen Maße überhaupt nicht an. Es gibt gar nicht so viele Veränderungen, an die man sich anpassen muss. Aber dennoch kann dort sehr viel davon profitiert werden, wenn die Kontrolle über das Lernen an die Mannschaft übergeben wird. Es gibt. aber auch heutzutage, also zum Teil habe ich mit Unternehmen zu tun, die machen Qualitätsmanagement, also was überhaupt gar nicht mit Software und überhaupt nicht mit irgendwelchen Produkten. Vertrieb macht heute ganz viel Agilität, Marketing. Eigentlich alles, wo die Arbeit Wissensarbeit ist. Also wenn man sich am Ende des Tages fragt, wenn ich am Morgen gewusst hätte, was ich eigentlich tun soll, wie lange hätte ich wirklich gebraucht, um diese E-Mails zu schreiben, um diese PowerPoint-Präsentation zu verändern, um diese Excel-Tabelle zu machen. Und wenn dieser Prozentsatz der Zeit deutlich unter 50 Prozent ist, dann weiß man, dass man vor allem Wissensarbeit leistet. Und das bedeutet, dass man mit der Arbeit anders umgehen kann, um effektiver zu werden.
Joel Kaczmarek: Gibt es typische Rollen, die man eigentlich bei agiler Softwareentwicklung hat? Kannst du die vielleicht mal ein bisschen beschreiben?
Anton Skornyakov: Ja, es gibt eine Denkschule der Agilität, die man Scrum nennt und da gibt es vor allem die drei verschiedenen Arten von Rollen. Die eine Rolle ist halt die eines Teammitglieds, also eines der, der die Arbeit verrichtet, eines Coaches, eines Scrum Masters. der von der Seite guckt, nicht tatsächlich die Arbeit macht, aber dem Team dabei hilft zu wachsen und aber auch dem Management dabei hilft zu wachsen. Und die dritte Rolle, der Product Owner, das ist ein konkreter Manager, dessen Hauptaufgabe es ist, die Priorität festzulegen, von wann was machen wir zuerst und was machen wir danach. Denn es geht ja nicht darum, dass die Mannschaft entscheidet, ah ja, wir mögen. Wenn wir jetzt wieder das Beispiel der Möbel, wir mögen die Möbel aus Kirschbäumen besonders gut, lassen wir uns nur darauf konzentrieren. Darum geht es nicht. Es geht ja darum, dass ein Unternehmen am Ende des Tages Geld machen soll. Und der Product Owner ist derjenige, der verantwortlich ist, das zu maximieren, dass der Mehrwert von dem, woran das Team arbeitet, maximiert wird.
Joel Kaczmarek: Kannst du den Unterschied zum Scrum Master vielleicht nochmal hervorheben? Bei Owner und Master denkt man immer, das sind so die Managerrollen.
Anton Skornyakov: Das Scrum Master ist ja das englische Wort und im Englischen ist Master eigentlich anders gemeint, als wie man es im Deutschen versteht. Es ist eigentlich derjenige, der das Scrum gemeistert hat. Es ist eigentlich eine Art Großmeister, wie man es jetzt so sagen wir mal in der Kampfkunst. Der Meister erkennt die Kampfkunst besonders gut. Also er ist ein Meister der Kunst. Während der Product Owner tatsächlich eine Managerrolle ist, das ist ein Business, vor allem jemand, der Businessverständnis hat und Businessentscheidungen trifft und ganz klar Autorität hat, diese Businessentscheidungen zu treffen. Und Teammitglieder sind die verschiedenen, sagen wir mal, Handwerker oder die verschiedenen Menschen, die die notwendigen Fähigkeiten haben, um das Produkt herzustellen oder was auch immer herzustellen.
Johannes Schaback: Genau, du hast jetzt schon ein paar Mal erwähnt den Begriff Scrum. Was ist Scrum? Was sind die entscheidenden Elemente im Scrum, in dem Framework?
Anton Skornyakov: Die einfache Art von Scrum zu beschreiben? für mich ist, Scrum bedeutet, wir arbeiten in Teams, in Iterationen, die kurz sind, also von einer bis vier Wochen. Und am Ende jeder Iteration lernen wir, daraus haben wir das Richtige gebaut. Und haben wir es gut gemacht? Also wie haben wir es gebaut? Und dieses Lernen ist ganz wichtig. Und im Laufe dieser Iteration treffen wir uns mindestens einmal pro Tag und synchronisieren miteinander, wo stehen wir eigentlich. Das ist so die wichtigsten Elemente für mich zumindest in Scrum.
Johannes Schaback: Was heißt das konkret jetzt in so einem Softwareentwicklungsprojekt? Wie sieht da so ein optimaler Scrum-Prozess aus? Kannst du vielleicht ein Beispiel beschreiben, wie jetzt in einem Idealfall das aussieht?
Anton Skornyakov: Kannst du mir eine Hilfe geben, also eine typische Anforderung, so ein größeres Ziel von so einem Projekt?
Johannes Schaback: Pass auf, also das übergeordnete Ziel ist, dass wir einen neuen Payment-Provider integrieren in unsere Webshop-Software. Wir sind jetzt ein Team von vier Entwicklern, einem Product-Owner. Wir haben vielleicht sogar einen Scrum-Master.
Anton Skornyakov: Also ein Product Owner für vier Entwickler ist fast schon ein Overkill. Aber wie würde das aussehen? Also angenommen, wir haben jetzt Visa-Zahlungsfähigkeiten, wir wollen jetzt PayPal integrieren. Dann ist die allererste Frage, okay, was ist das allerkleinste Ding, was wir entwickeln können, was bereits den allerersten konkreten Mehrwert liefert? Und der Mehrwert ganz am Anfang von so einem Projekt ist in der Regel nicht, dass es ein Kunde direkt nutzen kann, sondern dass es sichergestellt ist, dass es technisch funktioniert. Und ganz am Anfang
Johannes Schaback: Das Minimal Viable Product sozusagen? Oder ist es das Minimal Viable Technical Feasible Product?
Anton Skornyakov: Payment-Integration ist ein schwierigeres Beispiel dabei, weil bei Payment-Integration ist es so, dass du ja in der Regel nie das freischalten würdest für echte Kunden, bis es nicht wirklich vollständig durch ist, weil du die Möglichkeit hast, dass da irgendjemand betrügt, die Möglichkeit hast, dass da irgendwie falsche Transaktionen und es geht ja sofort ans Geld. Also als Unternehmen möchtest du bei diesen Sachen echt vorsichtig sein. Aber du möchtest trotzdem, wenn du agil arbeitest, vorher schon etwas gesehen haben. Und das heißt in der Regel, womit beginnt so ein Projekt? Es beginnt damit, dass man sich dieses große Ziel anguckt und erstmal ein paar ganz kleine Steine davon runter bricht, deren Ergebnis man einem Product Owner oder anderen Business Stakeholdern zeigen könnte. Das aber noch nicht die vollständige Implementierung ist. Das könnte zum Beispiel so ein PayPal-Projekt sein. Okay, ich kann genau eine Art von Produkt über die Testschnittstelle von PayPal für genau einen konkreten Preis, der bereits feststeht, zahlen. Und es ist ein Test, bereits bestehender Test-Account von PayPal. Und wenn ich da gezahlt habe, dann kommt eine Bestätigungs-E-Mail an diese Testadresse. Und es ist alles Fake-Projekt.was wir da haben. Es ist kein richtiges Produkt, kein richtiger Preis. Aber die E-Mail kommt an und es funktioniert wirklichdurch die richtige PayPal-Schnittstelle. Das ist in der Regel bei solchen Payment-Geschichtendas größte Risiko. Und das machen wir, das können wir innerhalbvon einer Woche entwickeln. Und jetzt haben wir das auseinandergebrochenund sagen, okay, ein zweiter Schritt wäre,wir erlauben, dass der Preis variiert.
Johannes Schaback: Aber das Produkt ist immer noch Und diese Woche springt von einem Sprint.
Anton Skornyakov: Genau, und das ist eine Iteration. Das heißt, am Ende dieser eine Woche, sagen wir mal, zeigen die Entwickler versammelten Stakeholdern, hey, man kann jetzt das machen. Und die Stakeholder gucken darauf und sagen, ja, Moment mal, wieso bekommt man eine E-Mail, die so etwas sagt? Die E-Mail sollte etwas ganz, ganz anderes sagen. Ach, interessant, das haben wir jetzt gelernt. Oder die Mannschaft sagt, na, wir haben festgestellt, dass so wie unser System gebaut ist, es überhaupt gar nicht so einfach ist, mit PayPal das zu machen. Wir müssen echt was anderes, wir müssen echt hier viel verändern. Leider haben wir einen Misserfolg, aber wir wissen schon nach einer Woche, was was ganz, ganz Grundlegendes falsch ist. Früher wäre das erst ganz am Ende von sechs Monaten festgestellt worden und wir hätten richtig viel Geld versammelt.
Johannes Schaback: Und innerhalb dieses Sprints, was gibt es da für wiederkehrende Sachen, also damit das funktioniert? Und auch nach einer Woche muss ja irgendwie dieses Produkt irgendwie funktionieren und stehen. Du hast jetzt gerade vom Synchronisieren gesprochen. Was sind so wiederkehrende Elemente, die man da macht?
Anton Skornyakov: Also wir beginnen den Sprint damit, dass wir ihn planen. Also im Grunde genommen uns fragen, was sind all die Dinge, die wir tun müssen, damit das Ergebnis, was wir uns vorgenommen haben, fertig wird. Dann haben wir jeden Tag einen Sync, wir nennen das Daily Scrum. Scrum kommt ja übrigens vom Rugby. Und es ist dieser Moment, wenn beide Mannschaften, die gegeneinander antreten, gegeneinander total ineinander eingekeilt sind und darum kämpfen, diesen Ball aufzuheben. Und das ist so das Sinnbild davon, wie die Mannschaft sich quasi einkeilt, einmal am Tag für höchstens 15 Minuten, um zu sehen, okay, wo stehen wir? Was ist der Plan? Sind wir immer noch on track? Was hat sich verändert? Und das passiert einmal am Tag und das ist dieses Daily Scrum. Und dann arbeitet man jeden Tag und die Struktur der Arbeit, da organisiert sich das Team vollkommen selbst, unterstützt vom Scrum Master und am Ende des Sprints gibt es ein Review, das heißt, wir zeigen die Arbeit den Stakeholdern, also verschiedenen Leuten, die daran Interesse haben, legitimes Interesse, bekommen Feedback, lernen daraus. und nachdem wir daraus gelernt haben, ob wir das Richtige gebaut haben, reden wir darüber, wie wir zusammengearbeitet haben und das nennen wir Retrospektive. Und das sind im Grunde genommen die Elemente.
Johannes Schaback: Und was für Artefakte, was für Tools werden in der Regel verwendet? Also jetzt kann man bei einem komplexen Softwareprojekt sich eine Menge Sachen ausdenken, aber schreibt man das in Excel-Tabellen oder irgendwie muss man das ja festhalten, dokumentieren. Was sind so deine Erfahrungen?
Anton Skornyakov: Also es gibt in Scrum die drei wichtigen Artefakte. Das Produkt-Backlog, das ist im Grunde genommen einfach eine geordnete Liste von Dingen, die wir vorhaben zu tun. Das zweite ist ein Sprint-Backlog. Das ist die Liste aller Dinge, die sich das Team vorgenommen hat. Und da gibt es ganz viele Freiheiten, gerade wie das Team es gestalten kann, aber du kannst es halt selbst machen. Und der dritte Artefakt ist eben das fertige Stück Inkrement, also das fertige Stück Software. In der Regel machen ja viele Unternehmen ganz viel mit digitalen Tools. Das macht Probleme. Wir reden häufig in der agilen Welt von sogenannten Informationskühlschränken und Informationsradiatoren. Also so ein Radiator ist ja so ein Heizkörper. Er strahlt halt Hitze raus. Das heißt, wenn man da dran geht, dann wird einem warm. Und einen Kühlschrank, da muss man halt reingucken. Und so ein Jira oder irgendwie ein digitales Sprint-Backlog, das ist halt so ein Ding, der guckt halt nur derjenige rein, der weiß, dass er da reingucken muss. Niemand von außen wird das jemals sehen. Deshalb, je mehr man visuell arbeitet, also das heißt, wirklich Wände nutzt, um dort mit Stickies, mit verschiedensten Dingen klarzumachen, wo man gerade steht, umso besser, umso transparenter ist alles. Und umso mehr ist es ein Radiator von Informationen.
Johannes Schaback: Das finde ich ein interessantes Konzept, weil diese Arbeit sichtbar machen ist total entscheidend. Das war für uns auch so ein unglaublich großer Aha-Moment, dass wir unsere Arbeit nicht sichtbar gemacht haben. Also beispielsweise haben wir Lego-Boards benutzt, um einfach mal zu visualisieren, wie viel Zeit wir verbringen mit welcher Art von Tätigkeiten. Also wie viel Zeit verbringen wir in Meetings, wie viel Zeit verbringen wir mit Bugs, wie viel Zeit verbringen wir mit Feature-Entwicklung, wie viel Zeit verbringen wir mit Mit Admin-Scheiß. Und plötzlich kriegt man ein Gefühl dafür, dass man eine gute Visualisierung findet für das, was man da eigentlich den ganzen Tag tut. Und man aufhört, sich selbst zu belügen. Das finde ich total entscheidend. Das war auch für mich so ein ganz, ganz entscheidendes Take-away, dass man es schafft, die Arbeit, make your work visible. Das fand ich ganz entscheidend. Genau, diese Sticky Notes, du kannst eben die Augen nicht davor verschließen. Du kannst nicht an der Wand vorbeigehen und die Augen zumachen. Sondern du siehst sofort, dein Backlog ist dreckig, dein Backlog ist schlecht aufgeräumt. oder du hast 1000 Bucks offen oder du machst zu viel gleichzeitig. Du siehst sofort, wenn das nicht ästhetisch ansprechend ist.
Anton Skornyakov: Und da sprichst du auch genau das wichtige Ding an, warum ich mich zum Beispiel Agile Coach schimpfe und nicht irgendwie Agile Berater. Weil das, was passiert ist, alle haben natürlich Ängste dann, Dinge transparent zu machen. Aber in dem Moment, wo die transparent werden, können plötzlich andere mich kritisieren. Ja, oder das. Also plötzlich können andere sagen, ja, Moment mal, dein Backlog, hey, ich habe doch mit dir gestern gesprochen, mein lieber Product Owner, ich bin dein wichtigster Stakeholder, warum ist meine Anforderung immer noch nicht so weit oben? Ja, und dann musste ich plötzlich darüber reden. Das heißt, damit das möglich ist, muss sich die Kultur des Unternehmens ändern.damit die Leute wirklich transparent sein können mit ihrer Arbeit. Und deshalb ist sozusagen Agilität einführen in einem Unternehmenhäufig nicht einfach nur ein mechanischer Akt,sondern da ist ganz viel mit Menschenarbeit zu tun.
Joel Kaczmarek: Was ist denn eigentlich mit diesen Scrum Boards, die man immer sieht? Ist das das, also die Tools, die du gerade beschrieben hast,ist das sozusagen damit auch gemeint? Weil wenn man manchmal in so IT-Abteilungen geht,sieht man ja immer so, das sieht aus so senkrecht,wie so Tabellenspalten und dann geht irgendwie so ein Post,und man hat von links nach rechts rum,von geplant zu Umsetzung zu fertig. Fehlt das noch oder ist das sozusagen
Anton Skornyakov: Das ist eine Art von Umsetzung von diesem Sprint-Backlog. Genau, das nennt man auch Scrum-Wort manchmal.
Johannes Schaback: Was ist eigentlich der Unterschied zwischen Scrum und Kanban? Fiese Frage.
Anton Skornyakov: Ja, fiese Frage, weil wir haben nicht so viel Zeit und es gibt da permanente Hate-Worts. Also aus Kanban-Sicht könnte man behaupten, Scrum sei eine besondere Art von Implementierung von Kanban. Das würden Scrum-Leute überhaupt nicht unterschreiben. Beide orientieren sich einfach auf völlig verschiedene Dinge. Scrum ist tatsächlich ein Framework für neue Produktentwicklung. Und bei Scrum geht es wirklich um die Rollen. Es geht um diese Events, die stattfinden müssen, um dieses Lernen, um die Feedback-Loops. Und es geht um die Art von Artefakten. Das ist ganz wichtig, dass es beschränkt ist, dass es nur einen Product-Backlog gibt und es nur einen Sprint-Backlog gibt. Das ist echt wichtig. Kanban lässt alles offen. Kanban sagt, visualisiere erstmal die Arbeit. Dann bist du erstmal dessen bewusst, was passiert? Stelle sicher, dass du keine neue Arbeit beginnst, bevor du etwas beendet hast. Ich vereinfache es jetzt sehr, aber im Grunde genommen stelle sicher, dass es einen Fluss gibt von links, wo die Sachen reinkommen, zu rechts. Und nicht, dass es einfach gepusht wird, dass wir immer mehr Sachen anfangen, aber nichts fertig kriegen. Mache ein Limit, wie viel du überhaupt gleichzeitig in Bearbeitung haben kannst. Denn das hat ganz große Vorteile. Und nutze das Wissen, um dich kontinuierlich zu verbessern. Also vieles davon merkt auf Scrum. Aber ohne jetzt noch tiefer reinzugehen, da gibt es eine ganze Menge Widersprüche.
Johannes Schaback: Was ich mal beobachte, ist, dass insbesondere in serviceorientierten Departments kann man sehr stark eingesetzt werden. Also wo die Arbeit wirklich schlecht planbar ist. Das heißt, in dem Moment, wo ich nicht sagen kann, okay, ich gucke jetzt auf sieben Tage oder fünf Tage voraus und innerhalb dieser fünf Tage weiß ich, dass ich XYZ erreichen möchte. Sondern ich weiß gar nicht, ob ich nicht Mittwoch einen Phonecall bekomme von einem großen Kunden und den muss ich ganz schnell bearbeiten oder ich muss irgendeinen Brand löschen. Also zum Beispiel die Systemadministration bei uns arbeitet eher auf Kanban, weil es einfach so schwer planbare Arbeit ist. Und das finde ich das Tolle an Scrum, dass du eigentlich ein Stück weit planbarer wirst, zumindest immer auf so einer Sprint-Ebene. Siehst du das auch so?
Anton Skornyakov: Es gibt halt Grenzen von wie flexibel du überhaupt sein kannst. Du kannst halt zum Beispiel so etwas wie die PayPal-Integration, das kannst du nicht mal eben heute machen und morgen machst du was anderes. Also du kannst das erlauben, aber dann wirst du halt viel langsamer entwickeln, weil die Entwickler werden halt wahnsinnig viel Zeit verlieren, während sie von einer Aufgabe auf die andere switchen. Das heißt Es gibt unterschiedliche Arten von Aufgaben. Wenn die Aufgaben eher klein sind, eher häufig und jeden Tag erst morgens reinkommen und am besten bis abends gemacht werden müssen und alle eher klein sind, das hört sich eher nach einem Kanban-Flow an. Ich würde aber eher behaupten, dass das eher planbare Geschichten sind. Das sind nämlich statistisch planbar. Während das, was man mit Scrum umsetzt, eher wirklich jedes Mal eine echt andere Sache ist.
Johannes Schaback: Kreativer sein muss. Haben wir jetzt gerade schon mal angerissen. Was ist denn dieses ominöse Extreme Programming?
Anton Skornyakov: Entstand dadurch, dass wahnsinnig viele Praktiken, die alle gute Praktiken waren, also zum Beispiel Peer Review, also dass ein Entwickler den Code des anderen reviewt, extrem gemacht worden sind. Also aus einem Peer Review ist Pair Programming geworden, dass zwei Entwickler einfach direkt am gleichen Rechner sitzen. Oder dass
Johannes Schaback: Ist das auch ineffizient? Muss ich zwei Gehälter zahlen, obwohl da eigentlich dann nur einer den Code schreibt? Oder ist das, der eine benutzt die linke Hand, der andere benutzt die rechte Hand? Oder wie ist das?
Anton Skornyakov: Nee, also in der Regel funktioniert das so, dass ein Entwickler der Driver ist, also der Fahrer, und der andere der Navigator. Und die ändern ihre Funktionen ungefähr alle so 15 Minuten. Und sie sitzen an dem gleichen Rechner, an einer Tastatur und beide denken mit. Und das führt dazu, dass tatsächlich, ja, du zahlst zwei Gehälter dafür, dass Leute an einem Programm arbeiten, also an einer Zeile Code, die sie sich überlegen. Aber die Qualität davon ist deutlich höher. Und das führt dazu, dass du viel weniger Defekte hast, die du hinterher wegmachen musst. Und es führt zusätzlich dazu, dass die Arbeit Spaß macht. Sehr viel mehr in der Regel, als wenn man alleine arbeitet. Und es führt dazu, dass die Leute voneinander lernen. Was ja, wir haben ja vorhin angesprochen, das Wissensarbeit. Das ist wahnsinnig viel permanent neues Lernen, neue Werkzeuge lernen. Und die Entwickler, der eine ist daran gut, der andere ist daran gut. Und man lernt einfach wahnsinnig schnell, wenn man miteinander zusammenarbeitet. Also es gibt da ganz gute Erhebungen, die zeigen, dass es sich finanziell lohnt für Unternehmen.
Johannes Schaback: Und Extreme Programming ist aber viel mehr noch, ne?
Anton Skornyakov: Ja, es gibt da ungefähr elf oder zwölf verschiedene Praktiken, die alle, also zum Beispiel das Schreiben von User Stories, also statt große Anforderungen zu machen, nehmen wir Anforderungen und sagen, wir reden nur davon einer kleinen Story, die im Grunde genommen den Kontext schafft für unsere Unterhaltung. Also wir versuchen gar nicht erst die Anforderung perfekt zu machen, sondern unserer Unterhaltung, also es ist eine Karte. Die Unterhaltung über diese Karte ist der große Mehrwert. Und auf dieser Karte stehen die wenigen Dinge drauf, die beschreiben, dass ich diese Arbeit, die hinter dieser Karte steht, akzeptieren kann.
Johannes Schaback: Joel kann mit PayPal bezahlen zum Beispiel.
Anton Skornyakov: Genau. Ein Nutzer kann seinen Warenkorb mit Paypal bezahlen.
Johannes Schaback: Ja, kann sein Katzenfutter mit Paypal.
Joel Kaczmarek: Sagt ja der Mann, der eine Katzenallergie hat.
Johannes Schaback: Continuous Integration fällt auch in Ja, absolut.
Anton Skornyakov: Continuous Delivery oder so?
Joel Kaczmarek: Merkst du das, wie charmant er immer so tut, als wenn er keine Ahnung hätte?
Anton Skornyakov: Ja, natürlich kennt er sich ja. Genau, also Continuous Integration bedeutet ja, wir integrieren nicht jeden Tag, was eine gute Praktik wäre, sondern wir integrieren einfach kontinuierlich, permanent. Sobald ich etwas gemacht habe, committe ich meinen Code in die aktuellsten Master und er wird sofort daraufhin geprüft, ob er die Tests besteht.
Johannes Schaback: Ah, okay, weil es ist ja total risikoreich, wenn ich das sofort live schalten würde.
Anton Skornyakov: Genau, also ohne dass ich automatisierte Tests habe, funktioniert das eben nicht. Aber Continuous Integration erlaubt es mir, dass ich mit vielen Leuten gleichzeitig arbeite. Denn es passiert ja, wenn ich eine Funktion verändert habe, die du gerade auch anfasst, dann wird das, was du gemacht hast,eben zu einem Konflikt führen mit mir. Das heißt, und wenn wir Hunderte von Leuten sind,dann kann ich alles überhaupt gar nicht vorhersehen,wo überall Konflikte sein können. Also das heißt,Continuous Integration wird umso wichtiger,je mehr Menschen ich in meinem Unternehmen habe. Continuous Delivery wird umso wichtiger,je mehr Menschen ich in meinem Unternehmen habe,weil es dann sofort mir ermöglicht,vom Kunden zu lernenund nicht zu warten,bis ich irgendwie, sagen wir mal,in zwei Wochen erst delivered habe. Test-Driven Development, genau sowas. Wir schreiben automatisierte Tests. Test-Driven Development bedeutet,wir schreiben die zuerst. Bevor wir unsere Software schreiben, schreiben wir erst einen Test und der Test sagt natürlich erstmal, hey, die Software funktioniert nicht, weil es gibt ja gar keine. Aber dann schreibe ich die Software, der Test wird grün und dann verbessere ich die Software so, dass sie sauber ist und leicht verständlich ist. und dann gehe ich zum nächsten Test über.
Johannes Schaback: Speaking of mehr Menschen im Unternehmen, was passiert denn, wenn ich jetzt 19 Scrum Teams habe? Wie kriege ich die denn organisiert? Also ich habe jetzt verstanden, wie jedes einzelne Scrum-Team funktioniert und dass die sozusagen in sich bottom-up sich selbst organisieren, ihre Arbeit sichtbar machen, iterativ verbessern, dass sie lernen, dass es ein Lernprozess ist. Aber irgendwie muss ich jetzt ja diesen Ameisenhaufen steuern oder zumindest, was ist der richtige Ansatz, wenn ich jetzt ganz, ganz viele Scrum-Teams hätte?
Anton Skornyakov: Also der wichtige Punkt, den man verstehen muss, ist, dass man bestimmte Dinge nicht einfach nur beliebig viel skalieren kann. Und der wichtige Punkt, den man nicht skalieren kann, ist die Priorität. Also man kann nicht 19 Scrum-Teams haben mit 19 POs. Weil dann hat man ein Schiff, wo 19 Leute alle glauben, in die verschiedenen Richtungen laufen zu müssen. Die haben alle ihr Ziel, die wollen alle mit ihrem Team irgendwas Eigenes erreichen. Dadurch fährt aber das Schiff nicht in die Richtung, in die es will. Es braucht immer noch einen Kapitän. Es braucht immer noch einen Haupt-PO. Und wenn man 19 Teams hat, dann kann man gegebenenfalls, kann dieser PO sagen, okay, das sind unsere, dann nicht Stories, sondern er priorisiert dann eher Epics. Und er sagt, okay, diese drei Epics, die gehen an diesen Bereich. Und dieser Bereich besteht dann aus vier bis acht Teams.
Joel Kaczmarek: Was heißt Epics?
Anton Skornyakov: Epics ist sozusagen der Begriff für eine, also Story ist eine Geschichte und Epic ist halt eine längere Geschichte. Und da gibt es, kann man auch noch von Sagas sprechen, aber das Lieber gar nicht.
Johannes Schaback: Muss am Ende mehr Wert generieren, könnte man auch sagen. Muss am Ende ein dickeres Brett bohren.
Anton Skornyakov: Genau, wir sprechen ja von einer Story, weil wir wollen ja immer nicht von Software reden, sondern wir wollen darüber reden, was kann ein Nutzer mit unserer Software machen. Und das ist seine Geschichte. Ich erzähle eine Geschichte, wie Joel kommt und hat bei uns eingekauft und jetzt möchte er mit PayPal bezahlen. Und das ist eine Geschichte. Und eine Epic, sowas wie Joel möchte mit PayPal bezahlen, ist eigentlich eine Epic in der Regel. Weil da ganz, ganz viele Untergeschichten gibt.
Johannes Schaback: Ich habe immer das Gefühl bei Scrum oder auch grundsätzlich bei agilen Methoden, es ist wie Fußball spielen. Also man kann von außen drauf schauen und verstehen, wie es geht. Man kann die Regeln grundsätzlich verstehen. Man weiß, man hat die Bücher gelesen, aber wirklich spielen. ist unglaublich schwer. Und ihr wisst nicht, wie schlecht ich Fußball spiele. Ich hoffe, mein Scrum ist besser. Das finde ich total beeindruckend. Das ist wirklich ein Lernprozess. Hast du das Gefühl, wie wird man gut in agilen Methoden? Hast du das Gefühl, muss man sich ständig fortbilden? Muss man eigentlich mehr ausprobieren? Oder ist es eher eine Disziplinfrage? Oder woher weiß ich, ob ich gut bin? Also viele Leute haben das ja sicherlich auch schon ein Stück weit implementiert oder glauben, diesen Mindshift vollzogen zu haben, können aber gar nicht so genau sagen, okay, ich bin jetzt wirklich agile oder nicht.
Anton Skornyakov: Ja, es gibt auch kein objektives Maß an Agilität. Leider ist das nicht möglich. Es gibt so ein paar Sachen, die man machen kann, die ich typischerweise mache, wenn ich in so ein Unternehmen gehe. Also wenn man zum Beispiel so einen typischen normalen Entwickler nimmt und den mal bittet, zu erklären, woran er gerade arbeitet und der innerhalb von vier, fünf Sätzen einem gut erklären kann, warum das Mehrwert macht, woran er da arbeitet, dann weiß man, aha, Meine Leute, also das muss man vielleicht nicht mit einem machen, sondern mit mehreren, aber dann weiß man, okay, meine Leute wissen, woran sie arbeiten. Sie wissen wirklich das Endziel, auf das sie dahin arbeiten. Und sie verbinden sich damit jeden Tag. Das ist ein wichtiges Merkmal. Was anderes ist, schaffen wir es, Vorhersagbarkeit zu erreichen? Also wenn wir vorhersagbar sein müssen, vielleicht müssen wir es nicht, verbessern wir uns. Also ein agiles Unternehmen, man erkennt es nicht wieder, wenn man in sechs Monaten wiederkommt. In der Regel hat sich da so viel verändert, dass man das wieder verstehen muss,wie die eigentlich funktionieren.
Johannes Schaback: Wird Scrum weiterentwickelt? Hast du das Gefühl, da gibt es jetzt neue Tendenzen? Was ist Scrum 2.0?
Anton Skornyakov: Es ist ganz wichtig, dass es keine Versionsnummern gibt. Der Ken Schreber sagte immer, Scrum kann nicht scheitern, man kann selbst scheitern. Tatsächlich hat aber Scrum Veränderungen durchgemacht. Es gab zum Beispiel früher keine Review- und Retro-Unterscheidung, sondern es gab ein Review, in dem beide Dinge gemacht worden sind, die heute sozusagen in zwei Meetings getrennt sind. Es gibt kleinere Veränderungen an Scrum, aber wirklich nicht große. Und die haben vor allem was damit zu tun, um es leichter verständlich zu machen. Der Kern wird, soweit ich weiß, eigentlich nicht verändert. Also ich habe bis jetzt von keiner Veränderung gehört, die irgendwie den Kern verändert hat.
Johannes Schaback: Scrum wird auch viel kritisiert. Ein beliebter Kritikpunkt, den ich immer wieder höre, ist, es hat zu viele Meetings. Man verbringt zu viel Zeit. Es gibt auch diesen schönen Witz, weeks of programming save hours of planning. dass man einfach zu viel sich mit sozusagen administrativen Prozessscheiß beschäftigt. Ich sage dann immer, ich glaube, wir müssen an unserer Mindset arbeiten. Und ich bin selber überzeugt, dass jedes einzelne Scrum-Element, also sage ich jetzt so eine Zeremonie, also irgendein Meeting oder Artefakt, also das, was du da irgendwie schaffst, Sinn macht. Und wenn du nicht das Gefühl hast, es macht Sinn, dann haben wir eigentlich nicht verstanden, warum wir das machen. Hast du das Gefühl Es gibt Bereiche, wo Scrum einfach wirklich überhaupt keinen Sinn macht, wo man wirklich sagen muss, okay, alles klar, hier ist Scrum nicht das richtige Mittel der Wahl.
Anton Skornyakov: Na klar, da gibt es ganz viele. Ich habe letztens ein sehr schönes Beispiel gesehen. Ich habe eine Präsentation gesehen von jemandem, der verantwortlich ist für den Aufbau von Offshore-Windparks in Deutschland. Und der hat erklärt, dass über 50 Prozent der Kosten von dem Aufbau von so einem Offshore-Windpark an dem einen Aufbautag passieren. Weil genau zu diesem einen Tag die wichtigsten Experten eingeflogen werden müssen, ein ganz besonderes Schiff bestellt werden muss, von dem es nur zwei, drei in der ganzen Welt gibt. Und es einfach wahnsinnig viel kostet. Dieser eine Tag kostet einfach wahnsinnig viel. Das heißt, dort planst du Bis ins kleinste Detail. Du versuchst alle Möglichkeiten auszuschließen, dass an diesem Tag irgendwas schief geht. Ja, weil dann einfach sich die Kosten explodieren. Es macht keinen Sinn, einen Wind Offshore Park iterativ aufzubauen. Es würde einfach wahnsinnig teuer werden. Und es gibt auch nicht so viele Veränderungen. Dagegen, die Entwicklung von den Rädern von dieser einzelnen Anlage, die werden inkrementell verändert. Das heißt, da gibt es sehr wohl agile Ansätze. Also es gibt eine ganze Menge Dinge, die zusammenkommen können, die es unmöglich machen, oder die es nicht effektiv machen, dass man Scrum macht. A, wenn es einfach sehr, sehr teuer ist.zu iterieren. Das ist zum Beispiel beim Hausbau oder so,also das ist häufig bei harten Sachen so. Oder wenn es sehr, sehr vorhersagbar ist,also wenn einfach ganz wenig Variabilität da ist.
Johannes Schaback: Fließband?
Anton Skornyakov: Ja, genau, also wobei man sich dann fragen muss,ob das Fließband wirklich das Beste ist,was das Unternehmen braucht. Aber wenn ganz wenig Variabilität da ist,dann sind halt unsere Retros total langweilig. Weil dann fragen wir uns ja, was haben wir denn diese Woche? Ja, wir haben wieder am Fließband gestanden. Ja, was sollen wir denn jetzt anders machen? Ja, wir haben gar keine Freiheiten. Da muss man andere Dinge, viel größere Dinge verändern,bevor eine Retro zum Beispiel Sinn machen würde. Das heißt, Scrum macht nicht überall Sinn. Und immer dann, wenn die Leute sagen, ja, Meeting, das hört sich nach etwas,das ist irgendwie bürokratisch hier, das ist ein Symptom. Und das kann ganz viele Ursachen haben. Und das ist im Grunde genommen auch ein Teil der Arbeit eines agilen Coaches oder eines Scrum Masters, wenn er da ist, sich zu fragen, okay, was können wir da mitmachen.
Joel Kaczmarek: Hervorragend. Ich bewundere deine schönen Sprachbilder, die du hast. Das macht ja wirklich Spaß. Scrum zu erklären, wann es nicht passt, anhand von Windrädern, das finde ich sehr, sehr gut. Und ich bin dankbar, endlich mal zu wissen, woher Scrum kommt. Das klingt immer so wie so ein Grock bei Monkey Island oder sowas. Ja, oder so ein Reinigungsmittel.
Johannes Schaback: Ja.
Joel Kaczmarek: Ganz herzlichen Dank, Anton, dass du uns auf so eine unterhaltsame, bildliche Reise mitgenommen hast, deine Zeit für uns geopfert hast und so viel Input gegeben hast. Danke dir, Johannes, dass du dich für uns auch mal ein bisschen dümmer stellst, als du eigentlich bist und uns so fleißig durch diese Themen führst. Also euch ganz herzlichen Dank, es hat viel Spaß gemacht.
Anton Skornyakov: Und danke euch für die Gelegenheit, mal wieder ein bisschen über Agilität reden zu können. Es ist mir ein Herzensanliegen, das mehr in die Welt zu bringen.
Johannes Schaback: Herzlichen Dank. Vielen Dank. Tschüss.
