Episode 7

Agile softwaredevelopment – water under the bridge or more relevant than ever?

„The biggest challenge with agile softwaredevelopment, like with every kind of change, is to include everyone.“

Welcome to our podcast „Querverlinkt – technology outside the box“. This is our 7th Episode and today we’re discussing agile softwaredevelopment. The question we’re asking in this episode: Is agile softwaredevelopment old news or do companies today need an agile mindset? One of our guests is Bernd Pohl. Bernd is one of the board members of Testfabrik AG. This company provides a platform called „webmate“ for automated web applications and app testing to other companies. Compatibility to all terminals with the push of a button.

Furthermore we have an in-house pro for agile projects on board today: Marcel Zinnow knows the opportunities and hurdels of agile softwaredevelopment like no other. Todays dialogue discloses the different aspects of agility in softwaredevelopment.

Happy listening!

Transkription

Transkription

Thomas Sinnwell: Heute habe ich zwei Gäste, Bernd Pohl von der Testfabrik und der Marcel Zinnow von consistec. Ich freue mich, dass ihr da seid. Bitte stellt euch doch mal kurz vor. Bernd, magst du starten?

Bernd Pohl: Hallo, schönen guten Abend! Bernd Pohl, ich freue mich, hier zu sein. Ich bin Mehrfach-Gründer und aktuell einer der Vorstände und Gründer von der Testfabrik, wir machen Testautomatisierung. Und nebenbei bin ich noch Gründer und Betreiber vom Coworking Space Fase 15 hier in Saarbrücken und entsprechend bin ich auch so ein bisschen in der Start-up Szene hier im Saarland noch aktiv.

Thomas Sinnwell: Ja, ich freue mich, dass du da bist. Das wird ein spannendes Gespräch.

Marcel Zinnow: Marcel Zinnow, ich bin Angestellter bei der consistec. Ich habe Informatik studiert und bin direkt nach dem Studium zur consistec. Ich habe dort jahrelang als Softwareentwickler gearbeitet und bin jetzt auch schon seit mehreren Jahren als Leiter von Softwareentwicklungsprojekten im Bereich der Telekommunikation tätig.

Thomas Sinnwell: Ja, schön, dass du da bist. Ich denke, wir haben jetzt einen spannenden Kreis, um über das Thema agile Softwareentwicklung zu sprechen. Und da ist es ja so, agile Softwareentwicklung, das ist ein Thema, das ist so Anfang der 90er Jahre hochgekommen. Das war damals auch Scrum, so als ein Framework für agile Softwareentwicklung. Und da kann man sich schon die Frage stellen: Ist agile Softwareentwicklung ein alter Hut oder ist das noch ein aktuelles Thema? Wie seht ihr das?

Marcel Zinnow: Ich würde sagen, es kommt auf die Unternehmen drauf an. Es gibt viele Unternehmen, wahrscheinlich auch grad in dem Bereich, in dem kleineren Unternehmensbereich, dass die kleineren Unternehmen, viele oft agil Software entwickeln und agil arbeiten. Aber ich glaube, bei den großen Unternehmen oder mittleren Unternehmen hat sich das noch nicht so durchgesetzt, insbesondere im Bereich der Organisation. Gerade die Agilität wird in der Softwareentwicklung ein bisschen vorangetrieben und dort auch gelebt, aber das Agile kann man ja auch weiter ausdehnen.

Thomas Sinnwell: Ich entnehme mal deinen Ausführungen, dass es allemal lohnt, darüber zu sprechen und dass es nach wie vor noch ein Thema ist?

Marcel Zinnow: Genau, natürlich. Ja.

Bernd Pohl: Ja, das würde ich genauso bestätigen. Ich kann das auch aus einem noch relativ aktuellen Beispiel darstellen. Wir sind als Testfabrik eine typische Universitätsausgründung, mittlerweile zwar seit einigen Jahren am Markt, aber doch in der Softwareentwicklung sehr agil und sehr dynamisch unterwegs. Und wir arbeiten zusammen mit großen Konzernen, und da gab‘s schon mehr als einmal die Situation, dass wir mit unserem Produkt in einen großen Konzern hineinkommen und das auch wirklich sehr gut angenommen wird und die das sehr zu schätzen wissen, dass man Innovation reinbringt. Wenn man dann aber mal so ein bisschen drin ist und das Ganze in dem Unternehmen etabliert wird, dann kommen ständig die Fragen: Ihr werdet jetzt aber schon in den nächsten vier Wochen nichts mehr an der Software verändern? Oder, weil dann müssen wir ja wieder unsere Leute umschulen und ähnliches. Das geht ja nicht, weil wir haben gerade erst so ein Lehrvideo gemacht, damit die Leute wissen, wie sie mit der Software umgehen sollen. Da merkt man sofort, wie die Welten immer noch aufeinanderprallen und diese etwas konservative Softwarewelt und die moderne Softwarewelt doch noch sehr weit voneinander entfernt sind.

