Skillbyte Podcast #23: Individualsoftware zügig und kostengünstig entwickeln

Willkommen zum Skillbyte-Podcast! Skillbyte ist Ihr Partner für digitale Exzellenz.

In diesem Podcast geht es um das Thema: Individualsoftware zügig und kostengünstig entwickeln

// Inhalt //
00:36 - Intro Markus Roth von expeso.de
01:25 - Beispiele für die Digitalisierung von Unternehmen
03:50 - Strategische und technische Themen
06:15 - Das Dreieck des Projektmanagements - Zeit, Kosten, Funktionalität
08:36 - Wie funktioniert Agilität?
14:45 - Product Owner ist die zentrale Schnittstelle
18:04 - Wie sollte der Kunde ein neues Projekt mit Erfolgskurs aufsetzen?
22:27 - Zusammenfassung: Vorteile des Agilen Vorgehens
25:32 - Kurzfristige und regelmäßige Software-Lieferung steigert Nutzerakzeptanz
26:27 - CI/CD als Toolunterstützung für zügige Softwarelieferung
30:10 - Zusammenfassung: Agile Entwicklung für Individualsoftware
31:00 - AHA Effekte aus realen Projekten
35:54 - Kontakt zu expeso

Informationen zu expeso finden Sie unter https://www.expeso.de

Das Whitepaper "6 Schritte für Ihren Projekterfolg" finden Sie hier https://www.expeso.de/service

Abonnieren Sie diesen Podcast und besuchen Sie uns auf https://www.skillbyte.de

Feedback und Fragen gerne an podcast@skillbyte.de

AUTOMATISCH ERZEUGTES TRANSKRIPT

Herzlich willkommen zu unserem Skillbyte Podcast Episode 23! Das Thema heute lautet Individual Software zügig und kostengünstig entwickeln. Abonniert unseren Podcast für mehr spannende Themen aus dem Technologie Umfeld. Und wenn ihr Fragen habt, sendet uns gerne eine E-Mail an Podcasts. Lasst uns doch gerne eine Bewertung ab. Ich bin heute hier mit Markus Roth, und ich freue mich super, dass du Zeit gefunden hast. Hallo Markus, erzähl uns doch kurz ein paar Eckpunkte über dich, das unsere Zuhörer wissen, was du machst und warum du der richtige Ansprechpartner bist.

Individual Software?

Ja, schön, dass ich heute hier sein darf. Ich bin seit fast 20 Jahren in der Softwareentwicklung tätig und berate mittlere und große Unternehmen. 2008 habe ich dann die Expo GmbH gegründet. Unser Schwerpunkt ist die Entwicklung von Anwendungen für Unternehmen und Apps für deren Kunden. Kurzum all das, was man heutzutage unter der Digitalisierung von Unternehmen zusammenfasst.

Wir haben uns ja selber auch bei großen Kunden kennengelernt und sehr schätzen gelernt, haben auch viele Jahre mittlerweile zusammengearbeitet, immer mal mehr, mal weniger, meistens bei dem gleichen Kunden. Und das Thema Digitalisierung oder auch digitale Transformation ist ja ein abstraktes Konzept, unter dem jeder sich ein bisschen was anderes vorstellt. Vielleicht möchte du ein bisschen konkretisieren, was genau du unter der Digitalisierung von Unternehmen verstehst.

Digitalisierung ist ja ein sehr vielfältiger Begriff. Darunter versteht man zum Beispiel auch die Versorgung auf dem Land und die Infrastrukturausbau von Digitalisierung und Unternehmenssprecher. Dann geht es typischerweise darum, Geschäftsprozesse beschleunigen die Zusammenarbeit von Teams zu verbessern, aber auch neue digitale Angebote für Kunden zu schaffen. Zum Beispiel? Wir waren mal bei einem Chemiekonzern im Einsatz. Da haben wir Investitionsplanung neu konzipiert. Da ging es im Endeffekt darum, dass die Abteilung Projekte, die wir für das kommende Jahr geplant haben, ein Volumen von mehr als 100000 Euro hatten, Extremisten geplant hatten.

Die nächsten wurden dann auch die nächsthöhere ebene Ebene zusammengefasst. Dort kamen also mehrere Exel, wurden zusammen kopiert. Dann wurde auf dieser Ebene miteinander gesprochen, was dann umgesetzt werden soll.

Man hört, es ist ein sehr komplexer Prozess mit vielen Medien, Brüchen, und der geht durch viele Hände. Ja, das ist ganz natürlich, dass da sehr viele Fehler passieren können, wenn viele Menschen daran beteiligt sind und die Datei wahrscheinlich immer wieder auf uns geklickt wird, durch unterschiedliche Abteilungen wandert.

Genau das war also ein sehr manuell intensiver Prozess, aber auch am Prozess. Daraufhin haben wir eine internetanwendungen entwickelt, mit der die Abteilungen ihre Projekte planen kann. Dann gab es einen festen Stichtag, der konsolidiert wurde, bereits weiter betrachtet wurde, konsolidiert wurde, bewertet wurde. So ging das über vier, fünf Stufen bis nach oben abschließenden Bewertung. Das heißt, der Kunde hat natürlich dadurch Zeit eingespart, weil wir einfach beschleunigt wurden, weil die Zusammenarbeit der Abteilungen beschleunigt wurde.

