Wir haben jetzt einfach mal aus der Not eine Tugend gemacht, dass wir nämlich nur ein Mikrofon haben, ist das quasi unser Sprechtoken und der Fischbowl ist quasi der ganze Raum. Also jeder der das Sprechtoken hat, darf dann mal was sagen

und das erste Sprechtoken hat der Herr Ebert. Danke und ich will es kurz sagen, ich habe schon genug gesagt, die Vorträge haben uns stimuliert und wir haben mit Herrn Strabe ja auch noch einen, den wir in das Panel mit aufgenommen hatten als Gründer und ich möchte gleich mal dieses Thema Agilität weitergeben. Es wurde vorher die Frage genannt, wie

bekommen wir mehr Agilität in unser Denken und das hat zwei Dimensionen, die eine ist, muss ich was zutrauen und das andere ist natürlich auch, man muss die richtigen Ideen haben, damit was draus wird. Ja, vielen Dank. Ganz kurz zu mir, Olaf Strave von der 4 technology group. Ich bin

der Stand-in quasi für die Frau Klüver, die heute bei der Enquete- Wechsel. Wir machen Software für Kundeninteraktion, das heißt also, wenn sie in Deutschland irgendwo bei einem Callcenter anrufen, ADAC, Zalando, Ergoversicherung, dann ist das unsere Software, die sie vermittelt. Das

nur kurz zum Hintergrund. Ja, wir sind eine relativ junge Mannschaft und wir arbeiten agil im Sinne einer Organisation, die aus kleinen Teams besteht und die

versucht, sehr schnell Dinge umzusetzen. Das heißt also, wir haben in verschiedenen Bereichen, wenn wir neue Produkte planen oder wenn wir bestimmte Dinge als neue quasi Funktionsgruppen sehen, den Ansatz, dass wir mit einem MVP arbeiten, also Minimal Viable Product, das ist so

im Silicon Valley auch sehr populärer Ansatz, relativ schnell was für den Kunden zur Verfügung zu stellen, auch wenn es noch nicht voll durchspezifiziert ist und dann zu schauen, ob der Kunde mit den Features und auch mit der Art, wie die Software aufgebaut ist, zufrieden ist. Und dann

fangen wir an, quasi das Feature Set weiter auszubauen und dem Kunden entsprechend mehr Funktionalität zu bieten. Und darauf ist die Mannschaft auch eingerichtet. Das heißt, wir haben auch klar eine Ansage bei uns, dass die erste Version noch nicht so shiny ist und vor allen Dingen auch noch

nicht alle Bugs quasi gefixt wurden oder notwendigerweise gefixt wurden. Und unsere Kunden wissen das auch. Also, obwohl wir B2B-Software machen, wissen unsere Kunden, dass sie eben an der Stelle erst mal mit einem

halbfertigen Produkt in die Versuche gehen. Also, das ist für uns Agilität. Das heißt, schnell eine Anwendung in den Markt zu bringen. Und man muss dem Kunden das richtig kommunizieren, aber dann versteht er das

auch. Ja, wenn es hier gerade um die Agilität geht, will ich mal aus der Praxis bei uns berichten, also in unserem Software Company. Da ist es tatsächlich so, dass wir nicht am Ende eines positiven Prozesses drin sind,

sondern mittendrin. Also, wir haben vor drei Jahren jetzt agile Teams eingeführt, weil wir auch bei unseren Kunden zunehmend es durch bekommen. Das ist ja immer ein Problem im Markt, dass der Kunde nicht sagt, ich will zum Festpreis wissen, was ich kaufe, so wie ein Haus. Dann sind wir wieder beim alten Pflichtenheft und beim alten Plan, Build, Run. Das haben wir bis heute noch. Das hat sich aber in den letzten Jahren Gott sei Dank verändert, dass immer mehr Kunden bereit sind,

agile Projekte zu machen. Das ist erst mal eine Grundvoraussetzung. Man darf hier nie den Markt vergessen. Ich weiß auch von vielen Untersuchungen, dass es sich oft leider noch so ist, dass dieses Plan, Build, Run durchgedrückt wird. Wenn es dann agil ist, haben wir eben bei uns interdisziplinäre Teams gemacht, die diese Projekte machen. Dadurch ist die Effektivität um fast 35 Prozent gestiegen, also extrem

