Сент. 11

Как мы внедрили Scrum: грабли и точки роста

Привет! Меня зовут Александр, я Scrum-мастер в Trionika. Хочу поделиться своими личными наблюдениями о том, как изменилась эффективность работы разработчиков и продуктолога во время и после внедрения Scrum в компании. Сразу уточню: компания специализируется на добыче и монетизации трафика. Помимо этого, разрабатывает свою платформу наподобие Upwork для работы с клиентами и подрядчиками по всему миру.

За 9 лет на рынке эта команда наработала огромную базу кода, поэтому за доработкой мелких фич стало сложно видеть прогресс в работе (думаю, многие поймут, о чем я). Начинало все больше казаться, что нынешний мощный IT-отдел компании превращается в неповоротливого монстра, который пытается успеть везде, а фактически топчется на месте. В качестве решения для сдвига с мертвой точки родилась идея попробовать Scrum: собрать пилотную Scrum-команду из 8 человек в IT-отделе, которая с выделенным Product Owner полностью следовала бы единому плану.

На этом этапе я и присоединился к команде. Что из этого вышло, читайте дальше.

Наша Scrum-команада

Первые шаги

Когда я пришел в компанию, уже были сделаны первые шаги: была сформирована Scrum-команда и проведено несколько спринтов. Перед тем как я окончательно вступил в должность, мне посчастливилось присутствовать на нескольких встречах в качестве консультанта. Роль PO выполнял один из ключевых заказчиков, который предварительно прошел сертификационный тренинг на Scrum Product Owner, а роль Scrum-мастера — CTO, познакомившийся с методологией по книге «Революционный метод управления проектами» Джеффа Сазерленда.

Команду разработки выбирал CTO, не вовлекая самих людей в принятие решений. Им был дан краткий экскурс в Scrum в виде 20-страничной методички. В непривычных для себя ролях и уже с большим опытом на руководящих должностях PO и Scrum Master пользовались наработанными за годы и зарекомендовавшими себя стратегиями: старались решать за всех. Команда разработки также следовала наработанной стратегии: в основном отвечать, когда спрашивают, и по большей части утвердительно кивать.

Среди всех участников наиболее заинтересованным во внедрении был PO, он видел максимальные перспективы в налаживании более тесного взаимодействия между разработкой и планированием. CTO относился нейтрально, так как на момент внедрения еще не убедился на собственном опыте в пользе Scrum для компании. Сама же команда разработки в основном относилась к Scrum, как и к любым изменениям, с настороженностью. Забегая наперед, отмечу, что те, в ком я видел главных скептиков Scrum, спустя полгода после внедрения максимально раскрылись в нем и увидели положительные для себя моменты.

Как прошла первая встреча по планированию спринта

Да, у команды разработки были карточки для планирования. Да, команда участвовала в обсуждениях. И тем не менее вся встреча больше походила на собрание двух руководителей с командой разработки в качестве зрителей. Когда я заметил эту особенность, я стал перенаправлять вопросы в сторону команды. Что она думает по этому поводу? Знает ли цель и рамки встречи? Какие бы предложения внесла?

В конце встречи на основании оценки Scrum-мастер подсчитал объем задач, доступный для спринта, добавил еще 10% (поскольку прошлый спринт такого же объема был закрыт полностью), спросил у команды, согласна ли та, и спринт стартовал. Здесь крылось несколько проблем:

Как задавался вопрос о согласии? По сути, у команды разработки не было ясной картины того, на что она подписывается. Был просто озвучен объем задач. И вопрос звучал так: «Согласны ли?» Во-первых, такая постановка вопроса подразумевает ответ «Да», поскольку сложно идти наперекор мнению руководителя. Во-вторых, было неясно, что именно предстоит сделать. Просто цифры с оценками ни о чем не говорят, важно именно увидеть сами задачи, представить их выполнение и реалистичность задумки. Мы еще неоднократно возвращались к способу оценки. А начали с визуализации взятых задач. Рисовали на доске задачи с оценками, и уже затем команда говорила, реалистично ли это.
Добавленные 10% задач были запредельными. Как выяснилось позже, на прошлом спринте команда старалась показать лучшее, на что была способна (поскольку ее только сформировали), и работала на пределе возможностей. Это годится для одного рывка, но не для постоянной работы. В итоге даже прошлый спринт команда закрыла с трудом, а видя, что в новом задач еще больше, команда была демотивирована и не справилась. Чуть позже мы пришли к более разумному подсчету закладываемых в спринт задач — к среднему арифметическому от последних четырех спринтов. Это сгладило резкие скачки в объеме задач.
Оценка задач привязывалась к дням разработки. От количества дней в спринте отнимались часы на встречи, и на оставшиеся дни набирались задачи. Такой способ усложнял определение вместимости спринта, а также лишал маневра в заполнении спринта задачами. И правда, на каком основании при 10-дневном спринте можно брать меньше задач, чем оцененных на 9 дней (один оставался на встречи)? Любая оценка дает лишь предположение о завершении, но не фактическое время. В дальнейшем мы ввели в обиход Story Points. Условно один SP так и остался равен одному дню, но именно при формировании спринта мы начали брать задачи, исходя из прошлой velocity команды, не привязываясь к дням. В первых спринтах «лихорадило» от 20 до 45 SP на команду из 5 человек на двухнедельный спринт, сейчас же более ровно — примерно 35 SP на спринт, и показатель понемногу растет.