Genau, aber auch ein anderes Beispiel. Ein Beispiel Für einen Energieversorger haben wir eine Kunden App entwickelt. Vielleicht bekommt es einmal im Jahr eine Postkarte, in der du deinen Zählerstand eintragen soll. Da haben wir eine App entwickelt, wo du in den Keller gehen kannst. Und statt im dunklen Keller mit Vogelschwärme irgendwie ein Zählerstand abzulesen, kannst du einfach den Zählerstand abfotografieren und hochladen. Das spart natürlich als Kunde dann wahnsinnig viel Arbeit, weil es komfortabler einfach im Unternehmen sparen.

Viel Arbeit, noch mehr in der total nachvollziehbar, dass man jeder hat ein Fotohandy und kann quasi den Zählerstand selber beweisen oder auch abschreiben und dann an den Energieversorger übermitteln. Genau das heißt Die Digitalisierung aus deiner Sicht hat jetzt zwei konkrete Anwendungsfälle genannt, hat eine strategische Komponente. Du hast jetzt gerade angesprochen. Die Komponente Der Prozess Verbesserung. Und wie siehst du das mit technischen Themen? Die Technologie treibt ja auch diese Entwicklung vor sich her. Zum Beispiel der Wechsel von physikalischer Server Hardware in Richtung Virtualisierung war vor einigen Jahren ein Trend.

Mittlerweile gehts in die Cloud.

Genau. Der technische Fortschritt ist natürlich ein wesentlicher Treiber. Beispielsweise haben wir ein Tool entwickelt für Journalisten, die im Feld sind und Videoaufnahmen machen und bereitstellen. Medien-Unternehmen. Und die App entwickelt, haben diese Video automatisch hoch zum Unternehmen. Wo führt diese Videos dann automatisch ein? Das sind natürlich Dinge, die dann technologische Weiterentwicklungen hier an der Stelle erhöhter mobile Bandbreiten und mobile Datenvolumen ausnutzen. Auch andere Beispiele wie Power Skalierbare Resources klaute Umgebung aber. Intelligenz Daten getriebener Geschäftsmodelle einfach super spannend Auf vielen, vielen Ebenen passiert was und ich bin immer ganz begeistert, dass wir bei der Entwicklung dabei sein dürfen oder ganz hautnah dabei sein dürfen.

Ja, auf jeden Fall sehr spannende Zeiten. Jetzt ist der Titel Individual Software zügig und kostengünstig. Entwickeln wir ein bisschen ein Widerspruch? Weil normalerweise gilt ja die Gleichung Wenn ich schnell eine kostengünstige Lösung haben möchte, um ein Problem oder ein Prozess zu digitalisieren, dann nehme ich Standardsoftware und passe diese Standardsoftware, die schon existiert, an mein Unternehmen an oder an meinen Prozess an. Oder ich sage Okay, es gibt keine Software oder die Software passt nicht für mich hier am Markt verfügbar ist.

Ich muss eine eigene Software Individual Software entwickeln, die natürlich länger dauert, oder? Die Entwicklung dauert wesentlich länger von Individual Software. Jetzt hast du ja das Versprechen, Individual Software zügig zu entwickeln. Unsere Zuhörer kennen vielleicht das Dreieck des Projektmanagements, also diese Beziehung zwischen Zeit, Kosten und der Funktionalität. Und dass man nicht alles drei auf einmal bekommen kann. Man bekommt immer zwei Punkte, kann sich innerhalb dieses Dreiecks bewegen, aber alle drei Eigenschaften kann man eben nicht gleichzeitig bekommen.

Die Quadratur des Kreises sozusagen.

Das ist eigentlich ein gutes Beispiel des Projektmanagements Pasten. Drei wesentliche Grundprinzipien sind zum einen das Budget, der Zeitpunkt, im anderen der Umfang, der liefert werden soll. Und wenn du das Budget kürzt, dann weiß jeder Sofort musst auch irgendwo am Funktionsumfang Abstriche machen, damit es wieder zusammenpacken. Oder wenn du neue Anforderungen hast, dann erhöhte typischerweise das Budget. Ja, was. Aber in meiner Erfahrung ist es tatsächlich dieser Aspekt. Und dann kann ich mehr benutzen, ob noch nicht.

Bei meinen Kunden habe ich die letzten zehn, fünfzehn Jahre immer wieder bewahrheitet. Das sitzt beim Kunden und erfragt dann Bis wann kann ich das denn haben? Diese Ungeduld, der Funktionsumfang ist oft verhandelbar. Es gibt immer Anforderungen, die man auch später umsetzen könnte. Im Rahmen der Wartung der Erweiterung. Aber dieses ungeduldige bis man kann nicht sein. Da steckt ja im Endeffekt noch mehr dahinter. Ja, wenn ich diese Software habe, dann habe ich einen Nutzen davon.

Dann kann ich etwas erreichen. Ich möchte ja ein Ziel erreichen. Und das ist ein Punkt, mir ein roter Faden durchzieht.

In der Führungsebene werden natürlich Zeitpläne erstellt, wo Investitionsvorhaben dran geknüpft werden. Und dann möchte man immer wissen Für wie viel bekomme ich was wann? Das sind die klassischen Fragen. Und es ist auch meine Erfahrung, dass oftmals bereits im Kick off gefragt wird Okay, wann ist es denn fertig? Also alle Anforderungen liegen quasi noch im Nebel, und man kann das noch gar nicht genau beschreiben. Und dann wird oftmals nach einem Release-Termin gefragt.

