スクラムがアジャイルでないと感じる人はいますか？

私はアジャイル開発の大ファンであり、数年前に非常に成功したプロジェクトでXPを使用しました。私はそれについてのすべて、反復開発アプローチ、テストの周りのコードの記述、ペアプログラミング、物事を実行するための顧客を現場に持っていることが大好きでした。それは非常に生産的な職場環境であり、私はプレッシャーにさらされているように感じたことはありませんでした。

しかし、私が働いた最後のいくつかの場所はスクラムを使用/使用しました。最近のアジャイル開発の代表的な子であることは知っていますが、アジャイルであることを100％確信しているわけではありません。以下に、私にとって俊敏性を感じない主な理由を2つ示します。

プロジェクトマネージャーは大好き

本質的にタイムラインに夢中になっているプロジェクトマネージャーは、すべてスクラムを気に入っているようです。私の経験では、彼らは時間要件を追跡し、特定のタスクに費やされた時間の記録を保持する手段としてスプリントバックログを使用しているようです。ホワイトボードを使用する代わりに、全員がExcelシートを使用します。各開発者はそれを宗教的に記入する必要があります。

私の意見では、これはアジャイルプロセスのための非常に多くのドキュメント/時間追跡です。タスク自体に取り掛かることができるのに、タスクがどれだけの時間を要するかを見積もるのに時間を無駄にするのはなぜですか。または、同様に、手近な次のタスクに移動できるときに、タスクにかかった時間を文書化するのに時間を浪費するのはなぜですか。

スタンドアップミーティング

私が以前働いていた場所でのスタンドアップミーティングは悪夢でした。毎日、昨日やったことと、その日に何をしようとしていたかを説明しなければなりませんでした。タスクの「見積もり」に時間を費やした場合、プロジェクトマネージャーは悪臭を放ち、タイムラインを順守していないためにあなたが無能であることを示す手段としてスプリントバックログを参照します。

今、私はコミュニケーションの必要性を理解していますが、確かに毎日の会議の雰囲気は軽やかで、知識の共有に焦点を当てるべきです。私はそれがあなたの宿題スタイルのシャレードの場所になるとは思わない。また、アジャイルの重要なポイントは、タイムラインが変更されることであり、それらを固定するべきではありません。

結論

アジャイルのアイデアは、開発者の生活を楽にすることでソフトウェアを改善することです。したがって、私の意見では、チームが使用するアジャイルプロセスは開発者主導である必要があります。プロジェクトマネージャーが、プロジェクトを追跡するために「アジャイル」とラベル付けしたプロセスを使用することは、アジャイル開発と関係があるとは思わない。

誰でも考えますか？

スクラムには、倒錯しやすい特定の要素がありますが、率直に言って、あなたが説明しているのは、すべての利害関係者にそれが何であるか、どのように機能するかについて教育せずにスクラムを採用させようとした結果ですそしてなぜそれが機能するのか。結果を得るには、会社全体で賛同する必要があります。

アジャイルな変革は、組織内で起こっているすべての悪いことを顕在化させます。これには、マイクロマネージャー、独自のアジェンダを持つパワー飢えた人々、不十分な訓練を受けた開発者、コミュニケーションサイロなどが含まれます。そして、あなたは「スタンドアップを行い」、「スプリントで作業する」だけで、スクラムの実装は一見フラットになります。

私はこれを十分に強調することはできません。スクラムをしたい場合は、道を示すことができる有能なコーチが必要です。エッセンシャルスクラムを読んで、それがどこにあなたを導くかを見るだけでは十分ではありません...

はい。アジャイルの「父」の一人でさえ、スクラムが本当にアジャイルであることに同意しません：youtube.com/watch?v=hG4LH6P8Syk – Euphoric

上記のコメントの1つからのこのリンクは本当にすべてを言っていると思います。それは一見の価値があります。ボブおじさんはスクラムの簡単な歴史を語っており、基本的にスクラムはアジャイル開発プロセスではないと言っています。この背後にある理由は、スクラムコースを受講していたのは開発者ではなくプロジェクトマネージャーであったためです。

あなたが説明しているのは、プロフェッショナルスクラムトレーナーが「実装されたスクラム」を持っている組織で多く見ているものです。多くの場合、「開発チームでXPを実行する」こともあります。つまり、ビルドサーバーのどこかでいくつかの単体テストが実行されています。これはスクラムではありません。

はい、プロジェクトマネージャーは製品バックログ（特にデジタル化されたもの）を使用して、そのようなシステムが収集するメトリックから地獄を悪用できます。しかし、開発チームとスクラムマスターは彼を許可すべきではありません。とにかくそこでプロジェクトマネージャーは何をしていますか？それはプロダクトオーナーではありませんか？！

XPがうまく機能せず、より厳密なプロセスが非常に流動的であるように（継続的な統合、展開、しかし非常に計画主導型）、スクラムは単なるフレームワークです。価値とプロセスをよく理解するには、それを実行する良い人が必要です。そこに到達するには、継続的な学習の改善が必要です。

おそらくそれを期待していましたが、一部の（多くの？）人がアジャイルでない方法でスクラムを誤用しているからといって、スクラムがアジャイルではないというわけではありません。

プロジェクトマネージャー：スクラムチームにはそのような役割はありません。スクラムマスターは、予算や会議の期限に責任を負いません。彼は、チームを支援し、彼らがコミットした目標に向かって立っている障害を取り除く責任があります。あなたの説明によれば、あなたのPMはスクラムをハイジャックして、通常はチームとプロダクトオーナーに行く特権を取り、以前の指揮統制の習慣を永続させているようです。

時間の追跡：スクラムは、個々のチームメンバーが費やした時間を指すのではなく、残り時間を追跡して合計することを推奨します。これは詳細に思えるかもしれませんが、非難指向の文化と目標指向のアプローチの間のすべての違いになります。

スクラムガイドから：

スプリントの進行状況の監視

スプリントの任意の時点で、スプリントバックログに残っている合計作業量を合計できます。開発チームは、少なくとも毎日のスクラムごとに残っているこの総作業量を追跡し、スプリント目標を達成する可能性を予測します。スプリント全体の残りの作業を追跡することにより、開発チームは進捗を管理できます。

スクラムはプロジェクト管理方法論です

アジャイルはソフトウェア開発方法論です（-ish）

scrum + agileは非常にうまく機能します

アジャイルのないスクラム...あまりない