アジャイル、スクラムについて学ぶ機会がありましたので、まとめてみました。
まず下記スクラムガイドをさらっとみてみる
何書いてあるかよくわからん。。。。。

そもそもアジャイル開発とは

アジャイルとは「素早い、身軽な、機敏な、頭の回転が速い」という意味の形容詞で、アジャイル開発とは開発手法の一つです。
一つの対象の開発スケジュールを要件をもとに決め、WBS引いて「設計→構築→テスト→リリース」という一連の開発サイクルを行うウォーターフォール型と違い、
一つの機能やビジネスユニットなどの細かい単位で開発サイクルを区切り、何度も開発サイクルを繰り返します。

何度もサイクルを繰り返すことで、変化に対応しやすいという利点があります。
例えばメンバが参画したり辞めたり流動性が高くても、開発サイクルを分けているので変化に強い。
一度テストなどで失敗や抜け漏れがあった場合、次の開発サイクルで対処したり修正に強かったりします。

変化の早い、正解がない不確実な環境で、素早く確認しながら動く必要のある領域に向いている領域
つまり大規模で継続的に新規機能を追加するアプリケーション開発や、長期間でWBSで期間を見積もることが難しく、見積もっても大幅にスケジュールが変動するようなプロジェクトに向いているメリットがあります。

スクラムとは

アジャイル開発でのプロジェクト管理の仕組みの一つです。

アジャイル開発にはデメリットもあります。
メンバが目的ややるべきことなどの共通認識を持っていなければ、

このプロジェクトのゴール（O）はなんだっけ？
達成するための指標（KR）はなんだっけ？
今どこのサイクルで何をやっているんだっけ？
それが終わるのはいつだっけ？
など見失い、結果スケジュールがズルズルと伸びやすいというところがあります。

共通認識を見失わないため、定期的に認識合わせや、成果に対してのレビューを行うような手法＝フレームワークの一つがスクラムです。
他にもXP（エクストリームプログラミング）とかカンバンなどのフレームワークがあります。

スクラムを始めるにあたって

まずスクラムとは手法の一つであり、こうしなければならないというものではなく、プロジェクトメンバで活用することでプロジェクトがうまくいけばなーというものです。
当然プロジェクトを進め、フィードバックが悪ければ改善していくものですし、プロジェクトメンバの性質によっては、手法を変える必要もあります。
つまりここで記載することも正解ではなく、実施しフィードバックをもとに改善していくものなので、そんなものなんだなレベルの理解で問題ないと思います。

上記は2020年のスクラムガイドですが、最新のスクラムガイドはIT以外でもプロジェクトを進める上で採用されているため、下記の2017年バージョンの方がエンジニアとして馴染みがあるかもしれません。