動機付けの負債 – それは自然に解決しますよね?
あなたを達成へと駆り立てるものは何ですか?お金?プロモーション?スキルマスター?モチベーションが何であれ、それは問題ありません。前に進むモチベーションがあることに感謝してください。どんな形であれモチベーションがなければ、個人的にも職業的にも停滞し、チーム環境で中傷者になる可能性があります.このブログでは、その罠に陥らないようにする方法と、それが引き起こす一般的な機能障害と動機付けの負債のいくつかについて説明します.
最近、私は会議に出席し、スピーカーが動機付けの負債の概念について話しているのを聞いていました。これは、技術的負債に例えると、定期的に対処して返済しない限り、品質と同様にモチベーションが低下する可能性があるという考えです。解決策と努力がなければ、この負債が発生し、製品の安定性ではなく、スクラム チームの安定性に影響を与えます。長期的には、チームの安定性とモチベーションが重要です。それは基本的に、家を崩壊させる可能性のある「もの」だからです。この話で、製品に集中しすぎて、健全なスクラム チームの基盤の上に製品が構築されていることを忘れてしまう可能性があることを考えるようになりました。
「ほとんどの人は、間違ったことに集中します。彼らはプロセスではなく、結果に焦点を当てています。」
ロンダ・ラウジー
動機付けの負債の症状はチームに固有のものですが、スクラムマスターとして、どのマーカーに注意する必要があるかを検討する必要があります。私のチームで最近見たものは次のとおりです。
- 「これら 2 つのスクラム イベントをマージして、コードの記述に戻ることはできますか?」.開発者は、スプリント レビューとスプリント レトロスペクティブから価値を受け取っていなかったため、それらを改善しようとする代わりに、露出を短くしたいと考えていました。
- 「スプリント目標のその部分を次のスプリントに持ち越します」.コミットメントは自由に与えられましたが、どちらの当事者からも評価されていなかったため、キャリーオーバーが増加し、Done に到達することに集中できませんでした。
- 「私たちライアンのためにこれを直してもらえますか?」.重要だが取るに足らないと思われるタスクをオフロードしようとすると、自己管理の努力が弱まっていることがわかりました。
スクラムでは、注文、可視性、理解を通じて、製品バックログが透明になるように努力しています。私の現在のチームの製品バックログには、過去の不適切な技術的決定に対処する PBI がいくつか思い浮かびますが、不適切なプロセス選択に対処する PBI は 1 つか 2 つしか思い浮かびません。どちらの負債も、表面化した問題の 10% しか表示されないという点で氷山のようなものですが、技術的負債があると、技術者が潜在的な機能不全を推定するのが簡単になります。モチベーションのようにあまり明確に定義されていないものを考えるとき、それが時間の経過とともに自然に修正されないことをどのように知ることができますか?透明性の格差は、部分的には未知のものによって引き起こされます。完全に理解していないものをどのように修正すればよいのでしょうか?動機付けの負債は、製品を提供するための隠れたコストです。古くなった PBI に生じているさび、スプリント バックログの底のスラッジ、何か新しいことをする必要があるときのプロセスのきしみです。
技術的負債は、動機付けの負債が処理するのと同じように、品質に関係します。
動機付けの負債はスクラム チーム全体が負担しますが、それには個々の要素も発生することを覚えておくことが重要です。すぐに跳ね返る短期的なストレス (「昨夜は一睡もできなかった」) とそうでない長期的な緊張 (「両親が病気です」) の両方が、スクラム チームのモチベーションの複雑さの原因となっています。これらに積極的に対処することは、倫理的な難題です。個人によって対処メカニズムが異なるため、助けようとする努力が実際に問題を悪化させる可能性があることを意味します。チーム メンバーの中には落ち込んでいる人もいれば、元気な人もいる可能性があることを忘れないでください。したがって、スクラム マスターとして、プルの全体的な方向性を意識することが重要です。全体論的に言えば、モチベーションの負債は個人的にも集団的にも感じられるものであり、それを最小限に抑えることができる環境を作ることは全員の責任であると言えます.しかし、どうすればこれを行うことができますか?
それについて話し合う
心理的に私たちは他の人の熱意に励まされているため、個人的および専門的な動機について話す環境を作るのに役立ちます.この潜在意識の活動は擬態と呼ばれ、ポジティブにもネガティブにも働きます。お互いの成功と失敗の一部であることは、モチベーションの負債を返済する際に不可欠な連帯感を生み出します. 「それについて話す」ことは、スプリント回顧展への言及だけではないことは言うまでもありません。勤務時間中にチームとしてコーヒーを飲み、ランチタイムの散歩に出かけ、利害関係者とおしゃべりをする時間を作ってください。何かを改善する方法について脳波を持っている場合は、次のスプリント振り返りまで座っているのではなく、次のデイリー スクラムでそれを上げてください。
追跡する
Jira などの管理ツールを使用している場合は、「Motivational Improvements」というエピックを作成し、必要に応じて PBI を追加します。この壮大なプロジェクトに費やされた労力を四半期ごとに追跡して、技術的負債の赤字と動機付けの赤字の両方に対処するために時間を費やしているかどうかを確認してください。そうではないことに気付くでしょうが、それは問題ありませんが、その目的は、スクラム チームと組織が健全で幸せなチームに価値を見出す会話を作成することです。
大切にする
新しい機能、自動化された配信パイプライン、またはプロセスに関与するチームのうち、より価値のあるものはどれですか?善悪を問わず、私はスクラム チームに影響の長さに基づいて注文値を検討するように指導していますが、これは、時速 100 マイルで常に走っている場合は困難です。持続可能なペースで提供することは非常に重要です。これにより、チームの健康を評価し、モチベーションの負債を意識する余地が生まれるからです。ヘルス メトリックを評価することで、それに影響を与えるために必要なアクションを評価します。
根本的に、動機付けの負債は対処するよりも無視する方が簡単な概念上の課題です。それは「ふわふわ」していて、議論の余地のないトピックであるため、自己伝播し、チームの健全性が低下するポイントに到達します.悲しいことに、この穴から抜け出すには、チーム構造のルートとブランチの変更が必要になる可能性があり、これは骨の折れるプロセスです。ここで重要なことは、技術的 (製品) 負債は、動機付け (プロセス) 負債と同じくらい重要であるということです。発生している領域を特定し、タイムリーに実装されるように修正を十分に評価します。じゅうたんの下にある問題をブラッシングしても、それらを取り除くことはできません。問題が大きくなりすぎて、もはや隠すことができない日まで仕事を遅らせるだけです…
…そして、それは私がそばにいたい日ではありません。