Im lockeren Gespräch mit Michael Asshauer über Agilität, Wasserfälle und wie du Chaos vermeiden kannst, obwohl du agile Methoden einführst.

Wir sprechen über Wasserfallmodelle, Lastenhefte, Agilität, Chaos, die Kosten von Agilität, Prozesskonformität, die Arbeitsprozesse als eigenes Produkt betrachten, Kanban, Scrum, Sprints, Management, Flexibilität, Backlogs, Prioritäten, Standups, Reviews, Retrospektiven, kontinuierliche Verbesserung des agilen Prozesses, Produktqualität, Produktbewertungen und deine Möglichkeiten dabei das totale Chaos zu vermeiden.

Podcast per iPhone, Mac oder iPad anhören

Podcast per Android und Google Podcasts anhören

- die Talente-Plattform und der Talente-Podcast von Michael Asshauer

Im Interview mit Michael Asshauer

Oliver Ratajczak: Hallo, schön, dass du wieder dabei bist bei einer neuen Folge des Blickwinkel-Kunde Podcast. Heute auf einen Kaffee mit jemanden, der sich ziemlich gut mit agilen Prozessen und dem Einführen von agilen Prozessen in Teams auskennt. Ich treffe mich jetzt auf einen Kaffee mit Michael Asshauer. Hallo, Michael.

Michael Asshauer: Guten Morgen, ich grüße dich, Oliver.

Oliver Ratajczak: Schön, dass es geklappt hat. Wir sind uns bereits ein paar Mal in den iTunes Charts begegnet, da kamen unsere Podcast Daily immer aneinander vorbei, was ich sehr schön finde. Dann haben wir uns gefunden und reden jetzt mal miteinander. Erzähle doch mal ein bisschen mehr zu dir. Was bist du für einer?

Wer ist Michael Asshauer?

Michael Asshauer: Ja, gerne. Wie du schon sagst, ich bin Michael Asshauer, Unternehmer und Gründer. Ich habe vor mittlerweile ungefähr sieben Jahren mein eigenes Start-Up gegründet, ein Tec Start-Up namens Familonet. Wir haben angefangen, eine B to C Smartphone App zu entwickeln, die Familo-App, eine App für Familien, wo Familienmitglieder untereinander ihren Standort teilen und den Familienalltag miteinander organisieren können. Mit der Zeit haben wir uns immer weiter entwickelt in Richtung einer B to B Tec-Bude sozusagen, weil wir dann auch die Technologie, die wir im Zuge unseres B to C Produktes entwickelt haben, extrahiert und sozusagen gekapselt auch an andere Unternehmen verkauft haben, die diese Technologie wiederum in ihre Produkte eingebaut haben. Wir haben dann auch eine Agentur gegründet namens Onbird und auch für andere Unternehmen ganze Produkte gebaut. Vor zwei Jahren wurden unsere Firmen beziehungsweise unsere Firma Familonet, zu der auch die anderen Firmen gehörten, von Daimler übernommen. Wir haben dann praktisch einen Exit an Daimler gemacht, und jetzt bin ich bei der Daimler-BMW-Tochter Reach Now und baue da auch wieder mobile Tec-Produkte, dieses Mal im Mobilitätsbereich. Es geht darum, dass wir sozusagen innovative Mobilitätsprodukte für unsere Shareholder Daimler-BMW bauen, weil – wie jeder weiß – müssen sich natürlich auch die Autokonzerne umschauen, wie sie in Zukunft Geld verdienen werden und das Auto nicht als einziges Modell, sondern in Zeiten von Shared Mobility, New Mobility, Städte im Wandet et cetera geht es natürlich auch darum, innovative Produkte zu bauen, die auch in Zukunft Bestand haben werden.

Oliver Ratajczak: Ja, das ist super spannend, gerade im Automobilsektor. Da tut sich in den nächsten Jahren, glaube ich, noch einmal eine ganze Menge.

Michael Asshauer: Auf jeden Fall.

Oliver Ratajczak: Deswegen ist es sicherlich gut, mal zu gucken, was alles geht. Kannst du ein bisschen mehr zu erzählen, was ihr tut oder eher nicht?

Michael Asshauer: Doch, das kann ich natürlich machen. Viele unserer Zuhörer kennen wahrscheinlich solche Produkte wie Car-to-Go, also Car-Sharing, oder auf BMW-Seite ‘Drive Now’ oder die Taxiruf-App. Eine unserer großen Missionen bei Reach Now ist es, solche Produkte, mit denen sich Menschen von A nach B bewegen, auf eine gemeinsame Plattform zu bringen. Du als Endnutzer möchtest in der Regel ja nicht zehn oder fünfzehn verschiedene Apps auf dem Telefon haben.