Genau das haben wir entsprechend aufgenommen. Da bietet die agile Softwareentwicklung natürlich auch die entsprechenden Mittel dazu. Schnelle Nutzen kurzfristige Lieferung der ersten Version gestellt haben. Im Endeffekt habe ich mit der Entwicklung regelmäßige, integratives. Alle paar Wochen bekomme ich dann eine neue, die ich sofort nutzen kann, die auch mir sofort einen Mehrwert, wenn vielleicht erst wenige Prozesse umgesetzt sind. Aber die wichtigsten Prozesse werden umgesetzt. Und ich habe sofort einen Nutzen und das Versprechen Wir entwickeln unseren Kunden kurz Apps, die Anwendungen für deren Geschäftsprozesse Kunden leisten.

Das setzt natürlich voraus, dass der Kunde sehr genau priorisiert und sagt, was denn wirklich das Kern Leistungsversprechen der Anwendung ist. Welche entwickelt werden soll und dann wie die Zwiebel weitere Funktionen drumherum schichtet, damit man dann die Komponente nach und nach ausbauen kann.

Genau. Im Endeffekt werden die Anforderungen im sogenannten Backend. Man hat als Sammelbecken aller Anforderungen in der agilen Entwicklung bekannt. Das ist das wesentliche Element. Wenn du nicht mal ein Backup erreichen, möchte man natürlich, Schwierigkeiten beim Ziel anzusteuern.

Das heißt, im Back Lock sammle ich erst einmal alle Anforderungen, vielleicht mit einer groben Priorisierung. Und dann? Das ist ja das Prinzip der Agilität. Setze ich die einzelnen Sprints auf, wenn man so möchte? arbeitspakete Ich kenne. Ein normaler Sprint dauert ungefähr zwei Wochen. Es gibt Teams, die machen einwöchige Sprints, oder ich hatte auch schon dreiwöchige Sprints und nimmt die jeweils wichtigen Elemente mit in einen Sprint. Und das Ziel ist es, dass es je nach Sprint, Ende oder an jedem Sprint Ende immer eine Software Komponente geliefert wird, die in sich geschlossen funktioniert.

Vielleicht nimmt man jetzt mal die ersten zwei, drei Sprints raus, weil da muss ja offenbar Infrastruktur bereitgestellt werden. Setup Genau. Aber das dann die Software sozusagen immer funktioniert beim Sprint. Ein inkrementelle hat, was eingesetzt werden kann. Genau im Endeffekt hat das Vorgehen auch verschiedene Vorteile für den Kunden. Wir haben jetzt den Prozess beschrieben. Wir haben das locker als Sammelbecken wiederholen, denn wir haben am Ende alle zwei Wochen an einer neuen Software. Daraus ergeben sich verschiedene Vorteile.

Vielleicht kann man sogar Amtsbeginn abgeben. Zu Beginn Ich nehme die wichtigsten Anforderungen aus dem Backend ab. Das sind die, die oben im Weg stehen. Das sind die wichtigsten, den höchsten Nutzen für den Kunden, neudeutsch Optimismus genannt. Der vergibt die Priorität. Die Priorität wird vom Kunden, und zwar in der Person des Produkt, vergeben. Ohne Manage und ohne ist dafür zuständig, die Anforderung zu formulieren. Die Anforderung in diesem Block zu formulieren, gegenseitig abzuwägen und priorisieren und zu bewerten.

Auch zwei Anforderungen, die vielleicht im Widerspruch stehen oder die in der Dringlichkeit miteinander ringen, wer denn jetzt tatsächlich mächtiger ist. Und so haben wir dann dieses Back lock, in dem nistete Anforderungen dargestellt wird, in der Reihenfolge der Umsetzung. Und wir wissen immer Wenn wir Sprintstar. Nehmen wir die Anforderung mit dem höchsten Wert, und diese werden in den nächsten zwei Wochen umgesetzt, so dass wir dann am Ende tatsächlich auch schon eine funktionierende Version haben, die wir einsetzen können und nicht monatelang warten müssen, bis wir tatsächlich unsere Software oft erst nach einem halben Jahr bekommen.

Außerdem minimieren wir natürlich auch das Risiko beim Kunden, weil er sie sofort nutzt. Diese Software kann wir nutzen. Er kann Feedback geben. Er kann es sich anders vorgestellt, hat eine Burghard kombinieren und kann über die Schiene natürlich auch steuern. Ein anderer Aspekt ist oft Anforderungen wandeln sich häufig einfach in seinem Unternehmen. Es gibt neue Antworten, und es gibt neue Zielsetzungen des Vorstands. Es gibt Entwicklungen auf dem Markt. Es gibt Gesetze, Gesetze, die einiger Zeit genau in im Moment agieren muss.

Stell dir vor, du steuert ein Ziel in einem Projekt an, und dieses bewegt sich jetzt plötzlich durch neue Anforderungen leicht nach links oder rechts. Und jetzt, in der agilen Vorgehensweise, kannst du natürlich alle zwei Wochen nachsteuern, den nächsten Sprint starten. Neue Anforderungen werden einfach im Back Lock dynamisch während der Projekten können eingegeben werden. In dieses Backnang verdrängen vielleicht andere Anforderungen, die weniger wichtig werden. Oft ist es auch eine Feststellung im Projekt Verlauf, dass man merkt Oh, was haben wir uns damals gedacht, das ist doch eigentlich gar nicht mehr so wichtig.

Und dann kann man auch andere Anforderungen Ossenberg locker nehmen. So kannst du einfach regelmäßig ändernden Anforderungen gerecht werden, in dem du neu strukturiert, neu priorisiert neue Anforderungen aufflogen.

