С "что это" разобрались, теперь "зачем это".

Изначально классические методологии управления проектами базировались на строгом соблюдении требований. То есть заказчик подписывает бумажку со списком задач к реализации, а исполнитель обязуется выполнить все в срок.
Ничего плохого в этом нет, но заказчик нет-нет да откажется от какой-то из фич, а другие нужны будут ему раньше.
Из этого родился Agile Manifesto (http://agilemanifesto.org/), люди видели во всем этом большую проблему и пришли с манифестом - мол вот как надо и давайте все вместе будет так делать.

Разница в том, что Agile - это не методология, а культура разработки, на основе которой и появились методологии. Scrum, Kanban, XP и прочие - все это результат внедрения культуры в процесс.
У каждой "гибкой" методологии есть свои преимущества и недостатки. Я не буду покрывать все, так как мы говорим только о Скрам.

Скрам безусловно подойдет командам разработки, которые делают продукт для массового пользования. Когда ваш условный клиент это любой пользователь интернета, объем хотелок может быть просто огромным, и в этом плане Скрам с "беклогом" подходит как нельзя лучше.
Что так же важно, работая по гибкой методике, будучи готовыми перелопатить весь продукт с нуля, вы пишете приложение, взяв за основу правило: "продукт должен быть максимально гибким и расширяемым."
Другим преимуществом является скорость доставки. Вы доставляете не 10 фич через год, а по 2-3 фичи каждый месяц (в зависимости от сложности).

Но у Скрама есть и недостатки. Так, например, ваша команда должна быть кросс-функциональной, что с одной стороны хорошо, но с другой - недостижимо. У вас не может быть разработчика с навыками сисадмина, дизайнера и тестироващика одновременно. Он может "что-то понимать" в этом, но экспертную оценку дать не может по умолчанию. Другой недостаток - строгое соблюдение всех процессов - все без исключения митинги должны быть вовремя, на них должны присутствовать все без исключения. Поверьте, поначалу это кажется нормальным, но в какой-то момент вечные болталки утомляют (разрабы интроверты меня поймут).

Но это уже условности, да и несерьезно жаловаться на календарь полный митингов и синков. Реальная проблема Скрама - не все можно под него подстроить, особенно когда речь идет об инженерном внедрении, а не о разработке.
Скрам хорош, когда у вас маленький продукт, и вы не знаете, что из него вырастет. Другое дело, когда вы внедряете готовый коробочный продукт. Вот, например, SCCM как в нашем случае. Наша проблема была в том, что первые спринты у нас были чистые итерации по установке, настройке и пусконаладке. Итог спринта Скрам - появляется что-то, чем можно пользоваться. У нас же 4 спринта (2 месяца) заняло эту махину собрать, поставить и хоть как-то запустить. Ни о каких deliverables речи и не могло быть.

И в принципе мы не одни такие. Другие инженерные группы (ребята по мониторингу, инженеры-инфраструктурщики, админы баз данных) страдают не меньше нашего, поскольку показывать буквально нечего.

- Что вы сделали?
- Мы обновили прошику роутеров ядра.
- Что мы от этого получаем?

Да ничего вы не получаете, аптайм больше будет. :)

Хотя если вы спросите меня, гибкие методики лучше чем классика, хотя я терпеть не могу Скрам (мне больше Канбан по душе).