Oliver Ratajczak: Die habe ich, aber das hilft ja noch aktuell nicht.

Michael Asshauer: Das werde ich unter anderem ändern, so dass du im Prinzip mit einem Klick sehen kannst, was ist jetzt gerade für dich der beste Service, der dich von dort, wo du jetzt gerade bist, zu deinem Ziel bringt. Wir bringen das auf eine gemeinsame Plattform, zum Beispiel auch zusammen mit Städten, um auch den öffentlichen Nahverkehr mit einzubinden. Das ist das Innovative an der Geschichte.

Oliver Ratajczak: Könnte man sagen, es handelt sich um so etwas wie ein Meta-Search für Mobilität?

Michael Asshauer: Ja, im Prinzip kann man es so beschreiben, warum eigentlich nicht?

Oliver Ratajczak: Ich hoffe inständig, dass es nicht nur eine “Search” Funktion ist, sondern dass ich für eine bestimmte Route auch ein Ticket buchen kann, und nicht sieben verschiedene bei 38 Dienstleistern.

Michael Asshauer: Richtig. Das ist natürlich die Magie an der Geschichte und auch genau das, was wir bei Reach Now machen. Unser Ziel ist es, dass du natürlich direkt entweder dein ÖPNV-Ticket kaufen oder dein Car-to-Go oder dein MyTaxi – beziehungsweise mittlerweile heißt es ja Share-Now und FreeNow – buchen kannst. Du brauchst dir somit keine Sorgen mehr zu machen über verschiedene User-Accounts bei verschiedenen Services für verschiedene Apps. Das ist natürlich eine feine Sache.

Oliver Ratajczak: Ja, definitiv. Ich krieg ja schon einen Anfall, wenn ich versuche, bei der Bahn etwas zu buchen und es heißt, nein, das ist aber Nahverkehr und das ist anders und so weiter. Eines der ersten Bilder, die wir damals in der Grundschule malen mussten, war, wie wir uns das Jahr 2000 vorstellen. Ich habe mich natürlich in so einem kleinen Raumschiff gemalt, das ist ja klar. Aber ich sage mal, wir haben 2019, und jetzt diskutieren wir noch über Nahverkehrs Dinge und verschiedene Tickets an Schnittstellen – danke, dass ihr etwas dagegen tut.

Michael Asshauer: Auf jeden Fall. Aber du lagst da, glaube ich, gar nicht so falsch in der Grundschule, weil eine der großen Visionen, die wir natürlich haben, ist diese selbstfliegende On-Demand, dich von A nach B bringende Drohne, der du einfach sagst, du willst jetzt von A nach B, dann kommt die angeflogen, du setzt dich rein, das Ding fliegt dich dahin wo du hin willst, unterwegs steigen vielleicht noch ein paar andere Leute ein und wieder aus. Und dann steigst du aus, und das Ding fliegt weiter, und du hast mit nichts weiter am Hut. Das ist gar nicht mehr so weit voneinander entfernt.

Oliver Ratajczak: Ich hoffe inständig, dass ich noch ein paar Jahre lebe, aber meinst du, ich werde es erleben?

Michael Asshauer: Ich glaube schon. Es gibt jetzt schon erste Modellversuche in diese Richtung, zum Beispiel in Südamerika und in Australien. Das ist gar nicht mehr so weit weg, wie es sich vielleicht für uns hier auch noch anfühlt.

Oliver Ratajczak: Ja, ich glaube technisch mache ich mir da gar keinen Kopf. Ich glaube eher, rechtlich, juristisch – irgendeiner wird einmal umgefahren, dann gibt es Diskussionen, warum der umgefahren wurde, und das wäre ja bla. Aber in der Zwischenzeit haben wahrscheinlich hundert Menschen am Steuer mehr Leute herumgefahren als der eine Automat.

Michael Asshauer: Das ist richtig.

Oliver Ratajczak: Diese Diskussion kann man beliebig lange weiterführen. Ich hoffe inständig, dass ich das mal erleben werde, weil das einzige, was mich an einem Auto nicht interessiert, ist das Lenkrad. Ich möchte eigentlich nur drinsitzen und etwas Sinnvolles tun. Toll. Ich bin gespannt. Du sagtest selbst, ihr seid sozusagen eine Tec-Bude, was immer ein bisschen despektierlich klingt. Und da ich ja aus der Technik komme, freue ich mich dann immer sehr, ich finde es toll, aber gerade so aus IT-nahen Bereichen, IT-Abteilungen, kommt ja immer so ganz modernes Zeug. Wenn ich mir große Unternehmen angucke, dann sind manchmal, manchmal in Anführungsstrichen, die IT-Abteilungen ganz innovativ, und die haben immer ganz besondere Arten, miteinander zu arbeiten. Ich denke an dieses typische Wasserfall-Modell von früher: Der Fachbereich denkt sich etwas aus, schreibt ein vierhundert Seiten Word-Dokument, und wirft es dann der IT über den Zaun, und die muss es dann umsetzen. Das ist hoffentlich nicht mehr ganz der Stand der Zeit.