Thomas Sinnwell: Okay! Das Thema möchte ich später nochmal aufgreifen, aber vorher der Frage nachgehen: Was ist denn agile Softwareentwicklung eigentlich? Ich gehe mal in Vorlage und spanne mal so ein bisschen den Rahmen auf. So diese Konzepte der agilen Softwareentwicklung, die gehen ja auf die Theorie der empirischen Prozesssteuerung zurück. Das gibt’s schon ein bisschen länger, da haben sich viele Leute Gedanken gemacht. So eines der ersten Frameworks, die da rauskamen, war ja dann Scrum. Und in Scrum werden diese Konzepte übertragen auf Softwareentwicklung. Okay! So weit, so gut. Wenn man sich dann anschaut, was die Basis dieser Konzepte ist, dann sind das eigentlich vier Themen. Das ist erstens das Thema Transparenz. Dann ist es das Thema Inspektion. Es ist das Thema Adoption. Und dann letztendlich die Iteration. Schauen wir uns an, Transparenz kann man sich eigentlich ganz gut vorstellen. Transparenz in Prozessen, das ist natürlich die Grundlage, um überhaupt mal Probleme erkennen zu können. Gleichzeitig vielleicht auch das Problem für viele: Probleme werden auf einmal sichtbar. Ich kann mich nicht hinter PowerPoint Präsentationen und Project Plänen verstecken. Und wenn man das konsequent macht, sieht man Probleme sehr früh. Letztendlich ist das ja, aus meiner Sicht, die Grundlage, um überhaupt Prozesse sinnvoll steuern zu können. Gut! Dann Inspektion, das ist ja letztendlich eine Methodik zum aktiven Erkennen von Abweichungen und Problemen. Brauche ich dann auch zwingend zum Steuern. Und die Adoption, die bietet dann wiederum die Möglichkeit, systematisch Verbesserungen in den Prozessen herbeizuführen. Und wenn ich das Ganze iteriere, bin ich bei einem kontinuierlichen Verbesserungsprozess. Das mal so als der große Rahmen. Jetzt fragt man sich vielleicht, wenn man mit agiler Softwareentwicklung noch nichts zu tun hatte: Gut und schön, aber wie sieht das denn jetzt in der Praxis aus? Ich denke, da könnt ihr vielleicht noch ein bisschen besser was dazu sagen als ich. Und vielleicht können wir uns dem Thema ja so nähern über die Frage: Warum ist das überhaupt entstanden oder umgekehrt, was ist das Problem bei der konventionellen klassischen Softwareentwicklung?

Marcel Zinnow: Ich finde, du hast ein gutes Stichwort gesagt, Thomas, dieses Verstecken hinter Projektplänen. Genau das, finde ich, ist auch so ein Punkt, der Ansatz, der Ansatz gerade von konservativen Unternehmen vergibt Termine, man erstellt Projektpläne und stülpt diesen Projektplan den Softwareentwicklungsteams auf. Und grad das ist das Problem. Während der Softwareentwicklung treten Probleme auf, das ist ja grad bei uns in Softwareentwicklungsfirmen bekannt, da werden die Probleme aufgrund des Termins aufgrund des Plans und der Vorgaben, der ja ganz strikt eingehalten werden muss, werden die Probleme unter den Tisch gekehrt. Und genau das ist eben der Ansatz, wo die agile Softwarewicklung ansetzt, praktisch umgekehrt, in der Softwareentwicklung treten nun mal Probleme auf, ob es Frameworks sind, neue Frameworks, die verwendet werden, ob es Probleme drumherum sind, die Abhängigkeiten zu dem Softwareprojekt Probleme bereiten. Das sind Dinge, die werden, sollen transparent gemacht werden und die führen natürlich wiederum dazu, dass der Projektplan nicht mehr so eingehalten werden kann, wie er vorgegeben wurde.

Thomas Sinnwell: Aber ist es nicht vielmehr so auch, dass es schon bei den Anforderungen, bei den Requirements, beginnt? Weil ich meine, es gibt ja diesen Spruch, die Last mit dem Lastenheft, da ist ja was dran. Ich meine, grad große komplexe Softwareprojekte auf dem Papier mal runter zu deklinieren und alles zu definieren, alles zu denken, das ist ja echt schwierig.

Marcel Zinnow: Mhm (bejahend).

Thomas Sinnwell: Und das ist ja, glaube ich, schon einfach ein Grundproblem, wenn ich Software bauen will. Ich habe keine maschinelle Fertigung, ich kann nicht Prozesse eins zu eins definieren und das rattert immer durch, sondern das ist ja ein Individualbau, eine Individualentwicklung. Das ist, denke ich, auch ein ganz wichtiger Punkt aus meiner Sicht, warum klassische Softwareentwicklungsprojekte so oft scheitern und eben nicht in der Zeit, nicht im Budget fertig werden. Seht ihr da noch weitere Themen?

Bernd Pohl: Insgesamt, glaube ich, gibt’s tatsächlich eine ganze Reihe von Themen. Also ein Faktor, der ja auch eine nicht unerhebliche Rolle spielt, ist, dass der Wert und der Einfluss von Software insgesamt nicht nur bei den klassischen Unternehmen, sondern natürlich dann auch gerade bei den modernen und softwaregetriebenen Unternehmen deutlich höher geworden ist und plötzlich auch die Art und Weise, wie diese Sachen gesteuert werden wollen, fast zwangsläufig sich verändern musste. Also früher in größeren Konzernen war die Softwareentwicklung nur ein kleines Teilelement einer großen, zum Beispiel keine Ahnung, weiteren Industriefertigung oder ähnlich, da musste ein bisschen Software dazu gebaut werden, aber die war nicht entscheidend. Entsprechend wurden die Strukturen eher aus den alten Strukturen etabliert und man hat dann eben auch so Software entwickelt. Aber heutzutage ist die Software der treibende Faktor, unter Umständen der überlebenswichtige Faktor und kommt aus einer ganz anderen Ecke und braucht eine ganz andere Geschwindigkeit. Daraus ergeben sich dann plötzlich auch schon ganz andere Anforderungen, die früher so gar nicht da waren.

