Ускорение команды в 25 раз (кейс E4 Wiley 2019)

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

Это история о команде E4 от компании Wiley во второй половине 2019 года.

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

Давайте начнем с широко известной диаграммы Канбана, которая называется накопительной диаграммой потока (Cumulative Flow Diagram, CFD).

Здесь вы можете увидеть прогресс, которого добилась команда E4 с июня по декабрь. Сфокусируйтесь на коричневой линии «Готово» внизу с июля по декабрь. Вы можете посчитать решенные элементы бэклога продукта (PBI) самостоятельно. С июля по сентябрь бригада закрыла 1 PBI, с сентября по октябрь – 4 PBI, с октября по ноябрь – 16 PBI, с ноября по декабрь – 12 PBI. К сожалению, период с декабря по январь не охватывается CFD, но за последний месяц команда закрыла 25 элементов бэклога. Если вы сомневаетесь, давайте внесём ясность - хотя приведённый CFD доказывает только ускорение X16, я буду говорить об ускорении Х25 в декабре. И прежде чем углубиться в объяснения, позвольте мне указать на несколько важных тонкостей:

• Команда E4 не проводила декомпозицию элементов бэклога
• Команда E4 не меняла состав — от начала до конца было 4 разработчика.
• Команда Е4 работала согласно бизнес-приоритетам, не откладывала важные, но тяжелые задачи
• Скрам-мастер и владелец продукта не занимались микроменеджментом разработчиков, мы рассчитывали на растущую самоорганизацию команды и доверие друг к другу.
• Никаких переработок для увеличения результата

Только представьте ситуацию — в вашей компании есть довольно старый огромный продукт электронного обучения, назовем этот продукт E4. E4 разрабатывался почти 10 лет с 2005 по 2015 год примерно 100 разработчиками (инженеры-программисты, QA, DevOps, бизнес-аналитики и т.д.).

И вот за окном 2019 год.

В течение последних 4 лет ваши команды разработчиков работали над заменой этого старого продукта, делали успешные (и не очень) релизы нового продукта. Ожидаемо, что внимание ваших команд разработчиков и большинства владельцев продуктов будет сосредоточено на новом продукте, но что делать со старым? Компания не может игнорировать тот факт, что старый продукт E4 все еще используется большинством их клиентов, а это означает, что для поддержки E4 необходима небольшая команда разработчиков.

Команда E4, сосредоточенная на старом продукте E4, была организована в июне 2019 года и состояла из 4 человек (backend, frontend, QA и Performance Engineer с навыками DevOPS).

Эта ситуация объясняет, почему команда разработчиков E4 закрыла только 1 задачу за пару месяцев.

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

Я присоединился к Wiley в начале сентября 2019 года и начал работать с двумя командами, одна работала над новым продуктом (команда Proton), а вторая - над старым продуктом (команда E4, наши герои в этой истории). К тому моменту у меня был 1 год опыта работы скрам-мастером (и владельцем продукта одновременно, не советую так совмещать) и 7 лет опыта работы разработчиком, в том числе 1,5 года я был руководителем команды разработчиков, занимавшихся поддержкой.

После того, как я узнал текущее положение дел, моим первым шагом в E4 стала мотивация команды.

Я предложил им изменить свою точку зрения и посмотреть со стороны клиента. Как клиенты решают, какой продукт они будут использовать в следующем году? Влияет множество обстоятельств, но клиенты также обращают внимание и на уровень поддержки. Если поддержка старого продукта удовлетворяет вашим ожиданиям, вы можете в дальнейшем выбрать новый продукт от этого знакомого вам поставщика, в противном случае вы можете переключиться на продукт конкурента. Кроме того, трудно вспомнить всю историю ваших взаимодействий с текущим провайдером, поэтому при принятии решения хорошее впечатление за последние 1-2 месяца можно расценивать как более важное, чем впечатление за предыдущий год. Таким образом, хорошая поддержка старого продукта может дать больше шансов для нового.

Второе, на что я обратил внимание команды, — это сосредоточиться на том, чтобы полностью заканчивать элементы бэклога.

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

