Антипаттерны Agile-команд

Доклад на конференции AgileDays 24 марта 2017 года. Слайды доклада

Дмитрий Павлов. Директор по инженерным практикам, Dodo Pizza

Доклад будет полезен начинающим скрам-мастерам, чтобы не наступать на «детские» грабли, а опытные команды смогут критическим взглядом оценить свой процесс. Все совпадения с реальными командами специальные. Надеюсь вы меня не убьёте после доклада.

Цель моего доклада: не просто потролить и посмеяться. Но также, чтобы вы вытащили что-то для себя, нашли «косяки» у себя в процессе. И на ближайшем ретро договорились, как вы с командой будете их исправлять.

Меня зовут Дмитрий Павлов. До того, как наша компания объединилась с «Додо Пицца», я работал в компании Smart Step Group. Мы занимались двумя вещами: заказной разработкой, а также консалтингом и тренингами. Всё то, что мы у себя применяли (экстремальное программирование, простой дизайн и так далее) мы также продавали клиентам. И показывали, как это хорошо. В феврале 2017 года мы объединились с компанией «Додо Пицца». Теперь это IT-компания. По сути она и была IT-компанией. Мы — пиццерия XXI века, где все решения оцифрованы в облачном сервисе: можно сразу смотреть выручку по кассе, смотреть трекер, доставку и т. д. — всё подключено к единому облачному решению.

Новые роли, прежние обязанности

Начнём с первого антипаттерна.
«Мы услышали что-то модное про Agile, Scrum. Есть существующие роли в команде. Есть маркетолог или продажник, который общается с пользователями, есть менеджер проекта, есть техлид. Давайте мы внедрим scrum или agile – не важно. Мы просто им бейджики заменим.

• Продажник, поскольку он ближе к пользователям — он будет владельцем продукта. Он же и так с пользователями общается!
• Менеджер проекта… Он же организует встречи, участвует в них. Команду держит в ежовых рукавицах. Значит, он — scrum-мастер.
• А техлид — он меньше код пишет, чем другие разработчики. Он же сидит с ребятами, вкладывает в них свою экспертизу. Он и будет коучем!

Можно, собственно, на этом Agile-трансформацию завершать. У нас всё готово. Внезапно работаем по scrum. Всё круто!» 

В продолжение этого антипаттерна, есть еще один. Называется «совмещение ролей» или Agile Project Manager — когда волк в овечьей шкуре.

«А давайте введём в должность scrum-мастера. У нас будут две схемы управления: одна через scrum-мастера, другая классическая — через проджект-менеджера. Не очень понятно, как эти две схемы будут сосуществовать. Но две должности лучше, чем одна. Правда же?».

Идея в том, что мы должны выбрать одну схему. И если мы решили жить по Scrum, то давайте жить по Scrum.

Какой бы инструмент мне купить?

Представьте себе такую ситуацию: звонит вам знакомый менеджер и говорит так.
«Я узнал, что Agile — это круто, модно, молодёжно. Хочу у себя в компании внедрить. Я слышал, что jira — хороший инструмент. Есть ещё target process, есть redmine с плагинами. Куча всего. Подскажи, что лучше купить? Куда свои 2000 долларов всунуть?»

Действительно, “важный” вопрос. Без него никак. И если мы решим, какую программу купить, то тут у нас и попрёт. Нужно ещё должности переназвать на бейджиках, тогда точно попрёт. Понимаете, да?

Мне кажется, сейчас Jira – enterprise standard сейчас, но не важно.

Я смею напомнить, что у нас написано в Agile-манифесте: “Люди и их взаимодействие важнее процессов и инструментов”. Так что люди сами должны своим взаимодействием выбрать инструмент.

Я не отрицаю того, что инструмент важен. Но инструмент должен помогать. А если мы  начинаем всю нашу трансформацию с того, что выберем инструмент — это не есть хорошо.

Отчет вместо стендапа

ОК, с инструментом определились. Пусть это будет Jira. Пришли на первый stand-up (Daily Scrum). А он у нас такой… верифицированный. Алексей Кривицкий вывел специальный термин для этого. Stand-up превращается в Status report. Как это происходит? Приходит scrum-мастер, он же бывший проджект-менеджер с переписанным бейджиком. Открывает Jira-доску, active sprint.

