Меня зовут Олег Егоркин, я agile коуч в Ростелекоме, и в этом посте я расскажу, почему «зомби-скрам» вообще возникает, как этого избежать и как убедиться, что в компании все готово к запуску скрам-команды.
Существующие подходы к запуску команд
Иногда скрам-команду пытаются запускать в IT, то есть — снизу вверх. Это когда сами разработчики и руководители подразделений понимают, все, пора, для этого продукта нам нужен скрам. Плюс в том, что инициатива идет от людей в теме. Минус — при таком подходе не вовлечен бизнес. А если бизнес не вовлечен, то и сама организационная структура при таком подходе либо меняется очень незначительно, либо (что чаще) не меняется совсем. В итоге вероятность превращения такого скрама в «зомби-скрам» очень велика. Само собой, не будет такого, что в первый же день все пойдет не так, как хотелось. Но примерно через полгода люди поймут, что все минусы, которые были при запуске, так никуда и не делись. Отсюда — фрустрация, которая всегда грустно отражается на продукте.
Есть и обратная история — сверху вниз. Тоже не та штука, к которой стоит стремиться. В качестве примера, помните, несколько лет назад, на заре Agile в одном зеленом банке по поручению высокого начальства “к лету” запускали 50 новых команд, а к концу года — 5000. Это вот тот самый подход про скрам ради скрама. Что происходит в таком случае? Люди бегом бросаются выполнять поручения. Под скрам начинают грести все, что не прикручено. Скрам в этой истории — это ни разу не совершенствование разработки и новые методологии, это всего лишь галочка в KPI у менеджера. В итоге — «зомби-скрам».
А есть третий подход — инициатива сверху и снизу сонаправленно. Нам повезло, и в Ростелекоме как раз так сейчас. Штука в чем. На уровне топ-менеджмента есть постоянное содействие всем трансформационным подходам в командах. При этом никто не ставит “амбициозных” планов.
Для больших и очень больших компаний это не совсем привычно. Работает примерно так: раз в месяц я провожу однодневное базовое обучение по Agile. На тренинги приходят и сотрудники из IT, и люди из бизнеса, человек 25 в группе. Стараюсь максимально доступно и широко об этом рассказывать. Спустя какое-то время (может пройти от недели до нескольких месяцев) коллеги, переварив полученные знания, возвращаются уже с понятным запросом на создание скрам-команды.
Про чеклист
Запросы у меня появляются двух типов — либо на запуск команды в рамках трансформации уже существующего продукта, либо на команду для нового продукта. Для обработки этих запросов я написал специальный чеклист, с помощью которого проверяю все необходимые для запуска условия. Если заявка не проходит по какому-то одному пункту и не выполняет предварительных требований, то мы не запускаем команду. Это осознанная необходимость — если откровенно забить хотя бы на один из пунктов и запустить команду без него, это все равно не принесет результата. Ну, кроме того, что неслабо демотивирует всех участников.
Если ко мне с заявкой приходит кто-то из ИТ, я прошу его поговорить с бизнесом и возвращаться вместе. Потому что бизнес в Agile — это основная составляющая. Отсюда у нас первый пункт чеклиста:
1. Agile-команду должен захотеть создать бизнес
Тут как с вампирами — они не могут просто взять и войти в дом, их надо пригласить. C Agile-коучами такая же штука, в смысле, что на изменения должен поступать запрос.
Люди из бизнеса и из IT замечают, что какой-то продукт работает в сложных рыночных условиях, обращаются ко мне сами и говорят — подход надо менять. И тут если очень повезет, то запрос приходит вообще в самом начале, когда команды еще нет, но есть идея, под которую людей можно начинать собирать. При этом все понимают, что четкое ТЗ на продукт не сформировать, оно будет меняться в зависимости от бизнес-модели, да и непонятно, какая модель сработает, а какая нет.
В общем, очень важно, чтобы бизнес был вовлечен.
А еще важно, чтобы драйвером этого вовлечения было что-то осязаемое, а не просто хайп. Поэтому я проверяю, чтобы мотивы бизнеса примерно попадали в следующее:
- уменьшить time to market, если этот показатель слишком велик;
- увеличить эффективность работы команды;
- повысить управляемость в условиях меняющихся приоритетов.
Если что-то из этих трех пунктов есть, то все отлично, это верный признак, что команда запускается с адекватными ожиданиями.
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-подхода.
Если же заявка на команду проходит по всем этим пунктам, начинается следующий этап — обучение и запуск команды.
О котором я расскажу в следующем посте =)
Комментарии (9)
Oegorkin Автор
29.06.2019 16:19В корпоративном мире принято давать деньги под детально просчитанные требования и экономическое обоснование. Но рост сложности продуктов (это, например, большое количество факторов, влияющих на функциональные требования, высоко конкурентный цифровой рынок, отсутствие экспертизы по новым для рынка продуктам) делает такой подход скорее вредным. Менеджеры потом едва ли прикрываются ТЗ и рекомендациями разного рода «консультантов» в случае провала.
Agile в этом плане намного честнее, он предполагает гораздо более строгий контроль, и направлен на достижение результата, а не на соблюдение процесса. Предпринимателю приходится подписываться под конкретные метрики, а в случае неудачи брать всю ответственность на себя. Это неслабо повышает уровень осознанности и мотивирует всю продуктовую команду на поиск оптимальных решений. Меня всегда вдохновляли такие люди.
Чеклист, собственно, для того, чтобы снизить риск ошибок на старте. В том числе и ошибок с выбором подхода к разработке. Сейчас, после последнего запуска скрам команды, я добавил бы еще один пункт, но об этом уже в следующий раз =)
mazhekin
29.06.2019 22:02+1Все гораздо проще, нужен просто скрам-мастер хорошо и правильно обученный и команда профессионалов. Остальное это просто фантазии на вольную тему.
Oegorkin Автор
29.06.2019 22:52Было бы просто, если бы где нибудь этому учили… но нет. Содержимое чеклиста получено из боли и страданий личного опыта =)
mazhekin
29.06.2019 23:01Не надо через боль, нужно сначала обучится, https://www.scrum.org/. В штатах эта профессия в топе высокооплачиваемых профессий наряду с прокурорами, инженерами т.п. https://www.forumdaily.com/top-25-samyx-vysokooplachivaemyx-professij-v-ssha/. Боль и страдания уже прошли предыдущие поколения разработчиков, которые уже выработали успешные рабочие модели.
Oegorkin Автор
30.06.2019 09:24Я больше пяти лет уже в этой профессии, учусь регулярно несколько раз в год. Любой тренер вам скажет, что скрам — фреймворк эмпирический, это значит, что значительную часть вашего процесса будет составлять личный опыт. Успешные рабочие модели уникальны для компании и рыночного окружения, именно поэтому нельзя скопировать, например, операционную модель Spotify, или любой другой успешной фирмы.
mazhekin
30.06.2019 10:05Скрам Фреймворк это достаточно жёсткий, с четко прописанными артефактами и событиями, каждое из который имеет достаточно глубокий смысл. Скрам это одна и та же модель, которая применяется для разных проектов (от ремонта до разработки ПО). И знать его надо как воинский устав, ибо высунулся из окопа полголовы снесло (проект забуксовал, упёрся в бесконечность, команда разваливается или начинает заниматься не тем чем нужно). Это жёсткий каркас в который гибко помещают запутанную среду (проекты со слабо сформулированными требованиями, командой и т.п.), для которой он и был создан. Я поэтому и написал, чтобы не было зомби-скрама, нужен Скрам мастер который обучен всем этим жёстким артефактам и событиям, и как хорошим инструментом эмпирически вытачивает успешные проекты. А зомби скрам это нарушение правил скрама, из-за неполного его применения. Там возьму чуть чуть из скрама а это нам не нравится и мы это не будем применять, вот и зомби скрам. Скрам это инструмент его — не надо переделывать и гибко изменять, его надо изучить понять, и умело применять в запутанных средах.
Scrum (skr?m; англ. scrum «схватка») — Фреймворк гибкой разработки ПО. Фреймворк основан на эмпирическом методе и предназначен для разработки продуктов высокой ценности в запутанной среде.
Неполное применение скрама это просто следствие недообучения или недопонимания скрама, либо просто отсутствие скрам мастера, который и наводит порядок в хаосе организации проекта с помощью этого метафреймворка и фокусирует продакт овнера и всю команду на результате.
Oegorkin Автор
02.07.2019 12:10Скрам это не корсет, он не сковывает движений, а помогает команде экспериментировать и раскрыться для того, чтобы продуктивно и творчески поставлять клиентам продукты с максимально возможной ценностью. Знание воинского устава никому еще не помогло выиграть войну. Ниже цитата из The Scrum Guide:
«Scrum is not a process, technique, or definitive method. Rather, it is a
framework within which you can employ various processes and techniques. Scrum makes clear
the relative efficacy of your product management and work techniques so that you can
continuously improve the product, the team, and the working environment»
Зомби скрам — это формальное «внедрение» внешних признаков скрама — того самого устава с муштрой и тотальной потерей смысла. Одним обучением, или попыткой найти «правильного» скрам мастера проблему не решить (вообще поиск подходящего кандидата на эту роль — история, достойная отдельного поста). Системный фреймворк проведения изменений Дэниела Кима говорит о том, что изменение шаблонов поведения возможно только через изменение системных (организационных) структур, которые их поддерживают. Чеклист позволяет еще перед стартом проверить организацию на наличие таких структур, которые неизбежно превратят скрам команду в зомби команду, что бы вы ни делали.
spamas
02.07.2019 12:33Плюс в том, что инициатива идет от людей в теме.
напомнило мне статью об «эффективных» менеджерах отсюда:
Людей третьего типа, которые сейчас есть практически на всех предприятиях, вы знаете – это те самые «эффективные» менеджеры. Они приходят на завод, чтобы получать. Но не просто получать – получать в рамках «темы». Я прошу прощения, так и не смог подобрать приличного и понятного синонима для этой «темы». Слово, само по себе, не плохое, но смысл, который в него вкладывается, не выдерживает никакой критики.
Смысл прост: увидеть популярную «тему», прочитать пару (в лучшем случае) книжек по ней, запомнить первые ходы по внедрению «темы» (как Остап Бендер знал первый ход шахматной партии), и грамотно себя «продать». По каждой составляющей есть масса информации в интернете, особенно – по «продаже», как универсальной, меж«тематической» практике.
cross_join
Часто сталкиваюсь с подобным на практике консультанта, поэтому небольшой перевод.
"продукт работает в сложных рыночных условиях" — зачем изучать рынок и потребности клиентов, давайте просто начнем, авось да небось получится
"все понимают, что четкое ТЗ на продукт не сформировать" — и нечеткое тоже, потому что это требует ответственности и компетентности
"очень важно, чтобы бизнес был вовлечен" — только тогда бизнес будет оплачивать карусель из спринтов
Добавлю, что аджайл неплохо работает для сопровождения уже существующего продукта, когда имеется стабильный входящий поток багов и небольших изменений.