Warum führt Agilität manchmal dazu, dass der Endkunde aus dem Fokus der eigenen Arbeit verloren wird?

Warum führt Agilität manchmal dazu, dass der Endkunde aus dem Fokus der eigenen Arbeit verloren wird? In dieser Folge mache ich mir Gedanken dazu, warum Agilität in der Produktentwicklung nicht (immer) das Allheilmittel ist. In vielen Projekten habe ich beobachtet, dass gerade im Rahmen der agilen Softwareentwicklung der Endkunde oft vollkommen aus dem Auge verloren wird. Aber hört selbst... 🙂

Podcast per iPhone, Mac oder iPad anhören

Podcast per Android und Google Podcasts anhören

010 Agile Produktentwicklung => schlechte Kundenorientierung?

Hier findest du die weiterführenden Links, die ich in dieser Podcast-Folge erwähnt habe:

So verpasst du keine Podcast-Folge mehr:

❤-lichen Dank für deine Weiterempfehlung:

Sei doch bitte so gut den BLICKWINKEL KUNDE Podcast auch in deinem Netzwerk bekannt zu machen. So sorgst du dafür, dass regelmäßig neue Folgen mit frischen Tipps für den Erfolg deines Unternehmens erscheinen. Wie ein guter Fernsehkoch habe ich hierzu etwas vorbereitet: 🙂

Klick hier, um diesen Podcast weiterzuempfehlen <<

Diese Podcastfolge als Video

Mit dem Laden des Videos akzeptieren Sie die Datenschutzerklärung von YouTube.
Mehr erfahren

Video laden

YouTube immer entsperren

Inhalt dieser Folge

Tja, ich sage mal, alle Fans der neuen Arbeit, von der Qualität und flexiblen Prozessen, werden jetzt wahrscheinlich erstaunt gucken und sich fragen: “Spinnt der Ratajczak eigentlich?” Ich kann euch beruhigen, ich spinne nicht. Ich möchte einfach nur mal diese Frage, okay, ich gebe zu, vielleicht etwas provokante Frage, dazu nutzen, einen anderen Blickwinkel auf die agile Produktentwicklung zu entwickeln. Hört mir einfach ein paar Minuten zu und ihr werdet verstehen, was ich damit meine. Ich freue mich auf spannende Diskussionen im Nachgang. Also, zum Hintergrund.

Was ist überhaupt agile Produktentwicklung?

Nehmen wir das Ganze mal auseinander. Da drin steckt “Produktentwicklung”, also Produktentwicklung ist der Prozess, um ein Produkt oder eine Dienstleistung oder Hardware oder Software, als ich sage mal, allgemeine Produkte oder Dienstleistungen zu entwickeln. Und “agil” nennt man einfach die Anwendung von verschiedenen neueren Methoden, um schneller Produkte entwickeln zu können. Und diese dann kontinuierlich weiter verbessern zu können. Warum ist es also wichtig, dass man seine Produkte agil entwickelt? Ich sage mal, der Time-to-Market sinkt, also die Zeit von der Produktidee, bis man dann sein Produkt draußen am Markt verkaufen kann, schrumpft in allen möglichen Branchen. Wie sagt man so schön, Zeit ist Geld, es geht eben darum, man hat eine neue, innovative Idee, man muss daraus ein Produkt entwickeln, es an den Markt bringen und ab da, sobald es am Markt ist, kann es natürlich gekauft werden und dann kann man damit Geld verdienen. Also, Time-to-Market sinkt, die Komplexität der Produkte da draußen steigt. Wenn man besonders an Software-Produkte denkt, die werden immer komplexer, die Softwarestrukturen werden umfassender. Es gibt diverse Schnittstellen, also es wird einfach viel komplizierter und deswegen hat sich herauskristallisiert, dass agile Vorgehensmethoden manchmal gar nicht schlecht sind. Aber, sind sie immer gut? Das werde ich beantworten. Ich würde mit euch heute gerne mal am Beispiel der agilen Softwareentwicklung dieses Thema besprechen. Weil ich selber in den letzten 18 Jahren zweimal für eine Softwareentwicklung verantwortlich war und die entsprechenden Teams geleitet habe. Und generell gelten meine Überlegungen aber hier für jede Art der agilen Entwicklung, also der agilen Produktentwicklung. Also, schauen wir uns mal an.