angestiegen. Die Menschen haben nicht mehr so schnipselmäßig gearbeitet, sondern haben sich im Team verantwortlich gefühlt für einen Kunden, konnten sich gegenseitig ergänzen, ersetzen, haben ihre Sprints gemacht und so weiter. Jetzt muss man aber fairerweise sagen, dass wir im Moment in so einer Phase sind, wo wir wieder bei minus zehn Prozent sind. Also es geht im

Moment zurück. Wir sind zwar immer noch bei plus 25 von vorher, aber es ist, es schleifen sich wieder Dinge ein. Also gerade der Support zwischendrin, da kommt irgendwas und dann fängt das Projektthema und man sagt immer, dann mach du doch das. Und plötzlich aber nicht mehr alle an einem Projekt, obwohl völlig frei das eigentlich entscheiden können.

Plötzlich fällt das Stand-up-Meeting aus. Also der Sprint, den machen nicht mehr alle sieben, sondern nur noch drei machen Sprint. Also kann ich jetzt nur wirklich aus der Erfahrung von, es schleifen, es ist leider so, wie es schon immer im Leben war, auch bei dem schönen, tollen Agilen, schleifen sich wieder die Dinge ein, die sich irgendwie immer einschleifen. Da würde mich auch mal von

anderen hier interessieren. Wie kriegt man das wieder rausgeschliffen? Also da sind wir natürlich dabei. Aber es ist nicht ganz ohne. Möchte dazu jemand was sagen? Wie kriegt man das rausgeschliffen? Okay, Herr Gengler. Also ich will jetzt nicht sagen, dass ich hier die Patentlösung habe. Ein Punkt ist natürlich, ich muss dabei bleiben. Da haben Sie das Thema Diskussion und so

weiter. Ich kann es nicht einführen und hoffen, dass das dann funktioniert, weil es ein Kulturwandel ist und weil er im Kopf standen muss und weil das nicht so schnell geht und weil wir alle wissen, dass wir gerne auf alte Gewohnheiten zurückfallen, wenn irgendwas nicht funktioniert. Das ist der eine Punkt. Der andere Punkt ist, ich muss diese Unterbrechung, diese Störung mit einkalkulieren. Und das ist das, was wir mit Experten gemacht haben.

Wie? Also wir haben angefangen mit Scrum. Das ist wunderbar für ein Entwicklungsteam. In dem Moment, wo ich mit Eskalationen und solchen Sachen arbeite, funktioniert es nicht mehr. Wir haben jetzt in einem Bereich eine Mischform zwischen Scrum und Kanban. Also wir planen die Sprints nicht mehr durch, aber wir haben trotzdem Iterationen zum Beispiel. Und bei uns fällt kein Stand-up aus,

auch wenn wir Eskalationen haben, weil die Leute in dem Team auch mit besprechen, wer kümmert sich dann jetzt darum und wer hilft wem und so weiter. Also Sie müssen es mit einbeziehen. So haben wir das gemacht. Ob das jetzt in Ihrem Fall hilft, müssen Sie mal gucken. Aber Experimente probieren, lassen Sie die Teams

das ausprobieren, ob Sie so besser gehen. Und wenn ja, gehen Sie in die Richtung. Ja, vielen Dank auch zu Ihren Kommentaren über Agilität. Ich selbst bin Eric Tittl. Ich bin eine Art Agile Coach bei der Allianz, also auch großes Versicherungsunternehmen. Wir versuchen Agilität schon seit vielen Jahren

in das Unternehmen zu bringen. Wir haben mehrere tausend Mitarbeiter in der IT oder auch in der Softwareentwicklung und haben seit ungefähr zwei, zweieinhalb Jahren eine neue Initiative, in der wir Agilität versuchen, wirklich einzuführen. Eine kleine Abteilung, jetzt 300 Mitarbeiter. Und ich bin sozusagen dabei, auch diesen Kollegen Agilität zu erklären und die Hintergründe

