Простое и доступное объяснение методологии Scrum, рассчитанное на 2024 год, с основными принципами и примерами применения.

Scrum — это метод разработки, который фокусируется на коротких итерациях и частых выпусках. Он используется при разработке программного обеспечения, но может применяться и в других областях, таких как управление продуктами и управление проектами.

В традиционном процессе разработки программного обеспечения разработчики пишут код, а затем выпускают его в конце процесса. В Scrum команда работает короткими итерациями, называемыми спринтами. Цель каждого спринта — создание рабочего программного обеспечения. Результат каждого спринта известен как инкремент и предоставляется пользователям в конце каждого спринта. Инкремент должен содержать все необходимые функции для нового продукта или функции, запрошенные клиентами или пользователями.

В начале каждого спринта вся команда договаривается о том, что она должна сделать к его концу. Каждый день во время спринта участники собираются для обсуждения прогресса в достижении целей, поставленных на этот день; это собрание называется ежедневным скрам–собранием, потому что участники встают во время обсуждения этих вопросов (чтобы при необходимости можно было быстро уйти).

Scrum — модный способ управления разработкой в айти. На первое место здесь выходит команда профессионалов: если внедрять Скрам будут неумелые ребята, все станет только хуже. В идеале люди в такой команде кайфуют от своей работы, они лояльны и болеют за продукт.

Метод Scrum отлично подходит, когда мы еще не знаем, каким будет наш продукт, не можем предсказать точный результат. Может быть хорош для стартапа и когда нужно улучшить уже существующий продукт.

Правила системы Scrum таковы:

• Владелец продукта отвечает за максимизацию ценности для бизнеса и совместно с командой определяет, какой объем работы может быть выполнен в каждом спринте.

• Команда разработчиков отвечает за реализацию приоритетного бэклога владельца продукта.

• Скрам–мастер следит за тем, чтобы все следовали правилам Scrum, и помогает устранить любые препятствия на пути прогресса.

Разработка делится на циклы (итерации или спринты), итогом каждого цикла — рабочая версия продукта. У каждой задаче есть приоритет. Работа идет по сценариям. Люди превыше всего (Люди превыше процессов). Помощник в работе — доска, на которой отражается статус задач.

Концепция Scrum — это методология разработки продуктов, которую можно использовать для управления любым проектом, независимо от его размера. Она состоит из пяти основных компонентов:

Владелец продукта отвечает за определение приоритетов работы, которая должна быть выполнена, и определение того, когда она будет готова к выпуску. Владелец продукта работает с командой и заинтересованными сторонами, чтобы определить приоритеты того, что должно быть сделано дальше. Этот человек также общается с заинтересованными сторонами о том, как ваша команда продвигается к достижению своих целей, а также о том, что еще предстоит сделать.

Скрам–мастер отвечает за то, чтобы команда придерживалась принципов гибкой разработки программного обеспечения. Для этого он проводит регулярные встречи со всеми участниками проекта и убеждается, что все понимают, как они должны эффективно работать вместе.

Бэклог продукта содержит все элементы, над которыми необходимо работать в течение данной итерации (около двух недель). Он разбит на более мелкие задачи, чтобы каждый человек точно знал, что ему нужно делать в любой момент времени во время спринтов (или недельных периодов).

Каждый день в рамках каждого спринта проводится часовая встреча, называемая ежедневным стенд–апом, на которой все делятся тем, над чем они работали со вчерашней встречи, и обсуждают любые проблемы или препятствия, с которыми они могли столкнуться.

Роли в Скрам описывают, чем занимаются участники команды и за что отвечают. У каждой роли есть свой набор навыков. Например, Владелец продукта имеет лидерские качества, умеет управлять и мыслить как предприниматель. Скрам–мастер умеет все организовать и спланировать, он знает, как помочь людям и отлично разбирается в методологии Scrum.

Роли не нужно записывать в трудовую книжку. Каждый сотрудник может взять на себя одну из ролей и ее обязанности. При этом он может совмещать свою роль с должностью, которую занимает.

Владелец продукта ставит задачи команде и ведет переговоры с заказчиком. Он расставляет приоритеты, когда и над какой задачей кто работает. Для этой роли сотрудник должен иметь лидерские качества, быть авторитетом для команды, уметь вести переговоры.