Wie lief Softwareentwicklung früher ab?

Häufig in Form des sogenannten Wasserfallmodells. Wie das funktioniert, erkläre ich euch gleich. Wenn ich solche Begriffe hier verwende wie “Wasserfallmodell”, findet ihr die auf alle Fälle in den Shownotes. Das heißt, es gibt zu jeder Folge eine Webseite auf meiner Seite unter “Ihre-Kundenbrille.de/Podcast” und dann da die entsprechende Podcastfolge, das ist heute nämlich Nummer zehn. Und da drunter findet ihr dann alle möglichen Erläuterungen. Ich habe euch Definitionen dorthin geschrieben, zum Beispiel zum Thema Wasserfallmodell. Also, ich sage mal, wenn man sich vorstellt, ihr seid in einer großen Softwarefirma oder in einer großen Firma, die hat eine IT-Abteilung und ihr arbeitet vielleicht im Marketing und habt bestimmte Anforderungen diese Software. Also, geht ihr hin als Vertreter der Fachbereiche, als Vertreter der Anwender, formuliert eure Anforderungen und schreibt die auf. Man nennt das klassischerweise Lastenheft, also lange Rede, kurzer Sinn, ein Dokument. Da steht dann drin, wir hätten gerne dass in dieser Software Folgendes passiert, das soll so aussehen, im Zweifelsfall steht ja auch schon drin, wir hätten gern die Möglichkeit, dass und das zu machen, damit wir das und das erreichen können. Das ist ein sogenanntes Lastenheft. Und diese Lastenhefte werden dann meistens auch zur Ausschreibung benutzt. Das heißt, irgendein Fachbereich möchte gern eine bestimmte Software haben oder eine Softwareänderungen, die eben die gewünschten Funktionen ermöglicht. Dann kann man dieses Lastenheft nehmen und damit Ausschreibungen machen, sagt am Markt: “Liebe Softwareentwickler, wir hätten gerne Funktionen umgesetzt, wer will?” Und “Wie lange soll es dauern, was macht ihr uns für ein Angebot?” Und der potentielle Auftragnehmer liest dann dieses Lastenheft, macht sich darüber Gedanken und erstellt ein Pflichtenheft. Und dieses Pflichtenheft beschreibt dann, wie die Anforderungen des Auftraggebers sozusagen umgesetzt werden. Und genau da beginnt nämlich auch schon der Ärger. Ich sage mal, IT-Mitarbeiter und die Mitarbeiter von nicht-IT-nahen Abteilungen, sei es jetzt Buchhaltung, Marketing, Sonstiges, Personal, die scheinen einfach eine vollkommen verschiedene Sprache zu sprechen. Und genau dann beginnt es nämlich einfach, dass sich Missverständnisse bilden, dass man denkt, man spricht über dasselbe. Die IT denkt, sie hat die Anforderungen des Fachbereiches genau verstanden. Der Fachbereich denkt: “Oh, die IT hat ja Folgendes geschrieben, dass sie es so umsetzen werden, sie haben uns genau verstanden und los geht es!” Ich habe in einer der vorherigen Folgen, ich glaube, es war unter anderem in der Folge 9 mal beschrieben, wie so etwas relativ schnell zu Katastrophen führen kann, wenn sich beide einigen, aber jeder ein anderes Bild davon im Kopf hat, man sich einigt und dann anfängt umzusetzen, ein langes Thema! Also, das führt dann zu Missverständnissen, weil Formulierungen manchmal fehlinterpretiert werden oder es kann natürlich auch sein, wenn ein Softwareentwickler, der ein Angebot macht, Formulierungen extra so wählt, von denen er weiß, dass der Auftraggeber die nicht auf den ersten Blick so versteht, wie sie da stehen. Also, es kann natürlich durchaus sein, dass wie soll ich sagen, bösartige Auftraggeber dann extra solche Formulierungen wählen, damit sie den Auftrag bekommen, aber in Wirklichkeit viel weniger Aufwand haben bei dem, was sie leisten müssen. Und das führt auf alle Fälle immer wieder zu extremen Missverständnissen. Und wie gesagt, also ich habe selber früher zweimal eine Softwareentwicklung geleitet und ich kenne deshalb solche Formulierungen ziemlich genau. Also, wenn ich die sehe in solchen Angeboten, schrillen bei mir immer die Alarmglocken, weil ich genau weiß: “Aha, da will irgendjemand etwas vertuschen.” Also, deswegen werde ich auch manchmal von Firmen beauftragt, die gerade in so einer Ausschreibung sind, mir die Unterlagen, die Angebote anzuschauen, die da kommen. Und ich habe es jedes Mal festgestellt, es gibt diese Formulierungen. Die ändern sich im Laufe der Jahre immer wieder ein bisschen, aber trotzdem, es gibt so Formulierungen. Und wenn ich die finde, reichen dann meistens schon ein paar Sätze, um mal den Daumen in die Wunde zu legen und bei dem Anbieter noch mal genau nachzufragen, wie er es denn genau meint. Wie soll ich sagen, so ein Softwareausschreibungsprozess ist ja ein Prozess auf Augenhöhe. Also ich meine, der eine will bestimmte Funktionen haben, der andere will sein Geld damit verdienen, dass die Entwickler das entwickeln, aber zusammen muss halt was Gutes herauskommen. Also, die Entwickler müssen anständig bezahlt werden, geschenkt, trotzdem muss die Funktion natürlich da sein, die der Fachbereich haben will. Unterstütze ich dann sozusagen oft mal meine Auftraggeber dabei, bei solchen Ausschreibungen genau die Formulierungen in den Angeboten zu finden und dann darauf hinzuweisen: “Achtung, Achtung, fragt an der Stelle mal nach!” Gehen wir davon aus, es gab eine Ausschreibung, ein bestimmter Anbieter hat die Anforderungen des Fachbereichs bestmöglich beschrieben und hat gesagt, wir setzen das so um, kostet so viel, wir machen das in der Zeit. Okay, der Auftrag wird dann erteilt und vergeben. Und genau dann passiert nämlich das, was im Wasserfallmodell klassisch war. Man schreibt ein großes Dokument, übergibt dass der IT, die fängt an zu entwickeln und nach einer beliebigen Zeit von X Monaten wird dann die Software ausgeliefert. Und der Fachbereich fängt dann an zu gucken und kann sich dann häufig schon nicht mehr so genau daran erinnern, was er denn überhaupt damals genau mit der Formulierung gemeint hat in seiner Anforderung, denn so eine Entwicklung kann ja Monate dauern. Da habe ich auch mal ein paar Sachen erlebt, der Fachbereich ist die ganze Zeit davon ausgegangen, dass sie eine Frontend-Anwendung bekommen. Das heißt, eine Webseite, die konnten darauf irgendwas klicken, ausführen, Knopf drücken, dann passiert etwas. Die IT hat das immer ganz anders verstanden, die haben immer gedacht, es geht um eine Schnittstelle und hat eine Schnittstelle programmiert. Also es gab de facto zu dem Zeitpunkt, wo dann die Software ausgeliefert wurde, nur eine bestimmte technische Schnittstelle. Also man konnte aus Fachbereichssicht überhaupt nichts sehen. Und genau das war das Problem. Die beiden haben die ganze Zeit über die einzelnen Funktionen gesprochen, dem Fachbereich war klar, sie wollen natürlich keine Schnittstelle, weil sie gar nicht in dem Moment wussten, was das überhaupt war, was sie damit hätten machen sollen, sondern die wollten halt eine Änderung an einer bestimmten Software haben. Ja, die IT hat zugesichert, wir liefern das euch in drei Monaten aus und nach drei Monaten kam dann eine Schnittstelle, die aber nicht Sichtbares, sozusagen Arbeitbares hatte. Das führte dann zu ziemlich langen Gesichtern. Und das ist aber eben das häufige Problem bei solchen Wasserfallmethoden, das führt dann zu extrem teuren Nachbesserungen und Zeitverzögerungen. Weil man dann nach langer Zeit, in der die Software entwickelt wird, da wird sie irgendwann ausgeliefert, dann guckt der Kunde sich die an und sagt häufig: “So haben wir das nicht gemeint. Also eigentlich meinten wir das sehr genau so.” Und im schlimmsten Fall führt das dann dazu, dass man die letzten drei Monate Entwicklungsaufwand zu großen Teilen wegschmeißen kann und einfach noch mal neu anfangen muss. Das führt natürlich zu extrem hohen Aufwendungen und zu extremen Verzögerungen.

