Jim Benson im Interview zu Personal Kanban

Inhaltsverzeichnis

Personal Kanban soll Entwicklern dabei helfen, ihre Arbeit zu visualisieren und sich den Teller nicht mit neuen Herausforderungen zu vollzuladen. Marcel van Hove hat sich für heise Developer mit Personal-Kanban-Erfinder Jim Benson unterhalten.

heise Developer: Jim Benson, willkommen zum Interview. Könntest du dich kurz vorstellen?

Jim Benson: Ja, gern. Ich bin der Geschäftsführer der Firma Modus Cooperandi und in der IT-Welt sowohl als Kanban-Pionier als auch als Erfinder von Personal Kanban bekannt. Vorher hatte ich eine Firma für Softwareentwicklung, die agile Praktiken genutzt hat. Dadurch wurden mir die Vor- und Nachteile von Agilität klar, wodurch ich mit David Anderson zusammenkam und Kanban für die IT als ein Ideal und eine Methode entwickelt habe. [Anmerkung der Redaktion: Kanban für die IT entwickelte David Anderson 2004 während seiner Arbeit bei Microsoft. Personal Kanban geht auf Jim Benson zurück.]

heise Developer: Also kamst du schon sehr früh mit Kanban und David Anderson zusammen, ihr wohnt beide in Seattle. Und zusammen mit Tonianne De Maria Barry hast du dann Personal Kanban entwickelt und das zugehörige Buch geschrieben?

Benson: Stimmt, die erste Unterhaltung zu Kanban zwischen David und mir fand bei einigen Scotch in einer Kneipe direkt um die Ecke von meinem Haus statt.

heise Developer: Was ist der Kern von Personal Kanban?

Benson: Im Kern hat Personal Kanban zwei Hauptregeln: Die erste Regel ist es, die gesamte Arbeit zu visualisieren, und die zweite Regel lautet, die Tätigkeiten, die man gleichzeitig bearbeitet, zu begrenzen, sich also ein Work-In-Progress-Limit (WiP) zu setzen.

In der Wissensarbeit (knowledge work) und Softwareentwicklung tendieren wir regelmäßig dazu, uns mehr Arbeit aufzuhalsen, als wir eigentlich bewältigen können. Darüber hinaus sehen wir nicht, welche Kosten unsere Wahl der Aufgaben mit sich bringt, da die Aufgaben meist so unterschiedlich und zudem fortlaufend sind.

Die Idee von Personal Kanban besteht daher darin, uns selbst und unserem Team zu zeigen, an was wir gerade und warum wir daran arbeiten, wo sich Möglichkeiten für die Zusammenarbeit ergeben und, das Wichtigste, wo Leute überlastet sind.

Arbeit verbildlichen

heise Developer: Warum ist es so wichtig, die Arbeit zu visualisieren?

Benson: Ein Grund dafür, dass wir uns tendenziell zu mehr Arbeit verpflichten, als wir schaffen können, besteht darin, dass Wissensarbeit unsichtbar ist. Genauso sind es die Versprechen darüber, dass wir diese Arbeit erledigen werden. Wir geben ständig unsichtbare Versprechen, entweder uns selbst oder anderen gegenüber. Wenn wir auf Basis dieser Versprechen arbeiten, sind wir oft überrascht, wie viel Arbeit wir damit wirklich haben. Plötzlich wird uns klar, dass wir ausbrennen, überlastet sind und uns zu viel Arbeit aufgeladen haben.

Das Ziel von Personal Kanban ist es, diese Arbeit in einem Backlog zu visualisieren und zu lernen, wie viele Verpflichtungen ("Commitments") wir wirklich eingehen können. Jedesmal müssen wir nun entscheiden, was das Nächstwichtigste ist, und jedesmal priorisieren wir damit ein Versprechen über ein anderes. Das mögen wir überhaupt nicht, das ist für uns sehr unbequem. Nachdem man jedoch Personal Kanban eine Zeit lang eingesetzt hat, fängt man an zu erkennen, dass man zu viele Dinge verspricht und sich das Backlog mit zu vielen Aufgaben volllädt. Man erkennt, dass man zuerst etwas fertig stellen muss, bevor man noch etwas neues versprechen kann.

