スクラムの5つの誤った希望とそれらを修正する方法

公開: 2022-03-11

多くの古典的で終わりのない対立のように、開発チームがどのように組織し、自治するべきかについての議論は激しさを増しています。 現在、スクラムのファンよりも批評家の方が多いようです。 最も一般的な3つの苦情は次のとおりです。

  1. このプロセスは、作業の中心となる可能性があります。
  2. 別の名前でのマイクロマネジメントとは簡単に混同される可能性があります。
  3. 毎日のスタンドアップは、その存在を正当化する必要がある会議のように感じることができます。

その他の場合、スクラムの役割が適切に表現されていません。 プロダクトオーナーは、スプリント内であまりにも多くのことを望んでいる場合や、スプリントの途中で優先順位を変更したい場合があります。スクラムマスターは、速度を維持し、学習したすべての新しいスクラムセレモニーを採用することに専念しています。 フレームワークを使用してしばらくすると、よくある質問が出てくるようです。「それは私たちなのか、それとも方法論なのか」。

スクラムの誤った希望

上で概説したような多くの機能障害がありますが、それらのほとんどの単純な根本的な原因は、スクラムが単にプロセスに従うだけで組織内の根本的な問題を解決するように設計されていないことです。 これを認識しないと、新しいチームが開始するとすぐに危険にさらされる可能性があります。

誤った希望#1:スクラムはチームの作業を高速化する

スクラムは速度に関連しています

スクラムは、リソースを追加せずにプロセスを加速するように、部外者に聞こえる用語を使用します。 スクラムの新しいチームとして用語に行き詰まるのは簡単です(たとえば、スクラムマスターとは何ですか?プロダクトオーナーとプロダクトマネージャーの違いは何ですか?ストーリーポイントとは何ですか?それらはどのように割り当てられますか?)

さらに厄介なのは、多くの人がベロシティやスプリントなどの用語を見て「スピード」と考えることです。 ただし、スクラムを含むアジャイル手法の目的は、完成品を提供することです。 最終的に、チームがスクラムの能力を高めるにつれて、新しい機能をより迅速に提供できるようになります。 ただし、速度は必ずしも主要な目標ではありません。 この区別は、スクラムチーム内で明確にする必要があります。また、スクラム手法をサポートするために社内で意識を高める場合にも明確にする必要があります。

あなたはスピードを売っていません。 あなたは完成品を売っています。

誤った希望#2:スクラムを厳守することで企業文化の問題が解決する

働き方は人それぞれです。 会議が好きな人もいます。 「一生懸命働き、一生懸命遊ぶ」などのフレーズを使う人もいます。 あなたの会社がどんな働き方を大切にしていても、あなたはその長所と短所の両方を受け入れていることを認識することが不可欠です。 会議を重視する企業は、日々のスタンドアップに苦労する可能性があります。 攻撃的でスピード志向のチームは、スプリント内のスコープクリープに問題があります。

特に最近結成されたチームの場合、全体像を見失うことがよくあります。 重要なのは、プロセスの最後のすべてを実行するのではなく、完成品を提供することです。 方法論を非難するのではなく、常に目標を達成するためにあなたの働き方を洗練する方法を探してください。

誤った希望#3:重要な貢献者は代表者を会議に送ることができます

方法論を開始したら、委任ではなく元のチームが参加することが重要です。 開発者からのほぼ普遍的な苦情が1つあるとすれば、スクラムマスターとプロダクトオーナーは必要なときに利用できず、その代理人には権限が与えられていなかったということです。 決定を下すことができる人がいないと言われるだけで決定を期待して会議に来るのを好む人は誰もいません。

委任は一般的な方法かもしれませんが、スクラムでは、参加者に権限を与える必要もあります。

誤った希望#4:毎日のスタンドアップは、誰もがより集中することを余儀なくされます

毎日のスタンドアップミーティングは、過去24時間に全員が行ったことだけに焦点を当てるべきではありません。 問題を解決するために、障害物の表面化や新しいアプローチを優先することがはるかに重要です。

スクラムは、特定の役割、特にスクラムマスターが断定的でありながら、圧倒されないようにする必要があります。 スクラムマスターにとって、完成品につながる前向きな環境を作ることが重要です。

誤った希望#5:最初の試みで成功する

スクラムの採用は、最初の試行では成功しない可能性があります

スクラムには、当て推量、演繹的思考、および間違いが含まれます。 人々は最初の試みでそれを正しく理解することはめったにありません。 スクラムは、完成品に到達する方法だけでなく、プロセスを管理および運用する方法においても、すべての点で反復的です。 スクラムは、チームが採用するための参入障壁が低くなるように設計されていますが、フレームワークへの参加を繰り返し、継続的に改善するというコミットメントも必要です。

壊れたスクラムプロセスを修正する方法

スクラムは、埋没費用の誤謬に耐性があります。 スクラムの反復的な性質は、効果のないプロセスを適応または破棄する機会を生み出します。 スクラムプロセスが期待したほど効果的でない場合は、次の提案のいくつかを検討してください。

あなたの期待を洗練する