Was ist aber nun die Lösung aus diesem Dilemma?

Und das ist nämlich die agile Softwareentwicklung, die auf den folgenden Grundprinzipien beruht: Erhöhte Transparenz und Flexibilität, iteratives Vorgehen. Das heißt, man formuliert nicht seine Anforderungen, übergibt dann das Dokument an die IT oder den Softwareentwickler und dann hört man monatelang nichts von dem, sondern es sind dauernde Abstimmungsschleifen dazwischen. Ich hatte gerade erhöhte Transparenz und Flexibilität, iteratives Vorgehen, zusätzlich gibt es noch schnelle Erstellung eines ersten testbaren Produktes. Das heißt eben, dass ein Stückchen Software möglichst schnell ausgeliefert wird. Manchmal sind das Zyklen von zwei Wochen oder vier Wochen. Das heißt, nachdem man die Softwareentwicklung gestartet hat, nach zwei Wochen später kann der Fachbereich bereits die angeforderten Softwarestücke anschauen, testen und gucken, ob es genau das ist, was er haben wollte. Er bekommt zwar nicht die ganzen Anforderungen an einem Stück, dafür bekommt er schon Teile relativ früh, sodass man eben schnell in eine Diskussion kommen und sagen kann: “Ja, okay, die zwei Wochen, das war jetzt nichts, weil, wir haben total aneinander vorbeigeredet, wir haben uns völlig missverstanden”. Aber, da verliert man nur zwei Wochen und nicht eben Monate. Aus meinem Verständnis ist das Allerwichtigste an dieser agilen Vorgehensweise, dass man gegenseitiges Vertrauen hat. Und eine enge Zusammenarbeit. Das ist natürlich eine extreme Herausforderung für beide Seiten., Wie gerade schon mal gesagt, IT-nahe Abteilungen und Abteilungen, die nicht so IT-nah sind, die sprechen einfach andere Sprachen. Und häufig führt das dann eben zu Missverständnissen. Diese agilen Methoden zwingen die beiden Parteien aber dazu, eng aneinanderzurücken und häufiger miteinander zu sprechen. Und anders geht es ja auch gar nicht. Weil, wenn der Fachbereich es nicht auf Bit und Byte und genau detailliert beschreiben kann, was er haben will, dann muss man halt häufiger miteinander reden, bis beide sich einig sind, was dabei herauskommen soll. Also, typische agile Methoden sind zum Beispiel so ein bestimmtes Vorgehensmodell Scrum, verlinke ich euch auf alle Fälle in den Shownotes. Detaillierte Erklärung würde da jetzt echt wirklich zu weit führen. Ich kann es gerne mal in einer anderen Podcastfolge machen, wenn ihr daran Interesse habt. Schickt mir einfach eine Mail an (podcast@ihre-kundenbrille.de) Wichtig ist bei solchen agilen Methoden, dass zum Beispiel alle 14 Tage es eine neue Softwaremethode gibt, die der Auftraggeber dann wieder testen kann. So kommen dann neue Funktionen schneller in den Livebetrieb und Fehler können schneller ausgemerzt werden. Wenn man dann sofort nach 14 Tagen schon merkt: “Oh, Mist, das haben wir falsch interpretiert, so wollen wir das gar nicht haben, wir wollen die nächste Version haben, wir müssen nochmals 14 Tage investieren, um das zu beheben.” Also, ich fasse noch mal kurz zusammen: Agile Methoden beruhen einfach darauf, dass man deutlich enger miteinander arbeitet. Beim Beispiel Softwareentwicklung ist das sozusagen der IT-Bereich oder der Softwareentwickler plus der Fachbereich. Und die stimmen sich extrem eng ab, das heißt, alle 14 Tage liefert die IT oder die Softwareentwicklung ein Stückchen Software. Der Fachbereich kann das testen, kann ein Feedback geben, und dann dafür sorgen, dass sozusagen in den nächsten 14 Tagen die Richtung zum Endziel schon mal besser ist. Also, machen wir weiter. Kommen wir noch mal zurück zur heutigen Frage.

