Друзья, всем привет!
Это третья, заключительная часть история про продакт-менеджера, который использовал Agile и наломал дров. Часть 1 и Часть 2.
Для наглядности я использую таблицу из второй части, чтобы показать, как сработала гипотеза и какой был эффект.
| № | Ошибка | Гипотеза для ее устранения | Ожидаемый результат | Полученный эффект |
| 1 | Груминг проводит аналитик. | Груминг проводит продакт | Продакт вместе с командой вовлечен в груминг задач и понимает, что там нужно сделать. Не сидит, не занимается в фоне другими задачами. | Полностью изменить процесс не удалось. В команде появилось два грумминга: от аналитика и продакта. |
| 2 | Работу оцениваем в человеко-часах, но не всю. | Всю работу оцениваем в человеко-часах или сторипоинтах | На основе статистики будем понимать капасити спринтов, не перегружать команду, а также давать бизнесу реальные сроки реализации фичи. | Перейти на стори-поинты не удалось. CTO был категорически против. Продакт так и не сумел убедить его на этот эксперимент. |
| 3 | Карту пользовательских историй строит аналитик. | Карту пользовательских историй строит продакт менеджер. | Продакт менеджер понимает последовательность фичей и может построить работу над продуктом итеративно, постепенно внедряя новые фичи. | До карты пользовательских историй не дошли. Стоит дополнить, что новый аналитик тоже не строил карту пользовательских историй. Данная практика не прижилась в команде. |
| 4 | Отказ от обзоров спринта. | Вернуть обзоры спринта в конце каждого спринта. | Стейкхолдеры понимают, что было сделано, могут задать вопросы по функционалу или дать обратную связь, что хорошо и что улучшить. | Продакт вернул обзоры спринтов и добавил к ним ежемесячное демо для стейкхолдеров, чтобы все видели изменения в продукте. Первое же демо показало полезность встречи. Все стейкхолдеры увидели новый ЛК и теперь могут рассказывать клиентам, что и как работает. |
| 5 | Цель спринта ставится не на какой-то функционал, а прописываются задачи для каждого члена команды, которые нужно закрыть за спринт. | Ставить одну цель спринта на конкретный функционал, который нужно сделать за спринт. | Фокус на одном функционале вместо списка задач позволит команде достигать цель за спринт. | Гипотеза сработала очень хорошо! Фокус на одной цели спринта дал свои результаты — команда стала делать самый важный функционал в течение одного-двух спринтов. Также сказалось ограничение функционала цели спринта. Теперь команда делает работу итерациями и успевает сделать функционал или полностью за спринт, или 90% от него. |
| 6 | Прилетающие баги сразу берутся в спринт, что расширяет его объём. | Сделать классы обслуживания для срочных задач, договориться, что берем в текущий спринт, а что оставляем для следующего. | Меньше переключений внутри спринта, сохранение капасити спринта, исключение рисков не достичь цели спринта. | Не успели внедрить. |
| 7 | Задач в спринте раз в 10 больше, чем членов в команде. | Пересекается с п.2. Объём задач в спринте должен соответствовать капасити команды. | Меньше переключений в спринте между задачами, фокус на завершение начатой работы снижение перегруза в команде. | Внедрили, но не до конца. Не хватило времени. |
| 8 | На груминге оценивается и обсуждается одна задача и та — пользовательская история. Таски и баги не оцениваются никак. | Пересекается с п.1 и п.2. Необходимо сделать еженедельные груминге и оценивать все задачи в бэклоге. | Будет проще рассчитать объем спринта, так как все задачи будут оценены, и сопоставить его с капасити комнады. | Не успели внедрить. |
| 9 | Нет понимания капасити команды (как следствие не оцененных задач). | Начать измерять капасити команды, начать собирать статистику. | Формировать объем спринта в соответствии с капасити команды. Больше завершенных задач в конце спринта. Выполнение цели спринта. | Не успели внедрить. |
| 10 | Нет понимания скорости команды (как следствие не оцененных задач). | Начать измерять пропускную способность команды — сколько взяли в спринт, сколько закрыли. | Снизится нагрузка на команду, снизится количество незавершенных задач, появится понимание скорости команды — будет легче выполнять взятые в спринт задачи. | Не успели внедрить. |
| 11 | Я использовал из Канбана подход “no estimate”, но неверно понял его суть. | Переход на подход “No estimate” возможен, когда уже накоплена статистика по классам обслуживания. | Ускорится планирование спринта и сохранится высокая вероятность реализации задач спринта. | Не успели внедрить. |
| 12 | Отсутствие согласований документации с бизнес-заказчиками. Если не согласовывать готовую документацию, а сразу передавать ее в разработку — это пипец как сокращает лид тайм. | Согласовывать с заказчиком документацию перед разработкой. | Это сэкономит время на переделку задач по некорректным требованиям. | Гипотеза очень хорошо сработала. Бизнес стал принимать документацию. Это немного сказалось на Lead Time, так как всё равно уходило время на согласование. Делали это асинхронно в почте. |
| 13 | Отсутствие приемки на стейдже готового функционала заказчиками. Это капец как сокращает лид тайм. | Согласовывать с заказчиком задачи на стейдже перед выкаткой в прод. | Это сэкономит время на переделке задач, которые не соответствуют ожиданиям заказчика. | Гипотеза очень хорошо сработала. Переделки свелись к минимуму. Но до конца процесс не сформировали. Это сказалось на Lead Time. Асинхронно в почте не работает. Следующая гипотеза — вернуть обзор спринта и показывать готовый функционал ключевым стейкхолдерам. |
Резюме
Я раньше думал, что роль агента изменений или коуча скоро перестанет быть нужной, так как Agile, Scrum и Kanban уже много лет и все «точно знают, как по ним работать». Я ошибался. Роль по-прежнему критически важна и нужна, чтобы посмотреть со стороны, как устроены процессы и подсказать, что и как можно поправить.
Так что если вы Agile-коуч, Канбан-коуч и агент изменений, не переживайте. Вы по-прежнему нужны. Правда уже не в таком объеме, как это нужно было раньше, но всё равно ценность роли очевидна.
Пожелаю этому продакту успехов в следующих компаниях и продуктах. Если вам нужна консультация, обращайтесь. Обязательно помогу!
1 thought on “Результаты работы над ошибками в Agile. Часть 3”
Comments are closed.