Thomas Sinnwell: Du sprichst da jetzt auch das ganz große Thema Digitalisierung an.

Bernd Pohl: Genau. Man ist da so ein bisschen natürlich auch getrieben mittlerweile. Ich kann es mir eigentlich heute nicht mehr leisten, als Unternehmen, das am Markt bestehen bleiben will, jetzt einen 3-Jahres-Projektplan zu machen, um in drei Jahren ein neues Softwareprodukt rauszubringen, das ich vor meiner Konkurrenz dann haben will. Weil dann haben die in der Zeit schon sechs andere Produkte gemacht, wenn sie softwareaffin sind.

Thomas Sinnwell: Ja, ich sehe da als weiteres Thema noch einfach die Dynamik, die man heute im Geschäftsalltag hat. Das hat natürlich auch ganz klar mit der Digitalisierung, Industrie 4.0, alles Treiber für so eine hohe Geschwindigkeit, hohe Dynamik, Zusammenarbeit mit Partnern, stärkerer Vernetzung, von den Partnern kommen Anforderungen, alles, alles Dinge. Und die bringen einfach auch ein hohes Maß an Unplanbarkeit mit sich. Insofern, und das ist jetzt für mich, aus meiner Sicht, auch so eine große Stärke jetzt dieser agilen Methoden, dass man das akzeptiert, dass ich nicht alles planen kann.

Bernd Pohl: Einer der Faktoren wie Software entwickelt wurde früher war ja unter anderem auch, weil man eben extrem steuern wollte, weil man Strukturen hatte, die begünstigt haben, dass ein paar Leute vorgegeben haben, was zu tun ist, und die anderen sollten es dann umsetzen. Dann brauche ich logischerweise auch mehr Strukturen, um das zu controllen, nachzuverfolgen und zu wissen, ob ich auch wirklich im Plan bin und ob das ungefähr auch am Ende rauskommt, was ich mir vorgestellt habe. Wenn ich mir moderne Softwarestrukturen in modernen, jungen Unternehmen angucke, funktioniert das ja völlig anders mit einem viel höheren Eigenverantwortungsgrad, mit einem viel höheren persönlichen Engagement in der Softwareentwicklung, weil irgendwie alle so ein bisschen eine Idee davon haben, wo die Reise hingehen soll, und die wollen das auch gemeinsam voranbringen. Dann habe ich plötzlich eine ganz andere Voraussetzung, warum ich die Software überhaupt entwickle und wie ich sie dann auch am besten entwickle. Also ohne das jetzt noch zu weit auszudehnen, aber das ist so, die Welt hat sich da, aus meiner Sicht, massiv verändert in den letzten 20 Jahren vielleicht.

Thomas Sinnwell: Ja, für mein Dafürhalten da hast du absolut Recht. Aber bevor wir das Thema vertiefen, würde ich noch gerne auf das Thema zu sprechen kommen, was denn jetzt agile Softwareentwicklung überhaupt ist? Die Frage ist bisher noch nicht ausgiebig beantwortet.

Marcel Zinnow: Es kommt ein bisschen auch auf die Projektgröße drauf an. Bei kleinen Projekten, dann ist es immer von Vorteil, wenn man direkt kundennah von Anfang an schon anfängt und mit dem Kunden spricht, direkt so nah wie möglich der Softwareentwickler bei dem Kunden die Anforderungen zusammen definiert, das Ganze dann umsetzt, auch direkt in kurzen Abschnitten, in Sprintzyklen mit dem Kunden zusammen, der sich nach einem Sprint die Software angucken kann, die gebaut worden ist, um dann eben gerade die Anforderungen, wo man dann merkt, nachdem das Review durchgeführt worden ist, okay, es ist doch nicht so, wie ich mir das gedacht habe, um dann eben noch Änderungen reinzubringen.

Thomas Sinnwell: Ja. Und ich denke, auch noch ganz wichtig an der Stelle zu erwähnen, durch dieses Arbeiten in Zyklen und nach jedem Zyklus kann sich der Kunde ja anschauen, was entstanden ist in dem Review. Da habe ich natürlich als Kunde die Möglichkeit, direkt zu sehen, ist das, was ich mir gewünscht habe, ist das jetzt so, wie es tatsächlich brauche, oder sollte da was anders sein? Dadurch, dass man jetzt eben nicht in Schichten die Software entwickelt, sondern einen Durchstich macht, besteht natürlich auch die Chance, ohne jetzt massiven Aufwand zu betreiben, an der Stelle zu sagen: Okay, wir haben festgestellt, das müsste eigentlich ein bisschen anders sein. Ich habe jetzt mit gearbeitet ich als Kunde, so wäre es doch besser, dass man das im nächsten Sprint dann auch wieder umbaut. Und sich so wirklich von Funktionalität zu Funktionalität durchhangelt.