Скрам–мастер следит, чтобы команда соблюдала правила Скрам, убеждает каждого и объясняет, почему это важно. Он помогает команде организовать работу, следит, чтобы все шло по плану. Если возникают проблемы и задержки, Скрам–мастер первым их замечает и помогает решить. Сотрудник в этой роли должен быть хорошим лидером и организатором. Он умеет вести переговоры и разрешать конфликты.

Скрам–команда создает продукт. В нее входят специалисты, которые нужны для разработки определенного продукта. Например, в команду по разработке мобильного приложения могут входить: UX–дизайнер, iOS–разработчик, Android–разработчик, менеджер. В команду разработки программного обеспечения войдут: UI/UX дизайнер, разработчики, тестировщики, бизнес–аналитик, маркетолог.

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

В книге «Agile Software Development with Scrum» роль Scrum Master описана такими словами: «Scrum–мастер несет ответственность за успех Scrum. Scrum–мастер отвечает за обеспечение того, чтобы ценности, практики и правила Scrum были приняты и соблюдались».

Чтобы Скрам–мастер мог выполнять этот функционал, на его роль ставили лидера команды: тим–лида или руководителя проекта. Считалось, что Скрам можно внедрить только давлением сверху. В некоторых компания вводили правило: если участник команды опоздал на ежедневный Скрам–митинг, он платил 1 доллар Скрам–мастеру.

Сегодня роль Скрам–мастера воспринимают иначе. Это скорее поддерживающий лидер, который помогает, направляет и подсказывает. Команды, которые переходят на технологию Scrum, часто нанимают Скрам–мастера со стороны, а не назначают на его роль лидера команды.

Что делает Скрам–мастер:

Следит за работой команды, чтобы Скрам–команда разбивала работу на части, записывала все задачи и их статусы на доске, внедряла решения ретроспективы, оценивала результаты спринтов.

Помогает организовать и спланировать Scrum мероприятия, объясняет, почему приходить на них важно.

Убирает блокаторы: сломалась кофе–машина и команда не может работать, Скрам–мастер делает все возможное, чтобы машина заработала или находит другой способ сварить кофе.

Скрам гайд — это пдф документ, который поддерживают и редактируют создатели фреймворка Scrum

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

В книге «Agile Software Development with Scrum» роль Scrum Master описана такими словами: «Scrum–мастер несет ответственность за успех Scrum. Scrum–мастер отвечает за обеспечение того, чтобы ценности, практики и правила Scrum были приняты и соблюдались».

Чтобы Скрам–мастер мог выполнять этот функционал, на его роль ставили лидера команды: тим–лида или руководителя проекта. Считалось, что Скрам можно внедрить только давлением сверху. В некоторых компания вводили правило: если участник команды опоздал на ежедневный Скрам–митинг, он платил 1 доллар Скрам–мастеру.

Сегодня роль Скрам–мастера воспринимают иначе. Это скорее поддерживающий лидер, который помогает, направляет и подсказывает. Команды, которые переходят на технологию Scrum, часто нанимают Скрам–мастера со стороны, а не назначают на его роль лидера команды.

Что делает Скрам–мастер:

Следит за работой команды, чтобы Скрам–команда разбивала работу на части, записывала все задачи и их статусы на доске, внедряла решения ретроспективы, оценивала результаты спринтов.

Помогает организовать и спланировать Scrum мероприятия, объясняет, почему приходить на них важно.

Убирает блокаторы: сломалась кофе–машина и команда не может работать, Скрам–мастер делает все возможное, чтобы машина заработала или находит другой способ сварить кофе.

Скрам гайд — это пдф документ, который поддерживают и редактируют создатели фреймворка Scrum

Существуют 5 ключевых событий:

• Планирование

• Stand up

• Обзор спринта

• Ретроспектива

• Очистка бэклога

В Скрам есть определенные церемонии и ритуалы (заклинаний нет). Они нужны, чтобы легче было делить работу над продуктом на кусочки и выпускать в итоге что–то стоящее.