zu vermitteln und zu festigen. Und wenn es einen Hinweis gibt, den ich Ihnen ergeben kann, ist das eben genau der, dass ich Ihnen empfehlen würde, sich nicht auf eine konkrete Methodik, sei es Scrum oder Kanban zu fokussieren, sondern den Mitarbeitern wirklich die Hintergründe, die Prinzipien klarzumachen. Und das ist so unser aktuelles, man könnte

fast sagen, Erfolgsprinzip. Dass wir sagen, wir machen keine Scrum Transformation und führen jetzt Scrum ein, sondern wir haben keine Scrum Master, sondern sogenannte Agile Master, die versuchen für jede einzelne, konkrete Situation eines Teams die passenden agilen Methoden, Prinzipien, Frameworks auszusuchen. Und damit kommt ein ganz bunter Strauß

zusammen, der anfängt bei Design Thinking, bei Lean Startup mit Minimal Viable Products, der weitergeht über Scrum, Kanban und so weiter. Und wir versuchen, den Kollegen wirklich klarzumachen. Warum machen wir diese Dinge? Also zum Beispiel ein Stand Up. Warum machen wir ein Stand Up? Wir machen ein Stand Up nicht, weil wir ein Stand Up machen, sondern weil wir für Transparenz sorgen wollen, für Koordination

innerhalb eines Teams und auch über die Teams hinaus. Ich glaube, wenn dieses Verständnis kommt, dann kann man Agilität an sich auch viel besser in die Teams bringen und dort platzieren. Ich hätte gerne noch andere Hinweise. Also die Hinweise sind mir alle klar. Deswegen machen wir es ja seit drei Jahren

erfolgreich. Aber es ist eben trotzdem so, gerade bei Ihren vielen Menschen, nehme ich Ihnen jetzt mal nicht ab, dass da, es gibt immer Menschen, die dann einfach sagen, es sind ja kleine Teams, natürlich wissen die, warum sie ein Stand Up machen. Sie haben ja selber diesen Erfolg damit gehabt. Das ist ja auch immer noch ein Erfolg, aber es schleift sich wieder etwas ein. Und die Frage ist halt, lässt man

dann, sagt man, es muss ein Stand Up. Also die Frage ist auch, gibt es dann, wie kriegt man die Agilität sozusagen am Leben gehalten? Natürlich, also diese ganze Lehrgeschichten kenne ich, die Mischung aus Verfahren und so weiter, alles klar. Die Diskussion ist super.

Also am Ende des Tages, ich bin da immer sehr pragmatisch unterwegs, mag auch mittlerweile ein bisschen was mit Lebensalter zu tun haben. Die, es hilft uns doch nichts. Wir haben, wir haben jahrelang haben wir die die wasserfallartige Softwareentwicklung bekämpft, methodisch bekämpft in heißen Diskussionen, bis wir sie

dann endlich in vielerlei Hinsicht über die Wuppa geschmissen haben. Wir müssen jetzt aber aufpassen, meiner Ansicht nach. Und da kann ich nur warnen vor, dass wir jetzt den gleichen Fehler mit dem damals unsere Väter den Wasserfall verteidigt haben, dass wir jetzt versuchen, die reine Lehre der Agilität zu verteidigen. Also die Ursache ist doch viel tiefer, wenn sich etwas

einschleift, dann ist ja die Frage zu stellen und man intellektuell der Meinung ist, die Tode X oder Y ist jetzt eigentlich das wahre. Was ist die Ursache? Warum schleift sich das ein? Schleift sich das ein aus purer Disziplinlosigkeit? Okay, sorry, auch wenn es böse ist, man muss auch manchmal Disziplin erzwingen. Oder hat es hat es tiefer krähende, gene Ursachen?

Sie sprachen vorhin von den Interrupts und den den den Sachen von draußen kommen. Ja, mag sein, dass es dann eine Reorganisation insofern erfordert, dass man halt nicht mehr mehr mit einem getrennten, mit einem geintegrierten Wartungs- und Entwicklungsteam arbeiten kann. Ich würde immer empfehlen, auf die Menschen zu hören an der Stelle und sag mal eher von draußen drauf zu gucken und zu sagen,