Bernd Pohl: Und da kommen ja genau die wichtigen von dir, Thomas, am Anfang genannten Faktoren dann zum Tragen. Man muss möglichst schnell erkennen können, ob das, was man jetzt im ersten Schritt gebaut hat, in die richtige Richtung geht. Da sind wir bei der Transparenz. Du musst dann, falls es nicht so ist, schnell rausfinden, ah, was könnte man denn anders machen, muss es dann adaptieren, also ein bisschen anders, und dann eine Iterationsstufe. Dann machen wir es mal so und probieren mal, wie es dann ist. Und dann hat man quasi permanent diese Stufen, die man immer wieder durchläuft, in der Regel 14 Tageszyklus zum Beispiel, und das bringt natürlich eine ganz andere Dynamik und eine ganz andere Ergebniswelt, als wenn man irgendwie im Januar sagt, wir wollen das so und guckt dann im Dezember zum ersten Mal drauf und stellt fest, oh, leider haben wir aneinander vorbeigeredet.

Thomas Sinnwell: Ja, so der Klassiker aus der alten Welt. Es wird zwei Jahre Software gebaut, die wurde mal definiert, und nach zwei Jahren stellt man fest, das Rad der Zeit hat sich weitergedreht, das passt eigentlich gar nicht mehr zu unserer Welt. Und dann hat man eine Software, mit der man nur bedingt was anfangen konnte. Da liefern, ich sag mal, agile Management-, agile Entwicklungskonzepte ja eine Antwort, um das anders zu machen. Wenn wir da grad dabei sind, vielleicht noch so einen kleinen technischen Schwenk. Und da sind wir ja auch wiederum bei eurer Welt, bei der Testfabrik, aber ganz generell: Warum ist denn automatisiertes Testen so enorm wichtig bei agiler Softwareentwicklung?

Bernd Pohl: Wenn man es ganz einfach formulieren will, kann man sagen: Man kann sich die agile Softwareentwicklung eigentlich sparen, wenn ich am Ende eines jeden Zyklus oder irgendwann nach einer bestimmten Zeit nicht schon automatisiert und integriert teste, sondern wenn ich dann wieder einen Flaschenhals habe und muss sagen, ja, jetzt alles Stopp, wir machen jetzt eine Woche nichts, weil jetzt wird erst mal getestet. Dann ist nämlich das ganze Prinzip der agilen Entwicklung ad absurdum geführt. Dann kann ich mir das Ganze auch sparen, weil es keinerlei Mehrwert mehr hat. Also das bedeutet im Umkehrschluss: Man muss die Testmethoden, die Teststrategien von Anfang an in die Entwicklung mit einbeziehen, mit integrieren und möglichst im Verlaufe des ganzen Prozesses immer wieder auch parallel automatisiert testen, damit ich das Produkt, das ich quasi ausliefere, das ich jede Woche oder wie auch immer deploye, auch immer gleich mit qualitätsgesichert habe. Dann habe ich das vom Aufwand her überschaubar, weil ich es von Anfang an mitbegleite, und ich habe insgesamt halt nicht den Prozess plötzlich wieder an einer Stelle unterbrochen, weil ich, wie gesagt, einen Flaschenhals, einen Ressourcenengpass oder irgendwas habe, sodass das dann mit dem agilen Entwickeln doch nicht mehr funktioniert. Also das ganz einfach ausgedrückt, warum es absolut notwendig ist, diese Aspekte auch mit einzubeziehen.

Thomas Sinnwell: Da adressiert ihr jetzt ja explizit auch so diese innere Softwarequalität, dass halt gute Software gebaut wird, die a) funktioniert, die aber auch wartbar ist, mit der man was anfangen kann, wenn man sie auch nach fünf Jahren mal wieder anschaut. Dann gibt’s ja aber auch noch die äußere Softwarequalität. Das, was letztendlich auch der Kunde dann sieht. Funktioniert das so, wie ich mir das gedacht habe? Funktioniert das gut? Gibt’s da sinnvolle Workflows, die ich abarbeiten kann? Diese Themen. Ich glaube, da habt ihr ja beide, so aus unterschiedlichen Blickwinkeln könnt ihr da noch ein bisschen was dazu sagen.

Marcel Zinnow: Ja, aber noch ganz kurz zu dem Punkt von eben, automatisiertes Testen. Da finde ich, ist es auch ganz wichtig zu wissen, der Vorteil von dem automatisierten Testen ist dann eben auch, dass man Software, die man schon vor längerer Zeit gebaut hat, dass man sich damit absichert, dass sie auch noch funktioniert.

Thomas Sinnwell: Wie sieht‘s denn mit der äußeren Softwarequalität aus?

Marcel Zinnow: Da spielen gerade die Sprint-Reviews dann eine wichtige Rolle, indem sich der Kunde dann das Produkt selbst angucken kann und dann auch die Gelegenheit hat, das Produkt zu testen, manuell zu testen. Wenn es größere komplexere Workflows sind, Prozesse sind, dann wird natürlich auch die gesamte Prozesskette getestet. Das sind dann verschiedene Stakeholder, die dann auch die Möglichkeit haben zu testen.