Führt eine agile Produktentwicklung automatisch zu schlechter Kundenorientierung?

Also, agile Produktentwicklung scheint doch die Lösung zu sein, oder? Es hat doch nur Vorteile, denke ich. Also, ich sage mal, alle zwei Wochen gibt es eine neue Version der Software, Fehler können schneller behoben werden, die Zusammenarbeit zwischen IT und Fachbereichen wird verbessert und intensiviert. Das Problem ist aber, dass unter bestimmten Umständen der wirkliche Endkunde gar nicht in diesem Szenario vorkommt und vollkommen aus dem Auge verloren wird. Das habe ich mir jetzt nicht ausgedacht, weil ich sozusagen unter dem „ihre-kundenbrille.de” firmiere und Unternehmen dabei helfe, ihr Unternehmen mit der Kundenbrille anzugucken, also aus Sicht des Kunden, sondern, das ist eben genau das Problem. Nehmen wir mal ein bestimmtes Szenario. Es handelt sich zum Beispiel um eine Softwarefirma, die einen bestimmten Web-Dienst anbietet. Also zum Beispiel Facebook ist ja nichts anderes als eine Softwarefirma, die entwickelt eine bestimmte Software, die heißt Facebook, Facebook.com, kann man draufgehen, kann man benutzen. Geht aber nicht um Facebook, es gibt diverse Softwarelösungen, die man da draußen eben anbieten kann als klassischer Serviceprozess. Das heißt, ich gehe auf irgendeine Webseite, schaue mir das an, sage: “Oh, das Angebot ist interessant, kostet 9,95 € im Monat, ich buche das jetzt”, Kreditkartendaten eingeben und Zack habe ich eine URL, habe einen Login, kann mich da einloggen, kann diesen Dienst nutzen. Gehen wir mal davon aus. Es handelt sich also um eine Softwarefirma, die einen bestimmten Web-Dienst entwickelt und den als Software, also Service an den Endkunden, anbietet. Innerhalb dieser Softwarefirma gibt es dann Fachabteilungen, die sozusagen sich überlegen, was könnte man tun, damit der Kunde noch mehr von unserer Software hat, damit er besser damit arbeiten kann, damit er länger bleibt, damit der länger gebunden wird und damit der im Zweifelsfall sogar sagt: “Ich habe jetzt gerade das Silberabo für 9,95 €, aber eigentlich die Funktionen, die in dem Goldabo drin sind, gefallen mir besser, für 19,95 €” oder so, lässt sich dauernd sozusagen der Fachbereich neue Funktionen einfallen, um den Kunden länger zu halten und im Zweifelsfalle mehr zu verkaufen. Das heißt, der Fachbereich lässt sich neue Funktionen einfallen, die Anforderungen werden dann zusammen mit der IT entwickelt, im Zweifelsfall mit agilen Methoden, wie zum Beispiel Scrum. Alle 14 Tage kommt dann eine neue Software heraus, der Fachbereich testet die kurz und irgendwann wird es freigegeben und es landet dann beim Kunden. Und das heißt, im Zweifelsfall, wenn dann der Prozess eingeschlichen ist und gut funktioniert, bekommt der Kunde da draußen alle 14 Tage neue Funktionen.