warum lasst ihr denn das jetzt ausfallen an der Stelle? Was was treibt euch denn eigentlich? Findet ihr Agil jetzt doof und wollt wieder Wasserfall kann ja eine Lösung sein, wenn die Leute sagen, dann wollen sie das so. Ok, oder halt entsprechend die Ursachen abzustellen, weil ich glaube halt nicht, dass es leider auch nur eine Meter Antwort für Sie, Herr Grün, aber aber ich glaube halt nicht, dass es da immer eine so eine one size fits all

Lösung gibt. Gut, haben wir noch weitere Einsichten dazu, also nicht so evangelistisch rangehen zu sagen, ok, es gibt noch ein wahres Agil, das muss ich genauso machen. Sie waren ja schon dran, von daher überspringe ich sie jetzt mal und würde das Mikro mal dahin? Ja, also ich bin ein Entwickler in einem agilen

Team und wir haben genau das Problem, was Sie gerade beschrieben haben. Wir haben genau das, dass wir vor eineinhalb Jahren für einen Kunden angefangen haben, ein Produkt zu entwickeln. Super toll lief ich schätze mal 15 Sprints gut. Und dann haben wir released

und darauf waren wir nicht vorbereitet im Sinne von nicht die Bugs, die zurück kamen, sondern dass dann plötzlich eine Wartungsaufgaben dazu kamen, dass man dann plötzlich ganz andere Aufgaben machen muss,

dass man das dann plötzlich der Kunde nicht das Team komplett auslastet. Also wir sind jetzt halt auf einen Kunden angewiesen. Dass dann, wie gesagt, dass der Kunde unser Backlog nicht genug fühlt und wir dann plötzlich noch ein Projekt bekommen und dann so was splittet das Team.

Es gibt. Weiß ich nicht, es ist schwer zu sagen, was die Lösung dafür wäre, Teams nur für Support zu haben oder wie auch immer. Also oder Teamgröße. Also wir haben dieses Konzept von festen oder stabilen

Teams bei uns im Unternehmen. Ich glaube, das ist keine gute Lösung. Also ich wirklich, obwohl ich diesen agilen Ansatz sehr gut finde, finde ich dieses feste Konstrukt. Ok, wir haben jetzt ein Team. Wir waren auch noch relativ groß,

würde ich jetzt sagen, dass man dieses Konstrukt krampfhaft versucht zu behalten, ist glaube ich falsch. Direkt eine Antwort drauf? Keine direkte Antwort, aber mal zu der ganzen Diskussion. Also mein Name ist Dirk Hoffmeister, ich bin von der SAP

und ich habe bis vor zwei Jahren mit Entwicklungsteams zusammengearbeitet bei der SAP. Wir haben seit ungefähr zehn zwölf Jahren vor zehn zwölf Jahren haben wir angefangen mit Lean und Agile. Und ich kann Ihnen da nur zu sagen, wir haben das praktisch ständig umgebaut. Wir haben angefangen nach Lehrbuch, da hatten wir dann auch so ein paar Fanatiker vorne dran,

die mussten wir erst mal wieder einfangen. Das heißt, wir hatten ewig lange Sitzungen und Reviews und so, bis wir festgestellt haben, das frisst viel zu viel Zeit. Die sind mittlerweile ganz kurz, die Leute fassen sich kurz, sie beschränken sich aufs Wesentliche. Aber man muss auch mit der eigenen Mannschaft immer wieder darüber reden. Was mache ich da? Es hat sich so viel geändert in der letzten Zeit

in der Softwareentwicklung. Es ist nicht nur dieser Lean Gedanke, der ist ja auch dadurch begleitet. Das ist noch eine Anmerkung zur Software an sich. In meiner langen Laufbahn sind wir von richtig dicken Monolyten, das ist wie bei der Software, wir waren früher, war ich auch bei der Software AG, von richtig dicken Monolyten runtergekommen, dass wir uns heute Software aus dem Baukasten zusammensuchen,

möglichst schnell fertig werden sollen. Ob Open Source oder nicht spielt dabei sogar nur eine untergeordnete Rolle für mich. Ich setze Software aus einem Baukasten zusammen und gucke, dass sie läuft im Sinne dessen, was der Kunde haben will. Und diese ganzen Prozesse, die muss sich zusammen führen. Und dann, da höre ich jetzt aber auf, dann könnte man das Ganze

