Полтора года назад я принял решение уйти из небольшого московского стартапа, где занимал руководящую должность, в более стабильную вологодскую компанию: вернулся «к станку» и стал Scrum Master-ом новой команды. Но, как «офицеров бывших не бывает», так, видимо, не бывает и людей, которые могут перестать беспокоиться об эффективной разработке, даже если за неё уже не отвечают.
На новой работе был поставлен Scrum со всеми классическими церемониями. Кросс-функциональные команды были не привязаны к конкретным продуктам, а постоянно перемещались между различными модулями большой системы автоматизации сети пиццерий (и нет, это не та самая компания с птичкой на логотипе). Выбранная методология разработки помогла компании из региона силами достаточно небольшой команды оцифровать большое количество бизнес-процессов на предприятиях, тем самым подготовив их к приему большого числа заказов.
Но одного Scrum недостаточно для стабильной работы: нужны инструменты поощрения сотрудников. И тут тоже было всё по-классике: периодическая аттестация сотрудников, которая позволяла увеличивать персональный оклад, и премии, которыми награждались уже команды за успешное закрытие эпиков. Но было и местное ноу-хау – турнир команд. Его целью было поощрение поведения команд, которое обеспечивает успех бизнесу.
На первый взгляд, система мне показалась вполне неплохой: взяли метрики, которые легко считаются, и вроде должны коррелировать с крутостью команды в техническом и бизнес контекстах. Но, поработав несколько спринтов с такой системой мотивации, во мне начало крепнуть ощущение, что здесь что-то не так.
Основным акцентом стала ответственность за взятые задачи. Это должно было повысить доверие между бизнесом и разработкой: у нас общие цели и мы «не заметаем общие проблемы под ковер». В качестве противовеса возможной стратегии “давайте будем меньше обещать” мы возложили на Product Owner-а и руководителей направлений разработки контроль над подозрительно высокой оценкой задач или слишком мелким дроблением user stories.
Вторым по приоритету стал «штраф» за недавние косяки, которые всё-таки дошли до пользователей. Чтобы и тут не происходило перегибов, решил ограничить сверху объем допустимого штрафа как по сроку давности, так и по объёму. На этот риск можно было пойти, т.к. у разработки, в целом, нет проблем с качеством релизов: тестировщики скрупулезно проверяют все целиком.
Ну и «на сладкое» оставил прокачку навыков проведения демонстраций. Умение правильно донести до бизнеса результаты работы - навык очень полезный. Но оценивать демо предлагалось самим командам, что должно было вызывать большее погружение в работу коллег. Да, это очень субъективная метрика и поэтому она была в списке приоритетов последней, но своим присутствием придавала приятную капельку человечности всему процессу.
На очередном Scrum of Scrum я поделился с коллегами своими идеями по прокачке турнира команд. Вместе мы немного подтюнили мою реализацию, и на следующем планировании спринта командам было объявлено, каким будет новый турнир команд.
int compareTo(Team t1, Team t2) {
if (sum(t1.doneRate) > sum(t2.doneRate)) {
return -1;
}
if (sum(t1.doneRate) < sum(t2.doneRate)) {
return 1;
}
if (t1.totalDefectedSprints < t2.totalDefectedSprints) {
return -1;
}
if (t1.totalDefectedSprints > t2.totalDefectedSprints) {
return 1;
}
return t2.totalBestDemos - t1.totalBestDemos;
}
Спокойное погружение команд в новые бизнес домены увеличивало вовлеченность, и иногда это приводило к тому, что команда доставала такие неочевидные инсайты, что процесс достижения бизнес результатов становился проще ожидаемого.
Напишите в комментариях – какие практики оценки работы подобных команд «мастеров на все руки» есть в вашей компании.
habr.com
На новой работе был поставлен Scrum со всеми классическими церемониями. Кросс-функциональные команды были не привязаны к конкретным продуктам, а постоянно перемещались между различными модулями большой системы автоматизации сети пиццерий (и нет, это не та самая компания с птичкой на логотипе). Выбранная методология разработки помогла компании из региона силами достаточно небольшой команды оцифровать большое количество бизнес-процессов на предприятиях, тем самым подготовив их к приему большого числа заказов.
Но одного Scrum недостаточно для стабильной работы: нужны инструменты поощрения сотрудников. И тут тоже было всё по-классике: периодическая аттестация сотрудников, которая позволяла увеличивать персональный оклад, и премии, которыми награждались уже команды за успешное закрытие эпиков. Но было и местное ноу-хау – турнир команд. Его целью было поощрение поведения команд, которое обеспечивает успех бизнесу.
Оригинальный турнир команд
Когда я пришёл, турнир состоял из раундов, каждый из которых был привязан к двухнедельному спринту. Спринты всех команд синхронизированы по времени, т.к. разработка пока не могла отказаться от «релизного поезда». Перед началом следующего спринта одномоментно подводились итоги прошедшего спринта, и каждой команде выдавались баллы в зачет турнира по следующим критериям:- До 4 баллов за уровень Focus Factor-а (по сути – количество выполненной работы оцененной в Story Points) команды в спринте.
- Один балл, если после релиза не было обнаружено багов, которые потребовали либо срочный фикс, либо полный откат изменений, которые сделала команда.
- Один балл за выступление на внутреннем техническом митапе.
- Один балл за лучшее среди всех демо по мнению stakeholders.
На первый взгляд, система мне показалась вполне неплохой: взяли метрики, которые легко считаются, и вроде должны коррелировать с крутостью команды в техническом и бизнес контекстах. Но, поработав несколько спринтов с такой системой мотивации, во мне начало крепнуть ощущение, что здесь что-то не так.
Анализ ситуации
Текущие метрики казались мне слишком “шумными”, а некоторые – скорее даже вредными:- Focus Factor стимулировал команду либо брать очень много задач рискуя облажаться, либо завышать оценки, если задачи спринта не могли обеспечить полную занятость всех разработчиков команды. Отдельную проблему он создавал для инженерной команды состоящей из «ветеранов компании», которая с одной стороны следит за стабильностью прода, а с другой занимается продуктовыми задачами, которые требуют полного понимания всей системы.
- С метрикой по багам всё было вроде хорошо. Но я периодически замечал, что, несмотря на всю тщательность проверки системы целиком до релиза, баги иногда всплывали спустя недели и не мотивировали команды в следующий раз быть внимательней.
- Митапы по факту проходили недостаточно часто, чтобы хоть как-то влиять на турнир. Время между спринтами команды предпочитали тратить на проработку будущих спринтов, внутренние улучшения системы или саморазвитие.
- Оценки демо от stakeholder-ов были просто очень волатильными
Надо лишь что-то где-то поменять...
Мой опыт подсказывал, что секрет долговременного плодотворного сотрудничества разработки и бизнеса кроется в поиске баланса, где каждый получает то, что хочет. Для разработки новой схемы предстояло понять мотивацию всех заинтересованных сторон.Чего хочет бизнес
Мне стало понятно следующее:- Бизнес понимает, что в регионах есть сложность с наймом и удержанием разработчиков, работа которых выступает драйвером роста компании.
- Оффлайн взаимодействия зачастую очень дорогие, оттого доверие в них ценится намного выше, чем амбициозные заявления.
Чего хотят разработчики
«Америку» я тут не открыл:- Не выгорать на работе (work-life balance).
- Справедливой оценки.
- Саморазвития.
Дизайним желаемые свойства турнира
Стала вырисовываться картина того, какие свойства хочется от турнира, чтобы он работал на обе стороны.Эффективный
- Метрики сложно хакнуть: нужен механизм сдержек и противовесов.
- Высокий контраст метрик - «лучшие команды» не должны теряться в шуме.
- Надо использовать метрики, не дающие какой-то из команд преимущества, которое невозможно нивелировать.
Понятный
Хотелось выстроить для команд максимально простые правила без кучи развилок.Полезный для участников, а не только победителя
Бытует мнение, что не бывает мотивации - есть только манипуляции. Но я смотрел на турнир как на инструмент, который подтолкнет команды к практикам, улучшающие их ощущения от работы, а не заставит их работать больше.“Я сделяль”
Было очевидно, что без комбинирования метрик не обойтись. Но вместо «замешивания тёплого с гладким в одном котле», выбрал каскадный подход, который используется в ICPC: сортируем метрики по степени важности и не даём выигрышу по менее важной метрике перевесить выигрыш по более важной. С одной стороны это потребовало ответственного подхода к выбору метрик (иначе зачем было всё это затевать, не правда ли?) и правильных акцентов, с другой - позволило максимально четко донести до команд мнение бизнеса на их работу.Основным акцентом стала ответственность за взятые задачи. Это должно было повысить доверие между бизнесом и разработкой: у нас общие цели и мы «не заметаем общие проблемы под ковер». В качестве противовеса возможной стратегии “давайте будем меньше обещать” мы возложили на Product Owner-а и руководителей направлений разработки контроль над подозрительно высокой оценкой задач или слишком мелким дроблением user stories.
Вторым по приоритету стал «штраф» за недавние косяки, которые всё-таки дошли до пользователей. Чтобы и тут не происходило перегибов, решил ограничить сверху объем допустимого штрафа как по сроку давности, так и по объёму. На этот риск можно было пойти, т.к. у разработки, в целом, нет проблем с качеством релизов: тестировщики скрупулезно проверяют все целиком.
Ну и «на сладкое» оставил прокачку навыков проведения демонстраций. Умение правильно донести до бизнеса результаты работы - навык очень полезный. Но оценивать демо предлагалось самим командам, что должно было вызывать большее погружение в работу коллег. Да, это очень субъективная метрика и поэтому она была в списке приоритетов последней, но своим присутствием придавала приятную капельку человечности всему процессу.
На очередном Scrum of Scrum я поделился с коллегами своими идеями по прокачке турнира команд. Вместе мы немного подтюнили мою реализацию, и на следующем планировании спринта командам было объявлено, каким будет новый турнир команд.
Новый формат турнира
Турнир проводится постоянно, но разбивается на независимые сезоны. Каждый сезон длится 6 месяцев (январь-июнь и август-декабрь). В каждом сезоне считаются метрики каждой команды, которые влияют на ее место в турнирной таблице.Ведение статистики команд
В каждом спринте для каждой команды считаются следующие метрики:- Целочисленный процент сданных Product Owner-y историй от числа взятых за каждый спринт с округлением вверх к следующим 25% (назовём это done rate). Подсчитывается на момент отправления «релизного поезда» каждого спринта и далее не изменяется. Коэффициент 25 и округление вверх были выбраны эмпирически, чтобы немного сглаживать разное количество историй, которые бывают у команд (в среднем их около 4) и не сильно наказывать за небольшие провалы.
- Список спринтов с дефектами. Может увеличиваться в пределах текущего сезона.
- Было ли демо команды признано «лучшим демо спринта». Подсчитывается после проведения демо всеми командами спринта и далее не меняется.
Учёт числа спринтов с дефектами
Если на проде находится ошибка, которая была привнесена командой в рамках в текущем сезоне, то руководству отдела разработки (руководители направлений и Product Owner) необходимо принять коллегиальное решение о засчитывания дефекта в статистику одной из команд. Для этого необходимо:- Определить спринт, в рамках которого появился дефект.
- Заслушать мнение самой команды о сложившейся ситуации
- Коллегиально принять решение и объяснить его команде.
Определение лучшего демо спринта
Каждый участник команды должен посмотреть демо других команд и выбрать то, которое ему понравилось больше. Команда(ы), чьё демо получило больше всего голосов получает балл «лучшее демо спринта».Принцип ранжирования команд
Компаратор команд для всего сезона турнира от первого места к последнему выглядел бы так:int compareTo(Team t1, Team t2) {
if (sum(t1.doneRate) > sum(t2.doneRate)) {
return -1;
}
if (sum(t1.doneRate) < sum(t2.doneRate)) {
return 1;
}
if (t1.totalDefectedSprints < t2.totalDefectedSprints) {
return -1;
}
if (t1.totalDefectedSprints > t2.totalDefectedSprints) {
return 1;
}
return t2.totalBestDemos - t1.totalBestDemos;
}
Подведение итогов турнира
Победившая команда получает:- Переходящий кубок «Лучшая команда разработки», который размещается рядом с расположением членов этой команды. Выдается на следующий сезон.
- Возможность распорядиться денежным фондом текущего сезона турнира команд.
6 Month Later...
Проведя сезон турнира по новым правилам были замечены следующие изменения.Команды стали стабильнее работать
Когда гонка за story points была официально отменена, focus factor и story points превратились из внешнего инструмента мотивации во «внутреннюю красную лампочку команды», которая загоралась каждый раз, когда появлялся риск облажаться. Velocity в спринтах перестало колбасить, и подрос процент успешно вышедших в релиз историй.Команды стали чаще брать в спринты аналитические истории
Пусть таких абстракций и нет в Scrum, но без них команды рискуют наломать дров в незнакомых областях. Наша команда выступила живым примером полезности этой практики, которую подхватили и другие команды. Это повысило уровень принимаемых инженерных решений (появилась практика проведения Design Review) и снизился стресс для команд, когда им предстояло изучать что-то новое.Спокойное погружение команд в новые бизнес домены увеличивало вовлеченность, и иногда это приводило к тому, что команда доставала такие неочевидные инсайты, что процесс достижения бизнес результатов становился проще ожидаемого.
Команды стали поддерживать друг друга
Вот тут произошло то, чего я не ожидал: метрику «лучшее демо спринта» команды стали иногда использовать для моральной поддержки коллег: в сложных спринтах, когда, несмотря на все усилия, у кого-то что-то не получалось; когда команда сделала что-то значимое для всего отдела разработки. Пусть это и не оказывало существенного влияния на результаты, но всегда было приятно услышать на подведении итогов спринта, что другие команды поставили вам лайк.Незакрытый гештальт
Если для команд, которые занимались только разработкой бизнес функционала, турнир вроде сработал, то для инженерной команды, которая и за продом следила, не всё было так гладко. Они хотели участвовать в турнире наравне с другими командами, но у них был понятный скептицизм насчет того, что они смогут поддерживать высоким процент своих историй: всегда есть форс-мажоры, которые ломают планы. У меня не было хороших идей, как их удачно вписать в общую схему. Но у них всё неплохо получилось: они стали оформлять свои инфраструктурные задачи как истории и очень аккуратно их оценивать. Получалось у них это настолько хорошо, что они едва турнир не выиграли.Напишите в комментариях – какие практики оценки работы подобных команд «мастеров на все руки» есть в вашей компании.
В заключении
Как говорил британский статистик Джордж Бокс:В жизни нам так или иначе приходится сравнивать мягкое с круглым, принимать решения в условиях неполной информации и «шумных» метрик, как бы не вопил от этого наш внутренний математик. Просто потому, что иногда бездействие хуже любого из вариантов. Стремление действовать даже в таких случаях поможет прийти в патовой ситуации не только к компромиссу, от которого мы получим хоть что-то ценное, но иногда помогает достигать идеального Win-Win, если мы найдем в себе силы докопаться до глубинных целей каждой из сторон и устранить конфликт интересов.
В поисках полезного турнира scrum-команд
Полтора года назад я принял решение уйти из небольшого московского стартапа, где занимал руководящую должность, в более стабильную вологодскую компанию: вернулся «к станку» и стал Scrum Master-ом...
habr.com