Bernd Pohl: Ein weiterer großer Aspekt des Testens, der auch in den letzten Jahren verstärkt dazugekommen ist, ist dann natürlich auch, wenn der Kunde eine Software in Auftrag gegeben hat, dann muss die ja auch am Ende des Tages oft hin zum Endkunden funktionieren. Also sei es jetzt bei Banken, Versicherungen oder ähnliches, dann werden Apps und Webanwendungen gebaut, und das Ziel dieser Anwendungen ist natürlich, dass die Versicherung Versicherungen abschließen kann, dass die Bank Girokonten eröffnen kann und so weiter. Dann kommen wir natürlich in das inzwischen sehr komplexe und heterogene Feld des Testens auf verschiedenen Endgeräten. Ich glaube, da brauche ich nichts Großes zu erzählen, da weiß jeder, es gibt heutzutage Tablets, es gibt Smartphones, es gibt Computer, Mac, Laptops und feste Rechner, und überall auf diesen Anwendungen oder Geräten muss die Anwendung funktionieren. Das ist natürlich eine sehr komplexe Geschichte, die der Kunde von Hand eigentlich nicht mehr darstellen kann. Genau dafür sind dann auch solche Testautomatisierungslösungen und Plattformen wichtig, auf denen man diese ganzen Dinge dann entsprechend abtesten kann.

Thomas Sinnwell: Das heißt also, jetzt wieder zurück zu dir, Marcel, was du erzählt hast, Kunde muss dann auch, aus seiner Sicht, letztendlich in den Reviews, aber auch, wenn er letztendlich größere Code-Fragmente vorliegen hat und dann wirklich Funktionalität testen kann, aus seiner Sicht das Ganze testen und da hilft natürlich, entsprechende Werkzeuge zu haben, so wie das die Testfabrik auch anbietet, um einen auch diese Phase deutlich schneller durchführen zu können. Dann würde ich gerne so noch mal auf das Thema zurückkommen, was wir am Anfang hatten. Für welche Unternehmen ist denn jetzt agile Softwareentwicklung geeignet? Wir hatten so ganz kurz diesen Fokus, groß, klein. Also ich kenne da jetzt so ein ganz großes Unternehmen, das macht das sehr konsequent, auch sehr erfolgreich. Aber wir hatten zu Anfang festgestellt, hm, ja, so bei den, ich sag mal, software-lastigen Unternehmen, bei vielen Start-ups, die sich mit Softwareentwicklung beschäftigen, ist das gang und gäbe, ist das das Mittel der Wahl. Größere oder mittelständische Unternehmen tun sich manchmal damit ein bisschen schwerer. Aber wie seht ihr das, für wen ist es denn jetzt was?

Bernd Pohl: Am Ende des Tages ist es, aus meiner Sicht, sowohl für klein als auch für groß geeignet, wenn sich alle Strukturen mit Herz und Verstand auch der Methode komplett verschreiben. Also das ist eine Geschichte, die nicht nur rein in der Softwareentwicklung dann stattfindet, sondern die insgesamt über alle Management- und alle Mitarbeiterebenen gehen muss, die sich im gesamten Unternehmen als Konzept verankern muss. Das ist eigentlich dann oft der springende Punkt und das ist dann natürlicherweise in riesengroßen Strukturen extrem schwierig und extrem langwierig, sowas unterzubringen, und in kleineren Strukturen sehr viel einfacher. Es ist dann eher so, also auch als konkretes Beispiel, dass dann aus kleinen modernen Strukturen, die irgendwann sehr groß werden, sowas mitgenommen werden kann und auch funktioniert. Beispiel Zalando, die halt über Jahre hinweg das sehr, sehr stark vorangetrieben haben und dann in der Endausbaustufe quasi jetzt so vor auch drei, vier Jahren beispielsweise mit vielen und mit mehreren hundert verteilten Teams in der ganzen Welt Software entwickelt haben und die quasi live in die Produktionsumgebung deployt haben, wobei währenddessen Millionen von Umsätzen getätigt wurden, weil da einfach ein Riesenvertrauen, eine Riesentransparenz und eine superschöne Struktur geherrscht hat, die das Ganze möglichgemacht hat. Das ist, glaube ich, bei einem großen Unternehmen, das schon mal anders aufgestellt war und dann auf diesem Weg sich machen will, eine sehr, sehr viel schwierigere Aufgabe an der Stelle.

Thomas Sinnwell: Dann kommen wir ja eigentlich auch schon nahtlos so zu diesem Punkt: Was sind denn dann diese Herausforderungen jetzt bei der agilen Softwareentwicklung?

Marcel Zinnow: Ich sehe als größte Hürde die Einstellung zur agilen Arbeitsweise. Das Ganze fängt ja damit, man muss selbst davon überzeugt sein, und das ist wie eben Bernd auch gesagt hat, es müssen alle im gesamten Unternehmen, es fängt ganz oben an bei der Geschäftsführung, das Topmanagement, das mittlere Management, alle müssen diese Einstellung dazu entwickeln. Und das ist ein Prozess, das ist nicht nur eine Schulung, die man sich mal anhört und dann kann man das, sondern das ist ein Prozess, den man erlernen muss. Das ist, glaube ich, die allergrößte Hürde, um diese agile Arbeitsweise in einem Unternehmen zu etablieren. Das macht‘s dann auch eben bei mittleren oder großen Unternehmen so schwierig, weil umso mehr Personen ich habe, umso schwieriger ist das Ganze umzusetzen.

