Ну так то чем угодно можно управлять по чему угодно ) Я бы посмотрел как вы по скраму будете управлять рисками, коммуникациями, работой с заинтересованными сторонами, мотивацией команды, закупками
Если же вы работаете не в условиях неопределенности, а ведете проекты, в которых итак понятно что делать, не надо себя мучить Скрамом. Скрам нужен там, где создается что-то новое и есть высокий уровень неопределенности.
Не отрицая вышесказанное, хочу заметить что высокий уровень неопределенности и уникальный результат - необходимый, но не единственный и далеко не главный критерий использования Скрама. Ни в одном проекте нет полной определенности. Вообще, недавно появившийся подход Кеневин это троянский конь в индустрии - он неявно всех подталкивает к гибким методологиям. Ни один руководитель проекта не скажет что у него заранее все понятно и никаких сюрпризов точно не будет. У вас высокий уровень неопределенности? Добро пожаловать в Complex домен, вот вам Скрам в помощь. А на самом деле - нет. Мы используем Скрам там где действительно непонятно как двигаться к результату, поэтому мы будем поэтапно экспериментировать, проверяя гипотезы и корректируя курс. И что важно - сказать "Дорогой клиент, мы будем сейчас эскпериментировать за твой счёт, потому что никто не понимает как это делать".
В чем же отличие тогда от классического вотерфолла, с последовательными этапами, кроме нового названия?
В том что классического вотерфолла не существует? ))
Скрам построен на самоуправлении, когда Скрам команде делегируется ответственность за продукт.
Минутку, за продукт полностью отвечает Владелец продукта. Команда, обладая автономностью, сама решает как она будет делать то, что счел нужным PO.
Спасибо за ссылку, интересно почитать. Однако, если задуматься, это все очень плохоже на следующее - если упростить до несколькх фраз - "Многие менеджеры и компании не понимают и не умеют правильно применять классические (предиктивные) подходы. Поэтому мы взяли оттуда некоторые идеи (да, в Скраме ничего революционно нового нет), акцентировали на них внимание, отбросили остальное и придумали Скрам. Попутно для усиления эффекта мы исказили смысл и демонизировали классические подходы. И вот ведь незадача, многие менеджеры снова неправильно поняли суть Скрама, приходится многократно объяснять"
За 2 месяца вывести на рынок новый продукт - производство модульных зданий.
Решение
Вывести новый продукт на рынок по методологии Скрам, что позволит ставить микрозадачи, регулярно отслеживать их статус, выявлять проблемы, мешающие процессу, и оперативно вносить корректировки. Что в итоге и поможет уложиться в 2 месяца.
Я вообще не понял, при чем тут Скрам. А все вышеперечисленное любая другая методология не умеет? Кроме Скрама другие варианты то были вообще?
Я правильно понял, что из 8 недель, отведенных на выполнение проекта, первые 4 недели вы "внедряли Скрам"?
А вы попробуйте сделать ремонт дома по Скрам. Без оценки срока и бюджета ("попробуем и увидим как пойдёт"), с вашим глубоким вовлечением ("мы стяжку залили, норм или переделать?"), без управления закупками ("надо клей плиточный купить, мы понятия не имеем как это сделать") и так далее ))
Вы уже не первый раз пишете о некой "команде ВП". Что это вообще? В Скраме нет этой сущности. Вы в курсе, что "Product Owner — это один человек, а не комитет."?
Да, открываем 7-ю версию PMBoK, домен исполнения "Подход к разработке и жизненный цикл" и вуаля - предиктивные, гибридные, адаптивные подходы, каденции поставок и прочее, целых 20 страниц в помощь менеджеру )
1. Если не вовлечь заказчика в процесс, то в лучшем случае получится не то, что заказчик хочет/ему нужно, а то, что он написал в тз.
Верно, и здесь самое время вспомнить что в PMBoK есть целая область знаний - Управление заинтересованными сторонами, со всякими интересными штуками как реестр заинтересованных сторон, матрица power / interest grid, стратегия вовлечения и прочими. Но это же скучно! Скрам все это спокойно выбросил упростил, и директивным порядком установил - Скрам-мастер берет ключевых стейкхолдеров за воротник и тащит на Sprint Review. Не хотят? Ну значит Скрама не будет. Что делать с остальными заинтересованными сторонами, можно ли привлекать их на другие церемонии, как кого информировать вообще - Скраму это неинтересно, он намеренно неполный. Почитайте где-то в другом месте, да хоть в PMBoK - там то все детально расписано, в отличие от. И тут внезапно появляются мнения "PMI вообще не работает, поэтому будет Скрам". Но постойте...
Тут интереснее даже другое, если задуматься - признаваемые всеми эксперты в отрасли говорят например, что люди самый важные фактор в разработке ПО, и при этом нелинейный и непредсказуемый, и большинство проблем в проектах имеет не технологическую природу, а социологическую (Кобёрн, Демарко). И что предлагает Скрам? Позволю себе побыть критиком.
Полное и безальтернитивное вовлечение заказчика в процесс. А он точно хочет, готов, его спросили? У Agile-вселенной есть ответ - а не хочет вовлекаться, мы ему газ отключим выставим его на Waterfall, вот там он наплачется и сам умолять будет. Как будто других вариантов кроме Скрама и водопада нет.
Мотивация команды методом "представим что у нас все самомотивированные професионалы". А где взять таких, а если нет? А нет самоорганизованной команды - нет Скрама, говорит нам руководство ) Хотя впрочем одно решение предлагает - этим должен заняться профессиональный Скрам-мастер. Где его взять? Обучите или наймите со стороны. Это такой человек, от которого в конечном итоге сильно зависит успех проекта (ок, не проекта а деятельности), но который за результат не отвечает.
Вишенка на торте - Владелец продукта, который один отвечает за всё, по сути. И рынок знает, и бизнес модель заказчика, и кастдев успевает, и с командой плотно работает, направляя её энергию туда куда нужно. Прямо и жнец, и швец и на дуде грец )
Мы тут забываем одну вещь: если бы PMI давал результат, то Agile движение не появилось бы вообще. Другими словами, из статистики мы знаем, что все эти инструменты, которые есть в классических методах в итоге не работают.
По такой логике и гибкие методологии бесполезны - если бы это было не так, PMI / IPMA / Prince2 и иже с ними давно канули бы в небытие - манифесту Agile уже больше 20 лет, Скрам и того старше. Достаточно времени чтобы забыть то, что не даёт результаты, не так ли?
Посмотрите на Chaos репорты - около 30% проектов успешны, около 50% - завершились с проблемами, остальные 20 провалены. И такая статистика плюс минус уже довольно давно, насколько помню (надо поискать и проверить кстати). Более того, где-то видел исследование лет года 3-4 назад, оценка эффекта перехода на гибкие методологии в работе, по-моему там именно Скрам фигурировал - по оценке компаний, рост эффективности около 3-4% отмечен. Можете прикинуть сами, насколько затратен переход на Скрам и окупается ли.
PMI прекрасно работает. Есть условия где Скрам будет лучше, есть человеческий фактор - в PMI сложнее разобраться (на первый взгляд, как мне знаем Скрам тоже с двойным дном штука), сложне работать (то жа замечание про двойное дно в Скраме), он менее хайповый и откровенно скучный, "академический". Поэтому выбор в пользу Скрама часто не основан на глубоком анализе, а банально "модно, современно, заказчик требует".
Ну и да, не так давно ставший известным Cynefin активно тоже к использованию Скрама подталкивает. Ещё аукнется многим )
Такой подход противоречит незыблемой истине: чем раньше QA вовлекается в процесс разработки, тем дешевле обходится исправление багов.
Всё верно, но часто эта незаблемая истина разбивается о суровую реальность - тестировщики на раннем этапе привлекаются для описания DoD для стори, может быть еще для DoR, и собственно на этом все до тех пор пока разработчик не переместит эту задачу на доске в колонку "ready to test". Если только работа не организована по процессу Test Driven Development, но я честно говоря не встречал рабочего симбиоза TDD и Scrum
Недельные спринты? Не представляю, как такое возможно.
Даже на Хабре можно найти материалы по такой работе. Видимо кому-то удаётся, либо команда не парится подсчетом временных затрат на митинги, либо планируют и проводят демо/ретро как-то очень быстро.
Я бы сказал что методика, на методологию он не тянет. Но фреймворком его называют сами авторы. Придуманный и успешно применяемый, кстати, самыми махровыми технарями. В том что его оседлали "эффективные гумманитарии", Скрам не виноват.
Обычно Agile-контракт (внешний или внутренний) подписывают на время (дату), сумму и команду, описывают качество как в обычном проекте, функционал по разному (описывают больше или меньше), но на него не комитятся. Из-за этого опять же обычно так работают только внутренние команды. Если контракт внешний agile, то его чаще всего подписывают как обычно, но делают рамочным (опять же фиксируется дата окончания и сумма, а ТЗ/заказы выдаются помесячно).
Так причем здесь Скрам. Это просто budget cap, лимит бюджета, может быть может не быть - Скрам никак не контролирует и не управляет. Никаких обязательств по срокам и бюджету команда не берет. В PMI за такое "управление бюджетом" сразу канделябром бьют )
Основная мысль про фиксацию возвращает нас к пирамидке. Аксиома: чаще всего с применением всех классических и неклассических подходов в нее уложиться не получается
Я бы это выразил по другому - в PMI или Prince2 есть (хотя и не всегда) обязательства по срокам - бюджету - объему работ. Есть инструменты контроля, есть способы коррекции. В Скраме может быть лимит бюджета, может не быть - Скраму всё равно, он никак не контролирует.
есть какая-то американская статистика по проектам и у каждого собственный опыт
В классических проектах небольшая группа экспертов это все оценивает, затем контрактом фиксирует. При этом возникают проблемы при реализации, на то он и проект, а не процесс. Тогда чем-то нужно жертвовать.
Не соглашусь, в классических подходах есть инструменты удержания проекта внутри треугольника. В Скраме нет. Я вот не совсем понял мысль про фиксацию времени и стоимости в Agile - это как и где, поясните? Каким образом Скрам контролирует попадание в дедлайны и бюджет? Только очень грубые оценки по burndown чартам, основываясь на эмпирическом замере velocity (термин "мощность" тут ближе всего, но большинство считает что это скорость, так что сорри за англицизм). И эта самая велосити нифига не прогнозируема, и в Скраме нет никаких инструментов коррекции если понятно что не укладываемся. Переприоритизация элементов бэклога это в данном случае эрзац, а не инструмент коррекции.
Метод управления, но не всеми вариантами проектов, есть ограничения (минимальные размеры проекта прежде всего).
Я собственно поэтому и не считаю его методом управления проектом, что в нем нет очень многих инструментов, нужных для проекта. Ничего нет о предпроектной активности (анализ и выбор по фин показателям, сбор и анализ требований), нет планирования кроме как "на лету" на ближайший спринт, и очень очень грубо дальше, нет инструментов корреции по срокам, нет управление рисками (кроме опять таки все того же backlog refinement), нет управления стоимостью. Да можно просто открыть PMBoK и читать по главам - по сути кроме части процессов исполнения - ничего больше и нет.
Обратную связь всегда возможно получать. Если даже нет, то это особо ничего не меняет -- лишь добавляет дополнительный этап опытно-промышленной эксплуатации, когда заказчик бужет уже смотреть. При этом Скрам команда с самого начала все так же итеративно поставляет сборки, которые могут быть продемонстрированы заказчику, чтобы показать, что прогресс идет, или отданы отдельной команде тестирования (если уж заказчик не хочет смотреть промежуточные этапы).
Так вы по сути уже нарушили основные принципы Скрама - постоянные инспекция и адаптация. Какая же здесь адаптация? Мы занимаемся самоуспокоением - ну мы же работаем инкременты деливерим, если заказчик их не может или не хочет смотреть - его проблема. От нас пули улетели.
Agile (даже не Скрам) позволяет заказчику уточнять задачу по мере увеличения понимания. Не обязательно запускать Скрам с момента подписания контракта или запуска нового продукта -- какое-то время до начала разработки может проводиться первоначальный анализ, прототипы дизайна и UI, это никак не противоречит Скраму, тк скрывается за абстракцией владельца продукта, а скрам-команда либо еще не начала работать, либо занимается какими-то заранее известными задачами (пишет интеграции с другими системами, например).
Да, согласен. Но тут очень важный момент - чтобы вся эта деятельность не превратилась в эксперименты за счет клиента. Которые вообще никак не противоречат идее Скрама, и даже в общем-то поощряются. РО - единственный, кто отвечает за ценность продукта. Если это человек со стороны заказчика, значит очень повезло. Если с вашей стороны - он должен быть полностью погружен в бизнес заказчика, мне кажется.
Да, в вашем примере это имеет некий смысл. Потому что в том примере, о котором говорил я - а он легко гуглится, модная была картинка, напр https://community.atlassian.com/t5/Agile-articles/Scrum-Artifacts-with-pictures/ba-p/1265154 - скажите мне как из самоката сделать велосипед, а их него авто? ) У вас то как раз то, на что Атлассиан говорит "не надо так делать!" )) Даже к вашему примеру сразу возникают вопросы:
А что вообще клиенту надо, автомобиль для передвижения вероятно? Ок, в первой итерации мы ему дали самай самый MVP, можно катать как тележку. А дальше что? Он сможет поехать на авто с рамой, колесами и кузовом, но без руля и двигателя? Какую ценность он извлечет из сверкающего новым лаком авто который не едет? И какой фидбэк он даст, что мы сможем скорректировать в работе? А не получится так что он покатает руками раму, потом посидит в салоне, порулит, "все Ок, продолжайте парни!" - а в финале, любуясь на сверкающий спорткар, спросит "Супер тачка, а куда тут бетонные плиты то грузить?" Тут изобретать примеры можно долго, но думаю идея понятна - если вы не сможете каждый спринт отгружать ценныйрабочий инкремент и получать по нему фидбэк "да, это то что надо", или "нет, мне нужно совсем другое" - толку от Скрама не будет.
А автор понимает разницу между производственным Канбан родом из Тойоты и Канбан-методом авторства Андерсона? А то кажется что смешались люди и кони.
Ну так то чем угодно можно управлять по чему угодно )
Я бы посмотрел как вы по скраму будете управлять рисками, коммуникациями, работой с заинтересованными сторонами, мотивацией команды, закупками
Может быть частью проекта )
Но это подможество всех активностей по управлению проектом.
Не проектами, а продуктовой разработкой.
Там нет почти ничего для управление проектами.
Не отрицая вышесказанное, хочу заметить что высокий уровень неопределенности и уникальный результат - необходимый, но не единственный и далеко не главный критерий использования Скрама. Ни в одном проекте нет полной определенности. Вообще, недавно появившийся подход Кеневин это троянский конь в индустрии - он неявно всех подталкивает к гибким методологиям. Ни один руководитель проекта не скажет что у него заранее все понятно и никаких сюрпризов точно не будет. У вас высокий уровень неопределенности? Добро пожаловать в Complex домен, вот вам Скрам в помощь. А на самом деле - нет.
Мы используем Скрам там где действительно непонятно как двигаться к результату, поэтому мы будем поэтапно экспериментировать, проверяя гипотезы и корректируя курс. И что важно - сказать "Дорогой клиент, мы будем сейчас эскпериментировать за твой счёт, потому что никто не понимает как это делать".
В том что классического вотерфолла не существует? ))
Минутку, за продукт полностью отвечает Владелец продукта. Команда, обладая автономностью, сама решает как она будет делать то, что счел нужным PO.
Спасибо за ссылку, интересно почитать.
Однако, если задуматься, это все очень плохоже на следующее - если упростить до несколькх фраз - "Многие менеджеры и компании не понимают и не умеют правильно применять классические (предиктивные) подходы. Поэтому мы взяли оттуда некоторые идеи (да, в Скраме ничего революционно нового нет), акцентировали на них внимание, отбросили остальное и придумали Скрам. Попутно для усиления эффекта мы исказили смысл и демонизировали классические подходы. И вот ведь незадача, многие менеджеры снова неправильно поняли суть Скрама, приходится многократно объяснять"
Вам не кажется, что описанный вами инкрементальный способ прямо и недвусмысленно противоречит руководству по Скрам?
Я вообще не понял, при чем тут Скрам. А все вышеперечисленное любая другая методология не умеет? Кроме Скрама другие варианты то были вообще?
Я правильно понял, что из 8 недель, отведенных на выполнение проекта, первые 4 недели вы "внедряли Скрам"?
А вы попробуйте сделать ремонт дома по Скрам.
Без оценки срока и бюджета ("попробуем и увидим как пойдёт"), с вашим глубоким вовлечением ("мы стяжку залили, норм или переделать?"), без управления закупками ("надо клей плиточный купить, мы понятия не имеем как это сделать") и так далее ))
Вы уже не первый раз пишете о некой "команде ВП". Что это вообще? В Скраме нет этой сущности. Вы в курсе, что "Product Owner — это один человек, а не комитет."?
Да, открываем 7-ю версию PMBoK, домен исполнения "Подход к разработке и жизненный цикл" и вуаля - предиктивные, гибридные, адаптивные подходы, каденции поставок и прочее, целых 20 страниц в помощь менеджеру )
Верно, и здесь самое время вспомнить что в PMBoK есть целая область знаний - Управление заинтересованными сторонами, со всякими интересными штуками как реестр заинтересованных сторон, матрица power / interest grid, стратегия вовлечения и прочими. Но это же скучно!
Скрам все это спокойно
выбросилупростил, и директивным порядком установил - Скрам-мастер берет ключевых стейкхолдеров за воротник и тащит на Sprint Review. Не хотят? Ну значит Скрама не будет. Что делать с остальными заинтересованными сторонами, можно ли привлекать их на другие церемонии, как кого информировать вообще - Скраму это неинтересно, он намеренно неполный. Почитайте где-то в другом месте, да хоть в PMBoK - там то все детально расписано, в отличие от.И тут внезапно появляются мнения "PMI вообще не работает, поэтому будет Скрам". Но постойте...
Тут интереснее даже другое, если задуматься - признаваемые всеми эксперты в отрасли говорят например, что люди самый важные фактор в разработке ПО, и при этом нелинейный и непредсказуемый, и большинство проблем в проектах имеет не технологическую природу, а социологическую (Кобёрн, Демарко).
И что предлагает Скрам? Позволю себе побыть критиком.
Полное и безальтернитивное вовлечение заказчика в процесс. А он точно хочет, готов, его спросили? У Agile-вселенной есть ответ - а не хочет вовлекаться, мы
ему газ отключимвыставим его на Waterfall, вот там он наплачется и сам умолять будет. Как будто других вариантов кроме Скрама и водопада нет.Мотивация команды методом "представим что у нас все самомотивированные професионалы". А где взять таких, а если нет? А нет самоорганизованной команды - нет Скрама, говорит нам руководство ) Хотя впрочем одно решение предлагает - этим должен заняться профессиональный Скрам-мастер. Где его взять? Обучите или наймите со стороны. Это такой человек, от которого в конечном итоге сильно зависит успех проекта (ок, не проекта а деятельности), но который за результат не отвечает.
Вишенка на торте - Владелец продукта, который один отвечает за всё, по сути. И рынок знает, и бизнес модель заказчика, и кастдев успевает, и с командой плотно работает, направляя её энергию туда куда нужно. Прямо и жнец, и швец и на дуде грец )
По такой логике и гибкие методологии бесполезны - если бы это было не так, PMI / IPMA / Prince2 и иже с ними давно канули бы в небытие - манифесту Agile уже больше 20 лет, Скрам и того старше. Достаточно времени чтобы забыть то, что не даёт результаты, не так ли?
Посмотрите на Chaos репорты - около 30% проектов успешны, около 50% - завершились с проблемами, остальные 20 провалены. И такая статистика плюс минус уже довольно давно, насколько помню (надо поискать и проверить кстати).
Более того, где-то видел исследование лет года 3-4 назад, оценка эффекта перехода на гибкие методологии в работе, по-моему там именно Скрам фигурировал - по оценке компаний, рост эффективности около 3-4% отмечен. Можете прикинуть сами, насколько затратен переход на Скрам и окупается ли.
PMI прекрасно работает. Есть условия где Скрам будет лучше, есть человеческий фактор - в PMI сложнее разобраться (на первый взгляд, как мне знаем Скрам тоже с двойным дном штука), сложне работать (то жа замечание про двойное дно в Скраме), он менее хайповый и откровенно скучный, "академический". Поэтому выбор в пользу Скрама часто не основан на глубоком анализе, а банально "модно, современно, заказчик требует".
Ну и да, не так давно ставший известным Cynefin активно тоже к использованию Скрама подталкивает. Ещё аукнется многим )
Всё верно, но часто эта незаблемая истина разбивается о суровую реальность - тестировщики на раннем этапе привлекаются для описания DoD для стори, может быть еще для DoR, и собственно на этом все до тех пор пока разработчик не переместит эту задачу на доске в колонку "ready to test". Если только работа не организована по процессу Test Driven Development, но я честно говоря не встречал рабочего симбиоза TDD и Scrum
Даже на Хабре можно найти материалы по такой работе. Видимо кому-то удаётся, либо команда не парится подсчетом временных затрат на митинги, либо планируют и проводят демо/ретро как-то очень быстро.
Я бы сказал что методика, на методологию он не тянет. Но фреймворком его называют сами авторы.
Придуманный и успешно применяемый, кстати, самыми махровыми технарями.
В том что его оседлали "эффективные гумманитарии", Скрам не виноват.
Так причем здесь Скрам. Это просто budget cap, лимит бюджета, может быть может не быть - Скрам никак не контролирует и не управляет. Никаких обязательств по срокам и бюджету команда не берет. В PMI за такое "управление бюджетом" сразу канделябром бьют )
Я бы это выразил по другому - в PMI или Prince2 есть (хотя и не всегда) обязательства по срокам - бюджету - объему работ. Есть инструменты контроля, есть способы коррекции. В Скраме может быть лимит бюджета, может не быть - Скраму всё равно, он никак не контролирует.
Да, у Standish Group есть Chaos reports по годам.
Не соглашусь, в классических подходах есть инструменты удержания проекта внутри треугольника. В Скраме нет.
Я вот не совсем понял мысль про фиксацию времени и стоимости в Agile - это как и где, поясните? Каким образом Скрам контролирует попадание в дедлайны и бюджет? Только очень грубые оценки по burndown чартам, основываясь на эмпирическом замере velocity (термин "мощность" тут ближе всего, но большинство считает что это скорость, так что сорри за англицизм). И эта самая велосити нифига не прогнозируема, и в Скраме нет никаких инструментов коррекции если понятно что не укладываемся. Переприоритизация элементов бэклога это в данном случае эрзац, а не инструмент коррекции.
Я собственно поэтому и не считаю его методом управления проектом, что в нем нет очень многих инструментов, нужных для проекта. Ничего нет о предпроектной активности (анализ и выбор по фин показателям, сбор и анализ требований), нет планирования кроме как "на лету" на ближайший спринт, и очень очень грубо дальше, нет инструментов корреции по срокам, нет управление рисками (кроме опять таки все того же backlog refinement), нет управления стоимостью. Да можно просто открыть PMBoK и читать по главам - по сути кроме части процессов исполнения - ничего больше и нет.
Так вы по сути уже нарушили основные принципы Скрама - постоянные инспекция и адаптация. Какая же здесь адаптация? Мы занимаемся самоуспокоением - ну мы же работаем инкременты деливерим, если заказчик их не может или не хочет смотреть - его проблема. От нас пули улетели.
Да, согласен. Но тут очень важный момент - чтобы вся эта деятельность не превратилась в эксперименты за счет клиента. Которые вообще никак не противоречат идее Скрама, и даже в общем-то поощряются.
РО - единственный, кто отвечает за ценность продукта. Если это человек со стороны заказчика, значит очень повезло. Если с вашей стороны - он должен быть полностью погружен в бизнес заказчика, мне кажется.
Спасибо, рад что усилия потрачены не зря.
Да, в вашем примере это имеет некий смысл. Потому что в том примере, о котором говорил я - а он легко гуглится, модная была картинка, напр https://community.atlassian.com/t5/Agile-articles/Scrum-Artifacts-with-pictures/ba-p/1265154 - скажите мне как из самоката сделать велосипед, а их него авто? ) У вас то как раз то, на что Атлассиан говорит "не надо так делать!" ))
Даже к вашему примеру сразу возникают вопросы:
А что вообще клиенту надо, автомобиль для передвижения вероятно? Ок, в первой итерации мы ему дали самай самый MVP, можно катать как тележку. А дальше что? Он сможет поехать на авто с рамой, колесами и кузовом, но без руля и двигателя? Какую ценность он извлечет из сверкающего новым лаком авто который не едет? И какой фидбэк он даст, что мы сможем скорректировать в работе? А не получится так что он покатает руками раму, потом посидит в салоне, порулит, "все Ок, продолжайте парни!" - а в финале, любуясь на сверкающий спорткар, спросит "Супер тачка, а куда тут бетонные плиты то грузить?"
Тут изобретать примеры можно долго, но думаю идея понятна - если вы не сможете каждый спринт отгружать ценный рабочий инкремент и получать по нему фидбэк "да, это то что надо", или "нет, мне нужно совсем другое" - толку от Скрама не будет.
Так это же не инкрементальный подход, это обычное эволюционное развитие.
Точно так же и любая другая техника создается