Agile
Agile-коуч
Agile-трансформация
AgileSurvey
Beyond Budgeting
DevOps
HR
Kanban
KPI
LeSS
OKR
OKR-инструменты
PMI
Project management
SAFe
Scrum
Scrum in Hardware
Scrum-мастер
Spotify
XM
Архитектура
Бюджетирование
Владелец продукта
Игра
Инженерия
Конфликты
Менеджмент
Обучение
Продуктовый менеджмент
Самоорганизация
Тренинг
Фасилитация
Финансы
Холакратия
Применить

Антипаттерны 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 — процесс непрерывных экспериментов (вспомните о цикле Деминга-Шухарта). Не факт, что те процессы, которые хорошо подошли в одной команде, они хорошо подойдут в другой.

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

2 июл 2020, Дмитрий Павлов
Другие статьи
Agile манифест
20 сен 2020, Василий Савунов
Как появился Agile. Часть 3. Призыв

Это завершающая часть статьи про причины появления Agile.

Agile поиски
1 сен 2020, Василий Савунов
Как появился Agile. Часть 2. Поиски

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

agile history
24 авг 2020, Василий Савунов
Как появился Agile. Часть 1. Предтечи

Чтобы исчерпывающе ответить на вопрос «Что такое Agile?», надо сперва понять, в каких исторических условиях он зарождался, какие условия рынка привели к его появлению, и что двигало его создателями. Ничто не появляется “на пустом месте”, всегда есть влияние как прошлого, так и настоящего. Из исторического контекста можно понять логику подхода и применять предложенные им решения с умом, не сваливаясь в карго-культ.