noch mal auf die Ausbildung. Das ist ja auch so ein bisschen ein Thema. Das muss man da ja auch alles wieder rückspiegeln. Also wie läuft, wie sieht Software eigentlich heute aus? Als Schlusssatz möchte ich nur sagen, unsere Kinder sind schlauer als wir eigentlich. Also die 10, 12-Jährigen, die machen uns was vor erst mal auf ihren Geräten. Was sie aber nicht drauf haben,

ist die Integration in die Industrie. Das ist das, wo wir auch einen besonderen Augenmerk drauflegen müssen. Wie führen wir das ins Feld zurück? Vielen Dank für den interessanten Beitrag. Auch da natürlich wieder Upscaling. Wie mache ich das quasi im Großen? Wie funktioniert das Ganze im Großen und bringen das Ganze so zusammen, dass es funktioniert?

Und ich denke, wir kommen langsam auch zu einem Ende dieser Session. Ein paar sind schon ausgeströmt, damit sie den Pole Position bei der Nahrungsvergabe bekommen. Ich glaube, so schlimm ist es hier nicht. Aber die eine Frage, die ich ja ursprünglich gestellt hatte, war, wie kommt es agil ins Denken? Unsere ursprüngliche Frage

heute Morgen war auch Zukunft der Software Entwicklung in Deutschland, um den Punkt hat sich es gedreht. Ich würde ganz gern einfach auch nochmal zurückkommen auf die kulturelle Dimension, die Sie genannt hatten. Agil ins Denken heißt natürlich, wir müssen hungrig werden. Und ich glaube, das war auch so ein roter Faden,

den wir nicht erst in der Fußball WM erkannt hatten, dass einfach diese Sattheit uns dazu verleitet, zu denken, wir sind besser als die anderen, was gar nicht stimmt, sondern wir müssen ein paar Mal hart auf die Schnauze fallen und dann aber auch aufstehen. Da haben Sie recht, da sind die Jugendlichen manchmal sehr viel schneller. Die denken da nicht unbedingt gleich an Was passiert mir? Aber hungrig werden jetzt

im Sinne von agil und auch im Sinne von Skalierbarkeiten Richtung Zukunft der Software in Deutschland heißt, Teams dazu bringen, Empowermenten sich das dann gerne, dass sie einfach auch ihres eigenenes Glückes schmied sind, dass es interne Wettbewerbe gibt in einem größeren Unternehmen, dass man wirklich mal nach draußen geht, auch lernt, seine eigene Software zu verkaufen.

Es sind viele solche Elemente, die wir in ganz unterschiedlichen Größenordnungen anwenden können. Kleines Beispiel. Ich bin gerade bei einem großen Automobil Zuliefer auch in der agilen Umsetzung und wir haben im Produktmanagement relativ schnell erkannt, dass es dort eigentlich geht oder nicht geht, weil die steuern die Entwicklung.

Und das heißt, ich muss die Produkte nach hungrig machen. Ich muss sie dazu bringen, Marketing zu machen. Ich muss sie dazu bringen, nach außen zu gucken. Und plötzlich kommt man dann auch in dieses, jetzt sage ich mal in Anführungszeichen, amerikanische oder asiatische Denken, nämlich es geht. Und wir blockieren uns manchmal. Ich habe es vorher so ein bisschen negativ formuliert, was uns nicht weiterbringt,

dass wir eigentlich stark sind mit Datenschutzgrundverordnungen so, ich sehe, nee, wir sind auch stark. Wenn es um Technik geht, wir sind auch stark. Wenn es darum geht, Neues zu bringen. Und das möchte ich Ihnen gerne zum Abschluss mitgeben, nämlich einfach aus diesen zunächst mal tollen Impuls Vorträgen was mitzunehmen, aber dann auch experimentieren.

Hungrig bleiben, das ist das Wesentliche. Es hat uns das Steve Jobs gesagt und das ist sicherlich auch das, was uns in der Zukunft in Deutschland in der Softwareentwicklung erfolgreich macht. Herzlichen Dank und noch weiterhin gutes Gelingen in Ihren entsprechenden Umgebungen.