Agile Softwareentwicklung – alter Hut oder relevanter denn je?

„Die größte Herausforderung bei der agilen Entwicklung ist, wie bei vielen anderen Veränderungen auch, dass man die beteiligten Menschen entsprechend richtig mitnimmt.“

Herzlich Willkommen zu unserem Podcast Querverlinkt – Technik über dem Tellerrand. In unserer nun schon 7. Folge widmen wir uns dem Thema Agile Softwareentwicklung. Die Frage, mit der wir uns heute beschäftigen: Ist agile Softwareentwicklung eher kalter Kaffee oder brauchen Unternehmen heute sogar ein agiles Mindset. Als Gast haben wir unter anderem Bernd Pohl eigeladen. Bernd ist einer der Vorstände der Testfabrik AG. Die Testfabrik bietet Unternehmen die Plattform webmate zum automatisierten Testen ihrer Webanwendungen und Apps. Und das auf Knopfdruck und für alle denkbaren Endgeräte. Außerdem haben wir noch einen Profi aus unserem Haus für agile Projekte an Bord. Marcel Zinnow kennt die Chancen und Herausforderungen in der agilen Softwareentwicklung wie kein anderer. In dieser Runde werden wir für euch viele Aspekte zum Thema Agilität in der Softwareentwicklung beleuchten. Wir wünschen spannende Unterhaltung.

Transkription

Thomas Sinnwell: Heute habe ich zwei Gäste, Bernd Pohl von der Testfabrik und Marcel Zinnow von consistec. Ich freue mich, dass ihr da seid. Bitte stellt euch 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. Nebenbei bin ich noch Gründer und Betreiber von einem Coworking Space Fase 15, hier in Saarbrücken und dadurch bin ich 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: Mein Name ist Marcel Zinnow, ich bin Angestellter bei der consistec. Ich habe Informatik studiert und bin direkt nach dem Studium zu consistec. Dort habe ich jahrelang als Softwareentwickler gearbeitet und bin jetzt schon mehrere Jahre als Leiter von Softwareentwicklungsprojekten im Bereich der Telekommunikation tätig.

Thomas Sinnwell: Ja, schön, dass du da bist. Ich denke, wir haben einen spannenden Kreis, um über das Thema agile Softwareentwicklung zu sprechen. Dieses Thema ist Anfang der 90er Jahre hochgekommen. Das war damals auch "Scrum", 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 an. Es gibt viele Unternehmen, wahrscheinlich auch grad im kleineren Unternehmensbereich, die 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 sich 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 seit einigen Jahren am Markt, aber doch in der Softwareentwicklung sehr agil und sehr dynamisch unterwegs. 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 sehr gut angenommen wird und sie dieses Produkt sehr zu schätzen wissen, da man Innovation reinbringt. Wenn man dann 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 agile Softwareentwicklung eigentlich? Ich gehe mal in Vorlage und spanne mal ein bisschen den Rahmen auf. So diese Konzepte der agilen Softwareentwicklung, die gehen auf die Theorie der empirischen Prozesssteuerung zurück. Das gibt es schon  länger, da haben sich viele Leute Gedanken gemacht. So eines der ersten "Frameworks", die rauskamen, war ja "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, 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 Projekt Plänen verstecken. Und wenn man das konsequent macht, sieht man Probleme sehr früh. Letztendlich ist das, aus meiner Sicht, die Grundlage, um überhaupt Prozesse sinnvoll steuern zu können. Dann Inspektion, welches letzendlich eine Methodik zum aktiven Erkennen von Abweichungen und Problemen ist. Dies brauche ich dann auch zwingend zum Steuern. 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 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 so dem Thema 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 genannt Thomas. Dieses Verstecken hinter Projektplänen. Genau das, finde ich, ist auch der Punkt. Der Ansatz gerade von konservativen Unternehmen: man erstellt Projektpläne und stülpt diesen Projektplan den Softwareentwicklungsteams auf. Und grade das ist das Problem. Während der Softwareentwicklung treten Probleme auf, das ist bei uns in den Softwareentwicklungsfirmen bekannt. In großen, nicht agilen, Unternehmen werden die Probleme aufgrund des Plans und der Vorgaben, der ja ganz strikt eingehalten werden muss, unter den Tisch gekehrt. Und genau das ist der Ansatz, an dem die agile Softwarewicklung ansetzt. Es ist praktisch umgekehrt, in der Softwareentwicklung treten nun mal Probleme auf, ob es komplexe Frameworks sind, die weitere Probleme mit sich bringen, neue Frameworks, in die sich neu eingearbeitet werden muss oder zum Beispiel die externen Abhängigkeiten zu dem Softwareprojekt, wie Abteilungsabhängigkeit und Prioretisierung. Das sind Dinge, die transparent gemacht werden sollen 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, grade große komplexe Softwareprojekte auf dem Papier mal runter zu deklinieren und alles zu definieren, alles zu denken, das ist echt schwierig.

