現場コーチとしてScrumでサービス開発しているチームの支援をしていると、よくディスカッションする話題の1つが「プロダクトバックログアイテム(PBI)の価値や成果をどう考えて、どのように扱うか？」というものです。

このような話題の時、OutputとOutcomeの話をします。

• Outputとは、リリースした機能の数や質のことをここではいいます。
• Outcomeとは、利用者がどう変わったのか？利用者の課題が解決したのか？と利用者視点での効果のようなことをいいます。
  
  • ※Outcomeはビジネス視点からのOutcomeと、利用者視点からのOutcomeの2つに分類されます。上記は利用者視点からのOutcomeのことを書いています。
    
    

たくさんのPBIをつくって頻繁にリリースしてOutputが増えたとしても、自分達にとっての価値、もしくは利用者にとっての価値(利便さや嬉しさ)といったOutcomeが増えていないとそのプロダクトやサービスを続けていくことはできません。

1つずつのPBIの情報に"売上の増える額"や"ユーザー数の増加”を加えているチームもあります。
また別の現場ではストーリーポイントと同じようなやり方で、仮想の単位を決めて相対的な値をチームで話し合って、どれからやるか？の参考にしています。

このセッションでは、"プロダクトバックログアイテムにおける価値の取り扱いのやり方”のいくつかの現場の事例を紹介しつつ、Outcomeについて考えをお話します。
みなさんのPBIのOutcomeがよりわかりやすく、より高くなるヒントになればと思います。

「もっとビジネスのスピードを上げたい」という課題意識があり、それの解決方法として「今までのやり方のままでは難しい。だからアジャイル開発手法を導入したい」と考える企業は多いです。

とはいえ「さあ始めよう」とするにしても、関わる人のマインドや協力会社との関係性、とりまく環境などなど変えて行かなければならないことがたくさんある場合が多く、実際のところそれがなかなか大変だったりします。人も組織もなかなか急には変われないものですよねぇ。

よく直面しがちな課題の例を挙げてみると...

• 受託開発でPOが発注側、DevチームとSMが受注側という関係性
• 復数Devチームだがコンポーネントチーム
• Devチームが個の集団
• 複数POが織りなす複雑なビジョン
• 得られた成果やアジリティが見えない
• POとDevチーム、SMのロケーションが別
• コミュニケーションしづらい座席レイアウト

などなど。

さて、このセッションではこのような課題を抱えつつもスクラムの実践に取り組み奮闘している現場のひとつをケーススタディとして、実際にどんな課題があり、スクラムチームやコーチがどのように取り組み解決を試みたのかの成功談や失敗談をみなさんの参考になるべく紹介したいと思います。

Scrumで「プロダクトバックログアイテム(PBI)の価値をどう考えて、どのように扱うか？」というのは時々聞く質問の1つです。

1つずつのPBIの情報に"売上の増える額"や"ユーザー数の増加”を加えているチームもあります。
また別の現場ではストーリーポイントと同じようなやり方で、仮想の単位を決めて相対的な値をチームで話し合って、どれからやるか？の参考にしています。

このセッションでは、"プロダクトバックログにおける価値の取り扱いのやり方”のいくつかの事例や現場コーチとしての知見や考えをお伝えします。
みなさんのプロダクトバックログがより良くなるヒントになればと思います。

ScrumでもXPでもアジャイルなやり方でプロダクト開発をしていく上で”会話”は大事になってきます。

そのような会話は1対1に限らず、チーム全員、チームとステークホルダーのような複数人である会話することもあります。
そのような場には様々なコンテキスト、利害関係を持った人々が集まることもあり、何もしないで良い結果を得るのが難しい場合もあります。

その場の質を高めるスキルの1つがこのセッションのテーマである”ファシリテーション”です。

ファシリテーションとは、会議、ミーティング等の場で、発言や参加を促したり、話の流れを整理したり、参加者の認識の一致を確認したりする行為で介入し、合意形成や相互理解をサポートすることにより、組織や参加者の活性化、協働を促進させるリーダーの持つ能力の１つ。日常での組織コミュニケーション全般において、ファシリテーション技術は活用される。 (Wikipediaより抜粋)

このセッションでは、スクラムマスターにとって必要なスキルの1つでもあるファシリテーションの難しさや楽しさを、現場コーチとして20以上の現場を支援してきた知見を交えてお話します。

このセッションでは、ある現場の社内アジャイルコーチと、その現場を外部から支援するアジャイルコーチ、2人のアジャイルコーチの視点でお話します。

社外のアジャイルコーチに支援してもらうとき、支援した方・された方、片方の視点からの事例を聞くことはありますが、案外双方の立場からの意見を聞くことは多くありません。ですが、ある一場面をとっても、お互い見えているものや感じていることは違うはずです。

本セッションでは、社外のコーチにチームの支援を最初に相談した時・改善の踊り場に来た時といった各場面で、双方のアジャイルコーチは何を見てどんな行動を起こし、どういう結果となっていったかをお話します。

このセッションでは、アジャイルコーチとして様々な現場のふりかえりを観察、ファシリテートしてきた経験から得た“ふりかえり”の始め方と続け方をお話します。

”ふりかえり”の目的は大きくは以下の2つです。

1. 自分達の仕事のやり方をもっとうまくできるようにすること
2. (うまくできるやり方を考えるために)仕事の手を止めて立ち止まること

この目的を実現するために様々なことにファシリテートするスクラムマスターは意識することがあります(できれば参加者全員が)。

• どのようなデータを収集すればよいか？
• どういう話し合いのやり方をすればよいか？
• 継続的にうまくできるように気をつけることは何か？

また以下のような"ふりかえり"あるあるに出会うこともあります。

• ふりかえりといえばKPTとばかりに同じやり方をしてマンネリしてしまう
• うまくできるようにするアイデアが実行されない
• なんとなく続いているんだけど効果がわからない

このようなトピックをお話することで、みなさんのふりかえりをよくするヒントになればと思います。

あるチームがScrum、XPなどアジャイル手法を用いての開発、またアジャイルな姿勢、ふるまいができるようになってきたとします。
その次のステップの1つとしてアジャイルなカルチャーを他のチームや組織に広げていくことがあります。
それにより、学び続け、変化に対応できる組織となり、不確実な状況を生き残ることができます。

しかしここに至るにはいくつもの壁や難しさがあります。
ギルドワークスの現場コーチでは、様々なクライアントの現場にいる開発チームの改善から始まり、その後、プロダクト、サービスの事業、そして組織の改善まで行っています。

このセッションではそのぶつかってきた壁、壁のアプローチ、その失敗談、また乗り越えることができたお話をします。