И третье, на чём мы сошлись с командой, — это особая структура нашего бэклога. Поскольку продукт старый и на данный момент успешно используется большим количеством клиентов в течение многих лет, наиболее критичные и распространенные проблемы уже были исправлены в предыдущие годы. Не все ошибки, о которых сообщают клиенты, должны быть исправлены в коде, некоторые из них могут быть результатом неправильного использования или неправильного развертывания на окружении клиентов. Некоторые запросы могут быть неактуальными или уже исправлены в более поздних версиях E4. Таким образом, команда должна регулярно общаться с заказчиками по проблемам, такое уточнение может даже полностью закрывать некоторые запросы.

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

Во-первых, мы запланировали регулярные ретроспективы.

Да, ретроспективы — это Scrum-мероприятия, но и вне скрама для команды по-прежнему полезно анализировать и адаптировать свой процесс. Поскольку это было регулярно и по расписанию, команда выработала привычку обсуждать не только то, что они сделали, но и то, как они это сделали, где были препятствия. Могли бы они обсудить это самостоятельно без такого мероприятия? Да, но из-за выученной беспомощности трудно продолжать попытки, когда думаешь, что ничего нельзя изменить, поэтому без поддержки скрам-мастера практика ретроспектив имеет тенденцию тускнеть, откладываться и исчезать после нескольких попыток. Итак, мы нашли несколько локальных точек улучшения, которые ранее откладывались без обсуждения, и попытались их решить.

Второй практикой было предложение проводить более длительные ежедневные встречи и обсуждать ВСЕ элементыбэклога, которые в настоящее время начаты, но не завершены, включая столбец «В ожидании».

Это изменение может быть спорным.

Конечно, такой Daily занял больше 15 минут. И можно представить, как мучилась команда, обсуждая десятки начатых, но незаконченных задач. Это было утомительно, так какой в этом смысл? Команда должна усвоить и понять самостоятельно, что нет смысла держать большое количество элементов «в работе».

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

Итак, после одной недели страданий, команда E4 заметила, что у них всего 4 человека в команде и 25 элементов бэклога, находящихся в работе или “в ожидании” одновременно, и у этих элементов мало шансов обновиться до завтра. Почему эти нетронутые элементы должны представляться как находящиеся в процессе и обсуждаться как находящиеся в процессе, когда на самом деле это не так? Таким образом, команда E4 форсировала прогресс по задачам “в ожидании”, спрашивала людей вне команды, к которым были вопросы по застрявшим задачам, и отодвигала назад в «ToDo» задачи, которые на самом деле еще не начались. Прозрачность бэклога в отношении того, какие элементы находятся в процессе, появилась как ответ на утомительный формат Daily.

Хорошо, с прозрачностью понятно, но почему это влияет на производительность команды? Элементы бэклога, которые не требовали написания кода и установки, завершались быстрее из-за форсированного общения и более быстрых ответов от людей за пределами команды. Еще одна причина, по которой команда E4 ускорилась, заключалась в том, что они сосредоточились на меньшем количестве элементов бэклога одновременно. Легче решать проблемы, когда у вас меньше контекста, который нужно иметь в виду, вы можете быстро закончить эту задачу и углубиться в следующую, не переключаясь на вспоминание другой, наполовину выполненной задачи из колонки «В ожидании».

Глядя только на цифры, 12 меньше 16. Значит ли это, что команда E4 замедлилась? Может быть. Означает ли это, что они произвели меньше ценности? Не совсем. После колоссального ускорения в октябре, в ноябре мы сосредоточились на увеличении ценности поставляемого. Команда E4 улучшила взаимодействие со своим владельцем продукта, в результате чего был изменен приоритет бэклога, и было реализовано несколько тяжелых, но ценных задач. Таким образом, даже при меньшем количестве «Готовых» элементов бэклога ценность для бизнеса все же, вероятно, увеличилась.

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

К сожалению, этот месяц не был охвачен представленной в начале накопительной диаграммой (CFD). С другой стороны, после всего вышеперечисленного, после всего преодоления и страданий, верите ли вы, что команда E4 могла бы сделать еще больше, еще лучше? Конечно, они сделали.

В первую очередь сыграла роль игра getKanban.

Во-вторых, улучшения от ретроспектив помогли ускориться. Совместон это повлияло на результат.