Bernd Pohl: Auch dazu ein ganz schönes Beispiel aus verschiedenen Praxisstrukturen. Man hat sogar in Studien innerhalb von großen Unternehmen herausgefunden, dass es sogar schon einen Unterschied macht, ob ich die Schulungen beziehungsweise die Fortbildungen der Mitarbeiter*innen in agilen Arbeitsweisen, ob ich die an den bekannten bereits bestehenden Orten durchführe, also zum Beispiel bei einem großen Unternehmen dann in einem Büro, in dem ich schon immer gearbeitet habe, oder ob ich die Mitarbeiter, Mitarbeiterinnen, rausziehe an einen neuen, etwas inspirierenderen Ort, der nicht mehr den, in Anführungszeichen, „alten Muff“ der alten Büros hat, sondern wo ein anderer Wind weht. Ich ihnen dort die gleichen Dinge vermittele und dann im Nachhinein feststelle, dass bei gleicher Ausbildungszeit, bei gleichen Inhalten, die vermittelt werden, die Leute, die draußen waren, das neue Thema wesentlich mehr angenommen haben als die, die einfach dringeblieben sind in ihrem normalen Umfeld. Also da fängt das schon an und daran erkennt man schon, wie komplex das Ganze ist dann in großen Strukturen tatsächlich umzusetzen.

Thomas Sinnwell: Was du da ja ansprichst, das adressiert ja auch so diesen Aspekt Mensch. Damit muss man ja ehr umgehen. Und wenn Unternehmen, ich sag mal, jahrelang anders gearbeitet haben und jetzt agile Entwicklungen, agile Managementmethoden da Einzug halten sollen, dann ist das ja schon eine massive Änderung in der Kultur am Unternehmen. Und Änderungen, das hängt natürlich immer von den Menschentypen ab, ich weiß nicht, wie ihr es seht, aber das ist so meine Erfahrung, es gibt halt immer die, die sind erst mal dagegen, und andere lechzen nach Veränderungen, nach spannenden neuen Themen. Und dann gibt’s natürlich auch so das Thema Sorge. Bisher wusste ich, wie ich gearbeitet habe, was auf mich zukommt, jetzt soll es anders werden. Oder auch, was ich auch immer wieder beobachtet habe: Boah! Jetzt wird ja alles sichtbar. Ich kann mich ja gar nicht mehr verstecken. Und das mag ja auch nicht jeder.

Bernd Pohl: Genau. Also das sind eigentlich die typischen Aspekte. Die größte Herausforderung in der agilen Softwareentwicklung, wie bei vielen anderen Veränderungen, ist, dass man die beteiligten Menschen entsprechend richtig mitnimmt, weil sonst funktioniert das nicht. Und auch kleiner Teilaspekt, weil du es grad kurz angedeutet hast, ist in dem Zusammenhang die Fehlerkultur. Wenn ich natürlich keine Fehler machen darf, weil anschließend irgendwie mein Vorgesetzter kommt und sagt mir, also nochmal und dann sehen wir uns im Archiv wieder oder so, dann kann ich natürlich auch nicht befreit Software entwickeln, weil dann habe ich überhaupt gar kein Interesse dran und versuche mich irgendwo hinter irgendwas zu verstecken. Also auch das eine Komponente. Und ich glaube, man merkt auch an dem Beispiel, agile Arbeitsweisen, agile Denkmodelle sind so vielschichtig und greifen an so vielen Stellen an, dass wir jetzt, glaube ich, auch in der Runde hier gar nicht die Möglichkeit haben, alle Facetten abzubilden, weil dazu ist es einfach zu komplex.

Thomas Sinnwell: Definitiv! Weil da könnte man eine ganz eigene Reihe mit aufmachen als Podcast. Gehen wir doch vielleicht jetzt einfach noch der Frage nach: Was bringt denn jetzt agiles Softwareentwickeln? Wir haben gehört, das ist gegebenenfalls, wenn ich ein anderes Konzept gewohnt bin, nicht so einfach, das erst mal im Unternehmen einzuführen. Aber warum lohnt es sich, sich dann trotzdem auf diesen Weg zu machen und vielleicht sogar mit Hilfe von Change-Management so eine andere Unternehmenskultur zu etablieren?

Marcel Zinnow: Ein großer Vorteil, den ich sehe bei agiler Softwareentwicklung, ist, dass viel mehr Qualität reinkommt. Nicht nur in der Softwareentwicklung selbst, sondern auch in der Kommunikation. Die Leute fangen von sich aus selbst an zu reden und untereinander zu reden, auch übergreifend, teamübergreifend, …

Thomas Sinnwell: Bereichsübergreifend.

Marcel Zinnow: … bereichsübergreifend, genau, und im Großen und Ganzen sorgt das einfach für Transparenz der Funktionalitäten von dem, was man gebaut hat. Und damit wird das Wissen auch verteilt. Das ist ein Wissen, was sich automatisch durch die Kommunikation, durch die Personen, die viel selbstständiger arbeiten, wird verteilt von ganz alleine. Und das finde ich, ist ein ganz großer Vorteil.

Bernd Pohl: Ich würde sogar noch einen kleinen Schritt weitergehen. Ich glaube, dass am Ende des Tages alle Unternehmen, bei denen Software Bestandteil des Unternehmenserfolgs ist, und das werden in den nächsten Jahren immer mehr, dass die nur dann dauerhaft erfolgreich bleiben, wenn sie den agilen Weg beschreiten. Und dass sie ansonsten auch von kleineren oder Unternehmen, die später gestartet sind, einfach überrollt und überrannt werden. Und selbst, wenn sie einen großen Puffer haben, einfach in ein paar Jahren dann keine Rolle mehr spielen werden. Weil die Unternehmen, die das auf eine andere Art und Weise machen, am Ende des Tages bei den Endnutzern, bei den Kunden, die das Ganze dann auch oft verwenden, die Erfolgreicheren sein werden. Das ist meine persönliche Meinung dazu.