Marcel Zinnow: Mhm (bejahend).

Thomas Sinnwell: Und das ist, glaube ich, schon 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 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. Die Art und Weise, wie diese Dinge gesteuert werden sollen, musste sich zwangsläufig verändern. Also früher in größeren Konzernen war die Softwareentwicklung nur ein kleines Teilelement einer großen, 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 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 ganz andere Anforderungen, die früher so gar nicht präsent waren.

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

Bernd Pohl: Genau. Man ist da ein bisschen getrieben mittlerweile. Ich kann es mir heute als Unternehmen, das am Merkt bleiben will, nicht mehr leisten. Jetzt einen 3-Jahres-Projektplan zu machen, um in drei Jahren ein neues Softwareprodukt rauszubringen, das ich vor meiner Konkurrenz dann will. 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 zu tun. Das sind alles Treiber für so eine hohe Geschwindigkeit, hohe Dynamik, Zusammenarbeit mit Partnern, stärkerer Vernetzung, von den Partnern kommen Anforderungen und so weiter. Und die bringen auch ein hohes Maß an Unplanbarkeit mit sich. Insofern, und das ist jetzt aus meiner Sicht, auch eine große Stärke dieser agilen Methoden, dass man das akzeptiert, dass ich nicht alles planen kann.

Bernd Pohl: Einer der Faktoren wie Software wurde unter anderem entwickelt, weil man extrem steuern wollte. Man hat Strukturen, 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 was ich mir vorgestellt habe auch ungefähr am Ende rauskommt. Wenn ich mir moderne Softwarestrukturen in modernen, jungen Unternehmen angucke, funktioniert das völlig anders. Man hat 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 am besten entwickle. Also ohne das jetzt noch zu weit auszudehnen, aber da hat sich die Welt, aus meiner Sicht, massiv verändert in den letzten 20 Jahren.

Thomas Sinnwell: Ja, 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 an. Bei kleinen Projekten ist immer von Vorteil, dass man direkt von Anfang an nah am Kunden ist  und mit dem Kunden spricht. Das der Softwareentwickler mit dem Kunden zusammen die Anforderungen definiert und das Ganze dann umsetzt. In kurzen Abschnitten, wie Sprintzyklen. Der Kunde kann sich nach einem Sprint die Software angucken , die gebaut worden ist, um dann die Anforderungen, nach einen Review, anzupassen. Wenn er merkt, dass es doch nicht so geworden ist wie es sich das vorgestellt, hat kann er noch etwas ändern. 

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 es das was ich mir gewünscht habe? Ist das jetzt so, wie es tatsächlich brauche oder sollte da etwas 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 als Kunde mitgearbeitet. So wäre es doch besser, dass man das im nächsten Sprint dann auch wieder umbaut. Und sich so 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, was man anders machen könnte. Man muss es adaptieren und dann kommt eine Iterationsstufe. Dann machen wir es mal so und probieren mal, wie es dann ist. Man hat 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 kann. Da liefern, ich sag mal, agile Management-, agile Entwicklungskonzepte ja eine Antwort, um das anders zu machen. Wenn wir da gerade 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 dann sagen muss: 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. Das Produkt, das ich ausliefere, das ich jede Woche oder wie auch immer deploye, immer mit qualitätsgesichert habe. Dann habe ich das vom Aufwand her überschaubar, weil ich es von Anfang an mitbegleite, und ich habe insgesamt nicht den Prozess plötzlich 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 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? Ich glaube, da habt ihr ja beide 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, was der Vorteil des automatisierten Testen ist. Und zwar das man sich absichert, das Software, die man schon vor längerer Zeit gebaut hat, 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. Der Kunde kann sich das Produkt selbst angucken und hat dann auch die Gelegenheit, das Produkt zu testen, manuell zu testen. Wenn es größere komplexere Workflows oder 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 diese auch am Ende des Tages hin zum Endkunden funktionieren. Also sei es jetzt bei Banken, Versicherungen oder ähnliches. Dafür 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 entsprechend abtesten kann.

