Perspektivenwechsel

Kanban-Scrum-Hype-Chat

Johannes Link und Henning Wolf

Am 27.05.2010 unterhielten sich Johannes Link, Henning Wolf und Arne Roock via Skype-Chat über Kanban. Dies ist das (gekürzte) Chat-Protokoll.

[14:06:48] Henning: Johannes, in der letzten Woche gab es eine Diskussion per Twitter darum, ob Kanban wirklich agil ist oder nicht vielmehr nur zur Abbildung von Wasserfällen führt. Du hattest die Diskussion angestoßen. Was sind deine Bedenken gegenüber Kanban?

[14:07:21] Johannes: Meine Bedenken sind eigentlich nicht, dass man nur Wasserfall mit Kanban könnte, sondern dass die Darstellung in Columns mit wasserfallartigen Aktivitäten den Neuling auf dem Gebiet glauben lässt, das wäre die angestrebte Arbeitsteilung bzw. der angestrebte Flow.

Jede Darstellung dieser Art sollte mMn DEUTLICH darauf hinweisen, welche Probleme hinter JEDER Art von Arbeitsteilung stecken und insbesondere hinter der Wasserfallaufteilung Analyse-Entwicklung-Test mit der risikoreichsten Tätigkeit am Schluss.

[14:10:53] Henning: O.K., das kann ich gut nachvollziehen. Allerdings besteht diese Gefahr ja auch bei anderen agilen Teams, die zwar ggf. sogar Unit Tests während der Iterationen anwenden, aber trotzdem auch erst nach der Iteration „richtig“ testen lassen durch eine QA-Abteilung. Das würde ja eine entsprechende Definition of Done auch bei Scrum erlauben, auch wenn wir uns einig sind, dass das nicht sinnvoll ist. Kanban macht das jetzt über die Spalten in gewisser Weise transparent. Du hast aber recht, dass man zu vielen Kanban-Spalten sagen müsste: „Tear down these walls! “

[14:13:46] Arne: Für mich bedeutet es in erster Linie Realismus: Hier stehen wir im Moment. Dann kucken wir, ob uns das gefällt und wie wir uns verbessern können.

[14:14:13] Johannes: Naja, alles, was ich irgendwo aufmale, ohne es deutlich als NEGATIV-Beispiel zu kennzeichnen, birgt die Gefahr, dass der Leser es sich einprägt.

[14:14:31] Arne: Aber es bringt doch auch nichts, die Realität zu leugnen. Wenn mein Prozess im Moment so ist, dann ist er so, und ich muss damit umgehen.

[14:15:12] Johannes: Als Werkzeug für Transparenz finde ich diese Darstellung ja auch passend…

[14:15:22] Henning: Ja, da steckt aus meiner Sicht eben auch ein Vorteil von Kanban: Die geringe Einstiegshürde. Ich mache erst nur den Status Quo transparent, dann muss ich verbessern. Wer das verpasst, behält seine Probleme.

[14:16:38] Johannes: Ich weiß, dass die Möglichkeit zu evolutionärer Änderung gerne als der große Vorteil von Kanban dargestellt wird. Das funktioniert aber auch nur, wenn das Team/die Organisation sehr anpassungswillig ist. In Fällen von großem Widerstand brauche ich oft den radikaleren Umbruch, um überhaupt etwas verändern zu können. Glaube ich.

[14:18:10] Henning: Ich gebe dir explizit recht, Johannes. Ich habe das auch wirklich schon erlebt, dass Kanban irgendwie stecken geblieben ist auf halbem Wege und nicht wirklich genug Änderungen vorgenommen wurden.

[14:18:17] Arne: Oder man ist mit Scrum von vornherein zum Scheitern verurteilt mit dem großen Umbruch…

[14:18:52] Johannes: Mit dem Unterschied, dass ich bei Kanban-But weit aus Kanban hinausgehen muss, um die Probleme zu sehen.

[14:24:39] Henning: Letztlich geht es doch immer nur um Erfolg, wer auch immer den wie definiert. Scrum oder Kanban oder agil oder Wasserfall sind doch nur evtl. Mittel: Jedem, was ihm schmeckt.

[14:25:34] Johannes: Ich habe auch noch ein weiteres Problem mit der gegenwärtigen Kanban-Welle. Wollt ihr es hören/lesen?

[14:25:54] Arne: Natürlich!

[14:25:56] Henning: Aber wir haben das erste doch noch nicht gelöst, oder?

[14:26:11] Johannes: Kanban man irgendwas lösen?

[14:26:17] Arne: ROFL

[14:26:26] Henning: War das erste jetzt die Gefahr, dass Leute glauben, mit den initialen Spalten wäre es getan? Da hilft ja Aufklärung und Information.

[14:26:49] Johannes: Dass sie die Spalten als das Ziel ansehen.

[14:27:09] Henning: OK, das teile ich als Problem, da muss man besser informieren.

[14:27:37] Arne: Für mich ist für Kanban halt Feedback entscheidend – genauso, wie für alle anderen agilen Ansätze auch. Und dann immer wieder kucken, ob man da stehen bleiben will oder wo man sich verbessern kann. Und diese Feedbackmechanismen sieht Kanban auf jeden Fall auch vor – das finde ich wichtig.

