Работая в разных компаниях с разными командами, я замечаю, что все по-разному понимают как должен работать Scrum. В своей заметке я попытался собрать основные проблемы понимания и дать свои комментарии. Если у вас есть примеры искаженного понимания Scrum, пожалуйста, поделитесь в комментариях.
Scrum - это вариант организации разработки, который ориентирован на максимально быстрое получение обратной связи. Он реализует PDCA (или PDSA) цикл с короткими итерациями работы. Scrum содержит в себе и фреймворк, и ценности, и философию.
Почему так много споров вокруг Scrum? Это работает?
Гибкие подходы к организации работы часто критикуют за то, что они не дают гарантированного результата (как-будто все другие дают). На самом же деле Scrum и не обещает нам результат, он помогает организовать нашу работу в условиях турбулентности и неопределенности.
Если ваш мир прямой, понятный и определенный, вам не нужен Scrum.
Какая основная мысль в Scrum?
Оперативная реакция на изменения - ключевая идея Scrum. Я намеренно не использую слово “быстрая”, так как даже в Agile-компаниях PDCA цикл может быть достаточно долгим. Такие компании постоянно работают над его сокращением, чтобы максимально быстро получить обратную связь.
Зачем нам быстрая обратная связь? Чтобы экономить деньги. До момента получения хоть какого-то результата вы тратите деньги. Мир вокруг меняется, а вы продолжаете вкладывать деньги в отдаленный результат. Работая с итерациями и с обратной связью, используя эмпирический подход, вы сможете корректировать точки приложения усилий и работать с рисками.
Scrum не обещает нам победы, славы и богатства. Вы можете сделать все правильно и проиграть. Agile предлагает нам путь выживания в быстро меняющемся мире, а Scrum адаптирован к изменениям.
Оперативная поставка, оперативное получение обратной связи, реакция на обратную связь и изменения. Повторить.
Мы сделали все правильно, но не работает
Scrum не всегда подходит под ваш стиль управления. При всей своей простоте Scrum требует гибкого образа мышления. Можно выделить несколько его основных составляющих:
- Вы понимаете и разделяете принципы Agile-манифеста.
- Вы понимаете, что скорость изменений в нашем мире будет нарастать.
- Вы понимаете, какие преимущества дают эмпирический и итеративный подходы.
- Для вас люди не ресурсы, а ваш главный актив.
Если вы не разделяете эти принципы, или в данный момент времени они вредны для вашего бизнеса, задумайтесь, а зачем вам Scrum?
Scrum хорошо работает в командах с вовлеченными участниками и быстро превращается в рутину, когда команды теряют мотивацию. То есть требования при найме сотрудников повышаются, нам нужно искать людей с гибким образом мышления (Agile Mindset), единомышленников.
И самое главное - внедрение Scrum требует полной и безоговорочной поддержки от руководства.
Почему спринт предлагается делать одинаковым по времени?
Чтобы измерять и улучшать метрики команды от спринта к спринту, используют одинаковые отрезки времени. Довольно странно сравнивать одну и ту же метрику по разным временным отрезкам.
Почему в Scrum все активности ограничены по времени?
Командам нужно стремиться укладываться во временные рамки встреч. Это учит нас эффективно использовать наше время.
Для Daily Scrum в гайде уже предложена адженда, а для остальных встреч - нет. Задача команды самим создать правила коммуникации.
Основная критика от разработчиков
Часто участники думают, что их загоняют в жесткие временные рамки, заставляя участвовать в крысиных бегах. Это небезосновательно, многие компании неверно понимают суть Scrum и Agile в целом. Они используют Agile для манипуляции сотрудниками. Гибкость для них - норма овертаймов, работа на износ, неадекватные сроки реализации задач. Держитесь подальше от компаний с такой культурой.
Я повторю мысль, которую озвучил с самого начала. Идея Scrum - это организация своей работы. Вам необходимо учиться планировать, делать, анализировать, меняться. Вы будете совершать ошибки, но не будете платить за них слишком дорого. Ретроспектива поможет оглянуться назад и в следующей итерации попробовать новый подход.
В Scrum мы делаем фичи, создаем вэлью, но не развиваем продукт. Не внедряем новые практики, не работаем с техническим долгом
В бэклоге должны быть не только задачи от стейкхолдеров, но также баги, технический долг и время на развитие инженерных практик команды. Если вы работаете только с историями, спросите себя, почему? И, если ваш ответ, что этого хочет бизнес, найдите в себе смелость рассказать им про процессы в разработке.
Зачем в команде Scrum Master, если команда решает все вместе?
Решаем вместе, но берем на себя ответственность. Члены команды обсуждают, спорят, договариваются, принимают решения, но за каждым решением будут стоять взятые на себя личные обязательства. За результат спринта ответственна вся команда - это означает, что каждый участник команды отвечает за результат. Внутри команды ответственность её членов разделена по ролям.
Член команды в роли Scrum Master берет на себя обязательства и дает обещание команде, что все будут соблюдать принятые командой правила.
Может ли Scrum работать в компании, где нет культуры Agile?
Нет. Это будет scrumbut (или скрамно) - особое понимание Scrum, когда берут только правила без ценностей и начинают работать. Такой подход, в самом деле, может помочь упорядочить и структурировать работу в командах, но о росте продуктивности и экономии можно забыть.
Обычно такой подход спускается сверху, когда руководству продали Agile, но не объяснили его принципы. Или, что еще хуже, когда руководство понимает, но не разделяет ценности Agile и манипулирует ими.