«Расскажи, Вася, что ты сделал за текущий спринт, такой-сякой?»

Остальные сидят и «втыкают» в телефоны, пока до них очередь не дошла. «Сказали придти на stand-up – мы пришли». 

«Вася ладно, присядь. Вот ты! Ты уже 2 дня бот чинишь. Расскажи, почему ты 2 дня бот чинишь?»

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

При этом stand-up становится абсолютно бесполезным. Становится без разницы, кто что делал и какой баг чинил. «Меня спросят — я скажу. А потом дальше уткнусь в телефон, буду читать Фейсбук и постить котов.»

Jira-фикация и Scrum-турбация 

Если развивать тему Jira, то Алексей Кривицкий придумал термин Jirafication. Суть очень простая: все командные встречи деградируют до уровня, когда мы просто «апдейтим» всё в Jira — просто для того, чтобы «проапдейтить» всё в Jira. Когда Jira не доступна, то всё — мы не можем планировать, мы не можем работать. Мы становимся людьми-роботами. Мы приносим ей жертвоприношения в виде tasks, user stories и burndown charts. Типичные фразы, которые приходится слышать, к сожалению:

• «У меня не поставлена задача в Jira – поставьте мне, пожалуйста»
• «А как мне таску добавить? Сабтаской или новой историей?»
• «Я открываю My Issues — там этого не видно»

Знакомая ситуация? Не переживайте — это наша общая боль. Надо всё поставить в Jira. Идёшь на обед — ставишь task в Jira. Оцени её. Возвращаешься — проверь, план с фактом совпал или не совпал. Без этого вообще нельзя работать. Никакой scrum не пойдёт.

Разовьем идею Алексея Кривицкого: «Скрам-турбация» или «Джира-турбация». Посмотрим на команду, где есть стендапы и есть доска (физическая или виртуальная). Scrum-мастер сертифицирован на PSM I или PSM II. Либо в Scrum Alliance, либо ещё где-то. На стендапы ходим, делаем демо и ретро.

На первый взгляд может показаться, что в таких командах всё ОК. Идея в том, что механику мы всю соблюдаем, но про ценности напрочь забыли. То есть, стендапы превращаются в статус-репорты. Мы на ретро не видим улучшения. У нас же всё круто в команде. У нас проблем нет. Пользователя не зовём, но демо показываем. Все и так всё видели, зачем их звать на демо?

Всё есть, но Скрамом тут и не пахнет.

Водопадные спринты

У нас же должна быть аналитика какая-то. Мы же не можем аналитику оставить без проработки. Давайте объявим нулевым спринтом спринт аналитики. В конце этого спринта у нас будут какие-то документы. Я как Product Owner приду к вам в конце спринта и спрошу: «А что у вас готово?». Вы ответите: «У нас есть документы». Я: «Ну, круто!». Но где-то в голове у меня червоточинка сомнения будет. Что-то вы меня как-то обманываете. Прихожу к вам через второй спринт. И абсолютно не важно, какая у вас продолжительность спринта: две или четыре недели. «Мы дизайн сделали! У нас дизайнер работал. Экраны офигенные!». Я: «Ок… А я могу что-то выкатить в продакшн?». «Нет. Пока не можешь. Тут только документация и дизайн». Прихожу на третий спринт — там спринт доставки в интеграцию. То есть процесс настолько кривой, что нам нужен целый спринт, чтобы «запинать» вот это в интеграцию. При этом желательно ещё не обломать смежные команды (бывает, что тестовые среды «шарятся» между командами).

Ну, и где-то по итогам пятнадцатого спринта я что-то увижу. Но самое прикольное, что в разработке — где больше всего неопределённости, где самая рискованная тема, — когдам мы начинаем что-то делать, оказывается, что оно совсем не так, как в документации. Framework не завёлся. Есть неточность. Документация устарела.

Водопадная итерация

Мы можем собраться на ретро: «Что-то не то! Давайте мы сделаем один водопадный спринт из этого всего». То есть, всё то же самое, только в рамках одного спринта. Казалось бы, всё нормально. В конце спринта есть готовый результат. Но тестировщики курят бамбук почти весь спринт, так как нечего делать. Девелоперы в начале спринта пока ничего не делают. Аналитики пока работают. Потом дизайнер включается, с чувством прекрасного делает экраны.

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

