Почему Scrum не работает: две проблемы компаний с продуктовыми командами

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

ПРОБЛЕМА

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

1. Почему постулаты Scrum в теории простые, а реализовывать их на практике сложно?
2. Почему в официальном пособии “Скрам” (Scrum Guide) ключевые термины сформулированы четко и понятно (фразы типа “Скрам-команда должна состоять из скрам-мастера, владельца продукта и разработчиков”), но разъяснений того, как они реально работают в бизнесе, нет?
3. У нас свой контекст. Почему вы говорите, что мы не можем изменить скрам?

Два ключевых вопроса

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

1. Присутствие единой цели, которая объединяет всех участников разработки.
2. Надлежащее функционирование скрам-команды.

1. Цель

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

Нечто похожее происходит в бизнесе, когда менеджеры вводят скрам, не до конца понимая его специфику. Один из вопросов, который они часто не осознают, “Вокруг чего нужно формировать команду?” Ради какой цели?

Оба понятия (цель и команда) тесно связаны между собой. Ведь участникам разработки нужны предпосылки, чтобы “склеиться” в единую кроссфункциональную команду для совместного взаимодействия и достичь пика своей производительности. Первой такой предпосылкой является цель, которую понимает каждый участник разработки.

Кейс 1. Шляпа “Скрам”

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

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

Дело в том, что извне все соответствовало требованиям пособия (Scrum Guide) – наличие команды разработчиков, владельца продукта и скрам-мастера, беклога продукта, спринтов, инкремента, ретроспективы и др.), кроме одного неожиданного “нюанса”: тестировщики работали отдельно от разработчиков как отдельная скрам-команда. Соответственно, дублировали все элементы и артефакты, вводили собственные спринты. Выяснилось, то же самое касалось и дизайнеров!

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

Услышав о цели, которая должна объединять всех участников разработки, один из участников не выдержал: “Слава, весь фреймворк, о котором ты рассказываешь, у нас есть, но общей цели нет! Нам дают различные задачи, которые мы просто должны выполнить, не понимая, зачем. Как нам действовать?“

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

Интересно, что после тренинга участники набрались мужества и бросили вызов руководителям: “После тренинга мы поняли, что все, что мы здесь делаем, вообще не скрам. Вам нужно пойти на тренинг, чтобы делать все правильно”.

Кейс 2. Курица без головы

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

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

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

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

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

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

2. Люди

Вообще 80-85% пилотных проектов запускаются как “недоскрам”. Руководители часто не до конца понимают специфику Scrum-подхода или как он работает на практике. Больше всего проблем возникает со скрам-командами.

Вот перечень типичных проблем:

1. Есть скрам-мастер или его роль дисфункциональна.
2. Непонимание роли владельца продукта.
3. Люди есть, кроссфункциональности нет.
4. Команда не развивается, как этого требует “Скрам”.
5. В компании разные департаменты – как им сотрудничать в рамках скрам-подхода?

В случае разрозненности и обособленности структурных подразделений организации друг от друга ввести скрам-подход чрезвычайно сложно. Просто прочитать пособие или книгу недостаточно.

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

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

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

В случае отсутствия налаженного взаимодействия между департаментами:

1. Постоянно возникает напряжение между различными участниками разработки;
2. Расходуется лишнее время, финансовые и другие ресурсы;
3. Существенно задерживается релиз продукта.

Неумение или невозможность объединить людей вокруг цели соблазняет руководителей отменить “этот эксперимент”, считая, что проблема в “подходе”.

Поэтому перед запуском пилотного проекта руководителям стоит задать несколько простых вопросов:

1. Достаточно у нас специалистов для того, чтобы сделать релиз? Если нет, сколько именно не хватает?
2. Нужна помощь специалистов других отраслей (с других отделов), чтобы сделать релиз? Если да, то каких именно? Сколько?
3. Что должны сделать, чтобы все участники разработки понимали цель? (Прежде всего это задача владельца продукта).

Кейс 3. Одинокий департамент

Чтобы сделать переход на Scrum безопасным, мы рекомендуем начать с одной команды.

Так и сделали наши коллеги из другой консалтинговой компании, запустив “пилотный проект”, цель которого заключалась в том, чтобы научить сотрудников одного из крупнейших банков в Восточной Европе, отвечавших за разработку продукта, основам Scrum, после чего масштабировать скрам-подход.

К сожалению, заметных преимуществ от “первой ласточки” банкиры не почувствовали.

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

а) в команде были только программисты;
б) кроссфункциональной команды не было создано.

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

Результатом получилось то, что называют недоскрамом (англ. – “scrumbut”, часто в русском переводе – “скрамно»).

Несмотря на это, лидеры банка решили не опускать руки и перезапустить “пилот”, устранив выявленные недостатки и привести модель в соответствии со Скрам.

Напомню, что за постулатами Scrum, каждая скрам-команда должна иметь продуктовую цель (product goal). Она должна объединять всех разработчиков продукта и пронизывать все процессы, связанные с ним. Это особенно ощутимо, когда продуктовая цель длится 3-4 месяца.

Забрать цель означает лишить команду стержня, объединяющего и держащего ее. Если KPI – это выполнение задач, говорить о цели, которая придает смысл проекта, довольно сложно.

Вся скрам-команда призвана работать над разработкой инкремента в пределах одного спринта, чтобы достичь цели продукта (product goal).

ВЫВОДЫ

Для успешного запуска Scrum нужно учесть два принципиально важных компонента: а) цель; б) люди – кроссфункциональные команды, каждый участник которой ее осознает. Без понимания цели всеми участниками разработки существует высокий риск нивелирования скрам-подхода и всех его преимуществ, главное из которых – быстрый вывод продукта на рынок, позволяющий успешно конкурировать в условиях современной конъюнктуры.

ПРИСОЕДИНЯЙТЕСЬ К AGILE.LIVE

Ближайшие сертификационные тренинги Agile.Live: Professional Agile Leadership Essentials (PAL-E), Professional Scrum Product Owner (PSPO)
Подписаться на страницу в LinkedIn
Подписаться на Telegram-канал Agile.Live
Подписаться на YouTube-канал Agile.Live