Michael Asshauer: Genau. Du sprichst natürlich das Thema Agilität an. Wenn wir da noch einmal kurz den Vergleich machen. Wie du gerade beschrieben hast, war der Ablauf früher so, dass eine Abteilung sich ein Feature oder Produkt ausdenkt und zunächst beschreibt, wie das Ganze aussehen soll und was das Ganze können soll. Das dauerte oft bereits eine lange Zeit. Danach wurde zum Beispiel ein Lastenheft erstellt und dann in die IT gegeben. Die ITler bauen das dann einfach, und dann wird es nach einer gewissen Zeit wiederum an die Abteilung geliefert, die es bestellt hat.

Oliver Ratajczak: Und die staunen, was dabei herausgekommen ist.

Michael Asshauer: Die staunen, was da herausgekommen ist, und dann geht das Ganze schlimmstenfalls nochmal von vorne los.

Oliver Ratajczak: Ich habe das bereits erlebt bei einem Unternehmen. Sie hatten damals Anforderung an die IT gegeben, die IT hat geschätzt, zu dem Zeitpunkt wird es live gehen. Die hatten allen Ernstes eine Pressekonferenz einberufen in dem Fachbereich und haben gesagt: “So jetzt hier, live, neue Funktion.” Das Geile war, die haben nie über eine Frontend gesprochen, der Fachbereich ist immer von einem Frontend ausgegangen, und die IT hat eine Schnittstelle gemacht.

Michael Asshauer: Ja, okay, ich verstehe. So etwas passiert dann.

Oliver Ratajczak: Das gab lange Gesichter.

Michael Asshauer: Das ist das perfekte Beispiel, um daran einmal zu erklären, was diese Agilität, von der man immer hört, eigentlich bedeutet.

Oliver Ratajczak: Da bin ich sehr gespannt. Die höre ich immer, die ist überall und jedes noch so tradierte Unternehmen wird gerade ganz agil.

Michael Asshauer: Richtig.

Oliver Ratajczak: Erkläre mal, was die tun.

Wie genau geht das mit SCRUM?

Michael Asshauer: Da muss man dann auch ziemlich aufpassen, aber darauf werde ich gleich noch zu sprechen kommen. Erstmal haben natürlich viele Unternehmen und Teams festgestellt, wenn ich mir heute was ausdenke, und jetzt erstmal ein Lastenheft drei Monate erstelle, und dann dauert es nochmal drei Monate, bis das abgeliefert ist, ist ein halbes Jahr und noch länger rum, da können sich die Anforderungen an dieses Produkt natürlich schon wieder komplett verändert haben, und es kann sein, dass wir sechs Monate an etwas bauen, was am Ende der Markt gar nicht will. Oder das Beispiel, was du gerade genannt hast, wir bauen an etwas, was eigentlich unser Abnehmer – sei es ein interner oder ein externer Kunde, ist erst einmal egal –eigentlich so gar nicht will und sich so vielleicht auch gar nicht vorgestellt hat. Und dann gab es sozusagen diese Bewegung der Agilität, dann gibt es da natürlich verschiedene Frameworks, wie zum Beispiel Scrum oder so etwas, wovon wahrscheinlich viele auch schon gehört haben, wo es dann darum geht, wir wollen auf diese wechselnden Anforderungen oder sich verändernden Anforderungen, die im Prozess aber erst deutlich und klar werden, eine Methodik haben, dass wir darauf schnell reagieren können, und sozusagen das Produkt, was wir bauen, immer sehr nahe an diesen Anforderungen, was zum Beispiel dann Marktanforderungen oder Kundenanforderungen sind, bauen können, aber mit der Magie darin, dass das alles passiert, ohne dass das Ganze in komplettes Chaos ausbricht und ohne dass durch diese gewonnene Flexibilität am Ende alle nur darunter leiden, weil sich jeden Tag alles ändert. Das ist auch genau der kritische Punkt.

Oliver Ratajczak: Ich habe bei Unternehmen eine Einführung von Agilität festgestellt und hatte dann jedoch das Gefühl, als hätte jemand ‘agil’ darauf geschrieben, meinte aber eigentlich so etwas wie ungeplant, spontan, hemdsärmelig dokumentiert.