А потом: «Не успели? Давайте в следующем спринте это сделаем».

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

Оценка на каждый чих

Есть тенденция у нас оценивать всё и вся. И количество багов, и сколько story points каждая задача займёт с точностью до 15 цифры после запятой.

А самое интересное, как мы эту информацию используем. У нас очень долгое планирование, мы упарывались, разбивали на сабтаски, оценивали и каждый task, и даже subtask. Но к следующему спринту совершенно забываем про то, что планировали в прошлом, и сколько в нем сожгли стори пойнтов. Scrum-мастер спрашивает: «Как вы думаете, мы сможем это сделать за спринт?» Ответ: «Да! Мы сможем!». То есть, мы упарывались с оценками, все учитывали, а потом забили на это. А зачем это было, если в итоге всё решает «Мы сможем!»?

Не надо так делать. Мы помним, что у нас в Agile — не оценка, а скорее прогноз (forecast). Мы лишь примерно можем сказать, что команда примерно такого состава более-менее похожие задачи сделает примерно за столько-то. При этом абсолютно идентичных задач — очень мало.

Ресурсное планирование

Мы садимся на планирование. Есть разработчики разных типов, люди разных специальностей. Есть аналитик, есть front-end разработчик, есть дизайнер, есть разработчики тестов и т. д. Мы начинаем распределять задачи: здесь «фронтовая», здесь «бэковая» и т. д. Раскидываем по людям. По результатам планирования весь бэклог у нас нарезан: у каждого свой набор task.

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

Если посмотреть на burndown таких команд, то он будет очень ровный! Стабильный. Причём если на эту картинку взглянет ресурсный менеджер, скажет — идеально! Все чем-то заняты. Работа не несколько недель вперёд расписана. Чёткий план. Правда, немного забыли про приоритеты, про интеграцию и про пользователей. Но в результате мы все задачи выполнили. А если не выполнили — переносим на следующий спринт и продолжаем. И график идёт прямо, а в конце резко падает. Повезло. Наверное, все сынтегрировались и выполнили.

При этом «фронтовики» же молодцы. Они всегда задачи доделывают. И то, что при этом «бэк» не готов, то это java-программист виноват. Его надо уволить. Или как-то наказать. А «фронтовики» молодцы. И аналитики всегда молодцы. Они всегда выдают документацию. Которая, иногда бывает, расходится с тем, что в коде написано, но в этом ничего страшного. Мы же написали документацию. Кто же в код будет лезть потом?

Карго-культ идеального burndown

Burndown — это зеркало процесса. Мы говорим: «Давайте сделаем идеальный burndown». Идеальный — это когда работа сгорает равномерно, маленькими кусочками, ценность доставляем чаще. Но сейчас у нас из-за разных причин burndown скачет и прыгает. Появляются возгласы в команде — карго-культ burndown: «Не добавляйте больше task – у нас burndown скачет». Или возглас от владельца продукта: «Что-то идет не так: у нас burndown не идеальный». И тогда приходит кто-то и говорит: «Чуваки! Я вас сейчас спасу. Давайте заведём новый тип task. Он в нашей калькуляции учитываться не будет. Но зато burndown будет ровный, без скачков.»
Это обман системы: по факту у нас работа будет добавляться, но мы про это не узнаем. Хуже только, если burndown используется для целей оценки «эффективности» команды: делаем работу, не учтенную в эффективности.

IT-шники — они люди творческие. Они придумают как обойти любую метрику или KPI. И у них даже появляется элемент соревновательности: кто как хитрее эту метрику обойдёт.

Бухгалтерия с оценками

Работаем мы по водопадному спринту. Всё здорово. Но в конце спринта ничего не готово. И мы обсуждаем самый важный вопрос. У нас была история на 13 story points. Мы её не доделали. Но мы же сделали какую-то часть.

• Одни говорят: давайте 5 point в этот спринт засчитаем. А 8 в следующий возьмём. И в следующем спринте задача пойдёт с оценкой 8.
• Другие говорят: Нет, так не правильно! Мы же ничего не поставили. Ставим 0. Целиком переносим следующий спринт