heise Developer: Ist das der Unterschied zwischen einer normalen To-do-Liste und Personal Kanban?

Benson: Ja, eine To-do-Liste ist linear, man kann keine Beziehungen zwischen den einzelnen Aufgaben sehen, obwohl es immer Beziehungen gibt. Sie ist einfach nur statisch. Wenn man die Aufgaben auf dem Board verschiebt, sieht man den Arbeitsfluss. Du siehst nicht nur die Arbeit, die du noch zu erledigen hast, sondern auch den Zustand deiner Aufgaben. Du siehst, wie lange ein Ticket wirklich benötigt, bis es fertig ist, und welche Aufgaben Spaß gemacht haben und welche nicht. Welche schwierig waren und welche dir leicht von der Hand gingen. Welche dich nervten, welche du niemals wieder machen möchtest. Es ist ein haptisches System, das du mit deinen Händen fühlst. Im Gegensatz zu einer To-do-Liste, bei der du einfach nur die Arbeit durchstreichst, die du erledigt hast, fühlst du die Bewegung der Post-its (Aufgaben) auf dem Board und hast so ein kinästhetisches Feedback. Es entsteht hierdurch eine Art Lernsystem für einen selbst, während du damit arbeitest. Mit dem Durchstreichen der Aufgaben auf einer To-do-Liste löschst du quasi deine erledigten Aufgaben aus.

Unterschiede

heise Developer: Was ist der Unterschied zwischen Personal Kanban und Kanban, wie man es von David Anderson kennt?

Benson: Es gibt mehrere Unterschiede, aber lass uns auf einige wenige konzentrieren. Der erste Unterschied besteht darin, das sich Personal Kanban stark auf dich als Individuum bezieht, darauf, wie du dich als Person bei deiner Arbeit fühlst. Darüber hinaus sehen andere, an was du gerade arbeitest, und du selbst weißt, welche Arbeit gerade vor deiner Nase liegt und was du selbst zu liefern in der Lage bist. Kanban ("Capital K Kanban") ist mehr auf den ständigen Fluss von Geschäftswert in einer Wertschöpfungskette fokussiert.

Ein anderer Unterschied liegt in der Granularität. Personal Kanban ist fein-granular und richtet sich mehr auf die einzelnen Aufgaben oder sogar Unteraufgaben aus, wohingegen sich Kanban eher auf die User-Story- oder Feature-Ebene bezieht.

Und der letzte Unterschied ist, dass es bei Personal Kanban um psychologische Messgrößen geht. Zum Beispiel: Wie fühlst du dich bei der Aufgabe? Wie viel kannst du erledigen, ohne dich zu überlasten? Dagegen geht es bei Kanban mehr um die Messung von Geschäftszahlen. Zum Beispiel: Was war die Durchlaufzeit? Oder: Wie viele neue Funktionen konnten seit der letzten Woche erstellt werden?

Davids Kanban und Personal Kanban passen sehr gut zusammen, es greift einfach gut ineinander. Wenn ich mit Teams oder Firmen zusammenarbeite, setze ich mit den Teams ein Kanban Board für jedes Team auf und für jeden einzelnen oder jede einzelne Untergruppe ein Personal Kanban Board. So kann jeder sein persönliches WiP-Limit verwalten, während er Teil eines größeren Teams ist, das ebenfalls sein WiP-Limit verwaltet.

Alles nur im Kopf

heise Developer: Ich habe gelesen, dass du dich auch für das Thema "kognitive Wahrnehmungsverzerrungen" ("cognitive biases") interessierst? Um was geht es dabei?

Benson: Das Thema hat viel mit Management und mit Selbstbetrachtung zu tun. Wir messen uns selbst an einem idealisierten Standard, und es ist schwer, gegen ein Ideal zu bestehen. Wir verstehen dabei aber nicht, warum es uns so schwer fällt. Der Grund dahinter sind Wahrnehmungsverzerrungen. Kognitive Wahrnehmungsverzerrungen sind ein Teil der kognitiven Psychologie. Wenn du bei Wikipedia danach suchst, findest du eine Liste von über 160 katalogisierten Wahrnehmungsverzerrungen. Diese finden in unserem Kopf statt und sind dafür verantwortlich, dass wir uns etwas weniger vorhersagbar verhalten und weniger unser eigener Herr sind, als wir denken.