Michael Asshauer: Das heißt komplettes Chaos. Das sehe ich leider auch sehr oft, und das ist einfach eine komplett falsche Interpretation von Agilität. Bei vielen Unternehmen wissen es die Leute oft nicht anders. Sie nehmen an, wenn es keine Lastenhefte mehr gibt und keinen Wasserfall, dann bedeutet das Agilität. Für diese Mitarbeiter bedeutet Agilität, ab sofort macht jeder das, was er will, und wir können alles jeden Tag ändern.

Oliver Ratajczak: Keiner macht was er will, alle machen mit.

Michael Asshauer: Genau. Das führt natürlich ins komplette Chaos und auch dazu, dass das Produkt am Ende schlechter wird, dass Mitarbeiter unzufrieden werden, dass die Fluktuation im Unternehmen steigt, dass Leute aussteigen, dass die Entwickler unzufriedener werden, dass das Management unzufriedener wird und dass der Kunde am Ende unzufriedener wird. Das will natürlich keiner. Deshalb muss man sehr stark darauf achten, wie führt man Agilität ein, was ist überhaupt Agilität, wie überzeuge ich Mitarbeiter, Management und so weiter.

Oliver Ratajczak: Da bin ich sehr gespannt, weil ich das bei manchen Unternehmen genauso so schon erlebt habe, nämlich einen Schwenk von Wasserfall auf Agilität, dann totales Chaos und Aussagen wie: “Agilität haben wir schon probiert, funktioniert bei uns nicht.” Und dann denke ich immer, das ist jetzt irgendwie verbrannt, war aber blöd eigentlich. Wie macht man es denn richtig?

Michael Asshauer: Es ist vor allen Dingen erst einmal wichtig, dass alle Beteiligten – sowohl das Management als auch diejenigen, die dann in der neugewonnenen Agilität leben sollen – verstehen, dass Agilität etwas kostet. Agilität kostet, dass man sich noch stärker an Prozesse halten muss, als man es sogar von davor kennt, als man es sogar vom Wasserfall kennt. Agilität geht mit super starken Prozessen einher und einem Commitment aller, die daran beteiligt sind und in der Agilität arbeiten, sich an diese Prozesse zu halten. Und damit das funktioniert, damit auch wirklich alle sich an die Prozesse halten, sowohl – wenn wir jetzt beim IT-Beispiel bleiben – die Developer, die in dem agilen Team arbeiten, als auch die Business-Leute, die Manager et cetera, die das Produkt zum Beispiel verkaufen, was das agile Team baut. Es müssen sich von Anfang an alle auf gewisse festgelegte Prozesse einigen und daran halten. Und dafür ist es wichtig, dass das Team sofort ab dem Moment, wo ein agiler Prozess eingeführt wird, nicht mehr nur das Produkt, was sie am Ende bauen sollen, als ein eigenes Produkt ansehen, sondern auch ihre Prozesse, ihr Framework, in dem sie arbeiten. Du hast vorhin dieses Frontend Beispiel angesprochen, zum Beispiel eine Webplattform.

Oliver Ratajczak: Ja, aber die sollen ja nicht irgendein Framework bauen, die sollen ja das Produkt bauen. Argumente, was man da wahrscheinlich zu hören bekommt.

Prozesse sind gerade bei SCRUM wichtig!