Und das Problem ist, was sagt denn der Endkunde dazu?

Wenn man sich selber in so einem Unternehmen befindet und davon ausgeht, dass der Kunde ja mehr Leistung für dasselbe Geld bekommen, weil alle 14 Tage neue Funktionen, Erweiterungen und das wird alles besser und runder, Fehler werden schneller behoben, sollte man eigentlich meinen, dass der Kunde davon immer begeistert ist. Ist er aber nicht. Ich habe nämlich beobachtet, dass der Kunde, also der Endkunde, der nachher die Software dann wirklich benutzt, oft völlig aus dem Fokus gerät. Der Fachbereich arbeitet mit der IT und alle 14 Tage gibt es eine neue Version, man freut sich und es gibt wieder Anforderungen, man arbeitet die ab und man kommt in so einen Prozess und freut sich, dass eine Software an sich weiterentwickelt. Aber, dass der Kunde da draußen manchmal komplett überfordert ist, weil alle 14 Tage gibt es halt einfach neue Funktionen. Das kann man positiv sehen, zum Beispiel, dass Fehler auch schneller behoben werden, aber man kann es auch extrem negativ sehen. Weil, der Kunde da draußen muss sich im Zweifelsfalle alle 14 Tage, also, wenn man jetzt diesen Zyklus von 14 Tagen nimmt, gehen wir jetzt mal davon aus, alle 14 Tage mit neuen Funktionen auseinandersetzen. Da bekommt er vielleicht einen Newsletter und da gibt es dann eine neue Funktion. Und nicht nur neue Funktionen, sondern manchmal passiert es eben auch, dass Knöpfe plötzlich anders beschriftet werden. Also man hat irgendwie gelernt, damit zu arbeiten und plötzlich heißt der Knopf anders oder der Knopf ist woanders oder Funktionen bewerten plötzlich etwas anderes. Natürlich hat man dann dem Kunden irgendwann mal gesagt: “Schau mal, wir haben das jetzt geändert, das ist aber viel toller für dich, mache das jetzt so!” Aber, der Kunde da draußen, der nutzt diese Software ja nicht hauptberuflich. Und das ist nämlich genau das Problem. Die Softwarefirma an sich kreist um ihr Produkt, diese Software. Und die beschäftigen sich den ganzen Tag damit und finden das total toll, dass diese Software sich weiter entwickelt. Aber, vielleicht wird diese Software als Web-Dienst einfach nur für 9,95 € von irgendjemandem benutzt, der das zwei Stunden im Monat nutzt. Und wenn der dann im nächsten Monat wieder den Knopf suchen muss, der ihm jetzt Arbeit ersparen sollte eigentlich, führt das zu Unmut. Ihr kennt das wahrscheinlich auch vom Smartphone, dauernd gibt es neue Software-Updates, es kommen neue Funktionen rein, es werden natürlich auch Fehler behoben. Also ich sage mal, bei Sicherheitsupdates ist es klar, da geht es ja um die Sicherheit. Und wenn Sicherheitslücken gestopft werden, da muss man halt sehen, dass man möglichst schnell ist. Aber, die Frage, die ich mir nämlich stelle, ist es wirklich immer sinnvoll, alle Updates, alle neuen Funktionen, die man hat, so schnell wie es irgendwie geht, an den Kunden da draußen auszurollen? Also, wenn ein Kunde ja schon jahrelang damit arbeitet und dauernd irgendwie neue Funktionen bekommt. Weil, es kann ja durchaus auch noch ein anderes Szenario sein. Zum Beispiel eine Marketingagentur nutzt eine bestimmte Software für einen Webshop. Also, WordPress zusammen mit Ucommerce und da dann noch ein paar Plugins dran. Und diese Plugins werden dauernd verändert. Die Agentur hat diesen Job an einen Kunden verkauft, der Kunde vertreibt damit sein Business und jede Änderungen bei irgendeinem Plugin schlagen halt durch bis vorne an den Kunden dieser Marketingagentur und die haben dann dauernd Diskussionen. Weil der Kunde natürlich sagt: “Moment, meinen Leuten habe ich beigebracht, die müssen dann immer das ausfüllen und dann da auf den Knopf drücken, dann geht es weiter. Und jetzt ist der Knopf nicht mehr da, der heißt plötzlich anders oder hat plötzlich eine andere Funktion.” Und dahinter hängt ein riesiger Rattenschwanz. Jede kleine Änderung kann da draußen eine ganze Menge bewirken. Weil, Leute nutzen diese Software im Zweifelsfall in ihrer produktiven Arbeit. Und da muss es schnell gehen. Also das heißt, man ist es geübt, da eintragen, da klicken und weiter geht es. Und wenn das plötzlich nicht mehr so ist, führt das im Zweifelsfall wieder zu Verwirrung, man hat Diskussionen auf allen Ebenen, bei der Endkunde ganz am Ende, der diesen Webshop zum Beispiel nutzt, fragt dann bei seiner Marketingagentur nach, die ihm die Webseite gebaut hat und den Job und sagt: “Was ist denn da jetzt los, es funktioniert wieder nicht, ist alles kaputt?” Nein, ist natürlich nicht kaputt, sondern es funktioniert jetzt nur anders, weil die zugrundeliegende Software, dank Scrum und agiler Methoden wieder mal neue Funktionen eingebaut hat, andere Funktionen geändert hat, plötzlich einen Knopf umformatiert hat, irgendwo anders hingeschoben. Das hört sich für IT-nahe Leute jetzt, wenn ihr mir zuhört, ein bisschen vielleicht abstrus an. Du sagst jetzt: “Ja, ist ja klar, ich meine, ich weiß ja, der Knopf ist jetzt anders, der hat jetzt eine andere Funktion.” Ja, wenn man sich damit immer beschäftigt, weiß man das. Wenn man aber mal eben schnell schnell sich damit auseinandersetzt, weiß man das vielleicht nicht. Also, in dieser Folge wollte ich eigentlich nur mal darauf hinweisen, dass agile Methoden nicht immer die Lösung von allem ist. Die interne Zusammenarbeit zwischen IT-Bereichen oder Softwareentwicklungsbereichen und Fachabteilungen wird dadurch häufig verbessert. Aber denk doch mal an den Endkunden, der die Software ganz am Ende da draußen benutzen muss. Und der ist ja nicht alle 14 Tage involviert und guckt sich an, was gibt es denn da Neues, wie muss ich es jetzt benutzen, sondern im Zweifelsfall loggt der sich mal alle drei Monate mal ein und stellt dann fest, irgendwie geht es jetzt anders, als ich vorher erwartet hatte. Also meine Bitte an alle, die an einer agilen Softwareentwicklung beteiligt sind: Denkt bei der Entwicklung doch öfter an den Endkunden, also den, der die Software und das Produkt in seinem Alltag wirklich nutzt. Ist es wirklich immer sinnvoll, jedes schnelle Update an den Endkunden auszurollen oder ist es vielleicht auch mal sinnvoll, zwar intern schnell agil alle 14 Tage neue Versionen zu erzeugen, dann aber gebündelte Versionen vielleicht nur alle drei Monate oder alle sechs Monate an den Kunden herauszugeben. Mit einer wohl dokumentierten Änderung. Dass man sagt: “Schau mal, das ist unsere Version so und so. Vor sechs Monaten hast du die benutzt, bei den letzten sechs Monaten hast du die benutzt, diese Änderung wird es jetzt geben. Da könnt ihr euch jetzt noch vier Wochen darauf vorbereiten und dann ist es anders.” Das mag ein Szenario sein, das Einzige was ich mit dieser Folge erreichen will, wenn ihr in der Softwareentwicklung arbeitet oder in Softwareabteilungen oder in der Produktentwicklung arbeitet, denkt doch mal drüber nach: Will euer Endkunde wirklich so schnell immer Änderungen haben, wie ihr sie erzeugen können?

Ich würde mich freuen, wenn wir dazu in eine bestimmte Diskussion kommen und ihr einfach mal euch überlegt, ist es bei mir im Unternehmen genauso oder, was sagen meine Kunden dazu. Fragt die doch einfach mal. Ich persönlich würde mich freuen, wenn wir darüber diskutieren. Schickt mir doch einfach mal eure Rückmeldung an Podcast@ihre-kundenbrille.de. Ich hoffe, ihr habt meinen Grundgedanken verstanden, könnt den nachvollziehen und vielleicht verändert er ja etwas euren Blickwinkel auf eure Kundschaft und was die mit euren schnellen Vorgehensweisen sozusagen auszubügeln hat. Na ja. Mir hat es Spaß gemacht, ich freue mich auf eine rege Diskussion und sage mal bis bald