Eine der für mich größten kognitiven Wahrnehmungsverzerrungen wird Planungsfehlschluss ("planning fallacy") genannt. Sie bezieht sich auf das Hofstadter-Gesetz von Douglas Hofstadter. Es besagt, dass Menschen jede Aufgabe, die sie übernehmen, in ihrem Aufwand unterschätzen, selbst wenn sie sich der kognitiven Verzerrung bewusst sind. Diese Wahrnehmungsverzerrung wurde überall auf der Welt getestet, sie scheint über alle Kulturen hinweg zu existieren.

Wir Menschen tendieren also dazu, Aufgaben zu unterschätzen, mit denen wir in Kontakt kommen. Wenn wir uns in den Bereich der Softwareentwicklung oder Wissensarbeit begeben, sehen wir, dass wir uns dort regelmäßig damit selbst geißeln, weil wir eine Aufgabe unterschätzt haben. In Wahrheit ist das einfach nur nicht unsere Stärke. Es gibt eine Million Gründe, warum das nicht unsere Stärke ist, und ich könnte Stunden darüber reden.

Für Personal Kanban, genauso wie für Kanban, ist dieser Sachverhalt wichtig, da uns beide Vorgehensweisen erlauben zu messen, wie lange etwas wirklich gedauert hat. Basierend auf diesen Messungen kannst du in der Zukunft bessere Schätzungen durchführen, indem du deine Annahme, wie lange etwas dauern sollte, damit vergleichst, wie lange es wirklich gedauert hat. Das ist eine riesige Veränderung.

Eine weitere meiner Lieblings-Wahrnehmungsverzerrungen wird Grundirrtum der Zuordnung ("fundamental attribution error") genannt. Er besagt, dass unser Gehirn dazu tendiert, den letzten, den es zu einem Sachverhalt gesehen hat, für den Zustand der Sache verantwortlich zu machen. Stell dir vor, die Entwicklung vieler neuer Funktionen hat 250 Tage gedauert, das Testen dauerte 6 Tage. Wenn die Funktionen nicht rechtzeitig live gehen können, werden die Leute immer die Tester beschuldigen, da sie die letzten waren, die daran gearbeitet haben. Durch die Visualisierung wird dir Kanban eher dabei helfen, systemische Einsichten zu gewinnen, warum du mit dem Testen hinterher hängst, warum etwas geschieht oder warum bestimmte Aktionen bestimmte Effekte auslösen. Auf diese Weise hilft uns Kanban, unsere kognitiven Wahrnehmungsverzerrungen abzumildern und unseren Alltag realistischer zu planen.

Problemlöser

Kaffeeklatsch der besonderen Art

heise Developer: Letztes Jahr wurde dir der Brickell Key Award der Lean System Society verliehen. Soweit mir bekannt ist, war ein Hauptgrund die Erfindung des Lean-Coffee-Formats. Worum geht es dabei?

Benson: Bei Lean Coffee triffst du dich mit Leuten an einem Tisch und baust ein einfaches Personal Kanban Board mit den Spalten To-do, Doing und Done auf dem Tisch vor dir auf. Anschließend bekommt jeder am Tisch ein paar Post-its, auf die er seine favorisierten Gesprächsthemen schreibt. So füllt sich die To-do-Spalte. Anschließend stimmt jeder Teilnehmer für zwei Themen, über die er gerne sprechen würde. So wird das Backlog schnell priorisiert. Dann geht es los, und die Gesprächsthemen werden anhand der Priorisierung besprochen.

Wir haben uns das Format aus zwei Gründen einfallen lassen. Der erste war, dass wir gerne einen Stammtisch zum Thema Lean in Seattle gründen, wir dieses Treffen jedoch nicht selbst betreuen wollten. Wir suchten also einen Weg, wie es sich quasi von selbst organisiert. Wir wollten der Gruppe genau so viel Struktur geben, dass sie nicht auseinanderfällt und noch etwas gemeinsam schaffen kann.

