Эволюция эффективности: SCRUM vs традиционный подход
Почему SCRUM не приживается? Главное препятствие - не люди, а структура <- мы здесь

В первой статье мы разобрали, почему SCRUM – это не просто новые ритуалы, а принципиально иная механика работы, которая ускоряет сроки сдачи проектов. Казалось бы – воу! Бери и внедряй!

И я видела компании, которые пытались это делать: начинали проводить Daily Stand-up, заводили SCRUM-доски... Но инструменты не приживались. Сотрудники выполняли ритуалы формально, не чувствуя в них ценности. Почему?

Ответ прост и сложен одновременно: основная причина неудачи – организационная структура компании, которая противоречит самой сути SCRUM.

Орг. структура «под водопад»: почему мы работаем в отделах

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

  • Есть этап анализа? Создаем отдел аналитики

  • Переходим к разработке? Вот вам отдел разработки

  • Начинаем тестирование? Пожалуйста, отдел тестирования

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

Из практики: хорошо помню это по своему опыту в отделе Аналитики. Мы сидели в одном кабинете, вместе пили кофе, обсуждали последние новости и личные темы. Но когда дело доходило до работы, оказывалось, что мы живем в параллельных реальностях.
Одна коллега полностью погружалась в проект для одного региона, другая вела задачи для другого, я же работала над третьим. Мы могли неделями сидеть рядом, но ни разу не обсудить рабочие нюансы – просто потому, что у нас не было общих проектов или взаимосвязанных задач.
Основной поток коммуникации шел по вертикали: начальник отдела → аналитик. Каждый получал задачи от руководителя, работал по своему проекту и отчитывался о результатах.
Горизонтальные связи между отделами оставались слабыми и эпизодическими. С разработчиками и тестировщиками мы общались в основном через таски в JIRA. Мы были как соседи по дому, которые встречаются лишь чтобы решить проблему с коммунальными услугами. Ни о каком постоянном взаимодействии, общем понимании целей или сквозном движении проекта речи не шло.

Путаница в терминах: что такое «команда» на самом деле?

Здесь мы сталкиваемся с ключевым недопониманием. Руководители, читая про гибкие методологии, везде натыкаются на слово «команда». SCRUM-команда, кросс-функциональная команда, самоорганизующаяся команда... Но в корпоративной среде это понятие размылось. Руководство транслирует, что «мы – одна большая команда», отделы называют себя «командой». Это создает иллюзию: «Ага, мы же уже команда! Значит, SCRUM нам подойдет».

На деле в SCRUM «команда» – это не просто группа людей в одном отделе или компании. Это автономная рабочая единица, обладающая всеми необходимыми навыками для создания законченной части продукта. Это не «отдел в миниатюре» – это принципиально иная форма организации сотрудников.

Абсурд Daily Stand-up в оторванной от SCRUM структуре

Теперь представьте, что начальник отдела аналитики, вдохновленный SCRUM, решает внедрить у себя Daily Stand-up.

Daily Stand-up (ежедневный стендап) – 15-минутное собрание команды для синхронизации. Каждый участник отвечает на три вопросы: Что делал вчера? Что планирует делать сегодня? Какие есть проблемы?

Собираются все аналитики отдела. И начинается:
«Я вчера делал ТЗ для модуля 1 в проекте для Москвы, сегодня буду делать для модуля 2. Проблем нет»
Следующий коллега:
«А я обсуждал и фиксировал требования с заказчиком из Твери...»
Третий:
«А я работаю над техническим заданием для проекта в Сочи...»

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

Итак, что делать, чтобы SCRUM заработал?

Придется менять всю структуру. Люди должны быть перегруппированы: объединены в настоящие SCRUM-команды – кросс-функциональные единицы из специалистов разного профиля, работающих над общим продуктом.

Если сравнивать с «водопадом», то вместо классического единоначалия, в SCRUM-команде появляются два вектора ответственности и компетенций: Product Owner (отвечает за то, что мы делаем и какую ценность несем) и Tech Lead (отвечает за то, как мы это реализуем технически).

Также укажем «сбалансированное» количество специалистов в команде. При этом, безусловно, состав и количество сотрудников разного профиля может гибко меняться в зависимости от проекта.

Теперь посмотрим на орг. структуру более высокоуровнево. Мы рассмотрели базовые единицы: в водопадной модели – это отдел, в SCRUM – команда. Уровнем выше будет Направление / Департамент … (для «водопада») или Value Stream / Train /… (в Agile). В разных компаниях этот уровень называют по-разному, но суть в том, что люди в «отделах» / «командах» группируются вокруг Системы, которую создают / дорабатывают / поддерживают.

Сравним структуру Департамента / Направления /… в компании с «водопадной» (waterfall) моделью

с Value Stream / Train /… в Agile

ИТОГ: Внедрение SCRUM следует начинать с изменения организационной структуры, а не с введения ритуалов

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

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

Что дальше?

В следующий раз мы подробнее поговорим про «сбалансированную» команду и новые роли (схема с орг. структурой будет дополнена). А также попробуем переосмыслить позиции начальников отделов, если вдруг возникнет мысль перейти на Agile-рельсы.