Без этих моментов фреймворк Scrum не Scrum. Есть основные, без которых никак не обойтись. Есть опциональный — какие–то команды их применяют, какие–то от них отказываются.

Начнем с основных и самых важных ритуалов и церемоний.

В целом разницы между Scrum–мастером и Agile–коучем нет. Это человек, который меняет культуру и бизнес–процессы в компании таким образом, чтобы мышление сотрудников двигалось в сторону agile–манифеста, что положительно влияет на финансы компании.

Ключевое различие между Scrum–мастером и Agile–коучем заключается в том, что Scrum–мастер отвечает за то, чтобы у всех участников проекта было все необходимое для успеха. Scrum–мастер следит за тем, чтобы задачи выполнялись вовремя, чтобы команда следовала своим процессам, и чтобы все заинтересованные стороны, вовлеченные в проект, были удовлетворены его ходом.

Agile–коуч, с другой стороны, работает с отдельными членами команды, чтобы убедиться, что они понимают свои роли и обязанности в проекте и могут принимать решения о том, как лучше их выполнить.

Agile–коуч — это консультант, который помогает организациям внедрять agile–практики и процессы.

Scrum–мастер отвечает за помощь команде в достижении целей спринта, следя за тем, чтобы все члены команды четко понимали, чего от них ждут, и чтобы у них были все ресурсы, необходимые для выполнения работы. Скрам–мастер также обеспечивает устранение любых препятствий на пути прогресса, чтобы команда могла сосредоточиться на своих областях ответственности.

Agile–коуч поможет вам научиться лучше общаться и быстрее принимать решения, используя такие практики, как регулярные ретроспективы и ежедневные совещания. Они помогут вам определить ваши цели и составить план действий для их достижения, но они не будут говорить вам, какими должны быть эти цели.

Scrum и Kanban нельзя сравнивать. Нельзя сравнивать фреймворк с методом. Scrum — это процессный фреймворк, который помогает команде понять как взаимодействовать, чтобы выстроить крутой продукт. Kanban — это метод улучшения качества сервиса. Scrum и Kanban могут использоваться вместе и вместе они дадут крутой результат.

Scrum и Kanban — две популярные методологии в Agile, которые часто сравнивают друг с другом. Хотя у них много общих практик, есть и ключевые принципиальные различия.

Напрямую их сравнивать нельзя, так как хотя Kanban и относится к Agile–вселенной, но Scrum — это итерационный метод разработки програмного обеспечения, а Kanban является способом улучшения сервисов и услуг, и Kanban не относится к методам разработки ПО.

Scrum — это agile–методология, разработанная Кеном Швабером и Джеффом Сазерлендом в начале 1990-х годов. Методология состоит из пяти ролей: владелец продукта, скрам–мастер, команда разработчиков, тестировщики и заинтересованные стороны.

Владелец продукта отвечает за управление процессом разработки через четкие цели и критерии приемки. Роль scrum–мастера заключается в устранении препятствий, чтобы команда могла сосредоточиться на своей работе, сохраняя прозрачность своего прогресса.

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

Kanban — это бережливая методология, основанная на потоках ценности, а не на функциях или возможностях, как в Scrum. Она фокусируется на непрерывном совершенствовании путем максимизации пропускной способности и минимизации отходов с помощью методов визуализации, таких как стены из досок или карточек, на которых рабочие элементы размещаются в соответствии с уровнями приоритета, например, один для высокоприоритетных задач или три для низкоприоритетных.

Scrum — это способ организации работы = процессный фреймворк. Суть Scrum заключается в том, что команда делит работу на части и создает продукт вместе с заказчиком. Он лично включается в процессы, постоянно дает обратную связь.

Заказчик следит за созданием продукта на каждом этапе и может вовремя сказать, если результат не такой, как он хочет. При этом команда ведет переговоры с заказчиком: спрашивает, что не так, почему не нравится, что нужно изменить. То есть команда не вносит правки по первому слову заказчика. Она хочет сделать качественный продукт, который решает задачи бизнеса и приносит пользу клиентам. Переговоры помогут выяснить, в чем настоящая проблема и как ее решить.

Методологию Scrum используют, когда команда работает над новым продуктом и точно не знает, каким должен быть результат. Он зависит от обратной связи, от ситуации на рынке и множества других факторов.