Das heißt, für den Endkunden ergeben sich zwei Vorteile a dass er fortlaufend während dem Projekt neue Anforderungen kippen kann, ohne dass ein Change ist, sondern dass das die Prioritäten neu gesetzt werden können. Und er hat alle zwei Wochen oder nach jedem Sprint Ende sozusagen ein Software inkrementelle, eine funktionsfähige Software, die umgesetzte funktionsfähige Lokaltermin. Bis zu diesem Zeitpunkt erhält. Und dadurch kann er fortlaufend steuern und kontrollieren. Reicht mir das schon? Oder ist die Software wertvoll? Genau.

Im Gegensatz zum klassischen Wo du siehst, machen bekommen kannst du hier schon sehr. Auch die anschauen und eingreifen und vertrauen, Lieferanten aufbauen und Nutzer das schon testen lassen?

Genau.

Man entwickelt ja eine Software, wenn man glaubt, ein Wert zu schaffen. Ob dieser Wert sich tatsächlich dann einstellt bei den Benutzern? Genau.

Und wenn wir zurückgehen auf das Dreieck des Projektmanagements. Durch die regelmäßige Lieferung haben wir dementsprechend diese Zeit Aspekts dadurch erreicht, dass wir alle zwei Wochen eine Lieferung haben. Und wenn du dir im Reich des Projektmanagements Budget Komponente die Komponente anschaut, auch an der Stelle fest, weil wir einfach zu Anfang wissen Okay, wir machen dieses Jahr, hat 52 Wochen, machen wir 26 Sprints, da kannst du ganz genaue budgetieren. Was kostet das? Und du hast jetzt nicht im Ansatz Budget, weil irgendwelche Quests kommen?

Klar, die ein oder andere Anforderungen, die vielleicht unwichtiger ist, verschiebt sich auch im nächsten Jahr in die Weiterentwicklung, in die Wartung oder auch entfällt Ganze. Und von der Seite ist diese Budget Sicherheit natürlich auch eine ganz, ganz wesentliche Komponente der Unternehmen.

Okay, also, man hat Kontrolle direkt an drei Stellen sozusagen. A Was ist meine Priorität? B Was erstellt worden und c Habe ich volle Kostenkontrolle, weil ich immer in diesen kleinen Schritten in den Sprints gehe. Mal eben schon vom Product Owner gesprochen, der die Priorität oder der Projektverantwortliche, der die Priorität der Back lock Items festsetzt, natürlich auch in Abstimmung mit dem Fachbereich und den Entwicklern. Der ist quasi die zentrale Schnittstelle. üBer ihn laufen die zentralen Projekte, Informationen, damit er immer bewerten kann Was ist denn jetzt das Wichtigste?

Und was muss getan werden? Fallen hier noch Punkte ein, die der Product Owner bewerkstelligen muss oder wo er eine zentrale Rolle einnimmt?

Ich möchte auf jeden Fall noch einmal verstärken. Oder ist hier an der Stelle eine der zentralen Figuren in Polk Steuern, weil der Bewährte, der dafür sorgt, genau das Richtige umgesetzt wird? Und er hat ja verschiedene Möglichkeiten, wie er damit umgehen kann oder wie er das verlieren kann. Das ist natürlich eine klare Kundenorientierung. Baden ist das Wichtige. Und welchen Nutzen schaffe ich? Wie kann ich für mein Unternehmen als Auftraggeber maximieren und damit auch eine Fokussierung auf den Kunden eingehen?

Nun ja, was muss ich dafür tun, dass verschiedene Sachen? Er muss zum Beispiel ordentlich belegen, verständliche, transparente schreiben, erklären, was erreicht werden und umgesetzt werden. Er muss aber auf der anderen Seite auch entwicklungsziel annehmen und deren Beantwortung akzeptieren lernen, Eigenverantwortung akzeptieren. Entwicklungsteam sagt mir am Anfang. Was sind die wichtigsten Anforderungen und sagen Okay, wir können drei, vier aufnehmen. Aber der fünfte Punkt in deinem Backnang, den schaffen wir einfach nicht. Und da muss er auch akzeptieren, dass jedes Team sagt Wir schaffen das nicht, weil in dem Moment, wo er sagen würde, ich brauche den fünften Punkt auch noch, nimmt er die Verantwortung mit dem Team weg, und die Verantwortung hängt nachher wieder bei ihm.

Wenn das nicht erfolgreich war, weil das Team stellt sich dann hin und sagen Ja, wir haben es ja gleich gesagt. Wenn aber du das Team akzeptierten, sagt Okay, die schaffen nur die drei oder vier Black Lock. Dann haben die natürlich auch so eine Motivation, das auch wirklich umzusetzen. Dann hatten wir auch ein entsprechendes Commitment, also verschiedene Dinge ganz, ganz wesentlich Einfluss auf den Erfolg hat.

An meiner Erfahrung ist es auch eine ganz zentrale Rolle, und er wächst auch mit dem Team zusammen. Natürlich ist er Mitglied. Ich denke, es ist noch einmal wichtig zu erwähnen, dass Unternehmen nicht den Fehler machen sollten und glauben, das ist eine Rolle, die nebenher erledigt werden kann, sondern das ist ein Fulltime-Job. Viele, viele Fragen, die sich beim Pliening ergeben, muss klären Was ist jetzt wirklich wichtig? Die Prioritäten abklären. Und es ist eine sehr kommunikative Rolle, sowohl in Richtung des Teams als auch in Richtung der anderen Stakeholder genau Gewerk im Unternehmen, die betroffen sind oder die Anliegen dran haben.

