Es steht ein besonderes Interview mit einem besonderen Interviewpartner zu einem besonderen Thema an. Zunächst zum Thema: Agilität und Kanban. Seit einigen Jahren weht der frische Wind des "Software-Kanban" durch die Hallen von agilen Software-Schmieden. Während einige nur ein laues Lüftchen beim Durchlüften verspüren, bekommen manche starken Rückenwind und freuen sich über die frische Brise.
Im Interview: Markus Andrezak
Ich bin sehr stolz, den erfahrenen Kanban-Kenner Markus Andrezak für ein Interview über Agilität und Kanban gewinnen zu können. Als weltweit anerkannter Agilist und Kanban-Experte ist er genau der Richtige, um das Zusammenspiel zwischen Kanban und agiler Software-Entwicklung näher zu durchleuchten. Dieses Interview ist das vierte in der Interviewserie der Agilisten. Es folgt ein komprimiertes Gesprächsprotokoll. Viel Spaß!
Hallo Markus. Meine klassische Eingangsfrage: was machst Du beruflich?
Ich war lange im Management des Product Development bei mobile.de für Prozesse und Architektur zuständig, wurde dann Produktchef für die mobilen Produkte (iOS, Android, mobile Portal), werde aber im Mai Produktchef einer anderen Berliner Firma im Web, die ich noch nicht nennen darf.
Ok. Was sind Deine persönlichen Ziele bei der agilen Software-Entwicklung?
Ich will tolle Produkte bauen, die nicht nur in einer Nische 'funktionieren' sondern wirklich Breitenbedarf decken und wirklich in der Breite Wert schaffen.
Produkte sind aber nur so toll wie die Leute, die sie bauen. Deshalb ist mir immer wichtig, eine Firmenkultur mit aufzubauen, in denen alle Mitarbeiter sich verwirklichen und stetig weiterentwickeln können. Ich hoffe das klappt dann auch bei mir selbst! :)
Wie würdest einem Interessierten Kanban in einem Fahrstuhl erklären?
Ich würde sagen, dass man bei Kanban versucht auf sehr natürliche Weise in dem, was man tut, immer besser zu werden. Man versucht das, indem man sein Tun immer künstlich um einen kleinen Tick schwerer macht. Dabei stösst man automatisch immer wieder auf neue Probleme und Herausforderungen - ohne nach ihnen suchen zu müssen. Um einen Nordpol zu haben zu dem man läuft, sagt man: "man will Flow erreichen".
Den Flow visiert man an, in dem man immer weniger Dinge auf einmal erledigt... was in letzter Konsequenz immer schwerer wird. Am Ende, wo man natürlich nie ankommt, ist dann alles um einen herum viel entspannter, weil das Umfeld bewußt gut beherrscht wird.
Warum ist Software-Kanban denn so anders als das "Original" aus der Automobil-Industrie?
In der Automobil-Branche ist das Ziel grundsätzlich ein Anderes. Dort ist es wichtig, die selben Dinge immer wieder zu produzieren - so gut und effizient wie möglich. Deshalb versucht man hier, die Variabilität aus dem Produktionsprozess herauszutreiben.
Bei uns in der Software-Entwicklung werden neue Dinge geschaffen. Hier besteht gerade der Wert in der Variabilität. Deshalb muss unser Kanban so sein, dass es Variabilität zulässt. Ansonsten würden wir ja immer nur "Copy & Paste" machen - und somit keinen echten Wert generieren. Vorsichtig ausgedrückt: Das wäre ganz schlecht.
Ist Kanban eigentlich agil? Und wenn ja: Wieso?
Tja, wenn ich das so genau wüsste. Offen gesagt, ich weiss nicht einmal genau ob es mich wirklich interessiert. ;)
Ich bin mir ziemlich sicher, dass die Werte des agilen Manifests durchaus von Kanban vertreten werden. Ich würde sogar so weit gehen, dass gerade die Werte von Kanban und Lean es erst zu dem machen, was sie sind. Es geht vor allem um Ganzheitlichkeit, Menschlichkeit, Autonomie und die Veränderung von unten. Das macht es dann auch mit den agilen Werten ein bisschen schwer, weil sie - glaube ich - nur ein Ausschnitt der Kanban und Lean-Werte sind.
Kurzum: Ja, Kanban ist für mich persönlich sehr agil. Sogar noch einen Tick mehr als andere Methoden.
Viele "Kanbanista" preisen Kanban als methodisches Allheilmittel an. Ist es das wirklich?
Das ist zuerst einmal gar nicht meine Wahrnehmung. Für mich ist es so, dass Kanban mir eher "passiert" ist als das ich es "angewendet" hätte. So nehme ich das auch bei anderen Kanban-Teams wahr.
Es gibt ja die alte Diskusssion "Scrum vs. Kanban", die ein wenig banal und sinnfrei ist. Meine Vermutung für diese z.T. hitzige Diskussion ist, dass in den "Siegeszug von Scrum" nun einmal Kanban als alternative Methodik auftrat und einige, die gerade Scrum adaptieren, sich auf Kanban einlassen und soz. 'konvertieren'. Doch das nur am Rande.
Tatsächlich haben viele so wie ich mit Kanban die Erfahrung gemacht, Fortschritte machen zu können, die sie vorher nicht realisieren konnten, weil tatsächlich Kanban sich relativ viral über die Erfolge, die man hat, verbreitet.
Ich habe mit einem 3-Mann-Team ganz schüchtern angefangen, um ein ganz konkretes Problem mit Kanban zu lösen. Das haben andere in der Organisation gesehen und den Erfolg natürlich "Schick" gefunden... dann waren es 12... usw. Am Ende hat die ganze Abteilung von 40 Mann mit Kanban gearbeitet, ohne dass ich das großartig gesteuert hätte. Das war einfach eine tolle Erfahrung. Derart viral passiert das auch bei anderen Kanban-Teams.
Also: Erfolgsversprechend? Ja. Allheilmittel? - Nein. Selbstläufer? - Nein.
Was hälst Du von "Personal-Kanban"? Ist das eine Art "Solo-Kanban" für Einzelgänger?
Ich finde Personal-Kanban eine gute Sache, verfolge es aber nicht aktiv oder intensiv. Mir leuchtet es vollkommen ein, dass in dem selbstreflektierten Bereich die Visualisierung mindestens die selbe Kraft hat wie bei uns in der Software-Entwicklung.
Die Visualiserung alleine sind meiner Meinung nach 80% des Geheimnisses, Erfolges und der Kraft von Kanban. WiP limitieren und Pull sind dann noch einmal 10%.
Das genau diese Mittel im kleinen, persönlichen Bereich funktonieren bezweifele ich nicht eine Sekunde. Ich selbst wende es nicht an, weil ich mich gar nicht so sehr meinem Time-Management widmen muss.
Kann jeder Kanban? Anders gefragt: Braucht man Trainer und Coaches, um Kanban anwenden zu können?
Oha! - (kurze Pause) - Ich glaube die Umsetzung von Kanban ohne eine echte, professionelle Einführung ist sehr schwer. Nun, wie man diese Einführung bekommt steht auf einem anderen Blatt. Da kann es besonders unterschiedliche Wege geben.
Nehmen wir mal mein Lieblingsteam in einer Schwesterfirma als Beispiel. Da hat niemand jemals ein Kanbantraining bekommen. Wir haben uns im Sommer auf einer Terasse getroffen, ich habe etwas über Kanban erzählt und Schwupps - wollten sie alle mitmachen.
Sie waren so motiviert, ich musste nur ein paar Mal zu Beginn "dabei sein" und der Rest geschah in kompletter Eigenregie. Das Schöne: Es lief quasi Lehrbuchmäßig! Das ging so weit, dass alle Vorhersagen bzgl. Leadtime und Verringerung der Standardabweichung von Leadtime eintrafen. Auch die Qualität des Codes ist dabei unglaublich gestiegen.
Für mich steht fest: Man kann sich Kanban-Wissen auf ganz viele Arten aneignen. Aber: ohne eine gewisse Grundausbildung ist es schon schwer, den Geist und die Werte leben zu können - und das nachhaltig. Ansonsten wäre die Gefahr des "Slide-Back"-Effektes doch ziemlich hoch.
Kanban wird oft sehr mechanisch beschrieben. Welche essentiellen Werte hat die Kanbankultur?
Ooh. Ja. Das Gerücht der "mechanischen Beschreibung" ist mir auch schon zu Ohren gekommen. Bis heute ist mir nicht klar, wie es dazu kommen kann. Gehen wir mal vom Schlimmsten aus. Stellen wir uns vor, wir wären gar nicht bei uns, in der relativ netten Software-Industrie. ;) Nehmen wir an, wir sind bei Toyota. Dann würden wir erst mal irgendeines der Bücher von Ohno nehmen, um zu verstehen, was die Werte sind.
Und dann - die Überraschung. Da strotzt es nur so von Menschlichkeit, Autonomie, Selbstverwirklichung, ständiger Veränderung, stetiger Verbesseung - und zwar von unten getrieben. Man begegnet dem Manager, der auf dem Gemba lernt und seinen Mitarbeitern mit Respekt begegnen muss, um von ihnen ihre Probleme zu lernen.
Man kann auch Toyota Kata lesen um zu sehen, wie geschickt Toyota einen kleinen Trick einsetzt um eben auf jeder Ebene - von der Strategie, über die Produktentwicklung, bis zur Produktion - immer besser zu werden. Immer getrieben davon, als Firma agil und beweglich zu bleiben. Einen guten, sicheren, angenehmen Arbeitsplatz und tolle Produkte zu bieten. Das ist genau die Ebene, auf der wir die Werte übernehmen.
Welches ist der größte unternehmerische bzw. organisatorische Mehrwert von Kanban?
Der Wohl größte Benefit ist dieser unscheinbare, kleine Schalter im Kopf eines jeden im Unternehmen, der mit Kanban umgelegt wird. Es ist der Schalter, der uns als einzelne an die gemeinsame Arbeit und das gemeinsame Ziel blicken lässt. Es ist der Schalter, der den Fokus auf den eigentlichen produktiven Mehrwert legt.
Das ist das Besondere an Kanban: die ganzheitliche Fokussierung auf den Value Stream von allen Beteiligten.
Woran kann Deiner Meinung nach Kanban in einer Organisation scheitern?
Es ist ja in den vorangegangenen Antworten schon durchgeklungen, dass ein großer Erfolgsfaktor von Kanban die Kultur und die damit verknüpften Werte sind. Fehlt das Werteverständnis, so fehlt auch die Fähigkeit der Entfaltung der Autonomie oder das effektive Delegieren. Ein weiterer Risikofaktor ist sicherlich auch eine mangelnde Objektivität im Umgang mit der Arbeit und den Aufgaben. Es ist besonders wichtig, in Sachfragen die Sachlichkeit im Auge zu behalten.
Das führt mich gleich zur Minderung dieses Risikofaktors: Es ist absolut essentiell, durch eine stringente Umsetzung und objektive, belegte Fakten ein Grundvertrauen in die gemeinschaftliche Aufgabenstellung bzw. Arbeitsweise zu etablieren.
Fakten schaffen Vertrauen.
Ein Rückfall zu den altgedienten und spekulativen "Versprechungen" über Leistung oder Lieferung kann an einem einzigen Augenblick monatelang aufgebautes Vertrauen vernichten.
Versprechungen schaffen Mißtrauen.
Was wäre Dein Wunsch für die zukünftige, moderne Software-Entwicklung?
Ich denke uns allen wäre schon ein großes Stück geholfen, wenn es weniger von diesen unnötigen Territorial-Kämpfen geben würde. Agil oder nicht agil, Scrum oder Kanban, Java oder Scala, Emacs oder Vim - das alles muss nicht sein. Es ist schon verblüffend, wie irrational so ein ganz und gar "rationaler Berufsstand" wie der der Software-Entwickler sein kann. Gut - wir sind alle nur Menschen. Aber - wir sind auch Ingenieure.
Mein wichtigster Punkt dabei: Ich wünsche mir weniger Anekdoten und mehr Analytik. Es ist frappierend, wie heute z.T. Software entwickelt wird. Da werden Mutmaßungen über Vorgehensweisen und Konsequenzen gemacht und zu viel zu vielen Fragestellungen einfach nur vage Aussagen in den Raum geworfen.
Mehr Analytik und mehr Fakten - das bringt uns weiter.
Vielen Dank, Markus!