Neuerdings wird Scrum mit Kanban verglichen. Keine Ahnung, was das bringen soll. Ich habe in Ken Schwabers Artikel auch nicht verstanden, was beides miteinander zu tun haben soll, ausser, dass sich beide Methoden der Container-Technologie bedienen. Kanban schafft mit physischen Behälter Material an die Produktionslinie, während Scrum Teilziele in zeitlich und umfangmässig begrenzten Paketen erreichen will, die gegenüber äusseren Störungen abgeschlossen sind. Diese Pakete nennt Schwaber “Container”:

… we protect the container from any outside disturbances while the people attempt to bring the problem to a solution. We control the container by time-boxing the length of time that we allow the problem to be worked on… At the end of the time-box, we open the container and inspect the results… By frequently replanning and shifting our work, we are able to optimize value¹

Aber leider kommen die Störungen nicht nur von Aussen. Sehr oft liegen unvorhergesehene Ereignisse im System selber verborgen und brechen auf, wenn man sich mit dem System befasst. Das ist möglicherweise in Entwicklungsprojekten nicht der Fall, ist aber in Integrations- und Migrationsprojekten ganz typisch.

Ich frage mich auch, wie Schwaber die einmal optmierten Teilsysteme ins Gesamtsystem integrieren will. In Integrationsprojekten kann es fatal sein, das zu integrierende System für sich zu optimieren. Wird es dann in die Gesamtumgebung zugeschaltet, kann es den Engineers buchstäblich um die Ohren fliegen.

Die Hoffnung, einzel optimierte Teile ergäben zusammen ein optimiertes Ganzes. entspricht der westlichen “divide et impera”-Kultur. Reduktionisten sprechen dann gerne auch von “Komplexitätsreduktion”. Es ist aber das vornehmste Ziel eines jeden Projekts, die Welt ein wenig komplexer zu machen.

¹Ken Schwaber’s Blog: Telling It Like It Is. Waterfall, Lean/Kanban, and Scrum. June 2010