Und es ist auch eine sehr fordernde Rolle. Auf gar keinen Fall sollte man einen Fehler machen und sagen Okay, dass irgendein Projektmanager kriegt das auch noch mit und macht das so nebenher schon. Das ist schon sehr verantwortungsvolle Position, auch eine, die viel Arbeit erfordert und viel Kommunikation erfordert. Jetzt haben wir ja einige Vorteile schon genannt. Wenn wir jetzt mal aus deiner Sicht schildern, sollte es Ein Kunde spricht dich an und sagt Markus, ich würde gerne ein Projekt aufsetzen, was natürlich ein Erfolg werden soll.

Was würdest du ihm raten? Oder wie würdest du ihm sagen, dass das ein Projekt aufsetzen soll, das ja quasi von Anfang an möglichst viele Fallstricke umschifft und direkt den Erfolgskurs setzt?

Im Endeffekt ist die Vorgehensweise bei einem agilen Projekt eigentlich nicht viel anders als bei einem klassischen Projekt. Vielleicht zeige ich dir mal, wie wir das typischerweise machen, wenn wir so eine Anfrage beim Kunden bekommen. Erstgespräch klären wir typischerweise die Situation beim Kunden. Also hat man schon seine Vision, seine Ziele formuliert. Weiß er eigentlich, was er erreichen möchte? Denn diese Ziele sind natürlich auch so eine Art Kompass, ein Projekt, jede Entscheidung zu treffen. Das kannst du natürlich viel besser.

Diese Entscheidung treffen, wenn du weißt, welches Ziel zu erreichen. Weiterer Punkt, was natürlich auch nicht vernachlässigen wir Papst sind. Die anderen Punkte müssen bekannt sein. Projekt und Inhalt muss klar umrissen sein. Diese Vision, Ziele, Projekten handelt dieser typische Rahmen die Leitplanken eines Projekts. Nächster Punkt Was wir klären, sind die Anforderungen schon klar, und das sind alles Gute natürlich, die der Kunde auch selbst vorab bearbeiten kann, wo er Klarheit schaffen kann, ihn aber auch unterstützen könnte.

Dabei müssen wir auch einen Workshop anbieten, wenn es wichtig wäre, wenn der Kunde da Bedarf an Unterstützung braucht. Was sind notwendige Schnittstellen zu anderen Systemen, die da gemacht werden sollen? Wir können den Workshop an der Stelle gerne anbieten. Wir haben aber auch dazu auf unserer Homepage ein weiblicher Zuhörer gerne kostenlos downloaden können. In sechs Schritten zu Ihrer erfolgreichen Individual Software haben wir im Endeffekt diese typischen Punkte aufgezählt. Das ist auch gar nicht so viel anders als bei klassischen Projekten.

Ich glaube, im Anschluss wird es eigentlich schon spannend, wenn ich die Anforderungen analysiert. Die unterscheidet sich gegenüber klassischen Projekten. Da bieten wir weder entsprechende Workshops zu Project Klärung an. Was muss ich denn machen, damit dieses Projekt nachher erfolgreich ist? Endeffekt ist das Ergebnis dieser Workshop Dokumentation der Ziele eine Klarheit im Projekt, die der Kunde auch verwenden kann, um an Bord zu holen, um interne Kommunikation entsprechend zu steuern. Aber ob man sie Budget zu beschaffen und zu überzeugen, dass eine gute Investition?

Ihr helft dem Kunden wirklich aus. Ich sage mal einigen Ideen oder vielen, vielen Ideen, so ein Projekt Paket heraus zu schnüren und zu sagen Okay, das ist realistisch, das sind die Anforderungen. Und dann in Workshops er mit dem Kunden zusammen hin und setzt das Projekt organisatorisch so auf, dass es schon ein Erfolg wird, weil ihr einfach wisst, das und das sind die Kriterien, die wir brauchen, oder die Informationen, die wir brauchen, damit es als agiles Projekt durchgeführt werden kann.

Genau zu Anfang hast wir auf die Situation in Kunden, das war ganz, ganz viele Ideen im Raum stehen. Und dann die Frage Wie gehen wir eigentlich an, wie sortieren wir? Doch irgendwas ist vielleicht auch nicht der zentrale Punkt. Damit man überhaupt starten kann. Wir Kunden gerne klären. Was sind die Anforderungen an die wichtigsten Anforderungen, die du so genannte Apax, aber auch Priorisierung dieser Epiktet eine der wichtigsten Anforderungen an eine Vertiefung der ersten wichtigen Anforderung erfüllt hat?

Ob man irgendwann in einer vollständigen Art und Weise man kann aber auch schon eine erste Einschätzung machen, eine Projektplanung oder auch an der Stelle dann wirklich die Badesachen, dieses Projekt zu starten.

Also wirkliche Projektentwicklungen von der Idee bis zum Projekt aufsetzen. Und das ist ja supercool wie bei Skorbut. Wir gehen ja erst sozusagen. Wir helfen den Kunden natürlich auch dabei. Aber wir sind wirklich Technologie, Dienstleister und spezialisiert auf verschiedene Technologien und kommen oft ein bisschen später erst spielen. Schön, dass wir dem Kunden sozusagen helfen, ein eigenes Projekt direkt auf Erfolgskurs zu bringen.

Ja, wahrscheinlich seid ihr oft auch in der IT-Abteilung auf ihr Projekt. Wir haben dann auch Business Entscheider mit am Tisch und sind in einer Phase, wo man noch mal ein Tür stadien. Das Projekt kommt bei uns auch vor.

Aber ja, die Spezialität von Skiba ist auf jeden Fall die Technologie, Kompetenz und dann auch die Umsetzung. Du hast es im Verlauf schon erwähnt. Es gibt ein klassisches Projekt Vorgehen, was sehr starr ist und die so neu ist das agile Vorgehen jetzt auch nicht mehr. Gibts ja schon seit zehn Jahren. Ja, eher schon länger, ja schon intensiv gepusht. Vielleicht möchte ich nochmal genau sagen, worin die Vorteile genau liegen. Das Agieren Vorgehensweise ist jetzt schon umrissen.

