Первый Спринт
Как говорят, «первый блин комом». Это относилось и к первому Спринту. Несмотря на всю подготовку и тренинги, команды лицом к лицу столкнулись со сложностями локальной оптимизации. Ранее в компании не было ориентированного на клиентов Бэклога Продукта. Теперь же порядок в Бэклоге Продукта определялся, главным образом, важностью фич для клиента.
Изучив Бэклог Продукта, дизайнеры и разработчики Android увидели, что в первом Спринте для них мало работы. Поэтому в ходе Спринта они много времени занимались обучением и помогали другим. Это обычная ситуация: первый Спринт выявляет так называемый «долг знаний», который всегда скрыто присутствует в функциональных подразделениях. Особенно это касается масштабных внедрений, когда речь идёт о крупных подразделениях — и крупных «долгах знаний». Этот новый «организационный перенос навыков» (если использовать формулировки из первой статьи о Скраме в Harvard Business Review за 1986 год) был очень непривычен участникам группы. Люди не понимали, почему нужно учиться вместо того, чтобы «делать что-то полезное».
Мы обнаружили несколько проблем, которые не учли во время запуска. Например, как справляться со срочными задачами и багами, поступающими от группы технической поддержки. Также мы не учли заранее, как будем проводить регрессионное тестирование. К сожалению, налицо был большой технический долг, а доля автоматического тестирования была мала.
Я также заметил, что люди устали от большого количества тренингов и длительного запуска. Тем не менее, первый Обзор Спринта прошёл успешно. В ходе него команды демонстрировали готовые PBI. Заинтересованные сотрудники компании, посетившие Обзор, дали положительную оценку увиденному.
В ходе первого Спринта накопилось огромное количество вопросов. Многие вопросы, поступившие от команд, были схожими, поэтому в конце Обзора Спринта я предложил провести несколько более длительную Общую Ретроспективу, в которой бы участвовали все члены продуктовой группы. Нам понадобилось три часа и масса терпения. В результате вышли на такие решения:
Изучив Бэклог Продукта, дизайнеры и разработчики Android увидели, что в первом Спринте для них мало работы. Поэтому в ходе Спринта они много времени занимались обучением и помогали другим. Это обычная ситуация: первый Спринт выявляет так называемый «долг знаний», который всегда скрыто присутствует в функциональных подразделениях. Особенно это касается масштабных внедрений, когда речь идёт о крупных подразделениях — и крупных «долгах знаний». Этот новый «организационный перенос навыков» (если использовать формулировки из первой статьи о Скраме в Harvard Business Review за 1986 год) был очень непривычен участникам группы. Люди не понимали, почему нужно учиться вместо того, чтобы «делать что-то полезное».
Мы обнаружили несколько проблем, которые не учли во время запуска. Например, как справляться со срочными задачами и багами, поступающими от группы технической поддержки. Также мы не учли заранее, как будем проводить регрессионное тестирование. К сожалению, налицо был большой технический долг, а доля автоматического тестирования была мала.
Я также заметил, что люди устали от большого количества тренингов и длительного запуска. Тем не менее, первый Обзор Спринта прошёл успешно. В ходе него команды демонстрировали готовые PBI. Заинтересованные сотрудники компании, посетившие Обзор, дали положительную оценку увиденному.
В ходе первого Спринта накопилось огромное количество вопросов. Многие вопросы, поступившие от команд, были схожими, поэтому в конце Обзора Спринта я предложил провести несколько более длительную Общую Ретроспективу, в которой бы участвовали все члены продуктовой группы. Нам понадобилось три часа и масса терпения. В результате вышли на такие решения:
- Алгоритм для разработчиков с малым количеством задач по основной специализации во время Спринта: помогать коллегам по команде (в парной работе), продолжать приобретать новые навыки, помогать другим командам.
- Как проводить регрессионное тестирование и на самом деле выпускать инкремент. Мы уточнили разработанные ранее Критерии Готовности и расширили их.
- Как во время Спринта обрабатывать срочные задачи и баги: они поступали через отдельный резервный канал, и любая группа могла их взять при наличии свободных ресурсов.
Визуальный менеджмент
Визуализация Бэклога Продукта.
Мы с самого начала визуализировали Бэклог Продукта (эксперимент «Попробуйте визуальное управление Бэклогом Продукта или Релиза»). Владелец Продукта и два сотрудника, которые противились внедрению Скрама и поэтому не были включены в состав какой-либо группы (два бизнес-аналитика), вели актуальный Бэклог Продукта прямо на стене. Каждый PBI был представлен стикером. Элементы перемещались по стене слева направо к состоянию «готов» и в итоге становились частью Бэклога Спринта.
Визуализация Бэклога Спринта. Я предложил командам визуализировать Бэклоги Спринтов и ограничить незавершенную работу (WIP). Мы провели небольшой воркшоп по Канбану и сыграли в FeatureBan. Эта небольшая игра прекрасно демонстрирует необходимость ограничения WIP и принципы оптимального управления очередями. Каждая команда установила чёткие ограничения WIP для Бэклога Спринта.
Визуальный менеджмент помогает коллаборации.
В LeSS нет зависимостей между командами. Почему? Любая фиче-команда может работать со всей кодовой базой независимо от других команд. И команды сами координируют взаимодействие между собой, внедряя такие подходы, как непрерывная интеграция, сообщества, мультикомандные архитектурные воркшопы, скауты и т.д. Поэтому для команд есть только возможности только для сотрудничества и совместной работы, а зависимостей нет.
Во время Второй Части Планирования Спринта мы заметили, что полезно отмечать PBI, для выполнения которых во время предстоящего Спринта потребуется совместная работа нескольких команд. Обычно это был просто ещё один небольшой стикер с техникой координации (например, «скаут», «компонентный ментор», «просто поговорите» и т. п.).
Визуализация рабочих договоренностей. Все основные рабочие договорённости (Определение Готовности и пр.) и решения с Ретроспектив хранились в той же комнате, что и Бэклог Продукта. Мы визуализировали график мероприятий LeSS и вывесили его в коридоре. Рядом висел календарь встреч сообществах.
Мы с самого начала визуализировали Бэклог Продукта (эксперимент «Попробуйте визуальное управление Бэклогом Продукта или Релиза»). Владелец Продукта и два сотрудника, которые противились внедрению Скрама и поэтому не были включены в состав какой-либо группы (два бизнес-аналитика), вели актуальный Бэклог Продукта прямо на стене. Каждый PBI был представлен стикером. Элементы перемещались по стене слева направо к состоянию «готов» и в итоге становились частью Бэклога Спринта.
Визуализация Бэклога Спринта. Я предложил командам визуализировать Бэклоги Спринтов и ограничить незавершенную работу (WIP). Мы провели небольшой воркшоп по Канбану и сыграли в FeatureBan. Эта небольшая игра прекрасно демонстрирует необходимость ограничения WIP и принципы оптимального управления очередями. Каждая команда установила чёткие ограничения WIP для Бэклога Спринта.
Визуальный менеджмент помогает коллаборации.
В LeSS нет зависимостей между командами. Почему? Любая фиче-команда может работать со всей кодовой базой независимо от других команд. И команды сами координируют взаимодействие между собой, внедряя такие подходы, как непрерывная интеграция, сообщества, мультикомандные архитектурные воркшопы, скауты и т.д. Поэтому для команд есть только возможности только для сотрудничества и совместной работы, а зависимостей нет.
Во время Второй Части Планирования Спринта мы заметили, что полезно отмечать PBI, для выполнения которых во время предстоящего Спринта потребуется совместная работа нескольких команд. Обычно это был просто ещё один небольшой стикер с техникой координации (например, «скаут», «компонентный ментор», «просто поговорите» и т. п.).
Визуализация рабочих договоренностей. Все основные рабочие договорённости (Определение Готовности и пр.) и решения с Ретроспектив хранились в той же комнате, что и Бэклог Продукта. Мы визуализировали график мероприятий LeSS и вывесили его в коридоре. Рядом висел календарь встреч сообществах.
Попробуйте визуализировать встречи.
Я фанат Дэвида Сиббета и концепции визуальных встреч. В ходе таких встреч мне нравится визуализировать все без исключения. Я называю эти визуализированные встречи «живыми», потому что они стимулируют высокий уровень вовлеченности, формируют общую картину происходящего и способствуют групповой памяти. Вот что отличает «живые» встречи от «мёртвых»:
- участники стоят и активно участвуют в обсуждении;
- работа ведётся в небольших группах (до 5 человек);
- никаких электронных устройств — только стикеры, маркеры, ножницы, флипчарты и бумага;
- визуализация всех обсуждаемых вопросов (мнение каждого будет услышано);
- периодически группы разбиваются на малые группы и снова объединяются, благодаря чему команды выигрывают от работы и автономных дискуссий в малых группах, а потом и от общего обсуждения на пленарной сессии в общей группе.
Координация
Интересно, что до того, как команды узнала про LeSS, оны считала координацию работы самым важным вопросом. Во время встречи в формате Lean Coffee я заметил, что большая часть вопросов касалась именно координации. Мы быстро закрыли эти вопросы. Перед тем как изменять структуру, мы провели тренинг Certified LeSS Basics (CLB), в ходе которого обсуждали вопросы координации и на котором команды заполнили таблицу, в которой указали то, что необходимо координировать и то, как они это будут делать. По моим наблюдениям, самыми используемыми практиками координации были руководство «Коммуникация в коде», руководство «Просто поговорите» и более продвинутая версия «Просто крикните».Команды выбирали подходящую практику в зависимости от ситуации, возникающей во время Второй Части Планирования Спринта. LeSS работает с возникающей координацией, которая базируется на самоорганизации. Одним из важных для самоорганизации моментов было размещение всех команд в комнатах, выходящих в общий коридор.