Thomas Sinnwell: Das heißt also, jetzt wieder zurück zu dem was du erzählt hast Marcel, der Kunde muss dann auch, letztendlich in den Reviews, aber auch, wenn er größere Code-Fragmente vorliegen hat und dann wirklich Funktionalität testen kann, das Ganze aus seiner Sicht testen. Da hilft es natürlich, entsprechende Werkzeuge zu haben, so wie das was die Testfabrik auch anbietet, um einen auch diese Phase deutlich schneller durchführen zu können. Dann würde ich gerne so nochmal auf das Thema zurückkommen, das 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 relevant?

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 stattfindet, sondern die insgesamt über alle Management- und alle Mitarbeiterebenen gehen muss, die sich im gesamten Unternehmen als Konzept verankern muss. Das ist eigentlich oft der springende Punkt und das ist natürlicherweise in riesengroßen Strukturen extrem schwierig und extrem langwierig, sowas unterzubringen. In kleineren Strukturen hingegen sehr viel einfacher. Es ist eher so, auch als konkretes Beispiel, dass aus kleinen modernen Strukturen, die irgendwann sehr groß werden, sowas mitgenommen werden kann und auch funktioniert. Beispiel Zalando, die das über Jahre hinweg sehr, sehr stark vorangetrieben haben und dann in der Endausbaustufe, so vor drei, vier Jahren mit mehreren hundert verteilten Teams in der ganzen Welt Software entwickelt haben und die quasi live in die Produktionsumgebung deployt haben. Währenddessen wurden Millionen von Umsätzen getätigt, weil da einfach ein Riesenvertrauen, eine Riesentransparenz und eine superschöne Struktur geherrscht hat, die das Ganze möglich gemacht hat. Das ist, glaube ich, bei einem großen Unternehmen, das schon mal anders aufgestellt war und sich auf diesem Weg machen will, eine sehr, sehr viel schwierigere Aufgabe an der Stelle.

Thomas Sinnwell: Dann kommen wir ja eigentlich auch schon nahtlos 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 damit an, dass man selbst davon überzeugt sein muss und das ist das was Bernd eben 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 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 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, 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*innen, rausziehe an einen neuen, etwas inspirierenderen Ort, der nicht mehr den, „alten Muff“ der alten Büros hat, sondern wo ein anderer Wind weht. Wenn ich ihnen dort die gleichen Dinge vermittele und dann im Nachhinein feststelle, dass bei gleicher Ausbildungszeit, bei gleichen Inhalten, 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 es ist das Ganze in großen Strukturen umzusetzten. 

Thomas Sinnwell: Was du da ja ansprichst, das adressiert ja auch diesen Aspekt Mensch. Damit muss man ja eher umgehen. Und wenn Unternehmen, ich sag mal, jahrelang anders gearbeitet haben und jetzt agile Entwicklungen, agile Managementmethoden da Einzug halten sollen, dann ist dies ja schon eine massive Änderung in Unternehmenskultur. Und Änderungen, das hängt natürlich immer von den Menschentypen ab, ich weiß nicht, wie ihr es seht, aber das ist meine Erfahrung, es gibt 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 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 mir sagt: also nochmal und dann sehen wir uns im Archiv wieder oder so. Bei so etwas kann ich natürlich nicht befreit Software entwickeln, weil dann habe ich überhaupt gar kein Interesse dran und versuche mich irgendwo hinter irgendwas zu verstecken. Also auch das ist 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 sich auf diesen Weg zu machen und vielleicht sogar mit Hilfe von Change-Management 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ät 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, 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 diese nur dann dauerhaft erfolgreich bleiben, wenn sie den agilen Weg beschreiten. Und 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, der die agile Entwicklung bei uns etabliert hat. 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 bis dann, aber ich weiß, zu dem Zeitpunkt bringen wir die Release. 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 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, 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 10, 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 einer Perspektive, wie in der Testfabrik, mit einem sehr agilen Team und einer Software, die quasi von null komplett neu entwickelt wurde mit modernsten Tools und in den letzten Jahren erst, ist es ja was ganz anderes als mit einer beispielsweise großen Versicherung. Die macht seit ungefähr 100 Jahren Versicherungsgeschäft und hat im Keller noch Geräte stehen 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, 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!