Oliver Ratajczak: Genau. Das Produkt entspringt am Ende den Prozessen. Wenn man sich jetzt zum Beispiel einen Prozess anschaut, da haben sich ja schon viele Leute vorher Gedanken darüber gemacht, was es für agile Prozesse geben könnte. Es gibt Tools, wie zum Beispiel KanBan oder Scrum. Ich persönlich bin ein etwas größerer Fan von Scrum. Wenn ich da jetzt einmal kurz reingehe und kurz anschneide, wie so ein Scrum-Prozess ablaufen kann: Scrum-Prozess lebt davon, dass es Sprints gibt, festgelegte, zeitliche Perioden. In meinen Firmen war es immer so, dass einen Sprint immer auf zwei Wochen festgelegt haben, manchmal auch drei, manchmal vier. Ich bin mit zwei Wochen immer ganz gut gefahren. Wenn ein Sprint zwei Wochen dauert, dann ist das die gewonnene Flexibilität, das heißt, in zwei Wochen Rhythmen kann man sozusagen die Anforderungen noch einmal anpassen, kann die Anforderungen und vor allem auch die Prioritäten an das Produkt, was am Ende gebaut werden soll, anpassen. Aber innerhalb dieser zwei Wochen ist es ein absolut geschützter Raum für die Leute, die in diesem Prozess arbeiten, also die Leute, die sich zum Beispiel dann in diesem Scrum-Team befinden. Das heißt, ohne das jetzt zu sehr zu vertiefen zu wollen – jeder kann bei Wikipedia einfach Scrum eingeben – am Anfang der zwei Wochen gibt es eine Liste an Prioritäten, was jetzt für das Produkt gebaut werden soll. Dann einigt man sich in diesem Scrum-Team darauf, was am Ende der zwei Wochen an ship-baren, also wirklich auslieferbaren Teilen des Produktes bestehen soll, oder was in den zwei Wochen entstehen soll. Und dann müssen alle wissen, wenn dieser Sprint gestartet ist, dann ist es ein absolutes Tabu, diesen Sprint irgendwie zu unterbrechen, in diesen Sprint einzugreifen. Es ist ein absolutes Tabu, dieses Commitment, was am Anfang der zwei Wochen das gesamte Team auf das Ergebnis am Ende gegeben hat, zu untergraben. Und das ist etwas, was zum Beispiel auch ein Management oft nicht versteht. ‘Wir sind jetzt agil, wir können jetzt jeden alles ändern, unsere Prioritäten und Anforderungen ändern.‘ Nein. Das ist genau der große Fehler, den viele Unternehmer und auch viele Manager machen, dass sie denken, jetzt kann ich meine Leute jeden Tag irgendwie in eine andere Richtung scheuchen. Nein, überhaupt nicht, sondern das einzige, was ich machen kann, ist im Backlog dafür zu sorgen, dass eine Priorität anders geshiftet wird, die dann aber erst ab dem nächsten Sprint, also im schlimmsten Fall ab in zwei Wochen, umgesetzt wird. Und dieser geschützte Raum ist für das Team unendlich wichtig, damit kein Chaos ausbricht, damit diese gewonnene Flexibilität der zwei Wochen Sprint nicht darin endet, dass die Leute unzufrieden sind und überhaupt keine Lust mehr haben weiterzuarbeiten. Wenn ich vorhin gesagt habe, dass das Team auch für seine eigenen Prozesse zuständig sein soll und sein agiles Framework auch als sein eigenes Produkt ansehen soll, dann bedeutet das so etwas, wie ich es gerade angerissen habe: der Sprint dauert bei uns zwei Wochen, und wir committen uns am Anfang auf diese Dinge, die am Ende erreicht sein sollen. Während des Sprints gibt es immer noch sogenannte – im Scrum nennt sich das – Zeremonien, um im Prinzip wie in Meetings zu überprüfen, ob man on Track ist, und wenn man nicht on Track ist, was getan werden muss, um on Track zu kommen, und so weiter. Es gibt am Ende Reviews, wo das gesamte Team zusammensitzt. Es gibt Daily Standups, also das ist auch so ein agiles Ding, und so weiter. Und in jedem Sprint ist es auch wichtig, dass es eine sogenannte Retrospektive gibt, eines der wichtigsten Meetings des gesamten agilen Prozesses. In dieser Retrospektive sitzt das gesamte Team, das gesamte Scrum Team in diesem Fall, zusammen und überlegt sich, wenn wir uns jetzt den letzten oder die letzten Sprints angucken, was lief gut, was lief nicht gut, was wollen wir bei den nächsten Sprints anders machen, an welcher Stelle wollen wir unsere Prozesse verändern, anpassen und vermeintlich verbessern, um zu testen, ob das besser funktioniert. Und dann geht es wieder darum, dass sich alle darauf committen, diese Änderung im nächsten Sprint auch durchzuführen. #00:19:25-8#

Oliver Ratajczak: Aber da gibt es doch bestimmt jemanden, der sagt, „nach Scrum arbeiten ja ganz viele da draußen, die haben es bestimmt schon weiterentwickelt, nehmen wir doch einfach so eine Methode, Prozesse von denen, die das schon seit Jahren machen. Die nehmen wir auf. Fertig. Dann brauchen wir nicht daran herumfummeln und können uns nur um unser Produkt kümmern.“ #00:19:40-6#

Michael Asshauer: Ja, das kann auch sinnvoll sein. Scrum ist ein erster Aufschlag. Es ist sozusagen so eine Blaupause, aber es ist im Prinzip Open Source. Das heißt, jedes Team wird Sprint für Sprint für sich diesen Scrum-Prozess, der die Basis ist, anpassen in eine Richtung, so dass es für das explizite Team besser passt. Kein Scrum-Prozess und kein agiler Prozess ist jemals fertig. Es gehört praktisch zur Konstitution des agilen Prozesses dazu, dass man sich Sprint für Sprint zusammensetzt und überlegt, wie können wir es beim nächsten Mal noch besser machen. Das heißt, kein Team wird irgendwie einen Prozess gefunden haben, und der wird dann für immer so funktionieren, sondern jedes gute agile Team wird sich in regelmäßigen Abständen hinsetzen und seinen eigenen Prozess, sein eigenes Framework weiter verbessern. Das heißt, das gibt es gar nicht, dass irgendein Team das sozusagen fertig ausformuliert hat. #00:20:48-1#