Aber vielleicht kann es das noch mal so griffig zusammenfassen, das agile Verfahren es natürlich schon seit über zehn Jahren, sieht aber tatsächlich in dem einen oder anderen Unternehmen jetzt ein Zustände weiterzuverbreiten in den Unternehmen. Im Endeffekt. Agilität zielt darauf ab, immer nur das Wichtige zu tun. Wieder der Vergleich Klassische Projekte schreiben die Pflichtenheft agil, skizzieren jetzt alle Anforderungen und die wichtigsten Patience. Aber nur die wichtigsten kreative ich heute. Ich arbeite nur an dem, was mir heute Wert bringt.

Das Ganze natürlich auch das Risiko des Kunden. Der Kunde muss nicht heute die klassischen Entscheidungen über das Gesamtprojekt strecken, sondern startet vielleicht erst mal mit einem Kundenkonten, mit einem überschaubaren Budget und anschließend? Vielleicht muss Beauftrage man mal die erste Version umsetzen. Er kann jederzeit eine neue Entscheidung treffen, er kann jederzeit eine Korrektur Filmprojektor. Und auch wenn noch an die Einführung des Projekts denkst. Typischerweise entwickelt es klassisch mehrere Monate, bis man geliefert bekommt. Dann macht einen Big Bang Einführung alles auf einen Schlag.

Alle Länder müssen geschult werden, alle Prozesse auf einmal geändert werden, und Agile machen es einfach so Nimmst dir den ersten wichtigsten Prozess vor. In kleinen Schritten setzt du diesen um, hast dann vielleicht mal erst mal eine Anwendung. Kube Eine Abteilung Prozess. Dann kannst du natürlich auch das Unternehmen nicht hier an den Rand des Wahnsinns bringen, weil du alles auf einmal ändert.

Ich glaube auch, dass dieses Vorgehen immense Vorteile mit sich bringt. Denn das ist in meiner Erfahrung gewöhnen sich auch die Nutzer der Anwendung sozusagen dann daran, dass sie regelmäßig alle zwei Wochen drei Wochen neue Funktionen bekommen und dass sich die Software immer ein bisschen ändert und weiterentwickelt. Dadurch hat man meinen Kennt das vielleicht von den Apps, von dem eigenen Handy. Man macht ein Update, dann sieht alles ein bisschen anders aus. Aber mittlerweile ist man dran gewohnt, und es ist gar nicht mehr so ein großer Bruch.

Wenn da jetzt ein neuer Button erscheint oder eine neue Funktion erscheinen. Und du nimmst die Leute viel besser mit dadurch, dass sie sich an diesen kontinuierlichen Veränderungsprozess gewöhnen. Dann auch wirklich sehen Oh, ich habe vor einem Monat beispielsweise eine Anforderung gekippt und die wurde mittlerweile umgesetzt. Und jetzt hilft mir das, und meistens kriegst du dann ja ein Feedback. Wenn ihr das und das noch automatisiert, dann wird es noch schneller gehen. Und dann hast du diesen Zyklus, diesen Rückkopplungen Zyklus einmal wirklich durchlaufen und hast die Leute sehr schnell auf deiner Seite oder die Endanwender sehr schnell auf deiner Seite, weil die wirklich merken, wenn ich hier was sage und meine Meinung Komtur, dann bringt es auch etwas und die Software verbessert sich wirklich, das ich meinen Job besser erledigen kann oder ganz neue Prozesse anstoßen kann.

Das ist auch ganz wichtig nach den Projekten Erfolg und Akzeptanz. Wenn du hier regelmäßig auch tatsächlich liefern kann und Verbesserungen liefern kann, noch mehr Vertrauen schaffen und du merkst Okay, da tut sich was. Und da hast du natürlich dementsprechend auch das Vertrauen in die Akzeptanz auf allen Ebenen.

Das hilft auch, dem Projekt ONA oder dem Projektverantwortlichen neues Budget einzuwerben beim Vorstand, wenn man sieht Okay, jetzt haben wir hier. Mit dem Budget haben wir die erste Stufe geschaffen. Aber ihr wisst ja, wir haben noch Stufe 2 und 3, und das müssen wir jetzt nochmal nachlegen. Aber wir haben ja schon was geliefert. Und dadurch nimmt man a auch den Entscheidern ein bisschen die Angst, dass man sagt Ja, das ist aber schon aufwendig.

Genau kann man mit Recht das in kleinere Stücke runter vertrauen, dann Lieferanten und weitere Auftraggeber und Auftragnehmer.

Natürlich habe ich aber doch noch ein technisches Thema Wodkas, und zwar damit es funktioniert. Das man wirklich alle zwei Wochen oder nach jedem Spendende wirklich Software liefern kann, ist ja ein relativ hoher Grad an Automatisierung notwendig, das die Entwickler nicht immer ein riesen Release bauen müssen, sondern die neuen Funktionen nach und nach inkrementelle in den Produktionsprozess eingeführt werden können. Typischerweise spricht man davon, dass die die Pipeline Continuous Integration oder Continuous Delivery um den neuen Code produziert wird. Meistens ist es softe Code automatisiert zu testen, automatisch fertige Releases zu bauen und diese dann auch direkt auszurollen.

