Когда Scrum не работает. Пять основных проблем его применения
Всем привет, меня зовут Алексей Киселев, последние 10 лет я работаю в IT, половину этого срока в роли Java-разработчика, а половину — как менеджер проектов разных уровней. Сейчас управляю пятью командами в R&D-департаменте Playtika.
Эту статью я решил написать после многих собеседований с кандидатами на менеджерские позиции. Тогда я обнаружил, что многие PM’ы работают только по скраму и думают, что он спасает в любых ситуациях. Материал будет полезен начинающим менеджерам и любопытным разработчикам.
Scrum framework стал священной коровой современного IT, им пользуются все, и про него не принято говорить плохо. Любой адепт скрама скажет, что если он у вас не работает — значит вы просто не умеете его применять. На конференции разберут Agile-трансформацию очередного банка, юридической фирмы или даже завода, который успешно и под аплодисменты стал работать по Scrum.
При знакомстве скрам подкупает своей простотой. PMBOK состоит из 700+ страниц, после любой из которых хочется закрыть его навсегда. Библия скрама, Scrum Guide, уместилась всего на 13 страницах.
Но эта простота обманчива. Скрам — самый требовательный фреймворк в проектном управлении, в первую очередь к команде. О ней и поговорим.
Иллюстрация Марии Рыбак
Проблема оценки проекта
Представьте, вы скрам-мастер новой команды. Проект стартует через неделю. Заказчик прислал требования и на первом созвоне интересуется: сколько времени примерно займет разработка и сколько денег ему отложить на проект? Вы идете смотреть в Scrum Guide...
Что говорит скрам: никакой конечности разработки здесь не предусмотрено. Требования постоянно появляются в бэклоге с помощью продакт-оунера и сжигаются командой. Никаких сроков, оценок и так далее в скраме нет, зато есть предсказания.
Предсказание строится на знании производительности (velocity) команды. А знать мы будем это не раньше чем через
Проблема планирования
Прошло
Но как только вы собрались посчитать, сколько времени займет весь проект, лид бэкенд-разработчик сообщает, что хочет в отпуск на неделю. Еще через неделю идет в отпуск другой бэкендер, а дизайнера забирают на другой проект, потому что он выполнил свою часть работы и будет подключаться по необходимости. Вы смотрите в Scrum Guide, что делать в такой ситуации...
Что говорит скрам: если меняется хоть один человек в скрам-команде — перед нами новая команда. Старая производительность уже не годится, и нужно начинать считать заново. Заказчик, конечно, доволен, что прогресс по его проекту есть, но он совершенно не понимает, когда это все закончится.
Даже если команда стабильна и мы можем взять среднюю velocity, обычно бэклог проработан всего на пару спринтов вперед, а дальше — только очень высокоуровневые «хотелки» заказчика. Команда их не изучала, а Scrum Guide не дает инструментов для грубой оценки.
Проблема специализации
Проходят дни, пролетают года. Команда выросла до 9 человек, а новые User Stories в бэклоге становятся все более сложными. Вы замечаете, что при мощности команды в 60 SP не можете взять задачу даже на 30 SP, не заглянув внутрь бэклога: а вдруг там много бэкенда и почти нет фронтенда? Тогда фронтендщики останутся без работы. Или наоборот. В итоге команда негласно разбивается по специализации на несколько подкоманд, которые следят за своим бэклогом и не сильно интересуются соседями. При этом все тяжелее закрывать задачи целиком: в любую User Story входит работа многих людей, и, например, заливка на продакшн может уже не поместиться в спринт. То есть команда сама начинает нарушать definition of done своих задач во имя хоть какого-то инкремента.
Что говорит скрам: команда — кроссфункциональна. Это значит, что в ней есть все необходимые компетенции для выполнения работы. При этом единственная роль для разработчиков в скрам-команде — разработчик. Других нет. Скрам не признает разные виды разработчиков и проблему их синхронизации. Выравнивание загрузки каждый спринт лежит на продакт-оунере, который становится таким god object — он должен хорошо понимать не только каждую задачу с продуктовой стороны, но то, сколько внутри работы Back-end, Front-end, DevOps, QA. Иначе приоритизировать бэклог не получится. Перекос в любую сторону — и спринт гарантированно провален.
При этом скрам требует, чтобы в команде только один человек отвечал за бэклог, независимо от его сложности. Это усложняет жизнь и ведет к появлению прослоек — прокси продакт-оунеров, бизнес-аналитиков и так далее.
Проблема ответственности, или Колхоз им. Д. Сазерленда
Со временем вы начинаете замечать, что мидл бекенд-разработчик Миша каждый раз быстро закрывает свои задачи, а его лид Гриша в основном коментит чужой код и статьи на ДОУ. Гриша всегда берет одну-две самых больших задачи и делает их весь спринт. Но успевает же! Значит, никаких проблем?
Что говорит скрам: команда несет коллективную ответственность за все, что она делает. Никаких персональных метрик. По сути, убивается личная ответственность разработчиков за результат своего труда — хвалят или ругают всех одинаково, даже если кто-то впахивал весь спринт, а кто-то — Гриша.
Проблема раздувания оценок
Вы решаете присмотреться к Грише. Как у него получается закрывать больше всех стори-поинтов и при этом, мягко скажем, не потеть?
Дело в том, что стори-поинты в скраме оценивают сложность задачи, а не срок ее выполнения. Эксперты рекомендуют использовать planning poker для оценки задач перед началом спринта — церемонию, когда все члены команды одновременно выбрасывают карточку с цифрой, во сколько оценивают работу, и обсуждают отклонения. На «покере» зачастую возникает такой диалог:
Скрам-мастер: Во сколько оценим эту задачу?
Миша: 5.
Гриша: 13.
Скрам-мастер: Гриша, почему 13?
Гриша: Ой, ну там, кроме разработки, нужно еще учесть пару корнер-кейсов, поправить тесты, выделить общую функциональность в отдельные классы...
Миша: Согласен, ставим 13.
Примерно так из-за желания перестраховаться, быть хорошим для начальства или просто из-за лени и происходит инфляция стори-поинтов. В компаниях, где velocity команды — единственная метрика ее успешности, такое видим постоянно. Цифры в отчетах растут, значит команда огонь! Вот только заказчик никак не может дождаться новой версии продукта.
Что говорит скрам: команда должна быть самоуправляемой, это значит, что она сама лучше знает, кто, сколько и чего должен делать. Скрам-мастер почти не имеет инструментов, чтобы вмешиваться в ее работу, разве что задавать наводящие вопросы.
И хорошо, если внутри команды хватит зрелости разобраться с этой проблемой, но происходит такое довольно редко.
Вместо вывода
На самом деле, я люблю скрам — это классный фреймворк для командного решения сложных технических проблем. Меня смущают способы его применения. В украинском IT все описанные проблемы подпирают костылями. «У нас есть скрам-мастер, но в паре с ним поставили деливери-менеджера для работы с рисками, сроками, ну и чтобы разработчиков подгонял», «мы оцениваем в стори-поинтах, но на самом деле это все те же человеко-часы, чтобы потом заказчику сроки выполнения давать», «нам не нужен менеджер, мы сами управляемся. Если тимлид сказал овертаймить, мы овертаймим» и другие.
Такие рассказы я часто слышу на собеседованиях от разработчиков\менеджеров из разных компаний.
Если все же желание «подкрутить» скрам непреодолимо, прочтите заключение Scrum Guide: «Описанный здесь фреймворк Scrum не подлежит изменению. Хотя использование отдельных элементов Scrum допустимо, полученный результат не будет Scrum. Scrum существует только в качестве цельного фреймворка».
Ответ на вопрос «А что тогда делать?» заслуживает отдельной статьи. Как минимум не идеализировать скрам — это инструмент со своими ограничениями и подойдет он далеко не каждой компании. Кроме того, пробелы методологии можно закрывать добавлением инженерных практик из ХР или «классическим» управлением проектами. Например, считать путь до MVP продукта проектом, а значит инициировать его по правилам PMBOK, расписать иерархическую структуру работ, дать заказчику сроки и вперед.
Напоследок приведу цитату одного из авторов Scrum Джеффа Сазерленда. Мне кажется, она хорошо отражает изначальную суть этого подхода.
Scrum in the mid-1990s (as I implemented it and saw it implemented back then) was all about finding innovative solutions. Teams were given a problem, and given a month (or four weeks) to solve the problem. With that much time, teams were able to try one or more potential breakthrough approaches before having to revert back to a safer, tried-and-true approach.
А как поживает ваш скрам?
