昨年、私は製品チームを古典的な SCRUM アプローチから Basecamp の Shape Up 手法に移行しようとしました。それは信じられないような経験でした。私はそこから多くのことを学びましたので、その発見の一部を皆さんと共有したいと思いました。 ご自身で実験されたことがあれば、どうだったかぜひお聞きしたいです。そうでない場合は、なぜ離れていたのかぜひ聞きたいです。 パート 1: なぜシェイプアップするのか? 私のチームはずっと SCRUM で動いていました。スタートアップ時代、私たちは古典的な技術サイクルを生きていました。つまり、迅速に作業し、出荷し、プロセスについてはあまり考えませんでした。その後、買収されました。 製品方法論のオプションを検討する時間がもう少しできたら、Shape Up を試してみることにしました。理由はいくつかあります。 それまで、私たちは 2 週間のスプリントに挑戦していましたが、ほぼ一貫して完了できませんでした。毎週は、決して終わらせることのできないチケットがベルトコンベアで運ばれてくるような気分でした。 チームはコードモンキーのように感じました。チケットを選びます。仕事のチケット。チケットをお届けします。 スプリントを完了することがなかったので、タスクは常に次のタスクに波及していました。やがてダムは決壊する。 私たちは皆、集中力を欠いていました。各スプリントは、コードベース全体にわたって取り組むべき事柄の選択と混合でした。 チームワークはほとんどありません。各開発者は自分のパイの小さな部分に取り組むことになり、お互いから学ぶ余地はほとんど残っておらず、率直に言ってコミュニティ感覚も残されていませんでした。 顧客の理解はほとんどありません。開発者は割り当てられたチケットを受け取り、それを完了させますが、なぜ/誰が/何をするのか全く分かりません。 再読後 、それらの問題のほとんどを解決すると主張していたので、試してみることにしました。 ベースキャンプのシェイプアップ パート 2: 社内でのピッチング Shape Up への移行で最も困難だったのは、アイデアを社内に売り込むことでした。 私はシェイプアップのコンセプトのほとんどを理解するために余分な時間を費やし、あらゆる質問に対応できるようにしました。当然のことながら、開発者はこの新しいアプローチのアイデアを気に入りました (より多くの時間、より集中し、より多くのコラボレーションが必要です。なぜそうしないのか!)。 また当然のことながら、階層構造はより寡黙でした。最終的に、私は次の方法で彼らを説得することができました。 それがただのトライアルだったということを確認する。物事がうまくいかなかった場合は、「通常」に戻ります。 私がこれまでと同じように彼らを助けることができるようにするつもりでした。開発者たちは集中していて中断されないでしょうが、私はそうではありませんでした。 シェイプアップを強調することで、より大きな問題を解決できるようになり、より大きなチャンスが得られることを意味します。 製品が現在経験している痛みと、それが各チームにどのような影響を与えるかを主張します。 私は非常に明確なスライド資料を用意し、各部門 (顧客サービス、営業、経営幹部) の責任者にそれを説明しました。 パート 3: 恐怖と懸念 創設者、マーケティング担当者、プロダクト マネージャーとしての私の経験から、実験を開始する前に懸念事項を書き留める価値は常にあると学びました。シェイプアップでいくつか食べました。 「ノーと言う」べきだとわかっています。 '忙しかった。' 「次のサイクルでは、それを検討することができます。」これが理論であり、会社全体がこの方法論に同意すれば機能します。初めてのサイクルトライアル中、緊急事態が発生するのではないかと心配していました。 気を散らすものにどう対処すればよいでしょうか? Shape Up はバックログを残さないことを推奨しています (第 7 章)。これを試しているだけだったので、cmd + a + バックログを削除することはしませんでしたが、それでもです。この方法論を採用する場合、バックログがないとやや迷ってしまうでしょう。 バックログ? これは本当に怖かったです。 6 週間のサイクルの終わりに達し、暫定的にはそこに達しているものの、完全には終わっていない場合はどうなるでしょうか? Basecamp は「やり直し」と言います (よほど接近している場合を除く)。迷惑な 20 ～ 30% の範囲でマークを外すのではないかと心配していました。 'ほとんど終わった。' 結局のところ、これらの恐怖や懸念のどれも、私が裁判を続けることを妨げることはできませんでした。ただし、それらを覚えておく価値はありました。 パート 4: サイクル そして出発です！ 私は月曜日の朝に最初のサイクルを開始し、6 週間にわたる集中力とチームワークを確認しました。毎週起こったことを要約すると次のとおりです。 : キックオフと...沈黙。チームを離れること、研究させること、そして自分の時間にコードに飛び込むことはすべて、この方法論の主要な部分です。最初の 1 週間、何もかも忘れて最新情報を求めないのは、私にとって信じられないほど大変でした。強く持ちましたよ！ 第 1 週 : チームはついに殻を破りました。コミュニケーションが取れました。作品のデザインが現れ始め、フィードバックを与えて一緒に作業するようになりました。 第 2 週 : 理論的には、3 週目は周期曲線の頂点になるはずです。最終的に、チームは、構築する必要があるものをどのように構築するかについて、非常に良いアイデアを持っているはずです。コミュニケーションが適切に増加し始めたので、サイクル固有の Slack チャネルを作成しました。その週の終わりまでに、プロトタイプ、デザイン、コードのスニペットなどが完成しました。順調に進みました！ 3 週目 ：また静かに。第 3 週からのすべてのやり取りにより、全員が作業を実行する中で集中した第 4 週が生まれました。私たちは金曜日の「ショー＆テル」を開始しました。 4週目 : カーブボールの週。スコープの 1 つでかなりのビビリ音が発生し始めました。範囲が十分に明確ではないことがすぐに明らかになりました。要件が十分に正確ではなかったので、最初は素晴らしく単純に見えたものが複雑であることが判明しました。この範囲を削減するという苦渋の決断をしなければなりませんでした。 第 5 週 ：残りのスコープは順調に進んでいます。第 6 週では、私があちこちで QA を行っていたため、その熱量は急激に高まり、開発者たちは私のフィードバックを信じられないほど速く繰り返していました。私たちは目標を達成するためにみんなで力を合わせていました。 6週目 最終的には目標を達成しました。やった！それは非常に強烈で、スコープの1つを切断しなければならなかったのでショックを受けましたが、なんとか成功しました。 次の月曜日の午前 10 時に、本番環境に出荷されました。 パート 5: いくつかのレッスン 順不同で、いくつかの教訓と推奨事項を次に示します。 。サイクルの恐ろしい部分のほとんどをうまく形成できたと思った。結局、私はあからさまに明らかな何かを見逃していたことが判明し、それがサイクル全体を狂わせそうになりました。 整形は難しいです 。私はほとんど自分で、時には開発チームのリーダーと一緒にそれを形作りました。他の開発者を含めることは私にとって価値があったでしょう。 形成中にチームに参加してもらいます 。すべてをやめてください。あなたの優先事項は、他のすべてが完全に狂ってしまう前に、その問題を解決することです。 サイクルの途中で議論したり、形を整えたりしていることに気づいた場合は、何か問題が発生しています 。チームメンバー間であれ、サイクル全体であれ、仕事の強度は大きく異なります。 PM としてのあなたの役割は、これらの激しさの部分を発見し、そこを通過している個人に特別な注意を払うことです。 強度は均等に分布していません 。これにより、コミュニケーションがはるかに簡単になりましたが、さらに楽しくなりました。サイクル チームは、私たちが取り組んでいた作業に関連する共有言語やミームなどをすぐに開発しました。基本的にはチーム内でスタートアップをしているような感じでした。 別の Slack チャネルを作成します 。これを行うには長すぎました。第 1 週の終わりから、見せたり話し合ったりするのに十分な内容があるはずです。また、会ったり、話し合ったり、学んだりする機会でもあります。 1週目からショー＆テルミーティングを実施 。 「その他の仕事」はすべて 6 週間にわたって積み重なっていました。まるでスクラムに戻ったような気分でした。これは私がまだ改善に取り組んでいる点です。 クールダウン期間は、サイクル自体よりもはるかに難しいことが判明しました おそらくお分かりかと思いますが、私はこの裁判で納得しました。 シェイプアップを実装し、その特徴を取り入れることは、確かに一夜にしてできることではありません。それは長い学習プロセスになると思います。この裁判が私たちにもたらした考え方の変化を特に高く評価しています。私たち (そして他のチームも) は、仕事の本質、つまり一緒に乗り越えるエキサイティングな課題であるということを学びました。 これを試したことがある方 (または試していない方) は、ストーリーやフィードバックをぜひお読みください。 この投稿を気に入っていただけたなら、 お楽しみいただけるでしょう。私は製品管理について書いたり、実用的な洞察を共有したり、楽しみのために実際の製品の課題に挑戦したりしています (当然ですよね?)。 私のニュースレターも