Способность команды проверять и адаптировать свой собственный процесс была улучшена за последние месяцы, поэтому с помощью этого системного взгляда они обнаружили пробелы, которые ранее не замечались. Команда E4 улучшила внутренние коммуникации, чтобы поддерживать друг друга в решении междоменных проблем. Backend и frontend помогли QA с smoke-тестированием. Они знали, что им не потребуется делать так постоянно, а только время от времени в нужный момент, чтобы получить более оптимальный командный результат, поэтому сопротивление этому было низким. DevOPS поделился знаниями о настройке среды, чтобы другие люди в команде могли также распознавать и решать проблемы, связанные с неправильной установкой или неправильной настройкой среды. Они заметили, что справиться с этим не так сложно, как они себе представляли. QA сотрудничал с Backend при написании и тестировании SQL-скриптов (давайте запомним этот момент).

И, наконец, конец года — самое напряженное, но самое продуктивное время. E4 был продуктом электронного обучения, и такая система использует больше в конце семестра, поэтому в бэклоге появляется больше свежих запросов от клиентов. Команда E4 очень хорошо знала об этом давлении, поэтому у них была высокая мотивация решить проблемы до конца семестра, чтобы студенты и преподаватели могли без проблем справиться со своими делами. При этом для команды это был еще и конец длительного периода в стабильном ритме, без перерывов на длительные летние каникулы или государственные праздники.

Хорошо, количество решенных проблем в месяц увеличилось, но как насчет ценности для бизнеса? Как я уже сказал, команда решила много свежих и срочных запросов от клиентов (так что они уже должны быть довольны). Но вдобавок мы выполнили 2 небольших, но ценных элемента бэклога.

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

Вторым ценным элементом была просьба всей разработки актуализировать список используемых окружений. Имейте в виду, что в компании была не гибкая оплата за фактически использованную мощность, а фиксированный месячный счет исходя из числа задействованных окружений. Ответственный владелец продукта заинтересован в повышении ценности продукта и снижении расходов. Отмечу, что владелец продукта, который хоть раз в жизни видел ежемесячный счет за среды разработки, больше никогда не будет игнорировать эти расходы. Я также видел эти счета на своей предыдущей работе, поэтому понимал значимость запроса и поддержал владельца продукта в объяснении его ценности для команды. Мы обсудили это в команде E4, проверили наши потребности за последние месяцы и заметили, что команда использовала только 3 среды из 5 имевшихся. Мы указали, что можем запросить новые, если нужно, но пока без сомнений пожертвовали 2 устаревшими неиспользуемыми средами. Таким образом мы снова сократили расходы на следующий год.

И снова количество решаемых вопросов уменьшилось. Но на этот раз причина была проста - единственный QA ушел в отпуск на целый месяц, у всех остальных были длинные государственные праздники. Единственное, что я должен отметить, это то, что количество закрытых элементов бэклога не упало до нуля. Можно представить, что если бы команда в июле или начале сентября осталась без QA, она могла ничего не закончить, все задачи могли остановиться в колонке «тестирование» на доске. Но когда они столкнулись с этим в январе, после всех улучшений, их стало не остановить.

Хочется ещё раз отметить тонкости, упомянутые в начале статьи, и обратить внимание на результат.

• Команда E4 не проводила декомпозицию элементов бэклога

• Команда E4 не меняла состав — от начала до конца было 4 разработчика.

• Команда Е4 работала согласно бизнес-приоритетам, не откладывала важные, но тяжелые задачи

• Скрам-мастер и владелец продукта не занимались микроменеджментом разработчиков, мы рассчитывали на растущую самоорганизацию команды и доверие друг к другу.

• Никаких переработок для увеличения результата

Работа скрам мастера и Agile-коуча ценна. Работая в этой профессии, занимайтесь именно этой своей работой. Конечно, иногда вам может хотеться получить быстрый результат за счёт микроменедмента, за счёт переработки команды, но помните, насколько это неэффективно по отношению с тем, чего от вас на самом деле ждут - устранения корневых препятствий и улучшения процесса. Я утверждаю, что никакой микроменеджмент и переработки не способны ускорить команду в 25 раз, скорее всего даже ускорение X2 “плохими” методами будет пировой победой. Я утверждаю, что если я, имея всего 1 год опыта за плечами, смог найти такие точки улучшения процесса, то и вы сможете.

Ps. Естественно, я пытался повторить успех с другими командами, и такой большой разницы до и после не получал, однако ускорение Х2 и Х4 удавалось добиться несколько раз.

#kanban #agile #канбан #scrum #team #case #ускорение