Thomas Sinnwell: Da würde ich total beipflichten. Was mir eben noch, als ihr so am Sprechen wart, durch den Kopf geschossen ist, und das ist jetzt auch so eine ganz eigene Erfahrung, wir entwickeln jetzt auch schon seit über 20 Jahren Software bei uns im Haus, auch für unsere eigene Produktlinie, und das war nicht von Anfang an agil. Ich muss sagen, ich war sogar noch einer der Mitstreiter, die die agile Entwicklung bei uns etabliert haben. Vielleicht eher untypisch, sonst ist die Geschäftsführung öfter mal dagegen und es wird von den Entwicklern getrieben. Das war auch ein Prozess bei uns. Die Leute sind da alle mitgegangen. Aber für mich war ein ganz ausschlaggebender Punkt, dass diese dicken Daumen-Abschätzungen, die man ansonsten klassischerweise hatte, dass die weggefallen sind. Weil manchmal war man schneller fertig, in der Regel hat es immer länger gedauert. Das fand ich persönlich, um irgendwas zu steuern, auch aus Vertriebssicht, ganz, ganz problematisch. Ich meine, jetzt habe ich nicht den Vorteil, dass mir mein Entwicklungsteam sagt, du hast das, das, das, das, das bis dann, aber ich weiß, zu dem Zeitpunkt bringen wir die Release raus. Und von der Vertriebsseite her wissen wir, das sind die wichtigen Features, die brauchen wir unbedingt. Wenn wir die und die noch hätten, das wäre klasse. Aber wenn das noch geht, wäre es das Sahnehäubchen. Und dann kümmern sich die Leute, die Softwareentwickler selber darum, organisieren sich selbst, haben dort dann auch mehr Spaß, sind motivierter, bauen diese Dinge, und ich weiß zumindest, ich bekomme einen großen Satz meiner Wunsch-Features zu diesem Zeitpunkt. Den exakten Umfang kenne ich nicht, aber ich weiß, ich kann dann damit was anfangen. Das kann dann weitergehen, es kann dann in den Markt eingeführt werden. Und das bringt natürlich, und das hast du angesprochen, Schnelligkeit. Aus meiner Sicht heutzutage ein wahnsinnig wichtiger Faktor in Zeiten der Digitalisierung, um als Unternehmen erfolgreich zu sein. So nach dem, was wir jetzt alles so besprochen hatten, würde ich gerne vielleicht versuchen, mit euch so ein agiles Mindset zu definieren.

Bernd Pohl: Ich kann aus der Testfabrik-Sicht da zu meiner großen Freude von der Oase der Glückseligkeit natürlich aus berichten. Denn was wir von Anfang an gemacht haben, ist, dass wir die Menschen danach ausgewählt haben, welche Menschen das sind, und nicht, welche Fachlichkeit sie hatten. Eine der großen Maxime bei uns ist Eigenverantwortlichkeit. Und aus dieser Grundlage heraus, ist nicht die einzige, aber ist eine wesentliche Grundlage, entwickelt sich ganz viel von allein, ganz viel Eigendynamik. Daraus entwickelt sich Vertrauen, daraus entwickelt sich Fehlerkultur, daraus entwickelt sich, dass man sich als Team versteht und noch viele weitere Faktoren. Und das ist halt ein Riesenvorteil natürlich, wenn man in diesen Zeiten jetzt auf der grünen Wiese neu anfängt und sich seine Leute zusammensucht, und das ist natürlich der Riesennachteil, den große Strukturen haben, die halt einfach auch mit dem arbeiten müssen, was da ist und was über die letzten zehn, 20, 30, 40 Jahre gewachsen ist, was das Ganze natürlich sehr viel komplizierter macht.

Marcel Zinnow: Aus meinen vielen Erfahrungen in der Vergangenheit weiß ich auch, dass die Projekte einfach scheitern, wenn nur der eine Aspekt der Softwareentwicklung berücksichtigt wird. Aber dieser menschliche Faktor, diese Begleitinstruktionen, die mitgemacht werden müssen, was Bernd erzählt hat, wie zum Beispiel Schulungen und Coachings, dass die Mitarbeiter mitgeholt werden, was bedeutet das denn alles, das sind ganz andere Tools, die eingesetzt werden, dass das einfach geschult wird und denen gezeigt wird. Dieser Teil fehlt einfach oft und das führt dann zum Scheitern von solchen Projekten.

Thomas Sinnwell: Hört sich halt ein bisschen so an, als ob man einfach ganz genau hinschauen muss: Welchen Stand hat ein Unternehmen? Was soll erreicht werden? Was sind die Ziele? Und insofern gibt es, aus meiner Sicht, jetzt nicht DAS agile Entwicklungskonzept, das auf alle passt, sondern man muss es letztendlich immer adaptieren an das Vermögen des eigenen Teams oder auch an die Situation, in der sich der Auftraggeber im Moment gerade befindet.

