Антон работает тимлидом в продуктовой компании. Его команда разрабатывает информационно-аналитическую систему для бизнеса и госкомпаний. В проекте много хаоса, команда ничего не успевает, и Антон предлагает внедрить Scrum. Он сталкивается с непониманием процессов в высшем руководстве и чрезмерной нагрузкой на команду. От Скрам остается часть ритуалов, Антон с трудом «вытягивает» проект и уходит из компании. Разберем по пунктам, почему Scrum может провалиться. 

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

В проектах, где работа идет на поток, а все процессы отлажены, Scrum только мешает. Например, компания выпускает лендинги для бизнеса. Опытный менеджер согласовывает все вопросы с заказчиком, передает дизайнеру понятное ТЗ. Заказчик выдает правки и принимает работу. Дизайнер в спокойном темпе делает по 10-15 лендингов в месяц. 

Руководство не хочет делиться властью

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

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

Разберемся, что происходит. 

✅ Руководство решает перейти на Скрам, провозглашает ценности и внедряет их в командах. 

✅ Сотрудники начинают работать в соответствии ценностями Scrum. 

✅ Ценности Скрам диктуют смелость и обязательства. Члены команды хотят сами принимать решения по разработке продукта, требуют прозрачности, отказываются выполнять задачи, которые им накидывают в середине спринта. 

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

Руководитель компании говорит: «Да, есть Скрам, Аджайл, но у нашей организации есть свои особенности, их надо учитывать».

Руководитель не справляется с ролью в команде

Бывает, что руководитель полностью поддерживает Scrum, но не может пустить ситуацию на самотек, и занимает роль Продакт Оунера в команде. Такой историей с нами поделился разработчик и по совместительству Скрам-мастер Сергей. 

Сергей пришел в продукт по поиску тендеров, увидел множество неизвестных и предложил Scrum. Руководство идею одобрило. Сергею дали карт-бланш: позволили собрать команду и наладить процессы. 

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

Scrum внедряют в одном отделе компании 

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

«Product Owner приносил задачи из других отделов для нашего продукта, — рассказывает разработчик-Скрам-мастер Сергей. — Мы пытались у сотрудников этих отделов уточнить требования и получить обратную связь. Но работа не складывалась. Коллеги из других отделов не приходили на планирование спринта и ревью, не хотели  писать критерии приемки или давали ложную информацию». 

Общение не приносит результат

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

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

• берет на себя ответственность за свою часть работы;

• принимает набор обязательств;

• понимает, зачем все это нужно. 

Совещания, летучки, планерки, отчеты не приносят ценности. Люди на них просто получают по шапке. 

Разберемся, как это бывает, на примерах и антипримерах.

Антипример

— Волдаев, почему не готов дизайн профиля? Чтобы завтра к вечеру прислал, буду показывать заказчику. 

— Мы переходим на скрам. Почитайте что это, завтра на стендапе обсудим, как вы все поняли. Потом я раздам вам задачи.

— Петров, ты отвечаешь за разработку по iOS. Максимов, ты берешь на себя дизайн главной страницы. Жду результат к среде, приклейте стикеры на доску, когда будет готово. 

Пример

— Сергей, вижу ты не успеваешь с задачей по дизайну профиля. Расскажи, какие у тебя сложности. Подумаем, как мы можем помочь. 

— Давайте разобьем задачи на user story и оценим трудозатраты по каждой. Начнем с самой важной. Потом обсудим, как это все должно функционировать. 

— Игорь, Евгений, Роман, давайте обсудим цель спринта и распределим нагрузку на эти две недели. 

В конце спринта нет ценного продукта

Скрам провален, когда команда две недели работает: все постоянно созваниваются, собираются на митинги, пилят задачки. Приходит время релиза. Дизайнер показывает картинки в Фигме, разработчики рассказывают сколько строчек кода написали. Ценности нет. 

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

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

Антипример:

Мы запустили профиль пользователя. Теперь он может добавлять друзей и ставить фото на аватар. 

Пример: 

Мы запустили профиль пользователя. Люди могут регистрироваться на платформе, оставлять нам свои данные, приглашать в приложение своих друзей.

Команда не соблюдает ценности Scrum 

Напомним ценности скрама из Скрам Гайда: 

✔️ Смелость

✔️ Фокусировка

✔️ Обязательства

✔️ Уважение

✔️ Открытость

Все эти ценности ведут к общению и достигаются в результате эффективного общения. Разберемся, что это значит. 

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

Фокусировка — мы выкинем все ненужное из списка задач и оставим только то, что даст ценность в деньгах или в метриках.

Обязательства —  я сделаю дизайн профиля в среду и отвечаю за эту задачу. Если что-то не получилось, задачу выносят на обсуждение, чтобы сделать лучше в следующий спринт. 

Уважение — я уважаю всех членов команды, заказчика и стейкхолдеров. Они все профессионалы в своем деле. 

Открытость —  мы ставим задачи в Jira, чтобы было понятно, что и кто делает. Создаем чат команды, где обсуждаем рабочие моменты. Если обсуждение затягивается на 15 минут, созваниваемся. 

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

Не соблюдают роли в Scrum

В Скрам есть три главных роли: 

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

Скрам-Мастер — общается с командой, чтобы подсветить проблемы, сфокусировать на чем-то. Пытается понять, что не так и помогает сделать лучше. 

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

Разберемся, что может идти не так.

Продакт Оунер не общается про деньги с заказчиком. 

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

Команда отказывается проводить ритуалы, увеличивает длину спринта и  не проводит ретроспективы. 

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

Иначе будет так:

— Да, мы это просили, но получилось не то, что нам нужно. 

Что делать, чтобы не провалить Scrum

Представим, что вы прочитали эту статью, и все еще хотите внедрить Scrum. Вкратце рассказываем, что делать, чтобы все получилось:

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

2. Роли, аббревиатуры, термины - все это не имеет смысла без артефактов, несущих бизнес-ценность, возникающих в результате эффективной коммуникации 2х или более сотрудников.

3. Не стоит делать то, что можно не делать. Особенно, если это не подтверждено $.

4. Попросить коллегу помочь - страшно, но работает лучше, чем идти через официальные регламенты.

5. Отчеты и Agile - совместимы, но не имеют ничего общего.

6. "Получать по шапке" - атрибут культуры менеджмента компаний из далекого прошлого, если такое присутствует - бегите.

7. Fail Fast и Get Out Of The Building = наше все, выйдите из комфортного офиса, чтобы встретить реальных пользователей, а затем провалите как можно больше тестов и гипотез, чтобы понять, куда идти дальше.

Мы уверены, у вас получится! 

Мнение 

Павел Зайцев, Agile Coach:

— Внедрение Scrum и Agile-трансформации сводятся к тому, что внешние атрибуты, типа названия ролей и ритуалов, принимаются. Но суть остается прежней: фабрика разработки с «потогонкой», где сотрудники не понимают, зачем им повышать эффективность. Члены команды не видят общей картины, у них нет никакой власти. 

Я не видел ни одной крупной компании, в которой руководство было готов разделить власть с сотрудниками. Плотно слежу за Сбербанком. Вижу, что они пытаются эту проблему осознать и бороться с ней. Но до преодоления еще далеко. 

Ну полезное и видео от LeadStartup вам в придачу