Работа по Scrum помогает команде и заказчику быть гибкими. Они готовы к тому, что путь из пункта А в пункт Б не пойдет по ровной прямой. Он может быть извилистым, с препятствиями, и точка Б может оказаться совсем не в том месте, где планировали.

Как может выглядеть путь из точки А в точку Б?

Термин Scrum в теме разработки IT–продуктов впервые прозвучал в 1986 году. Японские разработчики опубликовали в Harvard Business Review статью, где провели аналогию между командной работой и игрой в регби.

В регби «scrum» — это схватка. Элемент игры, когда игроки двух команд после нарушения правил сцепляются вместе и ждут вброс мяча.

В статье говорилось о том, что игроки в регби передают друг другу мяч и вся команда двигается по полю, как одно целое. Таким же должен быть и Scrum в работе над продуктом.

Позднее Джефф Сазерленд и Кен Швабер придумали, как должны работать процессы Scrum и опробовали метод для разработки продукта в компании Easel Corporation. Scrum помог им выпустить продукт почти без багов, сделать это за полгода и уложиться в бюджет.

Сазерленд и Швабер вдохновились успехом и сформулировали методологию Scrum для широкой публики. Они писали статьи в журналы для разработчиков и выступали на IT–конференциях. В основе первых версий Скрам лежал подход заводов Toyota: искать и устранять потери. Тогда была озвучена идея спринтов — коротких итераций, на которые делится работа.

В конце 90-х Сазерленд и Швабер описали шаблоны процессов Скрам, чтобы другие компании могли повторять их и создавать успешные продукты. Так появился фреймворк Scrum — набор правил и принципов: перенимаете их и Скрам работает. В это же время они описали роль Scrum–мастера, человека который устраняет проблемы и помогает команде на всем пути создания продукта.

В 2001-м году Кен Швабер и инженер–программист Майкл Бидл выпустили книгу «Agile Software Development with Scrum». В ней описаны процессы Scrum, роли в команде, встречи и события. Эти правила прижились, их сейчас использую скрам–команды в IT и других сферах, когда надо выпустить продукт.

В ней говорится, что фреймворк Scrum работает, если в команде выделены три роли, созданы три артефакты и происходят пять процессов

Структура Scrum — это три роли в команде, три артефакта и пять процессов. Когда команды начинали осваивать планирование по Скрам, они думали, что можно взять элементы, которые нравятся и это даст нужный эффект. Например, команды часто отказывались от ежедневных стендапов, считали их необязательными.

Об этом узнали создатели метода Scrum и написали книгу «Agile Project Management with Scrum». В ней они описали кейсы разных компаний, которые переходили на Скрам. Разбор кейсов показал, что мероприятия Scrum связаны между собой, одно без другого не работает. Роли, артефакты и процессы во–многом помогают добиться того результата, которого команды ждут от Scrum. Отсюда родилось правило 3-5-3.

Три роли в Scrum: Владелец продукта (Product owner), Скрам–мастер (Scrum Master), Скрам–команда (Scrum Team).

Три артефакта: Бэклог продукта, Бэклог спринта, Инкремент продукта.

Пять процессов: Планирование спринта, Спринт, Скрам–митинг, Ретроспектива, Демо спринта.

Scrum Guide — это руководство по теории и правилам фреймворка Скрам. Его написали создатели методологии — Кен Швабер и Джефф Сазерленд.

Scrum Guide продолжают поддерживать и разрабатывать. Например, если что–то в Скрам перестанет работать, то это уберут из гайда. Если появится новая роль, то ее опишут и добавят в документ.

Скрам гайд помогает найти ответы на следующие вопросы:

• Что такое Scrum

• Как и где его применять

• Что такое бэклог

• Зачем нужен стендап

• Какие бывают роли в команде

• Чем занимается Скрам–мастер

Скрам гайд служит учебником для Скрам–мастеров. Здорово, если его прочитает вся команда и руководство компании перед внедрением фреймворка.

• Разработка делится на циклы, их еще называют итерациями или чаще спринтами. Проще говоря, делим работу на небольшие кусочки и друг за другом их делаем.

