Project Demonstration, Sprint Demo, Sprint Review, Iteration Increment Show – мы все знакомы с различными названиями одного и того же процессного события фреймворка Scrum. Цель этих встреч состоит в том, что бы показать заинтересованным лицам и владельцам бюджета проекта всё, что команда сделала в конце итерации. Все мы знаем, насколько важна эта встреча и насколько, в теории, это просто – всего лишь собрать всех и показать, что вы сделали.
Ниже опыт реального проекта. Мы рассмотрим основные проблемы, а затем акцентируем внимание на аспектах эффективной подготовки и успешной демонстрации результатов спринта.
Обзор проекта
Команда разрабатывает ключевой продукт, используемый повсеместно всей компанией. У него есть более 10 ключевых заинтересованных лиц в Москве и еще около 10 по всему миру. Более половины из них – высшее руководство (очень занятые люди). Product owner, руководители команд и аналитики находятся в Москве. Scrum Master и команда разработки (около 15 человек) находятся в Днепропетровске.
Как это было
Итак, самый простой способ — просто попросить всех прийти и посмотреть. И именно этим путём пошла команда.
Однако произошло следующее:
Встреча началась с задержки на 15 -20 минут
• Команда ждала всех приглашённых
• Команда начала подготовку в начале встречи: WebEx, аудио конференция, подключение к системе и т.п.
• Микрофоны не работали или работали плохо.
Хаос на демо
• Не всем было понятно во сколько демо-сессия начинается и заканчивается
• Отсутствие чёткого плана демонстрации
• Отсутствие лидера демо-сессии
• Началось длительное обсуждение за пределами цели демо
• Никто до конца не понимал смысла этой встречи
Только участники из Москвы принимали активное участие
• Люди из других локаций не слышали обсуждений и не имели возможности общаться с другими участниками встречи
Отсутствие ясности и прозрачности
• Участники не понимали, что было показано
• Участники не понимали статус проекта целиком
• Участники получили большое количество сложных и неясных слайдов
Неверные пользовательские истории
• Часть невозможно было продемонстрировать
• Использование тестовых данных: “12345”, “qwerty”, “test surname_1”. Участники не понимали, как это будет работать в реальной жизни.
• Фактический объём пользовательских историй был не ясен. Было трудно понять выполнена эта история или нет.
• Причины выбора имплементации не были ясны
Технические истории были показаны абсолютно не техническим людям. Большое количество технических деталей было не приемлемо для такой аудитории.
Забытые Action Items. Было очень много пунктов, которые или были потеряны после встречи или неверно истолкованы.
Решения и методы, которые помогли
Итак, всем понятно, что эта встреча прошла не эффективно. Какие методы помогли улучшить ситуацию:
Создание повторяющихся встреч. Мы создали повторяющие встречи в Outlook – все участники всегда знали, где и во сколько будет следующее демо. Это позволило всем участникам заранее планировать своё расписание.
Внесение подготовки в расписание. Теперь каждый, кто был ответственен за проведение Демо, имел время для подготовки (старт аудио/видео конференции, проверка подключения, готовность конференц-зала и т.д.). Всё это делалось для того, чтобы, когда заинтересованные стороны пришли на встречу, всё уже было готово и мы могли начинать.
Определение условий для старта. Мы решили, что демо начинается именно тогда, когда ключевые участники(2-3 человека) присутствуют. Теперь все заинтересованные стороны знают, что мы начинаем именно тогда, когда придут ключевые участники и больше не будет никаких задержек.
Строгая агенда встречи. Демо следует согласно агенде. Агенда прописана в расписании и напоминается перед каждой встречей. Теперь все знают когда тот или иной пункт будет обсуждаться и не возникает хаотических дискуссий.
Рабочие соглашения. Это инструмент сохранения эффективности встречи и поддержания сосредоточенности на достижения цели встречи. Рабочие соглашения написаны на маркерной доске на каждом Демо. Демо-лидеры могут использовать их как инструмент управления дискуссией.
“Parking Lot”. Когда дискуссия уходит за пределы агенды или займёт слишком много времени, то лидер демо помещает его на «стоянку», как Action Item. Любые Action Items, возникшие во время встречи, также помещаются туда.
Раздаточные материалы. Мы напечатали красочные раздаточные материалы, чтобы каждый мог увидеть слайды презентации и быть в состоянии делать заметки для себя. Также полезно, чтобы на проектор выводилась не только презентация, но и работающее приложение.
Agile Графики. Мы изменили все слайды со статусом релиза или спринта. Ранее использовался «классический подход», мы сделали его более «agile». Это повысило понимание прогресса.
Было:
Стало:
Демо Лидер. Мы ввели роль лидера демо. Это только один ведущий в конференц-зале, который управляет демо, дает право голоса другим, следит за временем, повесткой дня и использует рабочие соглашения как инструмент управления демо. Теперь все знают, кто является лидером и кто имеет право управлять встречей.
Помощник в другой локации. Мы сделали одного из членов команды в Днепропетровске ассистентом Демо Лидера. Ассистент контролирует все, что отображается на экранах и может подключать членов команды к обсуждениям. Также помощник вручную добавляет Action Items на Parking Lot, чтобы каждый в режиме реального времени видел, что все написано и написано правильно.
Видео Мост. Мы отказались от скучной и неэффективной аудиоконференции и ввели видеомост. Презентацию и приложение показали с помощью проекторов. Сейчас заинтересованные стороны и члены команды не только видят приложение и слышат презентацию, но могут эффективно общаться, видя друг друга.
Удаление технических историй. Мы убрали технические историй из демо, потому что они не интересны для заинтересованных сторон и могут ввести их в заблуждение. Но для всех, кто хочет их увидеть(например, если среди заинтересованных сторон есть технические ребята) выделен временной интервал сразу после демо для их показа.
Вопросительные знаки. Знак вопроса – очень быстрый и действенный механизм остановки демо. Это работает лучше, чем попытки прервать говорящего человека из другой локации.
Приём пользовательских историй на другой встрече. Мы сделали еще одну встречу, перед демо для приемки историй(с использованием критериев приёмки, определённых владельцем продукта). Процесс детальной приёмки не интересен для заинтересованных сторон – им не интересна демонстрация каждой истории в деталях. Так что на демо мы показываем только принятые владельце продукта пользовательские истории, собираем отзывы.
Быстрая обратная связь. Мы просим заинтересованных сторон после демо дать быстрый отзыв о организации демо ( что было хорошо, а что нет). Это помогает нам улучшать качество демо непрерывно.
Ретроспектива демо. Мы проводим короткую ретроспективу после каждого демо. Это помогает улучшить слабые места.
Вот и всё. Нет магии, rocket science, комплексных решений – это всего лишь ряд простых, но мощных методов, которые помогли команде стать более эффективными в проведении демо и сделало их клиентов счастливыми.
Это не полный список того, что можно улучшить в проведении демо. Зачем в Agile демо, как его эффективно проводить и многое другое мы детально раскрываем на наших тренингах.
А как вы проводите свои демо?
Автор: Evgenia_s5
