Чеклист: запускаем SCRUM-команды и делаем прививки от зомби-скрама

в 8:05, , рубрики: agile, scrum, Блог компании Ростелеком, Ростелеком, управление проектами, управление разработкой, чеклист

SCRUM стал настолько популярен, что сейчас его пытаются внедрять практически везде. В больших компаниях иногда получается так, что SCRUM внедряют ради отчетности, или для того, чтобы быть “прогрессивным” и “модным”. В результате ситуация, что вроде как ответственный менеджер поставил себе очередную галочку, мол, надо было внедрить методологию — внедрил, молодец, но при этом вместо каких-то качественных улучшений на выходе оказывается так называемый «Zombie SCRUM». Это когда формально фреймворк внедрен, но по нему никто нормально не работает. Отсюда и название.

Чеклист: запускаем SCRUM-команды и делаем прививки от зомби-скрама - 1

Меня зовут Олег Егоркин, я agile коуч в Ростелекоме, и в этом посте я расскажу, почему «зомби-скрам» вообще возникает, как этого избежать и как убедиться, что в компании все готово к запуску скрам-команды.

Существующие подходы к запуску команд

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

Есть и обратная история — сверху вниз. Тоже не та штука, к которой стоит стремиться. В качестве примера, помните, несколько лет назад, на заре Agile в одном зеленом банке по поручению высокого начальства “к лету” запускали 50 новых команд, а к концу года — 5000. Это вот тот самый подход про скрам ради скрама. Что происходит в таком случае? Люди бегом бросаются выполнять поручения. Под скрам начинают грести все, что не прикручено. Скрам в этой истории — это ни разу не совершенствование разработки и новые методологии, это всего лишь галочка в KPI у менеджера. В итоге — «зомби-скрам».

А есть третий подход — инициатива сверху и снизу сонаправленно. Нам повезло, и в Ростелекоме как раз так сейчас. Штука в чем. На уровне топ-менеджмента есть постоянное содействие всем трансформационным подходам в командах. При этом никто не ставит “амбициозных” планов.

Для больших и очень больших компаний это не совсем привычно. Работает примерно так: раз в месяц я провожу однодневное базовое обучение по Agile. На тренинги приходят и сотрудники из IT, и люди из бизнеса, человек 25 в группе. Стараюсь максимально доступно и широко об этом рассказывать. Спустя какое-то время (может пройти от недели до нескольких месяцев) коллеги, переварив полученные знания, возвращаются уже с понятным запросом на создание скрам-команды.

Про чеклист

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

Если ко мне с заявкой приходит кто-то из ИТ, я прошу его поговорить с бизнесом и возвращаться вместе. Потому что бизнес в Agile — это основная составляющая. Отсюда у нас первый пункт чеклиста:

1. Agile-команду должен захотеть создать бизнес

Тут как с вампирами — они не могут просто взять и войти в дом, их надо пригласить. C Agile-коучами такая же штука, в смысле, что на изменения должен поступать запрос.

Люди из бизнеса и из IT замечают, что какой-то продукт работает в сложных рыночных условиях, обращаются ко мне сами и говорят — подход надо менять. И тут если очень повезет, то запрос приходит вообще в самом начале, когда команды еще нет, но есть идея, под которую людей можно начинать собирать. При этом все понимают, что четкое ТЗ на продукт не сформировать, оно будет меняться в зависимости от бизнес-модели, да и непонятно, какая модель сработает, а какая нет.

В общем, очень важно, чтобы бизнес был вовлечен.

А еще важно, чтобы драйвером этого вовлечения было что-то осязаемое, а не просто хайп. Поэтому я проверяю, чтобы мотивы бизнеса примерно попадали в следующее:

  • уменьшить time to market, если этот показатель слишком велик;
  • увеличить эффективность работы команды;
  • повысить управляемость в условиях меняющихся приоритетов.

Если что-то из этих трех пунктов есть, то все отлично, это верный признак, что команда запускается с адекватными ожиданиями.

2. Для запуска должен быть продукт

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

Чеклист: запускаем SCRUM-команды и делаем прививки от зомби-скрама - 2

3. У владельца продукта должно быть видение и роадмап по развитию

Причем роадмап на год вперед минимум, в виде самого верхнеуровнего понимания того, что вообще надо будет делать. Даже если у человека есть 3-5 гипотез насчет того, какие бизнес-модели он будет применять, что он хочет исследовать. Если я вижу, что роадмап есть — продолжаем.

4. У бизнеса должны быть деньги

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

5. Должен быть владелец продукта в бизнесе

Владелец. Не владельцы. Один владелец.

Человек, на 100% выделенный именно на этот продукт. Был случай, когда приходили двое менеджеров и говорили — мы хотим сделать мотивационно-образовательный продукт (такая внутренняя штука для сотрудников). Говорю им — здорово, а есть у вас владелец продукта? Отвечают — да, конечно, один владелец продукта по обучению, а другой — по мотивации. Продукт же мотивационно-образовательный.

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

Один продукт — один владелец продукта. Это важно.

6. Все участники команды разработки также должны быть на 100% выделены под продукт

Если кто-то из команды разработки работает на 50%, 30%, 10% — это сразу нет. Надо быть полностью в продукте. Но при этом я не требую наличия co-located команд. В наших условиях такое большая редкость, Ростелеком очень большой, у нас много ДЗО (дочерние зависимые общества), где и работают разработчики, входящие в команды. И они могут быть разнесены по Москве, Питеру, Краснодару и прочим городам нашей необъятной родины. Быстро собрать команду в Москве иногда сложно и долго, а зачастую вообще не получается.

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

7. Способ оплаты продукта

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

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

Что мы сделали, чтобы не закопаться в этом и не сойти с ума.

Можно работать по Time&Materials, когда заключается контракт и оплачивается время всей команды. То есть существует команда, которая работает на владельца продукта. Оплачиваются ее услуги помесячно или поквартально. Но у нас это в чистом виде нельзя сделать, потому что есть бюрократические ограничения.

Поэтому мы стали работать в рамках позаказной разработки на уровне квартальных заказов с фиксацией роадмапов (не ТЗ), при этом в заказе не детализируется, как именно будет реализовываться роадмап. У владельца продукта появляется гибкость формирования бэклога. А когда квартал заканчивается — мы выгружаем из джиры список сделанных задач и на его базе формируем акты, которые подписываются и оплачиваются. Де-факто получается тот же самый Time&Material.

И тут не надо четко соответствовать ТЗ, потому что ТЗ нет. Требования, в которых больше нет смысла после проверки гипотез, можно просто не делать.

8. У команды не должно быть никаких KPI, кроме тех, что связаны с продуктом

Важно как раз потому, что разработчики нанимаются в дочерние компании, где KPI привыкли ставить на утилизацию (это когда разраб должен быть постоянно чем-то занят). По сути так работают почти все интеграторы — в условиях дефицита проекта (или конкурирующих проектов) одного и того же разработчика расписывают на несколько проектов. И тогда, чтобы компания была в плюсе, разрабу ставят в KPI, что он должен быть всегда занят не менее 85%. То есть у него на самом деле стоит определенный KPI, который мотивирует его вписываться в максимальное количество проектов, дабы подогнать свою утилизацию под нужные цифры.

У скрам-команды такой необходимости, к счастью, нет (де-факто она 100%). Я слежу за тем, чтобы у команд не было других KPI, кроме продуктовых.

Итого

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

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

О котором я расскажу в следующем посте =)

Автор: Олег Егоркин

Источник

* - обязательные к заполнению поля