Bernd Pohl: Ja, das ist vollkommen richtig. Also aus so einer Perspektive wie in meiner bei der Testfabrik mit einem sehr agilen Team und einer Software, die quasi von null neu komplett entwickelt wurde mit modernsten Tools und in den letzten Jahren erst, das ist natürlich auch absolut nicht vergleichbar mit einer beispielsweise großen Versicherung, die seit ungefähr 100 Jahren Versicherungsgeschäft macht und im Keller noch Geräte stehen hat mit Daten, die einfach notwendig sind, damit man diese ganzen Versicherungsgeschäfte noch verwalten kann und in denen wirklich komplexe Strukturen über Jahrzehnte gewachsen sind. Die kann man halt eben mal nicht mit einem kleinen agilen Softwareprojekt irgendwie komplett umändern, das ist utopisch. Das heißt, das Ganze muss schon auch einfach in Schritten, in unterschiedlichen Scheiben quasi entstehen und wachsen, und dann kann man das sukzessive umsetzen und versuchen, sich da am Markt auch entsprechend so zu etablieren. Aber das geht nicht mit so einem Hauruck und vier Wochen später ist man dann agil, das klappt nicht.

Thomas Sinnwell: Ich würde das gerne für die Zuhörer jetzt noch mal zusammenfassen. Wir können ja mal versuchen, so die Top 3 Themen zu benennen, die wir unseren Zuhörern mitgeben wollen, was man denn beachten muss, wenn man sich auf agile Softwareentwicklung einlassen will. Bernd, magst du starten?

Bernd Pohl: Mhm (bejahend). Ganz wichtig ist auf jeden Fall, die Menschen bei diesem Prozess, und das ist ein Prozess, mitzunehmen und dafür zu sorgen, dass alle sich mit diesen neuen Themen und mit diesen neuen Zielen identifizieren, damit das insgesamt als Prozess funktionieren kann.

Marcel Zinnow: Für mich ist ganz wichtig die Entwicklung eines Mindsets. Dazu gehört zum Beispiel, ein ganz wichtiger Faktor, die Fehlerkultur, die Akzeptanz von Fehlern dazu.

Thomas Sinnwell: Okay! Und so aus meiner Sicht, jetzt auch vielleicht mal so aus der Geschäftsführungssicht: Man muss sich einfach darauf einlassen können, dass nicht alles planbar ist. Das ist ja auch die Realität, die dazu geführt hat, dass so viele große IT-Projekte eben gescheitert sind. Daraus muss man lernen. Ich kann nicht alles planen, also muss ich mit diesem Unplanbaren umgehen. Und dazu ist, ich sag mal, so diese agilen Entwicklungskonzepte, ein sehr brauchbares Mittel, um diese Unwägbarkeiten zu händeln. Hat mir viel Spaß gemacht mit euch das Thema zu beleuchten. Ich hoffe, dass wir unseren Zuhörern ein bisschen was mitgeben konnten. Vielen Dank und bis demnächst!

Bernd Pohl: Vielen Dank und einen schönen Abend noch.

Marcel Zinnow: Vielen Dank! Tschüss!

So, das war‘s mal wieder von uns. Wir hoffen, wir konnten euch einen kleinen Einblick in die agile Welt geben und euch gut unterhalten. Wie immer haben wir weiterführende Links für euch in den Shownotes. Und wenn ihr Lust auf mehr habt, dann freuen wir uns natürlich, wenn ihr uns abonniert. In der kommenden Oster-Folge beschäftigen wir uns noch mal mit einem Thema, zu dem wir locker noch einige Folgen machen könnten, und zwar Digitalisierung. Diesmal aus einer unternehmerisch ganzheitlichen Perspektive und mit dem Schwerpunkt Change-Management. Am 1. April und garantiert ohne Aprilscherz. Wir freuen uns auf Euch!

Your cookie settings

Technically necessary (essential) cookies

Information on the individual cookies

  • Show more

    Technically necessary (essential) cookies

    Necessary cookies help to make a website usable by enabling basic functions such as page navigation and access to secure areas of the website. The website cannot function properly without these cookies.

    Name fe_typo_user
    Supplier consistec.de
    Purpose Secures anti-spam measures when using the contact form
    Expiration Session
    Type HTTP
    Name conCookieSettings
    Supplier consistec.de
    Purpose Saves the consent to cookies
    Expiration 30 days
    Type HTTP
    Name mtm_consent_removed
    Supplier consistec.de
    Purpose Used by Piwik Analytics Platform (matomo) to determine that the tracking has been contradicted
    Expiration 1 month
    Type HTTP
  • Show more

    Statistics

    Statistics cookies help website owners understand how visitors interact with websites by collecting and reporting information anonymously.

    Name matomo.php
    Supplier consistec.de
    Purpose Records statistics about the user's visits to the website, such as the number of visits, average time spent on the website and which pages were read.
    Expiration Session
    Type HTTP
    Name _pk_id#
    Supplier consistec.de
    Purpose Records statistics about user visits to the site, such as the number of visits, average time spent on the site and which pages were read.
    Expiration 1 year
    Type HTTP
    Name _pk_ses#
    Supplier consistec.de
    Purpose Is used by the Piwik Analytics Platform (matomo) to track page requests of the visitor during the session.
    Expiration 1 day
    Type HTTP
    Name _pk_testcookie..undefined
    Supplier consistec.de
    Purpose Is used by Piwik Analytics Platform (matomo) to check whether the browser used supports cookies.
    Expiration Session
    Type HTTP
    Name _pk_testcookie.#
    Supplier consistec.de
    Purpose Is used by Piwik Analytics Platform (matomo) to check whether the browser used supports cookies.
    Expiration Session
    Type HTTP