По итогам первой ретроспективы мы выработали свод правил, по которым построили дальнейшее общение. Проблема была в том, что при переходе на Scrum мы выделили один общий чат, в который начала валиться вся подряд информация. Согласно ожиданиям, у команды разработки сразу должна была появиться коллективная ответственность и самоорганизация в отношении принимаемых решений. В этом потоке было невозможно понять ни то, кто совершает действие, ни то, насколько это важно. В итоге сообщения пропускались: Product Owner не понимал, как может влиять на команду, а команда не понимала, что ей делать с сообщениями.

Новые правила

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

Как отличать важные сообщения от проходных? @mention человека решало половину проблем, а всеобщее согласие на чтение нетаргетированных сообщений с низким приоритетом — вторую.
Как таргетировать сообщения конкретным людям или команде в целом?
Как реагировать на сообщения? Мы выстроили своеобразную «эстафету», по итогам которой отправитель мог рассчитывать на ответ, не дергая поочередно всех участников команды в надежде получить его. Первый отреагировавший (иногда сам отправитель) помогал решить проблему или найти того, кто может это сделать.
Как реагировать на изменения в задачах? Это тот необходимый минимум, который нужно зафиксировать в задачах / отписать по итогам принятых решений.
Как реагировать на запросы, написанные в конце рабочего дня / после его окончания? Как показала практика, почти все эти запросы не требуют мгновенной реакции и было достаточно просто написать, что «принято во внимание, на следующий день проверим».

В итоге снизился уровень стресса и стало понятно, что и в каких случаях делать.

В новых условиях Scrum владелец продукта привычно воспринимался командой разработки как руководитель, которому, в свою очередь, не было понятно, как влиять на команду разработки. Это вылилось в ряд претензий друг к другу, и в итоге ни о какой открытости речь не шла. На ретроспективах обсуждались какие угодно проблемы, кроме первостепенных. Перезапуск отношений стал моей ключевой задачей. Нужно было создать возможность высказаться и команде, и PO. Быстро выделились основные претензии. На встречах я выступил симулятором оппонирующей стороны, позволив спокойно узнать о потребностях друг друга. Дополнительно уточнил, какова ответственность для каждой из ролей. Это дало свои плоды.

Главные выводы: компания на своем опыте убедилась, что роли CTO и Scrum-мастера несовместимы из-за большого соблазна руководителя именно руководить, а не создавать условия для зарождения самоуправления в команде. Поэтому было решено привлечь меня как Scrum-мастера, а CTO должен был сфокусироваться на своих непосредственных обязанностях. Также стало очевидно, что Scrum — это не просто фреймворк для разработки, а совершенно новый подход, требующий изменений и в осознании своих ролей со стороны всех участников.

Уровни развития

Одна из самых интересных задач — это оценка уровня развития команды. Кто-то из участников команды более зрелый и готов быть лидером. Другой же готов выполнять только свои задачи и сейчас осваивает ценность умения делиться результатами работы с другими членами команды. Для Scrum-мастера, как и для любого тренера/коуча, жизненно необходимо выявить этот уровень, действовать в соответствии с ним и мотивировать всех участников двигаться к высокой цели. Ну и конечно же, постоянно расти самому. Это естественный ход вещей в жизни человека, команды и компании. Все последовательно проходят этапы, если не происходит застревания на каком-то из уровней.

Базовый уровень

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

Для команды актуально то же самое, но в большем масштабе:

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

Здесь важно помнить, что инерция и сопротивление изменениям будут максимальные. Приведу реальный пример из нашей практики. На stand-up-встрече участники передали PO информацию, которая нигде не зафиксировалась и о которой в дальнейшем никто не напоминает (информация остается важной!). При этом у команды возникают домыслы, что PO пофиг. А PO думает, что как раз таки команде пофиг. А все дело в том, что в целом внимания хватает только на одно действие, а на следующее (проконтролировать, подстраховать друг друга) — нет.

В таких ситуациях советы к действию и обучению просты:

