アジャイル

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

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

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

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

スクラムの誤った希望

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

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

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

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

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

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

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

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

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

llc分類cまたはs

誤った希望＃3：重要な貢献者が代表者を会議に送ることができる

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

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

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

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

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

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

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

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

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

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

あなたの期待を洗練する

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

c-corp vs s-corp

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

参加者に力を与える

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

問題に積極的に取り組む

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

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

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

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

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

ふりかえりを使用して問題を解決し、プロセスを反復する

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

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

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

人間の行動に対する色の心理的影響

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

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

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

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

あなた自身のグーグルグラスを作る

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

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

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

基本を理解する

簡単に言うとスクラムとは何ですか？

スクラムは製品開発フレームワークです。チームは2週間ごとに製品の増分をリリースし、クライアントのフィードバックを求めます。このアプローチは無駄を最小限に抑え、クライアントが早い段階でフィードバックを提供する機会を生み出します。

スクラム方法論はどのように機能しますか？

スクラムチームは、2週間のスプリントで実用的な製品の増分を提供します。各スプリントには計画セッションがあり、その間にチームは2週間で実行できる作業量を決定します。製品の所有者は、ユーザーと市場調査に基づいて作業に優先順位を付けます。

なぜスクラムを使用するのですか？

スクラムは、ウォーターフォール開発の代替として使用されます。ウォーターフォール開発では、クライアントは開発サイクルの最後にのみ製品とインターフェイスします。スクラムでは、クライアントは常に新製品の増分をテストし、開発チームにフィードバックを提供しています。このアプローチは無駄を最小限に抑え、クライアントの価値を最大化します。