チームにスクラムとカンバンを導入して治安良くワークさせる話

チームにカンバンを導入する話をします。スクラムをチームに導入しようとしたとき、大体セットでカンバンも導入するかと思います。
ですのでカンバンを導入するときにどうするとうまくいくかと言う点とだいたいみんなこれをやってハマる点の話をしようと思います。

まず最初にチーム自体がJIRAでチケット管理している前提で話をします。Trelloなど他ツールを使っていたりするかもしれませんが私のいるチームは大体JIRAなのでJIRAの話をします。

ここでカンバンを導入しようとすると、大体皆やりがちなのがJIRAのカンバン機能を使うこと
大丈夫、みんなよくやる間違いです

JIRAのカンバンの最大の問題点は「縦に長すぎる」点にあると思っています。パッと見で全体が分かり、常に視界に入る位置にあり、メンバーから常に意識される存在でなければならないカンバンなのに
・わざわざブラウザを開かねばならず
・スクロールしないと全体がわからない
という時点で論外です。全員がブラウザのタブに常にJIRAカンバン常駐させているわけないです。意識の低い人何人かは絶対に常駐させていないので

ではどうするか？

出典 物理カンバンに頼ることになります。
どのスクラムの教科書を見ても物理カンバン推しなのでこれは当然ですね。下手にカスタムする必要はありません。

と言うことでこう言う形になります。

チケットの二重管理にならない？

よく聞かれる質問ですね。
なります。そして当然のコストです。
カンバンだけで管理するとアナログ情報なので計測ができません。計測無くして改善なしなので、これは論外です。
JIRAのみの管理も論外です。チームのために機能するカンバン機能を提供できないJIRAに頼っていても意味がないので。

JIRA以外の第三の選択肢はないか？カンバン機能をいい感じに提供できつついい感じにデータ連携できるツールはないのか？
これもいい質問ですね。ないです。あったらそれがスクラム界のデファクトスタンダードになっているはずなので。

現在の日本のスクラム界のデファクトスタンダードはJIRA＋物理カンバンです。なので私はここは迷う意味は全くないと思っています。
二重管理になると言う問題についても当然のコストであり、かつそのコストを払う選択がベストなんだと考えています。
マンションのオーナーがわざわざ管理会社をかますように。あるいはECサービスの業者が料金の高いヤマトを選好するように。コストを払うことがベストな選択肢のケースは絶対にあります。

JIRAとカンバンの同期の問題について

絶対に導入当初はJIRAとカンバンの内容はズレます。
・カンバン上では終わっていても、JIRA上では終わっていなかったり
・完了したチケットが１週間後に謎の復活を遂げてWIPにいたり（元の付箋は破棄されているので新規で再度付箋が貼られる）
・カンバン上にはレーン数が４つしかないはずなのに、JIRAでは進行中ステータスのチケットが１０以上あったりします。

この問題をどうするか？
初期にはJIRAからデータを取得し、カンバンとJIRAでチケットが同じステータスになっているかを確認するやり方がワークしやすいと考えています。
JIRAのデータはJQLで取得することも可能ですが、JQLでJIRAからデータを取得しそれをDBに突っ込む定時実行バッチを日次で動かした方が便利です。

チケット個別でチェックするのではなく
・レーン数制限とJIRA上の進行中ステータスのチケットの数はズレていないか
・カンバン上の進行中ステータスのチケットの数とJIRA上の進行中ステータスのチケットの数はズレていないか
・長期間進行中のまま停滞しているチケットはJIRA上にいないか
などの観点からSQLを書いて、朝会の折にチェックをかけるとメンバーがJIRAとカンバンの同期に気を使うようになります。

またJIRAからデータが取りやすいのでベロシティの変化や生産性の観点から定量的に計測し、分析しやすくなるのも利点です。