Wir haben Falko Werner zu Gast, mit dem wir uns über Skalierung in DevOps unterhalten: warum muß man skalieren (oder nicht?), wie geht man es an, sowie ein Überblick über verschiedene Skalierungsframeworks wie SAFe, LeSS, Flow Framework und einige weitere.
In dieser Podcast-Episode werden verschiedene Aspekte der Skalierung in DevOps erörtert. Die Gastgeber und ihre Gäste, erfahrene Trainer und Berater im Bereich DevOps, tauchen tief in die Theorie und Praxis der Skalierung ein. Sie diskutieren eine Reihe von Frameworks wie SAFe, LESS, Nexus und andere, und wie diese in verschiedenen organisatorischen Kontexten angewendet werden können. Es wird betont, dass die Wahl des richtigen Frameworks von den spezifischen Bedürfnissen eines Unternehmens abhängt und wie wichtig es ist, Agilität und Wertschöpfungsketten über die IT hinaus in die gesamte Organisation zu integrieren.
Inhalt
- Grundlagen der DevOps-Skalierung
- Verschiedene Skalierungsframeworks (SAFe, LESS, Nexus, ITIL 4, usw.)
- Anpassung von Frameworks an Unternehmensbedürfnisse
- Bedeutung von Agilität und Wertschöpfungsketten in Unternehmen
- Diskussion über die Praxiserfahrungen mit diesen Frameworks
- Der Einfluss der IT auf die Unternehmenswertschöpfung
- Kritik und Verteidigung von SAFe als agiles Framework
Shownotes:
https://vempio.de/produkt/skalierung-von-devops-deutsch/
Transkript (automatisiert erstellt, wer Fehler findet darf sie behalten)
Die Sendung wurde vom hr untertitelt.
Hallo und herzlich willkommen zu einer neuen Folge des Podcasts
DevOps auf die Ohren und ins Hirn.
Gestaltet und produziert von Luca Ingianni und Dierk Söllner.
Wir sind DevOps-Trainer und Coaches mit langjähriger Erfahrung.
DevOps umfasst für uns beide kulturelle, organisatorische und technische Aspekte.
Diese diskutieren wir mit Experten aus der Praxis oder in einer gemeinsamen Folge.
Heute haben wir ein etwas ungewöhnliches Setting,
denn Dirk, der ja der Gründer dieses Podcasts immer ist,
ist in Anführungszeichen nur als Gast hier.
Zusammen mit unserem lieben Freund Falko Werner.
Und mit den beiden möchte ich heute als Gastgeber
über das Thema DevOps skalieren sprechen.
Hallo Dirk, hallo Falko.
Hallo.
Hallo Luca, hallo Falko.
Falko, wer bist du denn eigentlich?
Wie, wer bin ich?
Ich bin schon zum zweiten Mal bei euch im Podcast.
Ich bin bereit.
Ich bin ein Berater, Coach, Trainer im Umfeld von verschiedenen Unternehmen,
die agile Arbeitsweisen vorantreiben.
Viel in der Automotive-Bereich, Mobilität, Car-Bike-Sharing und so weiter.
Also ganz viele verschiedene Sichten.
Auch in verschiedenen Rollen bin ich da unterwegs.
Auch als Architekt teilweise.
Und ich freue mich, dass ich zu Gast bin.
Und das in einer ganz besonderen Folge.
Luca, du musst noch einen Tusch nachher rein moderieren.
Also 50. Folge, das finde ich, muss man auch erst mal erreichen beim Podcast.
Ja, allerdings.
Wie viele Jahre sind das jetzt?
Das sind drei Jahre oder so, ne?
Ich glaube ja, es sind ja zwölf pro Jahr.
Also rechnerisch sind das sogar fast schon vier Jahre.
Ja, das ist sehr respektabel, finde ich, für den Podcast.
Müssen wir nachher irgendwie noch ein Champagner aufmachen oder sowas.
Plopp, plopp.
Genau.
Und für heute hatten wir uns ja vorgenommen, über das Thema Skalieren zu sprechen.
Und wir sind draufgekommen, dass das ein so spannendes und umfangreiches Thema ist,
dass wir direkt gesagt haben, wir machen da von vornherein zwei Folgen daraus.
Das bedeutet, ihr werdet heute die erste Folge zum Thema Skalieren hören.
Wo wir so ein bisschen über die Grundlagen sprechen.
Worum geht es denn?
Verschiedene Frameworks.
Warum sollte man überhaupt skalieren?
Muss man überhaupt skalieren?
Und dann in der zweiten Folge wollen wir uns ein bisschen mehr mit den, ich sag mal, praktischen Aspekten beschäftigen.
Wie macht man so eine Skalierung eigentlich?
Welche Schwierigkeiten können auftreten?
Welche Erfahrungen habt ihr schon gemacht?
Welche Erfahrungen habt ihr auch aus euren Trainings vielleicht beizusteuern?
Nicht zu vergessen, wir haben ja auch ein sehr cooles,
Trainings über DevOps skalieren.
Das ist so ein bisschen der Fahrplan für diese und die nächste Folge des Podcasts.
Insofern, lasst uns doch direkt reinspringen.
Wieso muss ich denn eigentlich skalieren?
Oder was ist denn skalieren?
Wieso muss ich das machen?
Okay, skalieren.
Warum müssen wir überhaupt skalieren?
Das ist natürlich die richtige Frage.
DevOps heißt natürlich, geht in Richtung Teamorganisation.
Und ich bringe also alle Funktionen, alles,
alles Wissen in ein Team für Dev und für Ops.
Selbst wenn ich nicht DevOps mache, wenn ich nur ein agiles Team habe,
was vielleicht rein in der Entwicklung tätig ist.
Irgendwo habe ich Grenzen.
Das heißt, die Grenzen liegen letzten Endes in der Teamgröße.
Und eigentlich reden wir schon über skalieren, also darüber, dass mehrere Teams zusammenarbeiten müssen,
dass ich die Zusammenarbeit organisieren muss, wenn ich zwei Teams habe.
Das heißt, rein von der Theorie her, skaliere ich ja schon, wenn ich mit zwei agilen Teams arbeite.
Und, ähm,
wie gesagt, in der Praxis, gerade wenn wir über DevOps reden, gibt es eigentlich ja immer mehr als ein Team.
Ähm, es gibt vielleicht auch eine Entwicklungsmannschaft, die irgendwie agil arbeitet.
Dann gibt es den Betrieb noch, es gibt noch IT-Infrastruktur, die auch irgendwie zusammengebracht werden müssen.
Also wir reden eigentlich immer darüber, dass wir verschiedene Gruppen, dass wir mehrere Menschen zusammenbringen.
Und das ist für mich skalieren.
Sehe ich letztendlich auch so.
Skalierung ist ein Begriff, der meist dann zusammen, ähm, ja, auftaucht, wenn man,
ähm, mit mehr als einem Team arbeitet.
Aber eigentlich ist ja schon die Arbeit im, im Team, ähm, eine Skalierung.
Und zwar die erste Ebene, ähm, von den Individuen hin zum Team.
Und im DevOps-Umfeld wird halt häufig, ähm, von cross-funktionalen Teams gesprochen,
die einen gewissen, ähm, ja, Bereich abdecken können von einem Produkt, von, ähm, Inhalten.
Und, ähm,
üblicherweise geht’s dann, wenn man über mehrere Teams spricht, in den Bereich der, der Skalierung, ähm, von den,
von der wir hier, ähm, reden, wenn wir sagen, wir skalieren DevOps.
Das bedeutet, ein Team ist sowieso schon die erste Ebene von Skalierung, weil einer, einer macht alles allein.
Das wäre sozusagen die einfachste Lösung, ne?
Ja.
Wenn das nicht mehr geht, schnalle ich mir mehrere Leute in ein Team.
Und wenn das auch nicht mehr geht, dann mache ich mir ein Team von Teams.
Zum Beispiel.
Ja.
Und aus meiner Sicht ist das Thema Skalieren bei DevOps, ähm, ja, vielleicht besonders sichtbar, weil eben auch aus meiner Sicht die, die Unternehmen,
wo wir als Trainer und, und Coaches und Berater unterwegs sind, in der Regel ja auch größere Unternehmen sind.
Das heißt, sind Unternehmen, die schon seit vielen Jahren agile Ansätze, ähm, und agile Methoden verfolgen, die ihre Erfahrungen gemacht haben,
wie diese Teams zusammenarbeiten, die an vielen Stellen auch schon seit Jahren unterwegs sind, ähm, diese agile Arbeit in den Entwicklungsteams zu skalieren.
Skalieren, also auszudehnen, Zusammenarbeit sicherzustellen, und jetzt kommen wir eben dann mit dem Thema Betrieb um die Ecke.
Das heißt, die Unternehmen möchten, das ist immer meine Wahrnehmung zumindest, irgendwie auch versuchen, den Betrieb mit reinzubringen, also DevOps.
Insofern kommt, glaube ich, auch das Thema Skalieren im DevOps-Umfeld mit dazu, weil eben der Bereich Dev jetzt in Richtung Ops, ich sag mal, die Fühle ausstreckt, um zusammenzuarbeiten.
Insofern hat man dann halt auch das, was man wertvoll findet.
Ja, genau.
Genau.
Dass man eine vertikale Skalierung hat letztendlich, dass man von Teams, die üblicherweise von, ähm, einem Bereich her, äh, zusammenarbeiten, häufig Entwicklung, meist kombiniert mit Testing,
dann halt von dem Wertstrom auch mehr abgedeckt wird in Richtung Operations, was du gerade meintest.
Aber jetzt muss ich doch mal ein bisschen ketzerisch sein und fragen, ähm, wenn’s bei DevOps auch sehr stark um Autonomie geht, was ich ja immer wieder höre,
inwieweit müssen diese Teams denn dann überhaupt zusammenarbeiten?
Kann ich nicht einfach skalieren, indem ich sage, ich steck hier, keine Ahnung, 20 autonome Teams nebeneinander und die machen halt jeder so irgendwie ihr Ding?
Kann man machen, wird aber nicht zum Ziel führen.
Ich glaub, das ist natürlich wirklich eine, eine ketzerische Frage, aber ich glaub, jeder, der so halbwegs in der, in der betrieblichen Umfeld, äh, unterwegs ist, der wird sagen, alles klar, die werden irgendwas machen, aber die werden, ähm, selten gut zusammenarbeiten.
Und das, was Falco ja eben auch sagte, ähm.
Ja.
Wir haben ja auch, ähm, immer diese, diese Freiheiten in den Teams, die sind super wichtig, ähm, aber ich muss natürlich schon dafür sorgen, dass, wenn ich skaliere, also wenn mehrere Teams zusammenarbeiten, dass sie auf ein gemeinsames Ziel hinarbeiten, dass sie, ähm, auch gemeinsame, ähm, Regelungen haben, wie sie arbeiten, wie sie sich abstimmen, das Thema Schnittstellen.
Also, ähm, ich kenn dich ja, Luca, das war sicherlich keine ernst gemeinte Frage, es war eine richtig schöne, ketzerische Frage, aber es wird nicht funktionieren.
Wenn die, wenn die Teams einfach so, ähm.
Wenn die Teams einfach so machen lasse.
Okay, also einfach so machen lassen geht nicht.
Schade eigentlich, aber du hast recht, wäre natürlich ein bisschen zu schön gewesen, ne?
Und daher kommen wohl dann diese ganzen verschiedenen Ansätze der Eskalierung, dass man sagt, wie kriege ich, wie, wie kann ich ein gemeinsames Regelwerk verfassen, oder?
Für mehrere Teams, mehrere, ich weiß auch nicht, ähm, auch Architektureinheiten nicht zuletzt, ne?
Weil es, es geht ja auch immer um das berühmte Conway’s Law.
Die Dinge, die ich da mache im Kontext der Organisation, die strahlen ja aus auf die Architektur.
Und umgekehrt.
Genau.
Das ist auf jeden Fall eine Sicht, die hilfreich ist.
Und zwar, ähm, kann man natürlich Teams einfach machen lassen und dann halt die Probleme aufräumen.
Ähm, oder man kann halt versuchen, schon ein Stück vorzudenken.
Und, ähm, je nachdem, wie man vorgeht, kann man sich auch inspirieren lassen von Erfahrungen, Best Practices, die sich in, in Frameworks widerspiegeln.
Man kommt aber selten drumherum.
Die Probleme, die mit Conway’s Law zusammenhängen, nämlich, ähm, cross-funktionale Teams aufzusetzen, die möglichst miteinander gut arbeiten,
die in ihrer Kommunikationsstruktur natürlich auch bei einem großen Produkt sich in der Produktkommunikationsstruktur wiederfinden.
Das heißt, die Zusammenhänge zwischen der Teamstruktur und der Struktur der Softwarekomponenten, äh, Module in einem großen System, ähm, spiegeln sich halt nach Conway.
Der hat das ja schon seit Ende der 60er-Jahre, äh, untersucht und, äh, mehrfach an verschiedenen Beispielen auch nachgewiesen, dass es so ist und immer wieder auftaucht.
Ähm, das kann man natürlich auch nutzen, um die Teamstrukturen und das vielleicht richtige Framework, äh, rauszusuchen, was die bestimmten Strukturen, die man technisch erreichen will, auch, ähm, organisatorisch unterstützt.
Im besten Fall geht das halt Hand in Hand.
Okay, ähm, aber eine Sache, die mich jetzt immer noch so ein bisschen beschäftigt.
Ist immer noch, ab wann muss ich denn eigentlich skalieren?
Weil du hast ja, du hast ja auch gesagt, nein, man kann ja auch den Ansatz wählen zu sagen, wir lassen einfach mal alle Teams machen und hinterher fegen wir die Scherben zusammen.
Das klingt jetzt natürlich sehr negativ, aber ich könnte mir vorstellen, zum Beispiel, wenn ich zwei Teams habe, ist das eigentlich gar kein schlechter Ansatz, dass man, dass man die erstmal so ein bisschen machen lässt und denen gar nicht so ein strenges Korsett vorgibt.
Oder sehe ich das, stelle ich mir das zu einfach vor?
Das ist auf jeden Fall eine Variante.
Je weniger Teams oder je kleiner.
Das Produkt ist oder die Teams, die an dem Produkt arbeiten, ähm, sich aufteilen, desto einfacher wird es wahrscheinlich auch, was die Kommunikationsstrukturen und, ähm, die Frameworks angeht, die man dafür einsetzt.
Es gibt auch bestimmte Vorgaben von den Frameworks, in welchem Bereich sie einsetzbar sind.
Zum Beispiel, ähm, ein, ähm, Nexus, das sagt, bis zu acht Teams kann man gut in einem, ähm, für ein Produkt zusammenbringen, ähm, wenn man dieses Framework einsetzen will.
So ähnlich ist auch die Größenordnung bei, bei Less oder für einen agilen Release-Train bei Safe.
Insofern gibt es da ähnliche Größenvorgaben.
Was ich an, an sich ganz…
Was ich an sich ganz interessant finde, wenn man sich die Frameworks mal Stück für Stück, ähm, nebeneinander hält und anschaut.
Okay, ähm, also das fand ich halt schon mal sehr interessant.
Mit anderen Worten, es gibt so gewisse Untergrenzen, unterhalb derer man sich vielleicht das gar nicht antun muss, sich da jetzt systematisch mit Skalierungsframeworks und so auseinanderzusetzen?
Mal, das würde ich, wenn ich auf unsere, auf unsere Schulung gucke und auf die Frameworks, die wir da vergleichen, ähm, würde ich das ein bisschen, ähm, ja, in Frage stellen.
Also, ähm, eine, eine Untergrenze würde ich, wenn ich jetzt rein die Frameworks anschaue, die wir uns, ähm, und die wir untersucht haben, die wir in der Schulung behandeln, würde ich sagen, es geht auch schon mit 15 oder 20, ähm, Teilnehmern.
Wir haben hier ein Framework mit dabei, was letzten Endes nur dafür geschaffen ist, ein, ähm, ein, ein, ein Team abzudecken, also ein Team zu skalieren, ohne dass ich mehrere Teams, ähm, habe.
Also, wir reden da über, über Floating Teams als Ansatz zu sagen, wir haben also…
Es bleibt ein Team, was bis zu 30 Teilnehmer hat, es bleibt ein Team und ich skaliere quasi in diesem Team.
Also, insofern, wenn ich, wenn wir auf eine Untergrenze gehen, würde ich sagen, 30, einfach um mal eine Zahl rauszuhauen.
Ich weiß nicht, wie, wie Falco das sieht, aber ich würde mal die Zahl 30 raushauen.
Ja, ich denke auch, dass da verschiedene Frameworks unterschiedliche Grenzen ziehen, aber 30 ist ungefähr, ähm, eine gute Basis, um, um zu starten und, ähm, muss dann halt schauen, wie groß der Bereich ist, den man da,
ähm, zusammenfassen will und dann gibt’s halt auch gewisse Obergrenzen für bestimmte Skalierungsebenen, wenn man halt vom, ähm, Individuum von dem einzelnen Teammitglied über das Team geht.
Da gibt’s ja auch gewisse Grenzen. So ein Team sollte ja üblicherweise nicht weniger als drei oder fünf, äh, Mitglieder haben, aber auch nicht mehr als, ähm, elf oder, ja, vielleicht manchmal auch in Ausnahmefällen 15.
So ähnlich ist es dann bei den, ähm, Skalierungsfällen.
Frameworks natürlich auch, dass sie auch eine, eine Obergrenze für ihr, für bestimmte Bereiche haben oder dass man dann, ähm, weitere Skalierungsebenen halt einfügen muss, die dann gewisse Strukturen auch unterstützen.
Aber mit 30 als, als Grundlage zu starten, man sollte nicht drüber, man muss nicht über Skalieren nachdenken, ähm, wenn man halt unter der Größe ist oder da macht’s halt Sinn, drüber nachzudenken.
Es gibt auch so ein schönes Zitat, ähm, wenn du skalieren willst.
Mach’s nicht. Oder auf Englisch, if you want to fail, don’t.
Das musst du mir erklären. Ich höre das zum ersten Mal.
Okay. Also wenn man letztendlich Skalieren, also Frameworkstrukturen nutzen will, die, ähm, sich an den Skalierungsansätzen und Frameworks orientieren, einfach nur des Frameworks wegen oder weil’s halt, ähm, schön ist oder weil man das mal ausprobieren will, dann hat man damit eine ganze Menge Overhead.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
Ja.
war, so 30 Teammitglieder an einem Produkt anzuwirken und gehen dann halt relativ weit
hoch, im schlimmsten Fall halt bis in den ganzen Konzern.
Ja, und ich wollte mal auf deine Eingangsfrage zurückkommen, Luca.
Du hast ja vorhin gesprochen, wann muss man denn skalieren?
Und das, was Falco eben mit diesem Zitat so schön gesagt hat, finde ich, das kann man
da auf jeden Fall nochmal aufgreifen.
Denn letzten Endes muss man nicht skalieren.
Man muss schon gar nicht skalieren, weil es ein tolles Skalierungsframework gibt, was
der gute Kumpel auch gerade irgendwie eingesetzt hat.
Das nennt man die Golfplatzentscheidung für mich.
Nein, bin wieder böse.
Also, man muss nicht skalieren, aber ich denke, dass die Unternehmen überall feststellen,
dass sie in Schwierigkeiten laufen, eben in dieser Zusammenarbeit zwischen den Teams.
Das könnten technische Schwierigkeiten sein, das können organisatorische Schwierigkeiten
sein, aber es gibt Schwierigkeiten.
Und dann sollte man sich eben überlegen, was kann.
Was kann man tun, um die Zusammenarbeit zu verbessern?
Und dann reden wir letztendlich schon über Skalieren und reden über Frameworks.
Wir reden über Erfahrungen von anderen Unternehmen, die das schon hinter sich gebracht haben und
zu denen es dann eben die entsprechenden Frameworks gibt.
Und das ist ja auch das Ziel unserer Schulung, dass wir eben versuchen wollen, mit dieser
Zwei-Tages-Schulung verschiedene Frameworks zum Skalieren darzustellen und das eben nicht
um neuen Frameworks darzustellen, sondern das alles mit Fokus auf DevOps.
Also, die Schulung heißt ja auch DevOps skalieren.
Also, was kann ich nutzen?
Welche Möglichkeiten gibt es, wenn ich in einem DevOps-Umfeld eben skalieren möchte?
Wie gesagt, nicht muss, möchte.
Und das ist wie gesagt, das ist der Inhalt unserer Schulung.
Und da stellen wir eben, wie gesagt, diese neuen Frameworks vor.
Aber nochmal nicht, um einfach Frameworks vorzustellen, um viele Frameworks vorzustellen, sondern um aus jedem Framework das darzustellen, was wir auf den
DevOps-Bereich übertragen können.
Okay, aber jetzt möchte ich an der Stelle mal fragen, nachdem wir schon gesagt haben, wenn man skalieren will, dann sollte man es nicht tun.
Aber warum sollte man es denn müssen?
Oder andersrum gefragt, was sind denn so die typischen Probleme, die man vielleicht verspürt, wenn man sich der Situation nähert, dass man jetzt halt doch skalieren muss
und dementsprechend vielleicht sich auch der Hilfe eines Frameworks bedienen soll oder sowas?
Welche Probleme lösen denn Frameworks?
Welche Probleme löst denn diese Skalierung?
Letztendlich sind es Probleme, die in Richtung Zusammenarbeit gehen, Kommunikationsprobleme, Alignment, insofern, dass alle Teams, die an einem Produkt arbeiten,
voneinander wissen müssen, dass es Abhängigkeiten gibt, dass man über die Abhängigkeiten dann redet, miteinander ins Gespräch geht und sie versucht zu lösen,
planerisch meist, dass bestimmte Dinge von einem Team geliefert werden müssen.
Und die eine Grundlage für ein weiteres Team sind, darauf aufzubauen, dass man sich da über Zeiten abstimmt.
Und da helfen Frameworks, diese Kommunikationsprozesse und Strukturen zu etablieren, um das Ganze ein Stück rund zu machen.
Wenn man das also nicht tut, hat man einen gewissen Chaos-Bereich, in dem man dann unterwegs ist.
Dann wartet ein Team vielleicht Wochen oder Monate darauf, dass ein anderes Team eine zulässt.
Wenn man dann eine Lösung bringt, die benötigt wird, die das Team selbst aber vielleicht aufgrund von Kompetenzen oder vielleicht auch Verantwortungsbereichen nicht übernehmen kann und selbst lösen kann,
weil es zum Beispiel sowas wie gemeinsames Produktverständnis, eine gemeinsame Software-Code-Basis oder ähnliches nicht gibt.
Ein Team hat eine bestimmte Ruhe für eine Komponente und solche Themen kommen dann halt in die Diskussion und führen dann vielleicht auch im Rahmen von einem skalierten Vorgehen
darauf hin, dass jemand, der sich für die Zusammenarbeit und die Performance der Teams Gedanken macht,
sowas wie ein Scrum-Master auf Team-Ebene oder wenn man sich bei SAFe vielleicht orientiert, ein Release-Train-Engineer,
Impediments halt sieht, die man dann halt lösen würde, wofür es dann aber ohne so ein Framework, ohne diese Rollen, ohne diese Verantwortung niemanden gäbe.
Und dann bleibt halt vieles liegen und man hat halt keinen gemeinsamen Fortschritt.
Man weist.
Man weist nicht, wo man jetzt wirklich wichtig an irgendetwas arbeiten muss, damit es für das Unternehmen oder dann auch für die Kunden wieder eine Wertschöpfung gibt.
Und daran kranken halt teilweise auch dann solche unkoordinierten Ansätze.
Also Falco, du hast ja eben ein bisschen was erzählt an dem Ansatz Kommunikation etablieren, Zusammenarbeit etablieren.
Ich glaube, dass so der Anspruch oder der…
Der Wunsch nach Skalierung, also nach besserer Zusammenarbeit, dann auch aus dem Business herauskommt, aus dem Management herauskommt,
die dort eben sehen, dass die Konsequenzen dieser schlechten Zusammenarbeit spüren, schlechte Ergebnisse, verzögerte Lieferung, unabgestimmtes Vorgehen.
Das heißt also auch, dass quasi die Kunden der IT, und auf die sollten wir ja auch achten, dass die Kunden der IT eigentlich auch feststellen, es passt nicht.
Naja, aber können die Leute nicht einfach miteinander reden? Ich meine, das ist doch auch okay, auch ganz ohne Skalierungsframeworks.
Tja, hört sich gut an, Luca, aber wenn ich meine Phoenix-Projekt-Simulation mir anschaue, wenn ich meine anderen Simulationen in irgendwelchen Trainings anschaue,
die Leute sind immer ganz überrascht, wie wichtig es ist, miteinander zu reden.
Und dazu muss man irgendwelche Spielchen spielen, ich sage es mal ganz despektierlich, und das muss man wahrscheinlich auch den Leuten klar machen.
Und man muss ihnen wahrscheinlich auch eine…
Ein Hilfsmittel eben an die Hand geben, wie sie diese Kommunikation etablieren können.
Also zu sagen, redet miteinander, reicht wahrscheinlich nicht aus.
Ja, wenn es dann über 15, 20, 100 Beteiligte sind, die in verschiedenen Teams arbeiten, mag dieses Redet doch miteinander ohne Hilfsmittel und ohne Koordination halt dazu führen,
dass du halt nur am Reden bist und erst mal am Suchen bist, mit wem du denn über welches Thema wie reden musst, damit es funktioniert.
Und genau da setzen dann halt die Frameworks an, um da Strukturen zu etablieren, um genau dieses Redet miteinander in eine Form zu bringen, die möglichst wertschöpfend ist.
Ja, das erinnert mich irgendwie auch sehr an eins meiner gegenwärtigen Lieblingsbücher, nämlich Team Topologies, die ja auch sehr rumreiten auf diesem Konzept von ungünstiger Kommunikation.
Man kann ja naiv sagen, ja, ja, Kommunikation ist immer gut und das stimmt ja auch a priori.
Aber es gibt gewisse Teams, die sollten vielleicht nicht miteinander reden müssen oder man sollte eben zum Beispiel nicht sich durchfragen müssen,
bei wem bin ich jetzt an der richtigen Adresse, um folgende Abhängigkeit zu behandeln oder sowas.
Das ist eine Art von schädlicher, von parasitärer Kommunikation, die halt nur Zeit frisst und niemanden weiterbringt.
Wir hätten eigentlich viel wichtigere Sachen, über die wir miteinander reden müssten.
Sprichst ja fast wie jemand, der Agilität nicht mag. Da gibt es ja nur die Meetings, die reden ja nur.
Ja, furchtbar.
Ja.
Ja, aber wenn wir das nochmal aufgreifen, also Kommunikation, hat man gesagt, ist ein Grund für Skalieren, also Kommunikation regeln, Kommunikation einfach in Gang bringen und dann auch zielgerichtet ablaufen lassen.
Das ist, glaube ich, etwas, was wir letzten Endes aus einzelnen Schulungen, also aus Scrum oder DevOps-Schulungen nehmen können und was wir aber genauso in der Skalierungsschulung eben bemerken, dass einfach klar ist, es gibt verschiedene Ansätze.
Wie kann ich skalieren?
Wie kann ich die Kommunikation unterstützen?
Wie kann ich das regeln, dass die Teams miteinander sprechen?
Und das ist, glaube ich, eben ein Punkt, den wir auch in unseren Schulungen oder in der Schulung behandeln, wo wir eben schauen, wie oder vergleichen, wie liefern einzelne Frameworks von diesen neuen einen Beitrag zur Kommunikation?
Wie kann ich einzelne Frameworks nutzen, um dort rauszulesen, ja, wie arbeite ich zusammen und wie kriege ich Alignment hin?
Das, was Falko ja vorhin auch sagte, dass ich ja auch ein Alignment hinbekommen muss.
Dass ich Governance hinbekommen muss.
Das sind alles Punkte, die man aus diesen einzelnen Frameworks rausziehen kann.
Und das ist auch der Versuch in unserer Schulung.
Genau.
Also das finde ich einen ganz tollen Punkt.
Vielleicht kann ich an der Stelle auch gleich einhaken.
Nämlich jetzt haben wir diesen Vergleich gemacht zwischen, ich glaube, neun verschiedenen Frameworks, die wir da einander gegenüberstellen.
Und ich bin wahnsinnig neugierig, was ihr entdeckt habt an bemerkenswerten Gemeinsamkeiten oder auch Unterschieden,
die, über die man vielleicht sprechen sollte an dieser Stelle.
Ja, dann sollten wir vielleicht erstmal anfangen und diese neuen Frameworks benennen.
Weil die meisten unserer Zuhörer werden wahrscheinlich eins kennen, die werden vielleicht zwei kennen.
Und vielleicht ist es ganz hilfreich, da einfach mal zu starten.
Also die neuen Frameworks, die wir im Vergleich sozusagen haben in der Darstellung.
Das erste ist natürlich SAFe, weil es das bekannteste Skalierungsframework ist.
Das zweite wäre LESS.
Auch das kennen noch ziemlich viele.
Ist ein bisschen einfacher, ein bisschen übersichtlicher, aber eben doch auch sehr, sehr hilfreich, um ein bisschen was daraus zu lernen.
Und dann kommt mein Lieblingsframework für Skalierung.
Ich weiß, dass ich mich bei allen Agilisten unbeliebt mache.
Wir haben ITIL 4 auch mit drin.
Natürlich ist ITIL 4 kein Skalierungsframework, aber ich habe ja eine spezielle Schulung dazu.
Und auch in der DevOps-Skalierungsschulung kriegen wir das dargestellt, wie man auch Elemente aus Skalierungsschulungen,
wie man auch Elemente aus Skalierungsschulungen, wie man auch Elemente aus Skalierungsschulungen,
wie man auch Elemente aus ITIL nutzen kann, um agile Teams, um DevOps-Teams zu skalieren.
Und wenn ich dann weiter mal auf der Liste schaue, Scrum at Scale haben wir noch mit dabei.
Das ist das, was Jeff Sutherland entwickelt hat, damals schon vor hunderten von Jahren, als das mit der Skalierung von Scrum schon losging.
Wir haben Nexus mit drin mit dargestellt, was von Ken Schwaber ja entwickelt wurde.
Das sind so die Ansätze, glaube ich, die die meisten auch kennen oder viele, die in der agilen Szene sind, die sich damit beschäftigen.
Das ist das, was Jeff Sutherland entwickelt hat, damals schon vor hunderten von Jahren, als das mit der Skalierung von Scrum schon losging.
Das ist das, was Jeff Sutherland entwickelt hat, damals schon vor hunderten von Jahren, als das mit der Skalierung von Scrum schon losging.
Dann sieht man natürlich auch die Devils, was auch hier zu sehen ist, was gleichzeitigschooliert, easily-elegable ist,
Und wenn man dann weiterschaut, haben wir noch die Flight Levels mit drin von Klaus Leopold.
Und wenn man dann weiterschaut, haben wir noch die Flight Levels mit drin von Klaus Leopold.
Das, finde ich, ist auch ein ganz toller Ansatz, eine ganz tolle Erfindung
Das, finde ich, ist auch ein ganz toller Ansatz, eine ganz tolle Erfindung
Das, finde ich, ist auch eine ganz tolle Ansatz, eine ganz tolle Erfindung
und dass deswegen macht es auch Sinn, das auch mit einzubringen in diese Schulung.
in diese Schulung. Und dann hat
Falco was ganz Tolles entdeckt
von IT Agile aus
Hamburg, das Floating Teams.
Das ist eben das, was wir vorhin schon angedeutet
haben. So ein Ansatz, wie kann
ich denn quasi in einem Team ein bisschen
skalieren? Wie kann ich ein Team
vielleicht bis zu 30 Personen
aufbauen, damit ich nicht anfangen
muss, eben dann Teams auseinanderzureisen?
Ich höre die Scrum-Polizei
schon kommen. Ja, ja. Lass mich
noch die letzten zwei, bevor ich verhaftet werde,
die letzten zwei nennen. Dann haben wir
noch das Flow-Framework von
Mick Kirsten entwickelt. Da gibt es auch eine eigene
Webseite zu. Und auch ein
etwas, ich will nicht sagen dinosaurischer,
aber auch ein Ansatz, der schon
ein paar Jährchen auf dem Buckel hat.
Das ist Disciplined Agile Delivery.
Das ist von Scott Embler entwickelt
worden und ist auch jetzt noch aktuell
am Markt, sag ich mal, verfügbar.
Ist vom PMI übernommen worden.
Also das sind jetzt im Prinzip die neuen Frameworks,
die wir darstellen.
Prima. Und wo wir schon bei der Ketzerei sind.
Dirk hat ja schon sein Lieblings-Framework genannt.
Falco, hast du auch ein Lieblings-Framework?
Mein Lieblings-Framework ist das
Komm-Drauf-An-Framework.
Das Schöne bei den Frameworks ist ja,
dass jedes für sich
einen bestimmten Fokus setzt.
Und das letztendlich
für das Unternehmen
passende ist für mich letztendlich
das, was an der Stelle
besonders gut ist.
Natürlich habe ich
mit verschiedenen Frameworks meine Erfahrungen
gemacht. Das, was am
verbreitetsten ist, mit dem ich halt auch die
meiste Erfahrung gesammelt habe, ist
SAFE. Das, was ich
persönlich am interessantesten
finde,
ist LESS
in Kombination mit
Floating Teams und Flow Framework.
Also ich finde, auch da lassen sich halt
aus verschiedenen Frameworks
spannende Ansätze kombinieren.
Und deswegen kann
ich mich nicht so richtig auf eins
festlegen. Es hat halt
also, wie gesagt, Flow Framework, Floating
Teams und SAFE in Kombination.
Okay, sehr gut.
Sehr schön. Jetzt habt ihr ein paar
spannende Sachen angesprochen oder du
vor allen Dingen, Falco, indem du gesagt hast,
verschiedene Frameworks sind
halt besonders gut für verschiedene
Sachen. Ich meine, wir wollen jetzt nicht
irgendwie mühsam alle neuen Frameworks
durchdeklinieren, aber vielleicht kannst du ein paar
Beispiele liefern, was vielleicht besonders heraussticht.
Eins hast du wahrscheinlich schon gesagt mit den Floating
Teams, was halt sehr
sinnvoll ist für
kleine Gruppen von Leuten, die sich
so ein Riesenframework gar nicht antun
wollen, sondern etwas, ich sage mal
pragmatischer den Ansatz
verwenden wollen. Was gibt es denn noch für spannende
Beispiele von Besonderheiten?
Ja, eines der wenigen
Frameworks, die sich auf ein gesamtes
Unternehmen beziehen,
ist SAFE, also Scaled
Agile Framework, das halt
in den verschiedenen Skalierungsebenen
von der
Team-Ebene in den agilen
Release-Train geht. Auf der Team-Ebene
sagt man halt Scrum, Kanban meist,
vielleicht auch
etwas Kombiniertes
aus Arbeitsweisen auf
Team-Ebene, hat aber
auch viele Inhalte, die
für große Produkte mit
mehreren hundert beteiligten
Mitarbeitern relevant sind
und bringt halt auch
Rollen mit, die
auf den verschiedenen Skalierungsebenen,
die das abbildet,
dann bestimmte Aufgaben übernehmen
und geht halt bis hin
in das Portfolio des Unternehmens
mit dem
ja, mit der
Portfolio-Ebene, bei der
es auch nicht auf ein Portfolio
reduziert, sondern halt auch sagt, ein Unternehmen
kann mehrere Portfolios haben
in verschiedenen Unternehmensbereichen
und bildet sozusagen
einen exemplarischen
Beitrag
für auch
große Konzerne ab,
in denen man letztendlich durchgängig
mit einem Framework arbeiten kann.
Ich glaube, das reicht
für mich als Beispiel für,
für SAVE.
Jedes Framework hat halt seine
Historie, kommt aus irgendeiner bestimmten
Richtung, so ähnlich wie SAVE
und LESS aus der Nokia-Welt kommen.
Nokia
Networks mit LESS
oder Nokia
mit den
Mobiltelefonen-Sparte
haben halt gewisse
Lernkurve gemacht,
die halt für das Unternehmen selbst nicht
so gut gelaufen sind. Anders
ist es halt bei einem Ansatz, den wir
auch mit erwähnen, zum Beispiel
Spotify, die sich halt auch aus ihrem
Spotify-Ansatz
heraus entwickelt haben und halt
weitergegangen sind. Und so sollte man
auch die Frameworks als Ideengeber
sehen, als
Inspiration für eine agile
Entwicklung in einem
Unternehmen. Und da
bietet es sich halt häufig an, aus
einer klassischen Welt heraus
ein recht verbreitetes
Framework zu nutzen, das halt
möglichst viele Ideen schon mitbringt,
an denen man sich halt orientieren kann,
aber eben nicht muss und da auch
nicht festgenagelt sein sollte drauf,
sondern dass man halt das als
guten Startpunkt sieht und
vielleicht mit einem
verbreiteten Framework halt startet
und dann halt schaut, was man auch von
anderen Frameworks sich abschauen
und übernehmen kann und welche Ideen
vielleicht auch besser passen als
aus irgendeinem By-the-Book-Ansatz.
Ich würde nochmal auf dieses
tolle Komm-drauf-an-Framework
eingehen, weil das finde ich echt
ein cooles
Framework, weil
letzten Endes wollen wir das ja auch in der Schulung
unseren Teilnehmern
ermöglichen, sich selbst
ein Das-kommt-drauf-an-Framework zu bilden.
Also wir kommen ja in der Schulung nicht zu einer Aussage,
das ist das beste Framework,
das musst du nehmen oder wenn du
fünf Mitarbeiter hast, dann musst du das nehmen
und wenn du zehn hast, dann musst du das nehmen,
sondern wir stellen ja wirklich die
Frameworks immer aus der DevOps-Sicht
dar. Also es sollte niemand erwarten, dass er
jetzt in zwei Tagen neun Frameworks komplett
nähergebracht bekommt. Also wir
gucken uns den DevOps-Part an
und wenn ich sage, kommt drauf an,
dann ist ja die Frage zum Beispiel,
will ein Unternehmen zentral planen
und zentral steuern weiterhin?
Das ist eine Frage, wo wir
eben dann drauf eingehen und wo wir
darstellen, welches Framework sich dort
vielleicht eher eignet und welches dort sich
eher nicht eignet. Das heißt also,
es wird nicht gesagt,
das ist das beste Framework, was Herr Falco
auch sagte, man startet mit einem
Framework und letzten Endes,
der Start, den wir mit unserer
Schulung bieten wollen, ist der Vergleich
bei bestimmten Punkten. Also zum Beispiel
zentrale Planung, zentrale
Steuerung. Da ist vielleicht SAVE und
ITIL 4 etwas besser geeignet
als LESS oder NEXUS an der Stelle.
Aber wenn ich natürlich nicht zentral
planen will und nicht zentral steuern
will, ja dann passen LESS
und NEXUS vielleicht wieder ein bisschen besser.
Wo wir jetzt so viel
über SAVE gesprochen haben,
wie steht ihr eigentlich zu der
recht verbreiteten Kritik oder
ich höre sie jedenfalls nahezu ununterbrochen,
habe ich das Gefühl, dass SAVE ja überhaupt
kein agiles Framework mehr ist und das ist ja nur
Wasserfall in neuen
Kleidern und überhaupt alles des Teufels.
Vielleicht bist du in der falschen Filterblase
unterwegs, aber jetzt
Spaß beiseite.
Also ich höre das ja auch und
ich stelle fest,
dass die Unternehmen, die sich mit SAVE
beschäftigen, also die skalieren wollen,
dass die schon sich
das genau anschauen, dass sie eben die Vorteile
sehen und letzten
Endes, wenn man jetzt ganz böse ist,
kann man ja auch sagen,
vielleicht ist es ja okay, dass es vielleicht gar
nicht so agil ist, wie
das manche Menschen wollen, wie das manche
Berater wollen, wie das manche Experten
auch wirklich wollen. Vielleicht ist das manchmal auch
dann ein zu großer Anspruch für die Unternehmen.
Also, kurz gesagt,
mir ist das im Prinzip egal. Ich habe meine
Meinung zu SAVE und meine Meinung
ist, dass es schon eine
schöne Sammlung ist von Ansätzen
und ob das unter den Unternehmen
hilft, das müssen die Unternehmen selbst
entscheiden.
Ich würde gerne auf die Frage nochmal zurückkommen
und fragen, was heißt denn
ein agiles Framework? Ist das Framework
nicht agil oder hilft es
Unternehmen nicht dabei
agilär zu werden
oder agil zu werden und wann ist dann
ein Unternehmen agil?
Tja, das weiß ich auch nicht. Ich gebe
nur die Kritik wieder, die ich so höre.
Ja, und mir geht es da glaube ich
so ein bisschen ähnlich wie euch.
Es ist halt nur ein Werkzeug oder nur ein Werkzeugkasten,
und wer sich jetzt mit der Beißzange den Finger
zwickt, der kann natürlich der Zange die Schuld
geben.
Ob das jetzt berechtigt ist oder nicht,
weiß ich auch nicht.
Gut, also ich finde es ganz interessant,
wenn man das Framework betrachtet und
sagt, es ist nicht agil, es
verändert sich ja mit der Zeit. Es wird
ja dazugelernt. Es gibt ja verschiedene
Versionen und eine Weiterentwicklung
über zehn Jahre mittlerweile
und es gibt Elemente,
die sind halt relativ stabil
dabei. Ich finde es aber ganz interessant,
dass halt immer wieder neue Aspekte
auch bei so einem Framework
wie SAVE aufgenommen werden.
Zum Beispiel mit der 5er-Version
halt nochmal den
Kundenfokus ein Stück zu schärfen oder
mit der 5.1er-Version halt
nochmal
bestimmte andere Aspekte wie
die Business-Agilität
in Vordergrund zu stellen und halt zu
sagen, man braucht bestimmte
Kompetenzen,
die wichtig sind, die man mit
aufnehmen muss und dabei
eben auch auf die Wertströme zu
achten, die in einem Unternehmen
relevant sind. Und das sind für mich
schon alles Aspekte, die
in Richtung Agilität
gehen. Ob man jetzt
in der Arbeitsweise dann
auf Projekte in
drei Monatszyklen
oder Quartalszyklen gehen, die dann mit
den SAVE-Programmingrementen übereinstimmen
oder nicht, ist halt immer
eine Frage der Sichtweise.
Im Umfeld von
SAVE gibt es ja große Anforderungen,
die sie im Framework in der
Beschreibung halt bewusst nicht
Projekte nennen, sondern
Epics. Und da gibt es eine schöne
Gegenüberstellung, was der Unterschied ist und was nicht.
Und ja, es gibt
halt eine gewisse Planung und
die ist aber im agilen
Umfeld ja kein
zu ignorierendes oder
zu verteufelndes
Element, sondern das bildet halt
die Grundlage, um darauf halt
wieder neu agieren und
reagieren zu können. Und im
besten Fall besser als ohne die Planung
zu haben. Das heißt,
auch wenn man dann halt mit mehreren
Release Trains,
mehreren hundert Mitarbeitern
so ein Quartal plant
und man dann halt sagt, ja, das ist jetzt
der Wasserfall, zumindest
von der Außensicht heraus, ändert sich
aber in den Unternehmen, die
damit arbeiten, doch eine ganze
Menge. Teamzusammensetzung,
Kommunikationsstrukturen,
der Wertfokus wird
viel mehr erhöht, als das ohne
so ein Framework ist.
Und deswegen sehe ich
letztendlich
an diesen Argumentationen
safe ist nicht agil, auch
Grund, mit den Leuten zu diskutieren
und da mal Erfahrungen zu sammeln. Das heißt,
wenn jemand, der Zuhörer,
das Thema safe ist
nicht agil vertreten möchte
und mit uns dann mal in die Diskussion
gehen mag,
lade ich gerne auch
in persönliches Gespräch
ein oder wenn Luca und Dirk
Lust haben, kann da
vielleicht auch mal noch eine spannende
Folge für den
DevOps auf die Ohren
und ins Hirn Podcast werden.
Ja, das ist eine lustige Idee.
Falls sich jemand bemüßigt fühlt,
feste gegen safe zu schimpfen zum Beispiel,
dann bieten wir ihm hier gerne eine Plattform
und schauen mal,
was jeder vom anderen lernen kann, oder?
Ja, ich würde noch mal
den Punkt aufgreifen von
Falco. Natürlich, es wäre sehr schön,
wenn sich Leute aus diesem Podcast,
aus der Folge heraus,
motiviert fühlen, auch mal zu Gast zu sein
mit ihrem Thema. Das ist der erste Punkt,
der mir wichtig ist.
Und inhaltlich würde ich sagen,
was Falco gerade gesagt hat,
würde ich noch ein bisschen rausarbeiten wollen.
Wenn safe nicht agil ist,
dann ist es vielleicht so,
dass das, was safe mitbringt,
auch vielleicht sozusagen eine nächste,
vielleicht ein bisschen pathetisch gesagt,
Evolutionsstufe ist.
Das heißt, die Frage ist ja, ist Agilität
noch die Antwort auf die,
ähm, aktuellen Herausforderungen?
Also, ich will diese Frage nur in den Raum stellen.
Ich will sie nicht beantworten.
Aber es könnte ja sein, dass das Thema
Value Stream, das Thema Wertschöpfungskettenbetrachtung,
dass das quasi der nächste
Schritt ist, wohin sich Organisationen
hin entwickeln müssen.
Und das wäre vielleicht eine Art
Ablösung oder eine Art
Übergang auf
Value Stream,
also auf eine Wertschöpfungskettenbetrachtung.
Und dann ist Agilität ein Teil davon.
Und warum sage ich das?
Weil ich es eben auch sehr interessant finde,
dass das Thema, das ITIL 4
sich auch in Richtung Wertschöpfungsketten
entwickelt hat. Also,
kurz gesagt, glaube ich, dass es sehr, sehr
hilfreich ist und sehr, sehr interessant ist,
zu gucken, ob Agilität
nicht vielleicht auch in einem Bereich ist,
wo wir über neue Ausrichtungen
nachdenken müssen. Und das könnte ja auch
Value Stream sein.
Ja.
Das finde ich einen ganz tollen Punkt, den du da
angeschnitten hast. Denn, ich hatte mir
auch als Frage notiert,
reicht es denn eigentlich
aus, wenn man diese
Skalierung rein auf
die IT-Organisationen anwendet?
DevOps ist aus meiner Sicht
kein Ansatz,
der sich nur auf
IT-Organisationen bezieht.
Also,
insofern,
bei DevOps, noch bei Agilität,
noch bei
Skalierung,
kann man sich auf
reine IT
beziehen.
Aus meiner Sicht, und
da stimme ich schon ein Stück auch mit
Safe überein, oder anderen
Frameworks, geht es da halt um eine
Ende-zu-Ende-Betrachtung der Wertschöpfung.
Und
da spielt es halt eben genau
rein, sich den
Kunden, den Kundennutzen
oder andere Bereiche
der Wertschöpfung
entsprechend anzuschauen. Kann ja auch
Unternehmensnutzen sein,
Unternehmenswerterhöhung oder ähnliches,
die man versucht zu erreichen.
Und üblicherweise reicht es dann nicht
aus, sich auf die
IT zu beschränken. Es ist häufig
der erste Punkt, an dem agiles
Arbeiten den Einzug
in kleinere, mittlere
und große Unternehmen
hat, oder wo letztendlich
Agilität startet,
zumindest aus meiner Erfahrung, und dann
in andere Bereiche
mit hineinwirkt, bis die
dann letztendlich ins ganze Unternehmen
und häufig auch über
Unternehmensgrenzen hinweg
wirken. Zum Beispiel
zu den Auftraggebern mit
hinein. Bin bei
einem Unternehmen mit
relativ vielen Schulungen unterwegs
und bekomme da halt verschiedene Sichten.
Und da ist halt die öffentliche
Hand der Auftraggeber.
Und wenn sich das Unternehmen
agilisiert, heißt das
natürlich auch, dass dann
andere Gespräche mit Auftraggebern
geführt werden müssen. Dass man sich
dann mit den Anforderern zusammensetzt,
dass man auch Planungszyklen,
dass man die Auftraggeber
in viel engere
Kommunikations- und Feedbackzyklen
einbindet, zum Beispiel Sprintlänge
oder Quartalsergebnisse,
Programmingremente
oder wie auch immer man sich dann sonst organisiert,
dass man da halt
viel engere Gespräche
miteinander
finden muss.
Und genauso wie das
im Unternehmen passiert, passiert es
halt in der Wertschöpfungskette,
auch über Unternehmensgrenzen,
hinweg, auch zu den Auftragnehmern,
die man letztendlich hat. Hat das
eine Veränderung der
Arbeitsweisen und Kommunikationsweisen?
Ja, bringt das halt mit.
Okay. Also mit anderen
Worten, genau meine Vermutung
hast du bestätigt, dass
es ist zwar eine gute Sache,
die IT-Organisationen zu agilisieren,
aber das ist vermutlich nicht
ausreichend. Und ich glaube, das können wir
auch bestätigen aus unserer Beratungs- und
Schulungspraxis, dass das dann ganz häufig
zu Spannungen führt, genau sozusagen an den Außengrenzen
der IT-Organisationen.
Dass die auf einmal
sich ganz anders anfühlt
für den Rest des Unternehmens oder für die Auftraggeber
und die ihrerseits irgendwie
sich auch an diese veränderte
Schnittstelle anpassen müssen
und da vielleicht auch
das eine oder andere Mal ein bisschen daran zu knabbern haben.
Was ich an der Stelle noch ergänzen
möchte, ist, wenn wir von
IT-Organisationen sprechen, es gibt
natürlich den Ansatz, dass immer mehr
Produkte mit immer mehr Anteil
von IT-Wertschöpfung
sich entwickeln.
Und dieses schöne Zitat
Software eats the world
geht so ein Stück in die Richtung,
dass man natürlich auch immer mehr
von der IT
eine Unternehmenstreiber-Funktion
hat und sieht, dass man
halt die Chief Information
Officers, CIOs,
immer mehr an dem
Unternehmenserfolg mit
beteiligt oder mit
einbeziehen muss, um
dann vernünftige Software,
Lösungen, Produkte auch zu ermöglichen
und genau
da kann man natürlich
sagen, steigt der Wert
der IT im Unternehmen, der
Anteil der Wertschöpfung der IT
in den Produkten, man denke nur an
Smartwatches oder
selbstfahrende Fahrzeuge
oder ähnliches, sind halt so
Beispiele, die man sich da vor Augen führen
kann. So ein Stück
spiegelt das natürlich dann auch
diesen Gedanken der Wertschöpfungskette
IT und man startet mit der IT,
um halt besser Wertschöpfen
zu können und das
trägt sich in das Unternehmen hinein,
spiegelt sich da halt wieder.
Okay, wunderbar.
Gibt es denn etwas, worüber ihr gerne noch sprechen würdet
im Rahmen dieser ersten Folge über, ich sage jetzt mal,
die Theorie von Skalierung?
Haben wir was vergessen? Gibt es noch was Spannendes,
was ihr loswerden wollt?
Also ich bin bedient.
Nein, also ich glaube,
dass wir genug über Theorie
gesprochen haben. Wir haben ja, glaube ich, in die Theorie auch schon
viele Sachen eingeflossen oder
einfließen lassen aus der Erfahrung,
aus praktischen Erfahrungen
und ich glaube auch, so eine klare Trennung
in Theorie und Praxis wollen auch die
Zuhörer nicht. Also man kann
sicherlich mal eine Theorie-Folge machen,
aber ich glaube, dass diese Folge, die wir jetzt hier hatten,
aus meiner Sicht eben genug Theorie
hat, aber auch schon sehr viele praktische
Erkenntnisse mit dazu. Also
ich freue mich auf die zweite Folge.
Genau, was ich damit sagen wollte,
sollen wir diese Folge hier beenden und zur nächsten übergehen?
Sehr gerne. Ich glaube, wir sollen.
Dann vielen Dank bis dahin.
Und liebe Zuhörer,
in wenigen Wochen kriegt ihr dann
den zweiten Teil.