Podcast Folge #16
Scrum oder wie schnell willst du wissen, dass du ein Problem hast? Björn Jensen im Gespräch.
Björn Jensen, Agile Coach und Trainer für agiles Arbeiten, gibt uns Auskunft über Scrum und agile Methoden. Dabei geht es nicht nur um Softwareentwicklung, sondern um die Führung von Teams und die Umsetzung agiler Transitionen.
Und was ist denn überhaupt Scrum? Einfach gesagt: Scrum ist ein Framework, welches uns hilft wertvolle Produkte leichtgewichtig und inkrementell zu entwickeln. Ein Scrum-Sprint dauert maximal 30 Tage, was es uns ermöglicht die Produkte schneller an neue Ideen anzupassen und ressourcensparend zu entwickeln. Björn entdeckte im Laufe der Zeit einen weiteren Vorteil der Methode: es findet nicht nur ein großartige Produktentwicklung, sondern auch eine geniale Teamentwicklung, statt.
“Und dann schaute ich noch ein wenig dahinter und habe gemerkt, es ist ebenso ein leichtgewichtes Werkzeug um Kollaboration und Zusammenarbeit zu lernen. Und heute blicke ich auf Scrum und sehe, es ist das perfektes Framework um Lernen zu lernen.”
Dass Annahmen zu einem Produkt oder Service validiert oder falsifiziert werden, heißt nämlich auch “blank zu ziehen”. Sich angreifbar zu machen. Wer nach Feedback fragt, sollte mit Antworten rechnen, das kann auch schon einmal weh tun. Wie kann man dieses Feedback verarbeiten? Wie kann ich das prozessieren? Scrum schafft es diese Fragen zu beantworten und einen eigenen Lernprozess für die Organisation mit den Mitarbeitern zu entwickeln.
“Wie schnell wollt ihr eigentlich wissen, dass ihr ein Problem habt?” - Joseph Pelrine
Scrum bringt keine Lösung, sondern hilft Probleme aufzudecken. Alle agilen Frameworks haben diesen Vorteil. Aber alle agilen Framework haben ebenso einen riesigen Nachteil: sie decken Probleme auf. Wenn eine Organisation nicht wissen will, welche Probleme sie hat, ist das agile Vorgehen vielleicht nicht unbedingt das beste. Ganz wichtig dabei ist zu verstehen, dass Scrum dabei nicht die Ursache, für die Probleme ist, sondern das Werkzeug um diese sichtbar zu machen. Und das kommt bei der Verteidigung der Vorstände der Fürstentümer eines Unternehmens nicht gut an. Wenn der agile Coach einsteigt und zu viel transparent macht, kommt oft der Impuls, dass man sich im gegenseitigen Einvernehmen voneinander trennen muss.
Der Weg zum Agile Coach
Erste Gehversuche in der Entwicklung begannen im Februar 2000 mit Extreme Programming und Pragmatic Programming. 2005 entdeckte er dann Scrum und 2008 Kanban. Seitdem “verkorkst” Björn Teams und Unternehmen im Bereich Agile Coaching. Kennengelernt haben wir uns im betahaus Hamburg, Björn in seiner Biker-Kluft coachte einfach mal ein ganzes Team. Man sieht ihm schon an, wie sehr er den Aufbruch und das Neue fördert. Denn Agile ist nicht nur eine Methode, wichtige Erkenntnisse docken auch an die eigene Lebensführung an. So war und ist auch einer der wichtigen Frage für ihn: “Wie kann man sinn- und wertgetriebener Arbeiten, so dass man sich selber mehr mit der Arbeit identifiziert?”
Mit dieser Frage ist er neben den Trainings unterwegs und gibt Kurzimpulse, aber auch in Aufträgen über längere Zeiträume hinweg spielt diese Sinnsuche eine wichtige Rolle. Coaching- und Mentoringprogramme zusammen bilden nun den Fokus seines Unternehmens.
“Scrum Master, Product Owner-Zertifizierungen oder auch Schulungen sind möglich. Ich versuche meine Trainings so zu gestalten, dass die Teilnehmer die Inhalte zu ihren eigenen machen können. Ich halte mich da ungerne an fest vorgeschriebene Rahmen.”
Entwickler und Coach gleichzeitig - wie geht das?
Björn ist eine spannende Spezies: Er ist Entwickler und Coach. Wie geht das zusammen? Als er als Entwickler in Teams gecodet hat, hat er sich immer mehr dafür interessiert, wie man besser zusammenarbeiten kann, als für die eigentliche Entwicklertätigkeit. Vom Coden kommt er nicht los, das bleibt einer seiner Leidenschaften. Der Anfang für ihn war in einem Startup mit drei Mitarbeitern: der Chef, einem anderen Entwickler und Björn. Dieser Entwickler-Kollege war der Inbegriff des Nerds, der Fenster mit Aluminiumfolie auskleidete und über seine eigenen schlechten Witze lachte. Alles in Björn schrie laut “Neeeein” zu der inneren Frage ob so seine Zukunft aussehen soll. Eine zweite wichtige Erfahrung war die Beförderung nach einigen Jahren guter Arbeit bei einem Konzern. Plötzlich war da ein Haifischbecken und er schwamm mittendrin. Schnell wurde ihm klar: dieses Maß an Selbstaufgabe und Verkauf der eigenen Prinzipien will er sich nicht weiter geben, das war er einfach nicht. Politik innerhalb des Unternehmens mitzuspielen, erteilte er also ein klares Nein.
Was hilft Björn ins Tun zu kommen? Wie gestaltet er für sich Veränderung?
Heute ist es ein leichtes für ihn, Freiräume zu nehmen, Headspace zu schaffen und sich rauszuziehen. Experten, wie befreundete Coaches, zu buchen um zu reflektieren gehört für ihn genauso dazu. Das war damals für ihn schwer, getrieben vom Zweifel und dem Hinterfragen seines Wertes. Denn er hat Informatik über einen zweiten Bildungsweg studiert und hat sich tatsächlich gefragt ob das so richtig war. Die fehlende Orientierung und der Zweifel, wie sehr man gerade seine Zeit verschwendet, das waren zwei stets Begleiter. Einem externen Bild oder anderen Ansprüchen gerecht zu werden, dass muss er heute nicht mehr.
Welche Probleme begegnen einem Agile Coach?
- Vererbtes Verhalten. Wir tragen relativ viel Altlasten mit uns herum, oft hört man in Unternehmnen Sätze wie: “Das ist schon immer so gewesen” “Das haben wir nie anders gemacht!”
- Wenn ein Unternehmen alt ist, besteht die Herausforderung darin, sich die Automatismen abzugewöhnen, die seit ewigen Zeiten gelernt sind. Sich neu programmieren; das ist harte Arbeit.
- Teil der agilen Transition ist das Aufbrechen alter Verhaltensmuster, das Mut machen Neues zu erlernen. Je älter die Organisation, deso länger kann es dauern. Wenn es nur von C-Level Personen getrieben wird, gibt es das Problem, dass die Bemühungen oft nicht von langer Dauer sind. Die Vorstände bleiben maximal 4-5 jahre und dann werden ihre Shiny Object Projekte wieder abgeschafft und durch andere ersetzt. Das ist nicht auf nachhaltige Veränderung der Organisation ausgelegt.
Was ist der Auslöser für positive Veränderung für Björn?
“Ich kann niemanden verändern, aber inspirieren. Ihn auf die Reise mitnehmen.”
Irgendwie schafft es Björn durch seine Geschichten Menschen zu berühren, weil sie merken, dass es bei ihnen ähnlich ist und das das Warum für eine Veränderung anfassbar und spürbar wird. Kleine Ankerpunkte setzen und Aha-Momente erzeugen. Egal ob auf Team oder Mitarbeiterebene, wenn er das erlebt, empfindet er die größte Zufriedenheit.
“Es ist meine Aufgabe als Coach dem Team zu helfen, dass die Erkenntnis passieren darf.”
Was heißt es zu scheitern?
Björn hat eine ganz besondere Einstellung zum Scheitern. Er zelebriert die Fehler und lernt daraus umso mehr.
“Meine Beobachtung transparent machen, meine Pfade aufzeigen, um Feedback bitten und dann fragen wie wollen wir mit dieser Situation umgehen? Wenn Kunden sagen, dass es nicht passt ist das für mich völlig ok. Ich glaube aber daran, dass die richtigen Leute zusammen kommen.” Der Trick um Situationen vor dem Scheitern zu bewahren? Kommunikation.
Wie kommunizierst du in heiklen Situation?
Björn kann mit einem hervorragenden Beispiel, das vor allem Entwickler*innen kennen werden aufwarten. Was passiert, wenn die Benchmarks regelmäßig nicht erreicht werden? Wie erkennt man Hindernisse? Es wurden dann die KDM’s getrackt, die “Kannst du mal?” Interessant waren dann die Zahlen. Über 350 KDMs wurden bedient, die Unzufriedenheit in der Review mit den Stakeholdern war mal wieder da, aber das Schweigen war groß als die KDM-Liste rausgeholt wurde mit der dezenten Frage, ob sich vielleicht jemand angesprochen fühlt. Der Begriff dafür? LDS - Lernen durch Schmerzen.