スクラムコミュニティのJim Coplienは、かんばんに代わるものとしてワンピース連続フローを提案している。
“ワンピース連続フローは、結束の固いユニットとして機能している単一のチームや、単一のセル(訳注：少人数制のチーム)(またはスクラムチーム)が仕掛中の作業にいくつかの変更(1回の変更箇所はひとつに限定)を適用する際に実施する。チームは非常に短い期間で少しの分析、少しの設計、少しの実装、少しのテストを一斉に実施する。”
ワンピースフローのセルは、ソフトウェアのペアプログラミングと比較することができる。
“コーダーやテスターはいない。2人の開発者が1つのワークセルで一緒に働き、仕掛中の作業がdone-done-doneになるまで連続的にテストや開発を行う。
Jimは‘スイムレーンスクラム’でプレーする替わりに、チームとして群れを成し、1度に1つのプロダクトバックログアイテムに対して作業することを提唱する。彼は更に、次のように主張し、かんばんに異議を唱えている。
“方法論としてのかんばんは、チームワークを妨げ、スプリントのようなタイムボックス内に合意された仕事を完了しないというリスクを増大させる。”
Samuli Heljoはスクラムからかんばんに遷移する際のコミットメントの欠如に関して同様の所見を述べている。
“最も大きな問題のひとつは、タイムボックスの欠如によって引き起こされた。私たちはリリースやデモの(恐らく持つ必要があった)リズムを事前に定義していなかったのだ。しかし、問題はリズムだけではなかった。コミットメントと‘ポジティブなプレッシャー’の欠如についてもまた問題だった。スクラムでは、タイムボックス化されたスプリントによって、デモでチームが愚かに見えないようなポジティブな雰囲気が培われていく。私は、かんばんにはそのエネルギーが不足していると感じた。”
かんばんコミュニティーでは、Jimの投稿に対するたくさん批判が見られている。かんばんコミュニティーのリーダーで、有名なかんばん本の著者であるDavid Andersonは、かんばんは決してスクラムに取って代わるようなものでも、その他のアジャイルメソッドでもないと考えている。
“かんばんは、スクラムのような方法をもっと上手く適用しようと苦労している人々を助けるための一手段である。”
Liz Keoghは、彼女のブログでこのようなスクラム適用の課題、主にクロスファンクショナルチーム作りについて語っている。
“スクラムを開始する状況には、大抵無理がある。私たちはいつも同じ場所にいるわけではないし、最近は多くのスタートアップや企業が在宅勤務を許容している。また、業界は未だにオフショア開発が安くできるという妄想に悩まされている。多様なスキルを持つ要員を確保することもできないだろう。スキルの習得には時間がかかるのだから。“
もうひとつ、最近のかんばんメーリンググループのスレッドでは、Alan Shallowayがソフトウェア開発でワンピースフローを実施する際の2大困難をより深く議論している。
“1. 仕事が異なる(規模や、誰がそれに取り組む必要があるかによって)
2. 作業を行うために必要なスキルセットとバックグラウンドが、入ってくる仕事と正確にマッチすることはめったにない”
あなたはスクラムやかんばんを実施する際、同じような課題に直面しているだろうか？ワンピース連続フローはその代わりに役立つだろうか？