• Итогом каждого такого цикла должна быть рабочая версия продукта. Или каждый сделанный кусочек = улучшенный продукт.

• В конце спринта проходит ретроспектива со всеми членами команды. На ней обсуждают прошедшую работу, что там пошло не так, как это можно улучшить в следующий раз. Все в позитивном ключе и не для галочки, а чтобы реально изменить что–то в следующем цикле.

• Каждой задаче присваивается приоритет, он зависит от того, как выполнение повлияет на прогресс продукта. Этому уделяют большое внимание. Нельзя просто так взять и надавать разработчикам задач «сверху».

• Работа идет по сценариям. Не «запилить кнопку регистрации», а «пользователь может войти в личный кабинет через соцсеть ВКонтакте, Инст и Гугл почту».

• Люди превыше всего. В скраме важна дружеская атмосфера в команде. Конфликты будут долго разбирать и решать все вместе.

• Реальная или виртуальная доска, на которой отражается статус задач, типа «Можно брать в работу», «В работе», «На проверке», «Готово».

Все начинается с формирования бэклога или списка с задачами. Их команда должна сделать, чтобы получить новый или улучшенный продукт. Эти задачи — пользовательские истории: сценарии, которые должны быть в продукте.

Пример:

«Пользователь может записывать голосовые сообщения и отправлять их своим друзьям из списка».

В бэклоге каждая задача получает свой приоритет. Он зависит от того, на сколько ее выполнение важно для продукта.

Составлением бэклога занимается product owner (продуктоунер, а переводится как владелец продукта). Часто эту функцию берет на себя Teamlead. Это не заказчик, но человек из команды, которые выполняет его роль. То есть он отвечает за видение продукта заказчиком или тем, как это хотят видеть Топы, СЕО компании. Product owner принимает решения об изменениях в бэклоге или в продукте. Связывает между собой команду и «верхушку» или заказчика, стейкхолдеров.

Когда список задач готов, команда начинает обсуждать и оценивать. Тут они решают, сколько задач взять и за какой период они смогут превратить их в нечто удобоваримое (ну или в стабильную версию продукта, которую можно кому–то показать).

Этот временной отрезок, который команда потратит на кусочек продукта, называется спринт или итерация. В одну итерацию может войти несколько пользовательских историй, это норма.

В идеале спринт длится от одной до четырех недель. В Apple, например, sprint занимает 3 недели. А в Nokia — 6 месяцев (хотя, стоит задуматься, где сейчас Нокиа, а где Эпл).

Чем срок спринта короче, тем более гибким становится процесс разработки. Команда быстрее получает обратную связь, может внести изменения, что–то исправить или улучшить. В большинстве компаний спринт длится 1-2 недели.

Задачи есть, время на их выполнение согласовано. Что дальше? А дальше команда каждый день проводит 15-минутные встречи. На них каждый должен ответить на три вопроса:

1. Что делал вчера?

2. Что буду делать сегодня?

3. Какие есть проблемы в работе над проектом? Что делаю, чтобы устранить их?

Стендапы в идеале должны проходить динамично. Где–то в команду бросают мяч, у кого он в руках, тот и говорит. Где–то включают таймер. В пандемию, когда многие перешли на удаленку, стендапы проводят в формате видеоконференции. И тут главное проснуться к началу, натянуть футболку и сделать бодрый вид.

Проходят стендапы утром, либо днем, если есть разница во времени между офисами. Но всегда в одно и то же время.

Цель всех этих стендапов не бесить участников. А сделать так, чтобы все в команде знали, как двигается работа над задачами, кто тормозит и почему, как ему помочь.

Проходит, как вы догадались, в конце спринта. Тут все показывают, что сделали за цикл и получают обратную связь. Во многих (особенно в продуктовы) компаниях этот этап опускают или заменяют на что–то другое. Например, улучшили что–то в продукте, выкатили на определенную аудиторию, собрали обратную связь, обработали, поправили, выкатили на всю аудиторию продукта.

Но вернемся к классическим церемониям. Длится спринт–митинг от 30 минут до двух часов (наверное, поэтому его многие и пропускают). На нем команда рассказывает, что было сделано, и демонстрирует те части проекта, которые окончательно готовы.