Genau. Die Automatisierung ist eigentlich eine wesentliche Voraussetzung, damit du überhaupt diese kurzen iterativen leisten kann. Manuell ist aber eigentlich nicht mit System, was regelmäßige Aufgaben, die gebaut werden muss, getestet werden. Die Software muss ausgeliefert werden. Da hilft natürlich eine Automatisierung auf verschiedenen Ebenen. Du kannst automatisiert mit Schenkens, das heißt, jedes Mal, wenn neuer Quellcode eingecheckt wird, das Quellcode Repository dann automatisch ein sogenannter Quellcode Laubsäge Software erstellt, der vielleicht auch automatisch Tests laufen lässt, um die Qualität zu beweisen.

Du kannst nachher auch automatisiert diese neue Software dann den Kunden bereitstellen, Stellen testen, Infrastruktur und natürlich die Anwendung auch beim Kunden, im Rechenzentrum oder in der Cloud installiert und betreibt. Das wird bei euch ähnlich sein wie das bei uns. Wir machen das Ganze mit Java aus. Gut für die Server. Anwendungen für das Frontend haben wir beispielsweise Engeler, und das sind alles bewährte, frei verfügbare Technologien. Der Kunde hat dementsprechend auch keine Technologie, Abhängigkeiten, und das Ganze funktioniert auch sowohl auf dem Desktop, aber auch auf dem Smartphone, so dass der Kunde an jedem Ort und jederzeit auch mit der Anwendung arbeiten kann.

Aber ich will die Automatisierung vielleicht noch einen Schritt weiter, nämlich nicht nur hier in der Entwicklung automatisieren, sondern es hat natürlich auch wieder für den Anwender in Unternehmen einen Wert. Wenn du auch mit Schnittstellen die Datenweitergabe automatisiert, hast du keine Daten. Wir haben da jetzt Laptops für einen Kunden, einen Prozess automatisiert heißt automatisiert Wir haben die Schnittstelle bedient. Daten, die an der Stelle übergeben werden von per App, werden automatisiert in das Managementsystem übergeben. Das war früher ein Prozess, der von Hand geliefert wurde, wird von Hand gelebt, wurde das heißt, da wurden Daten per E-Mail angelegt, hatten wir machen und dann manuell abgetippt.

Und heute gibt der Lieferant die Daten sofort in der web-anwendung ein und die Schnittstelle direkt und sofort. Das Entscheidende sofort und fehlerfrei. Das Managementsystem über das Thema Automatisierung hilft am besten natürlich auch durch Schnittstellen. Die Automatisierung der Daten zwischen den Anwendungen.

Jetzt ist es ja so, dass noch nicht alle Kunden so eine Pipeline, wie wir sie gerade beschrieben haben, haben. Könnte die auch Kunden helfen, die selber auch aufzusetzen? Im Projekt?

Klar. Zum einen übernehmen wir natürlich am liebsten das vollständige Projekt. Aber wir unterstützen natürlich auch Kunden dabei, diesen Entwicklungsprozess zu optimieren. Verschiedenste Themen geht davon los, die technische Infrastruktur zu schaffen. Es geht um die Prozesse, Beratung. Wie gehe ich eigentlich an Kur? Was sind eigentlich nur? Auch in der Infrastruktur. Da sind Berater eigentlich unser Duden.

Fassen wir noch einmal zusammen, was wir bis hierhin festgehalten haben das korrekte Verständnis von Agila Entwicklung, also beispielsweise das Einräumen, die entsprechenden Ressourcen für den Product Owner, klare Priorisierung, hoher Grad an Automatisierung bei der Software-Entwicklung und vielleicht auch bei Business Prozessen sind essenziell, um Kosten für die Entwicklung von Individual Software im Rahmen zu halten und gleichzeitig eine sehr hohe Entwicklungsmöglichkeit zu erzielen. Gleichzeitig bekommt der Kunde die Sicherheit, das Projekt jederzeit zu stoppen. Oder ich sage mal an sinnvollen Punkten zu stoppen, wenn halt funktions Pakete ausgeliefert wurden.

Oder das Team ist eingespielt. Es kann auch dann relativ kostengünstig einfach weitergefahren werden, wenn noch funktions Pakete dann notwendig sind, um weitere Geschäftsmodelle zu erschließen oder Prozesse zu automatisieren. Gibt es da noch weitere Themen, mit denen sich die Kunden befassen sollten? Vielleicht hast du in Projekten, die du durchgeführt hast oder die als Firma durchgeführt habt, Aha-Effekt erlebt, wo du gesagt hast Mensch, das ist ja unglaublich.

Wo soll ich da anfangen? Das sind verschiedene Themen.

Wahrscheinlich kennst du ähnliche Dinge, zum Beispiel aus Agila Entwicklung, sogenannte Thaiboxen. Das gibts auf verschiedenen Ebenen. Was bedeutet Thaiboxen? Du nimmst ihr eine gewisse Zeit für eine gewisse Aufgabe. Fängt an, bei dem zweiwöchigen Sprint zu sagen Ich möchte in zwei Wochen liefern. Da wird es auch wichtig, dass diese zwei Wochen eingehalten werden, wenn du Kenntnisse in Unternehmen. Da hängen dann verschiedene Punkte hinten dran. Da gibt's dann Der Kunde muss sich anschauen, er muss es bewerten, abnehmen, er muss den nächsten planen.

Da sind typischerweise dann auch noch Leute mit einem vollen Terminkalender. Ob Entscheider Argumente liefern? Erst drei Tage später, dann bringst du diesen ganzen Thema durcheinander. Also lieber Halte dich an, diese Thaiboxen lassen lieber etwas aus dem Weg, wenn tatsächlich mal nicht verschätzt, fokussiere sich dann aber auch auf andere Ebene. Du hast es so oft zu ersehen, dass die kein Bock mehr haben, weil du sagst vorher. Was möchte ich jetzt in der nächsten Stunde für Ergebnisse produzieren?