Oliver Ratajczak: Diese Retrospektive macht man aber nicht am Ende von jedem Sprint, sondern alle paar Sprints? Oder wie kann man sich das vorstellen?

Michael Asshauer: Die gehört, wenn man nach Scrum-Lehrbuch geht, zu jedem Sprint dazu. Ich finde es auch eines der wichtigsten Meetings des gesamten Sprints.

Oliver Ratajczak: Ich hatte es gerade so verstanden, dass alle paar Sprints mal so eine Retrospektive kommt.

Michael Asshauer: Nein.

Oliver Ratajczak: Ich hatte nämlich auch so einzelne. Aber, wie auch immer, ich habe auch verstanden, es gibt nicht DEN agilen Prozess, sondern der hängt ab von den Leuten, vom Team, von dem, was man da tut. Im Zweifelsfall gibt es ja auch agile Methoden, die nicht nur für Softwarenentwicklungen sind, sondern für alles Mögliche. Dann ist es bestimmt immer anders, und man muss es adaptieren. Was ich schön finde, ist, dass du sagst, das Ding ist nie fertig. Das bedeutet ja sozusagen, dass man kontinuierlich einen Verbesserungsprozess automatisch eingebaut hat.

Michael Asshauer: Richtig.

Oliver Ratajczak: Weil man gezwungen ist, dauernd wieder darüber nachzudenken und zu gucken, was war noch nicht, wo könnte man es noch besser machen. Das hört sich eigentlich schön an, und man sollte eigentlich von vielen Unternehmen seit Jahrzehnten erwarten, dass sie genau das tun, aber das ist eher manchmal nicht so.

Michael Asshauer: Das ist genau der iterative Ansatz. So wie auch Produkte niemals endgültig fertig sind und immer weiterentwickelt werden, ist der agile Prozess, um das Produkt zu entwickeln, das agile Framework auch nie fertig. Dann sind wir auch eigentlich fast schon wieder bei dem Thema, das wir gerade in unserer anderen Podcast Folge angesprochen haben. Wir haben gerade noch eine Folge für meinen Podcast aufgenommen, für den Talente Podcast, wo wir auch darüber gesprochen haben, die Leute dazu zu motivieren und die Leute zu aktivieren, man kann es nennen, sich zu beschweren beziehungsweise auch Verbesserungs-Feedback zu geben. Und zu schauen, was können wir, was haben wir gelernt, was haben wir für gute Erfahrungen gemacht, was haben wir für schlechte Erfahrungen gemacht, was wollen wir in den nächsten zwei Wochen oder im nächsten Sprint anders machen, um möglichst die schlechten Erlebnisse oder die Anzahl der schlechten Erlebnisse nach unten zu schrauben.

Oliver Ratajczak: Verstehe. Das finde ich super spannend. Du bist sozusagen ein großer Verfechter der Agilität, habe ich verstanden.

Michael Asshauer: Ich bin ein Verfechter der Agilität, aber ich bin oft auch der Buhmann, weil ich die Leute immer wieder daran erinnere, dass Prozesse beziehungsweise dass Agilität Prozessen bedarf und dass es wirklich kostet. Es kostet Commitment und Einigung auf Prozesse, und es kostet auch diese kontinuierliche, ständige Weiterentwicklung der Prozesse. Agilität ist nicht nur “ab heute sind wir komplett flexibel, jeder kann machen, was er will, und das ist jetzt hier das komplette Chaos”, sondern Agilität lebt von sehr festen Prozessen, an die sich alle halten müssen.

Oliver Ratajczak: Das finde ich gut, wenn man das Commitment hinkriegt. Ich erlebe das oft, dass der Geschäftsführer darunter doch noch schnell sagt: “Jetzt sag’ doch noch mal eben, ein Meeting, eine halbe Stunde geht doch”. Aber wer immer einmal Software entwickelt hat, der weiß, dass eine solche Unterbrechung einen aus der Arbeit gut herausreißen kann. Deswegen finde ich diesen geschützten Raum extrem sinnvoll. Jetzt komme ich mal wieder mit meiner Lehrerbrille und sage, will der Kunde überhaupt Agilität, der Endkunde da draußen? Ich persönlich kriege regelmäßig einen Anfall. Ich nutze Software, die frei verfügbar ist, sei es WordPress Themes oder sonstige Sachen. Zwei Wochen später ist der Knopf woanders, heißt woanders, die Funktion gibt es nicht mehr, die Funktion ist jetzt anders, Schnittstellen funktionieren nicht mehr wie geplant. Das Theme hat wieder eine neue, geile, fancy Funktion, dafür ist etwas anderes weggefallen, und ich kriege jedes Mal einen Anfall und denke: “Herr im Himmel, wollt ihr nicht, dass euer Produkt produktiv von anderen Leuten genutzt wird, oder wollt ihr die hauptsächlich verlieren?“