В этом митинге участвует команда, стейкхолдеры, заказчики, product owner и скрам–мастер. Последний — тот человек, что контролирует весь процесс работы над проектом. Он организует спринты, стендапы и митинги. Следит за порядком на доске, чтобы никто не завис на какой–то задаче, и все вовремя отмечали ход работы. Выявляет проблемы и узкие места. Типа, сломался у дизайнер ноутбуку, Скрам–мастер позаботился и быстро достал новый. Или команда пожаловалась, что кофе–машина плохо работает, поэтому на утренних стендапах все вялые. Скрам–мастер постарался и все починил сам или нашел ремонтника.

Она же ретро. Проводится в последний день спринта. Длится от 60 минут до двух часов (например, для двухнедельного спринта). Участвуют: команда проекта, Scrum–мастер, product owner или тимлид.

На ретроспективе нужно оценить, хорошо команда справилась или нет. Если есть трудности, то их разбирают подробно. Затем находят решения и выписывают план действий. Постоянные улучшения — важная часть философии Agile, ну вы помните.

Также смотрят на те моменты, которые дали хороший результат. Это в тексте может выглядеть глупо и странно. Но на деле это реально помогает команде не закапываться в плохом, а начинать сразу с позитива.Например, мы сделали все, что запланировали в этот спринт, ура!

Как должна проходить ретроспектива в идеальном мире:

1. Все позитивны и бодры. Не фокусируются на плохом. Отвечают: что было хорошо, но мешало? Думают, как устранить все плохое в будущем.

2. Участники могут заранее, ну или прямо на ретро, писать тезисно, что в спринте было отлично, где возникали препятствия, делиться идеями по улучшению к следующему спринту.

3. Потом все дружно голосуют и составляют план улучшений.

4. Если идеи изменений крутые, но слишком сложные и длинные по реализации, их иногда даже включают в бэклог.

Герой истории — NX Studio. Это студия разработки социальных и мобильных игр. Начинали с команды меньше 10 человек. Уже применяли на этом этапе элементы Scrum, но не по учебнику. Были спринты, выстроенная команда.

Но весной 2020-го выпустили успешную игрушку и резко начали расти, появилось много новых крутых проектов, их начали приглашать для совместной разработки. Людей в компании стало больше, появилось много команд, а не одна. Задумались можно ли стать еще круче и эффективнее прямо здесь и сейчас. И чтобы все по Scrum.

Обратились в специальную компанию, чтобы им помогли отладить и настроить все процессы. Начали с разделения дизайн–команд и бэклогов. Причем сотрудникам предложили самим решить как поделиться на команды. Все участники осознали, что разговоры и церемонии вокруг задач — это тоже часть работы. И заниматься этим полезно и нормально.

Продюсер компании NX Studio Дмитрий Цуканов заметил: «Теперь при встрече с новой задачей мы сами сначала ищем уже существующие готовые решения. Даже если они нам не нравятся, мы сначала пробуем что–то внедрить, а потом делаем выводы. Как оказалось, большинство лучших мировых практик имеют свое обоснование. Конечно, мы уже потом добавляем свое дизайнерское видение, такой подход кажется более правильным».

1. Довольные и мотивированные сотрудники. Неформальное общение, возможность высказываться и предлагать. Кайф же?

2. Отсутствие ненужной бюрократии и документации. Как Apple сильно заморачиваются над продуктами, и выпустить новый гаджет им куда важнее, чем крутую инструкцию по его использованию. Ее можно делать и после презентации.

3. Заказчик получит продукт, который купят. Потому что постоянно есть обратная связь и та самая гибкость в работе.

4. Скрам можно использовать даже в небольших стартапах.

1. Сложно собрать команду профессионалов. Да еще так, чтобы им было комфортно работать и общаться друг с другом.

2. Людей нужно обучить работе со скрам. А это время и деньги.

3. Сложно избежать ошибок в планировании. Особенно на старте. Времени на задачи закладывают то слишком много, то слишком мало.

4. Жесткое следование церемониям. Проект разбивается на части, которые делают в несколько спринтов. Со всеми митингами, ревью и ретроспективами.