Was muss am Ende dieser Stunde stehen? Dann kriegst du in dieser Stunde genau das erreicht über 80 Prozent fertig machen. Als sich im Detail Diskussionen, ob man dann andere Sachen Retrospektive, agiles Vorgehen sieht eigentlich alle zwei Wochen oder Rennverlauf eine typische Retrospektive. Was ist ein regelmäßiger? Alle zwei Wochen. Wie lief das? In den vergangenen zwei Wochen haben wir gut gemacht. Was können wir verbessern? Und leitete natürlich auch Maßnahmen ab. Zwei kleine Maßnahmen wollen wir im nächsten Segment besser machen.

So hast du eigentlich nur alle zwei Wochen Macht 26 mal im Jahr die Möglichkeit, nicht zu verbessern. Und wenn du das mal überlegst 26 kleine Verbesserungen im Jahr. Besser als jedes betriebliche Vorschlagswesen hast du auf einer hohen Ebene Abendblatts, und es ist im Prozess eingebaut.

Das heißt, man kann es nicht überspringen.

Da kannst du garantiert einiges Agenten. Fehlerkultur. Wie gehe ich mit Fehlern in meinem Unternehmen um? Weiß ich den Leuten den Kopf ab, oder akzeptiere ich, dass Fehler vorkommen, wenn ich mich selbst? Ich mache ja auch viele andere Ledermann. Wenn ich aber anderen Leuten deswegen den Kopf abreißen, was mir tun, die werden ihre komplette Energie darauf verwenden, Fehler zu vermeiden. Es wäre doch viel besser, wenn ich den vertraue. Sie werden das schon reißen, wenn es mal so Wir können das auch wieder korrigieren.

Wir haben doch alle zwei Wochen die Möglichkeit dazu. Plötzlich werden Energien frei, die hier die eigentliche Kreativität, auch Schaffung von Werten einklagen.

Was ich in den Projekten, in denen ich bisher mitgearbeitet habe, gesehen habe, ist Es ist super wichtig, dass die Entwickler ihr Sprint Ergebnis vorstellen. Ihre Komponente, an der sie gearbeitet haben und idealerweise sogar vor dem Endkunden. Dass die Entwickler den Endkunden kennenlernen und vor diesem in Anführungszeichen gerade stehen ihre Arbeit Endkunde auch die Entwickler kennenlernen, das ist ja oft gerade in großen Unternehmen ist das ja total entkoppelt. Und dass man dann auch so eine Vertrauensbasis aufbaut. Und auch die Entwickler sehen, wie ihre Software von den Endkunden genutzt wird und welche Funktionen man noch optimieren kann.

Da ergeben sich super oft Aha-Effekt, wo man sagt Urmensch. Wenn ich den Button Wenn ich den Fokus direkt auf den Button lege, muss ja nur noch Enter drücken, wenn die Maske aufgeht in 90 Prozent der Fälle und Spaß, wie das Ganze umgeknickt.

Da lacht mein Herz, wenn so etwas entsteht, wenn du das entkoppelt durch irgendwelche. Das alleine macht und hast du immer irgendwelche Stille. Post, Effekte und Hoboken werden auf der anderen Seite doch mal ehrlich Die Entwickler sind doch alle ähnlich wie. Zirkussen Wir leben doch unsere Anwender nutzen und begeistert sind. Das ist doch auch eine Motivation für unser Ziel. Auf jeden Fall.

Da verarbeiten wir ja jeden Tag die Software, die wir schreiben, dann eben auch einen hohen Nutzwert erzeugt und grauenhafte manuelle Prozesse. Repetitive Arbeiten, dann automatisiert, weil das kann der Computer viel schneller. Und wenn man mal ehrlich ist, möchten Menschen wahrscheinlich auch nicht irgendwelche simplen Datenerfassung zum Selbermachen von Hand.

Wie oft erlebe ich einfach eine Begeisterung? Ich habe letztens eine vor drei Wochen erlebte anwenderinnen. So was von kindlich begeistert ist, jetzt gar nicht abwertend. Diese Dieseln erkennt. Ja, es funktioniert. Jetzt kann ich das endlich einsetzen. Das ist doch super wichtig, auch für Entwickler zu erkennen und eine Motivation.

Mich freuen solche Ereignisse auch immer mal wieder total. Vielen Dank, Markus! Wenn unsere Zuhörer jetzt Blut geleckt haben und dich erreichen möchten, wie können Sie das tun?

Ja, am besten über unsere Homepage www. Punkt p so gut. Dort gibt's einen Kontaktformular, meine meine E-Mails, aber auch jede Menge whitepaper, wie man sich downloaden kann und der Blog mit weiteren www. Punkt.

OK, ich pack den Link auch in die Beschreibung zu diesem Podcast. Dann können unsere Zuhörer einfach da drauf klicken. Wunderbar. Vielen Dank, Markus! Wenn unsere Zuhörer Fragen haben, können Sie uns gerne eine E-Mail schreiben an Podcast. Wenn euch die Frage gefallen, lassen Sie gerne eine Bewertung da und abonniert unseren Podcast und für weitere spannende Technologie Themen. Schaut gerne auf www. Slash blog vorbei. Ich bedanke mich ganz herzlich bei dir, Markus. Das sollte dir die Zeit genommen hast.

Danke, dass ich mir auch. Ich wünsch dir was.