Засчитать или нет? На этот вопрос очень хорошо ответил Алексей Кривицкий: «Давайте от механики отвлечёмся. Вспомним про пользователя. Мы можем какую-то бизнес-ценность ему «заделиверить»? Если да, то считайте, как угодно!». Тут не важно, как вы посчитаете: пять или ноль. Оно в среднем сойдётся через несколько спринтов. Velocity выровняется через несколько спринтов. И без разницы, какую мы тут бухгалтерию ведём. Как проще, так и считайте. Нравится переоценивать — переоценивайте.

Местечковый Scrum

Чуть-чуть отвлечемся от антипатеррнов команд. Поднимемся чуть выше. Посмотрим на иерархию организации или IT-департамента. IT-директор говорит: «Я услышал что-то про Scrum. Прочитал книжку. Хочу также, но чтобы в остальной организации мы по-прежнему работали. Давай только у разработчиков Scrum настроим. По-моему, они работают медленно. Сериалы смотрят на работе. Надо их взбодрить. Scrum, дисциплина, хорошие результаты и в срок.».

К сожалению, Scrum у разработчиков не настроить. Как бы мы не старались, мы либо будем продолжать заниматься «скрамтурбацией», либо произойдет следующее. Допустим, у разработчиков есть подобие кросс-функциональной команды, и они способны что-то «деливерить» сами, и есть «кнопка» Deploy to Production, которую они сами могут нажимать, и это не нужно ни с какими безопасниками согласовывать и писать заявок. Тогда Scrum заработает, и они начнут потихоньку вытягивать из других отделов к себе либо компетенции, либо выделенных людей, чтобы эти компетенции с них взять. Если нужен безопасник — давайте его в команду, если из техподдержки — давайте его обучим.

Scrum заставляет делать организационные изменения. А местечковый Scrum — либо быстро загнётся, если нет сверху поддержки, либо будем продолжать играть в фейк.

Индивидуальные KPI

В крупных организациях нужно оценивать эффективность людей. Странная ситуация. KPI ставятся менеджерами, а менеджеры не в команде и не знают специфику продукта. И KPI — это способ распределить деньги в конце года между людьми. Причём scrum-команды состоят из 5-7 человек, поэтому они людей, которые не тянут — быстро вычисляют. Но нам все равно нужен сложный процесс с индивидуальными KPI, индивидуальными планами развития и т. д. При этом у нас есть продакт, который формирует бэклог, исходя из бизнес-приоритетов. Подходит конец года, и тут у разработчика встаёт дилемма: «Что взять?». С одной стороны, продакт с понятными требованиями по продукту, с другой стороны, у меня личный KPI и премия в конце года. А я уже айфон себе новый захотел. Что делать? Я говорю: «Сегодня у меня эти дни. Меня не трогайте. В четверг я ухожу делать свой личный план». Продакт: «Как же так? Куда у меня человек из команды свалил? Я за него деньги плачу, а он что-то не то делает?».

Роль Backlog Facilitator

Владелец продукта — это очень сложная и недооцененная роль. И не только в Scrum. Очень часто у продукт-оунера нет выделенного бюджета, он ничем не распоряжается, он не может нанимать/увольнять людей, он не может купить железа, Он не может назначать даты релиза, так как сверху все обо всё договорились, он не может сказать «нет». В этом случае Product Owner превращается в Backlog Facilitator. Не понятно, зачем нужен в таком случае продукт-оунер: он выполняет чисто административную функцию. По факту продуктом он не владеет. И начинается карго-культ продукт-оунерства. Формально мы вроде в Scrum работаем. Но полномочий никаких нет.

Подведем итоги 

1. Вспомните про ценности Agile. Их там немного: всего 4. Принципов — 12. Про Jira нигде не написано в Agile-манифесте. И в сносках нигде не написано.
2. Найдите у себя антипаттерны. Если какие-то вам понравились, то обсудите их с командой.
3. И поменяйте свой процесс. Scrum — процесс непрерывных экспериментов (вспомните о цикле Деминга-Шухарта). Не факт, что те процессы, которые хорошо подошли в одной команде, они хорошо подойдут в другой.

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