市場投入までの時間を短縮する場合でも、魅力的な製品を作成する場合でも、チームのコラボレーションを支援する場合でも、成功にはコミットメントと時間がかかります。 新しいチームにとって、達成すべき合理的なマイルストーンは、各スプリントの後に、動作するテスト可能なコードを本番環境に導入できるかどうかです。

高度なチームは、オンデマンドで構築、テスト、および展開する能力によって成功を測定できます。 新機能に対するユーザーの反応を計測して定量化できますか? より広範な組織は、チームが製品に加えている変更をサポートする準備ができていますか?

参加者に力を与える

チームメンバーの価値を高める方法の観点から、チームメンバーをオフラインで指導することが重要です。 彼らが決定を下すように求められている場合は、他のチームメンバーをいつどのように含めるかについて指導することで自信を高めます。 マネージャーは、障害を取り除き、必要に応じてチームをサポートする準備ができている必要があります。

問題に積極的に取り組む

スクラムはあなたの会社にイメージチェンジを与えるようには設計されていません。 問題を解決せずに放置した場合、製品開発プロセスでこれらの問題が表面化する可能性が高くなります。 スクラムマスターは、チームメンバーがフィードバックを構造化して対立感を減らすための前向きな方法を作成するように設計されたフレームワークを導入できます。

フレームワークを与えるスクラムフィードバック

そのような例の1つは、「私が望む、私は疑問に思う、もしも」フレームワークです。 チームディスカッションまたは回顧の際に、チームメンバーはこれらの3つのフレーズのいずれかでステートメントを開くことによってフィードバックを与えることができます。 たとえば、「スタンドアップミーティングで、その日に知っておく必要のある障害にもっと焦点を当てることができればいいのに」と言うことができます。 「Ilike…」などの独自のオープナーを使用することもできます。

会議中に役立つ可能性のあるもう1つの構造化されたフィードバックソリューションは、Brian Robertsonによって作成され、Zapposなどの企業によって使用されているHolocracyのトリアージメソッドです。 たとえば、参加者は話し合うための「緊張」の議題を作成します。 各参加者は、「緊張している」と言って問題を説明し、問題を解決するために必要な人とリソースをリストします。 ホラクラシーは、参加者が問題に「緊張」として直接取り組むことを奨励することにより、参加者が対立の雰囲気を作り出すことなく自由にコミュニケーションできるようにします。

ホラクラシーからのトリアージ方法

レトロスペクティブを使用して問題を解決し、プロセスを反復する

多くの企業では、回顧展は適切な注意を払われていません。 これは主に、回顧展が古い議論、対立、および苦情の場であるという多くの人が恐れているためです。 チームにとって、チームの価値観と企業文化を反映する基本ルールを作成することが不可欠です。

スクラムでは回顧が重要です

同様に重要なのは、静的プロセスへの投資を回避する必要があることです。 一度は機能したものが永遠に機能しない場合があります。 多くのチームは参加者の交代に苦労しています。 これは、参加者が他のチームに再割り当てされたり、昇進したり、会社を完全に辞めたりするため、多くの企業で一般的です。 チームの構成が進化するにつれて、スクラムではすべてが反復的であることにコミットし続けないことが重要です。 間違いは発生しますが、繰り返していくうちに短命になることを願っています。

プリンシパルが存在する場合、スクラムは最適に機能します

チームに参加しているので、あなたは存在し、利用可能であることを約束しなければなりません。 製品開発は、おそらくあなたの会社が長期的な成長を改善するために着手できる最も重要なプロセスです。 したがって、新製品開発への主要なパスとして、スクラムプロセスがそれに値する注目を集めることが重要です。 多くの環境では、開発者チームは、会社の目標を推進する決定や議論から切り離されて作業することがよくあります。 スクラムは違います。 スクラムは、意思決定、方向性、および開発が1つのプロセスとしてまとめられる場所です。 スクラム手法の範囲内で行われる会議から代表者を派遣したり、チームメンバーを除外したりすることは、プロセスにとって非常に重要です。

概要:壊れたスクラムプロセスを修正できます

スクラムは反復的な性質があるため、ビジネスが遠すぎて、悪いアイデアや不十分な実装プロセスになる可能性があることにコミットすることからビジネスを保護するのに役立ちます。 この原則を順守することで、過去の過ちから解放され、スクラムプロセスを繰り返し改善することができます。

あなたが持っている個人とチームに焦点を合わせることが重要です。 チームメンバーが変わります。 すべてのプロジェクトは異なります。 プロセスを厳密に順守しても、必ずしも最良の結果が得られるとは限りません。 プロセス外でチームメンバーに投資することは、プロセス内でどのように行動するかと同じくらい重要です。

スクラムは柔軟にすることができます。 何かが機能していない場合は、アジャイル内外の両方で他のフレームワークの要素を組み込むことを検討してください。 対立的な議論を行う構造化されたコミュニケーションスタイルを特定し、採用します。

スクラムは、変化するクライアントのニーズに応じてチームが完全な製品を構築できるようにすることで、長期的なROIに役立ちます。 スクラムは、優れたアイデアにさらに発展するためのスペースを与えながら、悪いアイデアに過剰にコミットすることを防ぐための最良の方法論です。