Scrumは過大評価されている

ほとんどの企業は何らかのScrumプロセスに従っています。通常、これは2〜3週間のスプリントを伴います。各スプリントの終わりに変更がデモされ、振り返りが実行され、バックログが整理されます。各スプリント中にタスクの完了時間が記録され、これにより管理者はプロジェクトがいつ完了するかを将来に向けて予測できます。

私が参加したScrumプロジェクトの多くは、タスクに「コミット」することや「オーナーシップを取る」ことを重視しています。スプリントの終わりに、多くのエンジニアが未完了のタスクについて責任を問われます。スプリントベロシティも強調される別のアイデアです。ベロシティを維持しなければならない！まるでソフトウェア作成が競争であるかのようですが、そうではありません。エンジニアがメトリクスによって責任を問われると、彼らはそのメトリクスに最適化します。これは望ましいことではありません。

Scrumはチームが従うべき理解しやすいフレームワークを作成し、管理者に未来を予測するツールを提供します。ウォーターフォールを実践してきたチームはScrumを理解しやすいと感じます。

Scrumの実践の多くは必要ありません。例えば、ほとんどの課題追跡ソフトウェアでは、管理者がチケット完了の頻度に関するレポートを実行できます。この情報により、管理者はベロシティを推測できるため、ベロシティをプロセスに組み込んで大きな問題にする必要はありません。オーナーシップを取ることは見せかけです。私たちは自然にそれを行うので、それを明示的にするのは侮辱的です。私が参加したすべてのプロジェクトで、各エンジニアはアプリケーションの自分のスペースを持っています。

ソフトウェア配信を改善する他の方法：

• 週次デプロイが必要な場合は、スケジュールを組みます。準備ができたものをデプロイします。
• バックログを整理し続けます。そうすればエンジニアが作業不足になることはありません。
• 私の意見では、振り返りは最も重要な非開発活動です。これなしには、より良く効率的な組織になるチャンスはありません。
• 自動化、自動化、自動化
• 機能のリストにコミットするのは馬鹿げています。タスクをランク付けし、できることを完了します。「タスクA」がなぜ完了しなかったかを心配するのは時間の無駄です。そのタスクが大きすぎたか、より優先度の高い作業が引き受けられたかのどちらかであることは明らかです。
• デモは、クライアントが気にかけてフィードバックを提供しない限り、時間の無駄です。
• 日次ミーティングは必要な場合とそうでない場合があります。私は数日おきにミーティングすることを好みます。

結局のところ、最も効率的な方法でクライアントに価値を提供することが重要です。