Oliver Ratajczak: Das hat jetzt per se nichts mit einem agilen Prozess zu tun, in dem das Team zusammenarbeitet. Ich würde sagen, diesen Effekt, den du beschreibst, den kann ich mir genauso vorstellen, wenn jetzt vielleicht nur eine Person das Sagen hat und sozusagen von oben diktiert, wo wir den Button hinbauen. Oder was in dem Fall, den du beschreibst, in der Realität oft der Fall ist, dass zum Beispiel AB-Testings gemacht werden und dann eine Version so ausgerollt wird, ist der Button unten links, ist er in einer anderen Version oben rechts, statt grün ist er rot. So etwas ist natürlich oft Markting- und Sales-getrieben. Oft wollen die Produktentwicklungsteams so etwas selber nicht unbedingt, sondern das wird oft aufdiktiert und dadurch, dass man sozusagen eine gewisse Macht in die Teams hineingibt im agilen Prozess, kann ich mir sogar vorstellen, dass so etwas dadurch sogar verhindert werden kann, was du da beschreibst. Da kann man sich verschiedene Szenarien vorstellen, warum das so ist, dass du bei verschiedenen Softwaren so etwas erlebst. Ich glaube nicht, dass es dem agilen Projektmanagementprozess zuzuschreiben ist.

