От Скрама к Канбану и новому продуктовому подходу

За 5+ лет работы в продуктовых командах я настолько привыкла, что «у нас Скрам», что даже не подвергала сомнению его волшебную силу, несмотря на то, что все время что-то смущало и раздражало.

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

Чистого Скрама у нас, конечно, никогда не было. Было что-то вроде Скрамбана: ограниченные по времени спринты, спринт-планинги и оценка задач. Но задачи (а особенно баги) могли втиснуться в спринт после его начала (мы же стартап, ну). Некоторые задачи на стадии реализации могли оказаться сложнее, чем казалось раньше, что добавляло им часов и ставило под угрозу завершение спринта. Для наглядности использовали Канбан-доску.

Приоритизация задач

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

В каждый спринт мы пытались взять минимум по 2-3 задачи из каждого блока с высшим приоритетом. Вверху беклога стояли задачи, которые не влезли в предыдущий спринт – их надо было закончить в первую очередь, что отодвигало текущие задачи.

Беклог вели в Spreadsheets-документе, выглядело это так:

Спринт-планинги

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

Да, это занимало много времени – до 4-х часов раз в две недели. Если умножить это на количество участников (с зарплатами разработчиков!) – получается куча денег.

Тикеты

Для наглядности мы использовали Канбан-доску. Даже не так – две Канбан-доски :) одну - цифровую в Jira и одну физическую в переговорке для дейли-митингов. Проблем с синхронизацией досок не возникало – в Жире доска обновляется автоматически, а физическую доску обновляем на митинге, проговаривая, что изменилось.

Тикеты организованно печатали после спринт-планинга и наклеивали в колонку ToDo. В среднем в спринт входило 25-30 тикетов. Целью было переместить их все в колонку Done за время спринта (1,5 - 2 недели). Чем больше тикетов оставалось в колонке ToDo – тем больше было давление на программистов. Под конец спринта всегда ощущалось, что парни стрессуют.

Началось с того, что к нам пришел новый Head of product с опытом работы по Канбану и сказал «Хей, давайте попробуем по-моему». Мы выразили скептицизм, но решили а чёб нет.

Первое, что мы сделали – отказались от беклога, разделенного на секции по отделам. Вместо этого стали фокусироваться на глобальных индикаторах компании и определять цели тех-команды на квартал и уже исходя из них ставить задачи. Для этого на самом верхнем уровне внедрили Hoshin и стали еженедельно с ним согласовывать работу всех отделов.

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

Второе, что мы сделали – прибрались в Жире. Но это, наверное, тоже тянет на отдельный пост.

Третье – отказались от спринтов. Заменили спринт-планинги грумингами, которые проводим не по расписанию, а когда хотим. Обсуждаем на них не все задачи, а только важные, которые требуют внимания всей команды. В часах задачи не оцениваем – обсуждаем только примерные оценки типа (2-3 дня или неделя). Плюс, каждый раз сверяемся с квартальным планом на предмет, все ли идет как планировалось и нет ли чего-то, что мы не учли. Груминг занимает не больше часа.

Оставили обе Канбан-доски. Перестали организованно печатать тикеты, завели стикеры и маркеры в переговорке, чтобы быстро можно было создать тикет и повесить на доску. Заказали для всех членов команды цветные магнитики с героями Star Wars, чтобы лепить их на стикеры и видеть, кто над какой задачей работает. Догадайтесь, кто я ;)

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

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

В колонке ToDo теперь не 30 задач, а 8-10 – это меньше давит на психику и позволяет команде контролировать ситуацию.

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

В целом, задач стало меньше и мы смогли фокусироваться на важных для бизнеса. Даже стали получать «Хей, спасибо за долгожданную фичу!» вместо «Ну когда вы уже это сделаете?» от других отделов.

Чего пока не хватает – это оценки скорости. Это важный показатель и его надо повышать. А чтобы повышать – надо измерять. Плюс, в планах – наладить похожим образом процесс для мобильного приложения (над ним работает отдельная команда и там пока все мутно).

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