Терпеливо и настойчиво напоминать, проговаривать, повторять правила и принятые решения.
Вырабатывать понятные способы коммуникации, чтобы важная информация не терялась, фиксировать принятые решения и итоги встреч. Мы начали с того, что я собирал все принятые решения и делал общую рассылку, затем часть перенесли во внутреннюю Wiki и со временем планируем перебраться в Confluence.
Фокусироваться на обучении коммуникации. Со своими прямыми обязанностями люди обычно справляются хорошо, проблемы в них легче всего выявить и устранить. Что касается soft skills (в перспективе — наиболее востребованного навыка даже у технических специалистов), с этим часто возникают трудности.
Учиться слышать других участников команды, понимать, что они делают, чем живут, каковы их потребности.
Думать не только о том, как решить свою задачу, но и том, как состыковать ее с задачами других.
Убедиться, что полученный результат — это то, что нужно на самом деле, а не то, что написано в ТЗ (снова-таки привет, sprint review!).

На этом уровне при наличии доступных и понятных правил люди и команды отлично справляются с однотипными задачами. На самом деле не везде и требуется уровень выше.

Как видно из нашего начала, команда находилась на базовом уровне и успешно преодолела его.

Наша Scrum-команада

Продвинутый уровень

На продвинутом уровне Scrum раскрывается во всей красе. Он предоставляет отличный фреймворк для усиления взаимодействия участников внутри команды, а также взаимодействия между командой и окружающим миром:

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

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

Правила работы уже неплохо освоены, также наработана определенная готовность к изменениям. Однако внимание не распространяется дальше собственной команды. Например, могут иметь место тлеющие конфликты между отделами (часто они почти не проявляются внешне). Что-то в духе «для своей команды готов на все, а остальное — не моя ответственность». Или попросту непонятно, чем занимаются другие, а значит, они вызывают неприязнь.

Что важно предпринять на этом уровне:

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

Одной из первых задач нашей команды было выработать определение завершенной задачи. Что мы понимаем под этим и до какой степени доводим задачу при сдаче? Хотя продумать и нарисовать на доске общий подход не составило никаких проблем, все же на то, чтобы реализовать его и договориться о некоторых деталях, у нас ушло несколько спринтов. Например, мы долго спорили, до какой степени нужно доводить задачу перед первой демонстрацией заказчику. Я был за то, чтобы показывать, когда все ключевое сделано и практически завершено тестирование. Но все же в итоге мы решили, что лучше доделывать задачу до состояния, когда мы готовы выложить результат, и после этого демонстрировать заказчику. Сейчас критерии готовности задачи у нас следующие:

По задаче проведен code review (проводится в несколько этапов на разных стадиях, ему была посвящена еще одна ретроспектива).
Задача реализована в коде.
Задача соответствует ТЗ (либо зафиксированным изменениям).
Задача проверена QA.
Баги, найденные QA, исправлены.
Прописанные To Do по задаче сделаны.
Задача доступна заказчику.
Сделана отписка в change log.
Задача продемонстрирована и принята заказчиком.

Отмечаем готовность задачи по критериям

На этом уровне команда отлично справляется с запуском сложных проектов, включающих в себя взаимодействие с разными отделами. Например, масштабный проект по перезапуску админки всей сети сайтов.

По конкретным действиям поводом для обучения может стать что угодно, но это должен быть реальный случай из жизни. Еще один пример из нашей практики: в середине спринта мы заметили его несоответствие общей стратегии компании. Неплохо, правда?

Что мы предприняли:

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

Сейчас мы находимся на этом уровне и присматриваемся к следующему.

Зрелый уровень

По-настоящему устоявшегося уровня достигают немногие люди и команды:

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

Пример зрелых команд — это сами разработчики Scrum Джефф Сазерленд и Кен Швабер. Будучи программистами, они реализовали методику для достижения наилучшего результата во взаимодействии с владельцами продуктов, а затем начали делиться методикой с миром.

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

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

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

Если ситуация имеет активную фазу (двое ругаются), перевести ее в более спокойное русло, переводя внимание на общие интересы команды и компании.
Когда ситуация вошла в спокойную фазу, выявить настоящий запрос/проблематику ситуации.
Вычленить первоочередные необходимые действия и выполнить их.
Еще раз пересмотреть ситуацию, учитывая общие интересы команды и компании. Найти все взаимосвязи и предпосылки, которые привели к сложившейся ситуации, учесть их во избежание тех же граблей в будущем.
Задать себе вопрос «Что еще я могу сделать в сложившейся ситуации?» и выполнить необходимое действие.

Делай раз, делай два

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

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

На какой стадии развития сейчас находится Scrum-команда?
Какие практики и в какой степени внедрены?
Какие практики заходят лучше, а какие тормозят процесс?
Какое следующее действие было бы наиболее уместно предпринять?

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

Выводы

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

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