[14:28:58] Johannes: Feedback ist zentraler Wert/Technik aller agilen Ansätze, da brauche ich kein Kanban, um mich zu erinnern, oder?

[14:30:34] Johannes: Mein anderes Problem mit Kanban besteht auch darin, dass es von vielen als eine neue agile Methode vorgestellt wird, während es in meinen Augen eigentlich eine 50 %-Untermenge der Lean-Ideen ist, mit einem Namen, bei dem von der ursprünglichen Kanban-Praxis in der Produktion nichts mehr übrig bleibt. Für mich bleibt Kanban am Ende eines von vielen Werkzeugen der agilen Entwicklung und der Scrum-ERGÄNZUNG. Mit einem schlechten Namen, weil er „hypish“ ist. Irgendwie scheint mir Kanban zu Lean so zu stehen wie Scrum zu XP.

[14:31:43] Henning: Hm.

[14:31:45] Arne: Nein, da gibt es einen Unterschied: Lean ist doch total unkonkret. Ich habe noch nie jemanden gesprochen, der Software nach der Poppendieck-Methode entwickelt. Weil es da keine konkreten Praktiken gibt, sondern nur allgemeine Prinzipien. Das ist in Kanban spezifischer und deshalb auch besser anwendbar.

[14:32:55] Henning: Aber es passt, wenn man Scrum als die Quick-Wins von XP sieht; dann ist auch Kanban das Mittel, die Quick-Wins aus Lean heraszuholen.

[14:33:07] Henning: Jeweils ist Scrum/Kanban ein Einstieg und nicht das Ende der Reise. Letztlich bieten Scrum und Kanban leichtere Einstiege in agile oder lean Entwicklung. Es darf da eben nur nicht steckenbleiben. Das ist doch erst mal gut, wenn es mehr Leuten einen Weg offeriert.

[14:37:21] Johannes: Auch Wasserfall bietet einen leichten Einstieg, wenn man sich daran hält. Er liefert nur meist nicht das, was man gerne hätte.

[14:37:50] Henning: Ja, deswegen ist Wasserfall in vielen (aber nicht allen) Fällen Mist.

[14:44:12] Henning: Ich finde attraktiv, dass das Optimierungskriterium ein anderes ist. Bei Scrum: Kontinuierliche flexible Produktentwicklung in hoher Qualität. Bei Kanban: Kurze Durchlaufzeiten. Und noch etwas: Viele Organisationseinheiten an Prozess beteiligt.

[14:46:32] Johannes: Und das findest du nicht etwas kurz gehüpft – lediglich Durchlaufzeiten verkürzen?

[14:46:47] Henning: Nein, warum? Ist doch für viele ein relevantes Problem.

[14:47:39] Arne: Bei den kurzen Durchlaufzeiten ist ja ein Punkt entscheidend: Kanban (wie Lean allgemein) geht davon aus, dass man schnelle Durchlaufzeiten nur _durch_ hohe Qualität erreichen kann.

[14:58:34] Johannes: Hätte noch eine Abschlussfrage an euch: Warum muss/sollte Kanban zu einer eigenen Methode werden? Warum genügt es nicht, Kanban als sinnvolles Werkzeug zu betrachten?

[15:00:01] Arne: David Anderson sagt ja, Kanban ist keine Methode, sondern ein Ansatz zum Change Management…

[15:00:14] Johannes: Also ein Werkzeug?

[15:00:18] Arne: .das man nur zusätzlich zu einer bestehenden Methode verwenden kann (Scrum, Wasserfall, was auch immer)

[15:15:01] Henning: Machs gut und vielen Dank für das Gespräch!

[15:15:06] Johannes: cu

[15:15:13] Arne: Bis Baldrian!

[15:15:19] Henning: Johannes, hoffentlich mal beim Personalgespräch. 😉

Kanban ganz kurz

In Kanban wird in einem ersten Schritt der aktuelle Workflow in Form von Spalten auf einem Whiteboard o. Ä. visualisiert (z. B. Analyse, Entwicklung, Test, Deployment). Anforderungen werden auf Haftnotizen notiert und durchlaufen die Spalten des Kanban-Boards von links nach rechts. Hierdurch werden Engpässe und Blockaden sichtbar, sodass der Prozess kontinuierlich verbessert werden kann. Sprints, Timeboxes und crossfunktionale Teams wie in Scrum sind in Kanban nicht zwingend vorgesehen, können aber auch hier eingesetzt werden.

Johannes Link ist freiberuflicher Coach für Softwareentwicklung. Testgetriebene Softwareentwicklung praktiziert und propagiert er seit beinahe 10 Jahren. Mehr über ihn findet sich auf http://johanneslink.net.
Dipl.-Inform. Henning Wolf ist Geschäftsführer der it-agile GmbH in Hamburg. Er verfügt über langjährige Erfahrung aus agilen Softwareprojekten (XP, Scrum, FDD) als Entwickler, Projektleiter und Berater. Er ist Autor der Bücher „Software entwickeln mit eXtreme Programming“ und „Agile Softwareentwicklung“. Henning Wolf hilft Unternehmen und Organisationen, agile Methoden erfolgreich einzuführen.
Geschrieben von
Johannes Link und Henning Wolf
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.