Oliver Ratajczak: Das glaube ich auch nicht. Nach allen meinen Erfahrungen, die ich gemacht habe, halte ich das für genau den richtigen Weg. Man arbeitet schneller zusammen, man hat schnell etwas shipable, wie du gesagt hast, ein fertiges Produkt. Man kann gucken, funktioniert alles, ist alles in Ordnung. Aber dann fehlt mit noch so eine Schicht in Richtung Endkunde. Einer, der sagt: “Pass auf, wir bandeln jetzt zehn Sprints zusammen, dann gibt es eine neue Version, und die kriegt der Kunde. Und zwar mit einer richtigen Anleitung, was gibt es Neues.” Nicht in der Art, „es sind vierzehn Tage vorbei, jetzt wieder (unv. #00:26:30-8#) Funktion.“ Im Zweifelsfall bedeutet das Umstellung bei Mitarbeitern, die das Ding gewohnt sind, bei denjenigen, die das Produkt nutzen. Es ist nicht alles super fancy, man macht mal eben eine App und probiert etwas aus, sondern es gibt Leute, die verdienen damit Geld, dass sie ein Tool von anderen Leuten benutzen, das sich alle zwei Wochen verändert. Da würde ich mir manchmal so etwas wünschen wie: “Pass auf, wir haben zwei verschiedene Release-Zyklen. Der eine ist für die, denen es egal ist, wie das funktioniert, und bei den anderen, jedes halbe Jahr gibt es eine (unv.)

Michael Asshauer: Ich verstehe dich. Das ist ein bisschen der Unterschied, wie zum Beispiel Google und Apple das Ganze handhaben. Google ist dafür bekannt, schnell neue Features zu shippen, ein bisschen nach dem Motto ‘better that than perfect’, selbst wenn das Facebook Zuckerberg Zitat ist, aber generell ist Google dafür bekannt, Sachen schnell herauszugeben, die vielleicht auch noch nicht hundertprozentig fertig sind, dafür dann halt schnell zu testen.

Oliver Ratajczak: Heutzutage macht doch keiner mehr hundert Prozent etwas fertig, habe ich gehört. Wenn es gerade nicht immer abstürzt.

Michael Asshauer: Das stimmt. Apple macht es eher so, wie du sagst, nämlich erst mal abwarten, erstmal ein abgehangenes Etwas oder etwas mehr abgehangenes Produkt dann erst vollständig zu releasen. Das hat beides seine Vor- und Nachteile, ist aber, glaube ich, durch den agilen Prozess nicht ausgeschlossen. Ich glaube, auch bei Apple, die eine andere Policy hat, kannst du davon ausgehen, dass bei Apple in den Produktentwicklungsteams auch agil gearbeitet wird.

Oliver Ratajczak: Davon gehe ich auch fest aus, nur kapseln sie das sozusagen weg vom Endkunden. Wenn man aber sagt: “Pass auf, alles zwei Wochen haben wir eine Version draußen, dann brauchen wir jetzt gar nicht mehr so genau testen, weil der Kunde testet ja für uns gratis mit. Und wenn der einen Fehler findet, meldet er sich. Dann können wir in der nächsten Version etwas Neues wieder hinrichten, also konvertieren.” Das beobachte ich manchmal und denke, wie genau wird denn der Kunde bezahlt?

Michael Asshauer: Das ist auf jeden Fall ein valider Punkt. Ein Statut des agilen Prozesses beziehungsweise insbesondere des Scrum-Prozesses ist es auch, dass man wirklich am Ende jedes Sprints einen Teil des Produktes veröffentlicht und shippt. Das könnte jetzt aber genau einer der Punkte sein, wo man sich als agiles Team überlegt, wir einigen uns jetzt darauf, dass wir vom standardmäßigen Lehrbuch-Scrum abweichen, dass wir sagen, wir haben vielleicht am Ende etwas Internes, was fertig ist nach zwei Wochen, aber das shippen wir vielleicht nur zu unseren Beta-Usern, die das schon gewohnt sind und die sich extra für das Beta-Programm eingetragen haben. Die Major Releases machen wir dann aber nur einmal im halben Jahr. Das wären typische Dinge, worauf sich das Team einigen kann, um vom Standardprozess abzuweichen.

Oliver Ratajczak: Wir haben in dem anderen Podcast, den wir bei dir im Talente Podcast aufgenommen haben, das Thema Beschwerdemanagement behandelt. Wenn die Unternehmen genau zuhören würden, was die Kunden da draußen für einen Ärger haben und sagen: “Mist, jetzt schon wieder alle zwei Wochen ein neuer Knopf woanders”, dann könnten sie so reagieren und ihren Scrum-Prozess anpassen.

Michael Asshauer: Das ist richtig.

Oliver Ratajczak: Das fände ich super. Ich finde das total spannend, also eine Mischung aus Zuhören und miteinander kommunizieren.

Michael Asshauer: Auf jeden Fall. Das ist gar nicht so schwer. Das sind zum Beispiel auch die Themen, die ich im Talente-Podcast viel behandele. Wie kann ich jetzt als Führungskraft dafür sorgen, dass so etwas vernünftig gehandelt wird, dass so etwas vernünftig eingeführt wird. Wie mache ich so etwas mit meinem Team am besten? Wie kriege ich es hin, dass es die Leute nicht demotiviert? Wie bringe ich so etwas auf die Straße? Welche kleinen Kniffe gibt es, um so etwas vernünftig umzusetzen? Das ist eigentlich am Ende gar nicht so schwer. Man muss sich nur an ein paar Dinge halten und sich einigen, dann ist es ein Riesengewinn. Ich weiß noch, als wir damals bei uns im Start-Up einen festen, agilen Prozess eingeführt haben. Unsere Produktqualität – und das dann auch wieder in Richtung Endkunde – ist innerhalb von weniger Zeit in die Höhe geschossen. Produktbewertungen haben sich massiv verbessert in den App-Stores. Es war wirklich unglaublich. Wir haben in viel kürzerer Zeit viel mehr geschafft und das Produkt massiv weit nach vorne gebracht. Die Kundenstimmen sind ein wertvoller Input-Faktor auf das Backlog, also auf das, was nach oben priorisiert wird für die nächsten Sprints. Das muss man natürlich nur nutzen. Da hast du recht.

Oliver Ratajczak: Nur – die Betonung liegt auf nur. Wie das immer so ist, je mehr man miteinander spricht, je besser man miteinander kommuniziert, umso mehr bekommt man mit, wenn irgendetwas im Argen liegt. Das finde ich extrem spannend, muss ich sagen. Mir hat es total viel Spaß gemacht, mit dir darüber zu reden. Ich werde auf alle Fälle deinen Podcast verlinken in den Show-Notes für die Hörer. Willst du den Hörern noch irgendetwas mitgeben? Wo finden die mehr über dich?

Michael Asshauer: Meine Plattform, die Talente-Plattform, findet ihr unter Talente.co. Da gibt es einerseits den Talente-Podcast, aber auf der Seite selbst gibt es auch viele Artikel und weiteren Content genau zu diesen Themen: Wie führe ich Leute gut? Aber auch: Wie finde ich gute Experten, Fachleute für mein Unternehmen? Wie überzeuge ich sie für mein Unternehmen? Wie binde ich sie? Wie halte ich sie lange? Da kommt dann übrigens auch die Podcast-Folge wieder ins Spiel, die wir zum Thema “Kunden- und Beschwerdemanagement” gerade mit Oliver aufgenommen haben. Finden, führen, binden der besten Leute – darum geht es bei Talente.co.

Oliver Ratajczak: Super. Das werde ich verlinken. Ich finde das total spannend und ich glaube, darum geht es. Das ist total am Puls der Zeit. Leute, hört euch das an. Ich danke dir.

Michael Asshauer: Tausend Dank, Oliver, es hat mir großen Spaß gemacht.

Oliver Ratajczak: Mir auch.

Michael Asshauer: Mach’s gut. Danke dir.