Der andere Grund liegt in der Organisation von Meetings. Zuvor hatten Meetings eine feste Agenda. Diese Agenda wird meist von einer Person geschrieben, wodurch sie zu einer Art Leiter des Meetings wird, der über die Zeit und die Redebeiträge wacht. Mit Lean Coffee hat das Meeting nur noch ein grobes Thema, zum Beispiel das Erschließen des Markts in Afrika, und jeder, der etwas zu diesem Thema zu sagen hat, kommt einfach beim Meeting vorbei. Wenn jemand mit einem Thema zum Meeting kommt, über das kein anderer in der Gruppe sprechen möchte, dann entsteht dadurch kein Kräftemessen zwischen ihm und dem Leiter des Meetings, sondern ein Kräftemessen zwischen ihm und einfach jedem anderen am Tisch. Das scheint Leute ein wenig vor sich selbst zu beschützen und zu verhindern, dass sie einfach ein Meeting mit ihrem Thema stören.

Das ist Lean Coffee – ich liebe es, Lean Coffees zu organisieren – sie sind einfach fantastisch. Mittlerweile werden weltweit regelmäßig über hundert öffentliche Lean Coffees abgehalten.

Derweil in Deutschland...

heise Developer: Die deutsche Übersetzung von deinem Personal-Kanban-Buch ist gerade erschienen. Wurde es bereits in andere Sprachen übertragen?

Benson: Nein, die deutsche Übersetzung ist die erste, die erschienen ist, und im Moment warte ich ganz gespannt auf mein eigenes deutsches Exemplar! Ich freue mich, die Übersetzung endlich zu sehen, und dann werde ich sie ganz ganz langsam lesen, da mein Deutsch eher schlecht ist. Das Buch wurde jetzt gerade ins Französische übersetzt, und eine Übersetzung ins Spanische ist bereits im Gespräch.

heise Developer: Durch dieses Interview interessieren sich nun vielleicht einige Leute für dein Buch. Möchtest du deinen deutschen Lesern etwas mitteilen?

Mehr Infos

Personal Kanban

Das Buch "Personal Kanban" von Jim Benson und Torianne DeMaria Barry ist im Januar 2013 in deutscher Sprache beim dpunkt.verlag erschienen.

Die Autoren beschreiben anhand zahlreicher Fallbeispiele, wie sich mit Personal Kanban Aufgaben durch eine bildliche Darstellung und das Begrenzen paralleler Tätigkeiten effizienter planen und abarbeiten lassen.

Für die Übersetzung war Meike Mertsch verantwortlich. Sie arbeitet seit 2011 bei it-agile als agiler Tester, Trainer, Coach und Entwickler.

Benson: Ich bin mir nicht sicher, ob man das so sagen kann, aber ich hatte auf meinen Reisen eine Unterhaltung mit jemandem, und diese Person fragte mich, warum Personal Kanban in Deutschland so bekannt geworden sei. Seine Vermutung war, dass es für Deutsche so interessant sei, weil sie so systematisch vorgehen und immer sehr exakt wissen wollen, was und wann sie etwas machen sollen. Ich antwortete: Ja, das mag sein, aber darüber hinaus glaube ich, dass Deutsche verstehen, dass die Prozesse und Systeme, die sie bauen, nicht ganz perfekt sind, und diese kognitive Dissonanz nervt die Deutschen. Also nach dem Motto, ich mache etwas, das zwar funktioniert, aber es ist noch nicht perfekt, und ich weiß, es könnte perfekt sein. Genau um dieses Gefühl geht es bei Personal Kanban. Personal Kanban hilft dir mit dem Gefühl konstruktiv umzugehen und dich so schrittweise zu verbessern.

Ich denke, dieser Verbesserungsansatz passt sehr gut zu dem Ansatz, wie Deutsche Probleme lösen.

Das Interview führte Marcel van Hove, der als agiler Berater für it-agile GmbH in Hamburg arbeitet. Sein Spezialgebiet ist die Einführung agiler Arbeitsweisen in Unternehmen. (jul)