в каком случае можно отменить демонстрацию команды

Процессы по Scrum. Демо спринта

Продолжаю серию статей про Scrum. В прошлый раз мы рассмотрели, как выполняется ежедневный Scrum-митинг, читайте об этом здесь>>

Вспомним, какую ценность дает возможность команде работать короткими спринтами? Целью работы по спринтам является получение быстрой обратной связи от владельца продукта по тому, что сделано командой за спринт, а это, в свою очередь, дает возможность уточнения требований к продукту проекта.

Мне очень нравится эта практика, т.к. команда не тратит много времени на «причесывание» ТЗ, а работает непосредственно над продуктом, создавая быстрые прототипы и показывая как это работает. Однако, не все заказчики проектов готовы смотреть части продукта, а не готовый полностью продукт. Поэтому прежде чем что-то показывать представителям заказчика, скрам-мастеру лучше объяснить им, что при работе по скрам не стоит ожидать законченных и выверенных решений, т.к. команде важно получить быструю обратную связь и если что-то сделано не так, подправить это в следующем спринте.

Что делать, если Вы, как скрам-мастер, понимаете, что владелец продукта и его коллеги не готовы смотреть что-то незаконченное или полусырое? Я в таких ситуациях предпочитаю проводить демо не по окончании каждого спринта, а по завершении какой-то логической части продукта. Да, это совсем не в духе скрам, но не отменять же из-за того, что владелец продукта не может смотреть на незаконченные вещи, работу по скрам?!

Честно признаться, мне жутко нравится прототипировать, и я использую этот подход очень часто и не только в бизнесе. Я заметил, что мне гораздо проще обсуждать требования к чему-то, когда есть какая-то упрощенная модель этого чего-то. Вместе с тем, я понимаю, что концептуальное проектирование больше подходит интуитам, чем сенсорикам. (О том, кто такие интуиты и сенсорики, подробнее читайте здесь>> )

Таким образом, знание MBTI мне помогает определить типологические особенности владельца продукта. И, если я понимаю, что он сенсорик, то я не буду ждать от него положительной реакции на мое предложение просматривать концептуальные (читай «сырые») прототипы частей продукта, над которым работает команда проекта. Для сенсориков я буду предлагать смотреть достаточно хорошо сделанные части продукта, которые выглядят законченными.

Еще одно наблюдение: умение правильно показать сделанное при работе по скрам – это очень важный навык. С одной стороны, команде проекта не стоит тратить слишком много времени на подготовку к демо, с другой стороны, сделанное нужно показать так, чтобы владелец продукта понял, как это работает и дал обратную связь. Поэтому, очень важно чтобы кто-то в команде владел навыками презентации.

Во время проведения демо я рекомендую кому-то из участников команды записывать полученную обратную связь от владельца продукта (и его представителей, если он пришел не один) и в конце демо продемонстрировать все сделанные записи и получить подтверждение, что все записано верно. Обычно, если я выступаю в роли скрам-мастера, то записи в ходе демо веду я.

Ну и после подтверждения владельцем продукта всех сделанных записей по итогам демо он включает новые пожелания в журнал продукта и приоритезирует их.

Что в итоге дает демо спринта?

Владелец продукта получает подтверждение того, что команда делает то, что имеет первоочередную важность для развития продукта и вносит коррективы, если что-то сделано не так, а команда получает обратную связь от владельца продукта и быстро исправляет ошибки в интерпретации требований, полученных от владельца продукта. Таким образом, продукт проекта наращивает свою функциональность от спринта к спринту и имеет шанс к концу проекта полностью попасть в ожидания владельца продукта.

Возникли при прочтении статьи какие-то вопросы? Пишите, я готов обсудить их.

Удачи Вам в Ваших проектах и до связи!

Источник

Agile. Успешное демо в распределённой команде

Обзор проекта

Команда разрабатывает ключевой продукт, используемый повсеместно всей компанией. У него есть более 10 ключевых заинтересованных лиц в Москве и еще около 10 по всему миру. Более половины из них – высшее руководство (очень занятые люди). Product owner, руководители команд и аналитики находятся в Москве. Scrum Master и команда разработки (около 15 человек) находятся в Днепропетровске.

Как это было

Итак, самый простой способ — просто попросить всех прийти и посмотреть. И именно этим путём пошла команда.
Однако произошло следующее:

Хаос на демо
• Не всем было понятно во сколько демо-сессия начинается и заканчивается
• Отсутствие чёткого плана демонстрации
• Отсутствие лидера демо-сессии
• Началось длительное обсуждение за пределами цели демо
• Никто до конца не понимал смысла этой встречи

Только участники из Москвы принимали активное участие
• Люди из других локаций не слышали обсуждений и не имели возможности общаться с другими участниками встречи

Отсутствие ясности и прозрачности
• Участники не понимали, что было показано
• Участники не понимали статус проекта целиком
• Участники получили большое количество сложных и неясных слайдов

Неверные пользовательские истории
• Часть невозможно было продемонстрировать
• Использование тестовых данных: “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 демо, как его эффективно проводить и многое другое мы детально раскрываем на наших тренингах.

Источник

Ежедневные собрания в Agile разработке: 15 минут, без которых не видать релиза

Большинство IT-компаний привыкли к ежедневным внутренним митингам, статусным собраниям или коротким stand up, которые призваны оптимизировать процессы и синхронизировать работу всех членов команды. Оптимально, если такие встречи не будут превышать 15-20 минут.

В Agile-разработке сегодня без митингов никуда. Однако рабочие собрания у команд Scrum, Kanban или XP отличаются и имеют свои особенности. В этом материале разбираемся в том, что отличает stand up в Scrum и Kanban, а также приводим аргументы в поддержку необходимости ежедневных собраний, как важного стимулятора роста в компании.

Любое внутреннее собрание – это элемент культуры любой организации. Не важно, какова цель встречи: обсудить выпуск новых почтовых марок или статусы задач в итерациях перед релизом вашего продукта, — каждое собрание собирает команду и обеспечивает принцип прозрачности работы.

Важно не создавать видимость полезного эффекта и не проводить собрания ради «галочки». Статус-собрание команды должно приносить пользу, потому что, даже 15 минут впустую потраченного рабочего времени каждого участника митинга может вылиться для компании в приличную сумму.

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

К сожалению, последняя большая цифра может настичь любую компанию: от «древней» бюрократической корпорации до молодого стартапа, в которых роль подобных встреч одинаково важна.

В Agile-командах, по большому счету, глобальный смысл ежедневного собрания с командой сводится к тому, чтобы быстро, качественно и надежно привести задачи к их завершению. Такое статус-собрание часто называют stand up, что имеет смысл «короткая встреча».

Менеджерам проектов или менеджерам продукта, которые чаще всего организовывают такие митинги и заботятся о том, как избежать рутины в задачах, следует постоянно следить, чтобы во время stand up некоторые члены команд не превратились в бесполезных статистов. Вот несколько их примеров:

Ежедневные собрания в командах Scrum и Kanban: в чем разница?

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

Главная цель в ежедневном митинге в Scrum-команде – отследить, смогут ли быть выполнены командой все итерации, либо как можно раньше выявить причины, почему они не могут быть выполнены. Stand up в Scrum ориентирован на людей. В течение непродолжительного митинга, каждый член команды по очереди озвучивает свои результаты прошедшего дня и актуальный статус задач, давая обещание команде выполнить конкретные задачи сегодня. Если есть какие-то проблемы – они также озвучиваются.

Цель митинга в Kanban — максимально сократить время работы над задачей на всех ее этапах. Kanban-собрания не являются обязательными, но носят рекомендательный характер, поскольку могут реально влиять на ход задач. Митинг ориентируется на конкретную доску и выявление тех самых узких мест (англ. bottlenecks).

Scrum митинг фокусируется на людях, Канбан митинг — на задачах

Классические вопросы собрания Scrum могут также задаваться по ходу Kanban встречи, но опять-таки с фокусировкой на задачи, а не на членов команды:

Сложно ли перейти с Daily Scrum на Daily Kanban?

Если принято решение перейти с Scrum на Kanban, то адаптация к новому формат встреч должна пройти гладко. Меняется формат обсуждения, но результат экономии времени очень скоро становится очевидным.

Как избежать «зависающих» задач?

Сперва важно понять, почему задачи «зависают» и предпринять действия по их эффективному ускорению. Причины «тормозящих» релиз задач могут быть следующими:

Как оптимизировать митинг. Или что мешает проведению эффективного stand up?

Каждый участник ежедневного stand up в любой Agile команде должен руководствоваться определенными правилами, которые помогут не превратить встречу в рутину, а в эффективное мероприятие:

Заключение

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

А вы уделяете достаточно внимания собраниям внутри команды? Как проходит ваш типичный stand up митинг? Делитесь в комментариях!

Источник

Как мы отменяли ретроспективы

Однажды для нашей команды перестали работать ретроспективы.

На ретро мы обсуждали вечные темы: надо лучше декомпозировать задачи, надо лучше оценивать задачи, надо перестать таскать долги между спринтами и т.д. Кто-то параллельно кодил, кто-то отвечал на сообщения, кто-то просто залипал в телефон. Звучит знакомо?

Это были мои первые спринты в роли скрам-мастера, и я чувствовал, у команды нет доверия к ретроспективам. Да и потребности тоже нет — есть жалобы на «скрам-день», забитый митингами. А работать-то когда?

Я решился на страшное для скрам-мастера: предложил команде отменить ретроспективы — и вот что из этого вышло.

Я, пытаюсь провести скучную ретроспективу

Привет! Меня зовут Павел, я занимаюсь фронтендом и скрамом в команде Wrike. Мы работаем по Scrum, сейчас у нас около 30 команд, в одной из которых я скрам-мастер. Я им стал уже больше года назад и хочу поделиться своим опытом. В этот раз — про ретроспективы.

Наши ретроспективы были похожи на карго-культ

Для полного погружения — пара слов про карго-культы. Вы знаете, островитяне во время Второй мировой войны осознали, что все самолеты (военные), которые прилетали к ним на остров (военную базу), на самом деле привозили множество замечательных предметов цивилизации именно для них, островитян. Когда война закончилась и самолеты перестали прилетать, их разочарованию не было предела.

Пытливый ум подсказал: чтобы вернуть самолеты, стоит попробовать сделать аэродром. Например, организовать взлетно-посадочную полосу в поле, разложить вдоль нее костры, соорудить радиовышку из пальмы, и, конечно, посадить диспетчера в шалаш. Все было сделано — но самолеты с дарами так и не прилетели.

Вот и у нас с ретроспективами вышла та же история. Они перешли по наследству от предыдущего скрам-мастера, и все внешние признаки соблюдались до сих пор: в конце каждого спринта команда собиралась, инспектировала себя, обсуждала план улучшений и следовала ему в следующем спринте. Только на практике мы обсуждали одно и то же в одном и том же формате, непонятно почему, непонятно для чего. Ребята не были вовлечены, в спринте потом все забывали про этот план, а скрам-мастер (я) все равно позитивно скакал вокруг доски каждую ретроспективу. Хуже всего, что в результате ничего не менялось.

Что мы сделали

Золотое правило скрам-мастера — не причинять команде скрам.

Окей: ретроспективы скучные, бесполезные, а вы все залипаете в ноутбуках. Давайте это узаконим и отменим следующую ретроспективу!

С таким посылом я и пришел к команде. Мне было важно понять, нужны ли ретроспективы самим ребятам и для чего. Если проблемы нет, то и не нужно искусственно ее «лечить». А если потребности нет, надо работать над ее здоровым формированием.

Моя гипотеза была в том, что при таком радикальном изменении команда сама расскажет, для чего ей нужна отмененная ретроспектива. Это было достаточно рискованно — отпустив команду тогда, я мог вообще не увидеть ее на следующих ретро. Но команда все сделала правильно.

Что получилось, когда мы отменили ретроспективы

Я, выясняю, зачем команде ретроспективы

Больше половины ребят с удовольствием меня поддержали и с формулировкой «конечно, лучше поработаем» расчехлили свои задачи на освободившееся время. Но три человека взбунтовались и привели такие аргументы:

Какие выводы мы сделали

Нужно верифицировать результат. Чтобы восстановить доверие команды к ретроспективам, нужно показать, что они приносят пользу. Команда не видела изменений после ретроспектив и поэтому перестала в них вкладываться. Какой толк что-то предлагать, если по опыту понятно, что мы это не реализуем? Если я хочу, чтобы команда начала лучше декомпозировать задачи — я и так буду это делать, а остальные все равно не начнут (а скрам-мастер не проконтролирует). Ребята так думали, потому что мы уже давно ничего такого не меняли, не улучшали.

Большим шагом стало то, что каждый Action Item мы стали заводить как отдельную задачу, брать в спринт, трекать его выполнение и верифицировать результат на следующем ретро. Началась долгая работа над тем, чтобы доказать команде: ретро работают, вот 10 закрытых экшн айтемов, которые вы предлагали, вот что мы поменяли.

Нужно разнообразить форматы. Классические плюсы-минусы, приехавшие от прошлого скрам-мастера, всем уже приелись. В конце концов, ретро — не только про прошедший спринт, это про улучшения. Когда команда уверена, что у нее все хорошо — можно построить колесо баланса и увидеть, что на самом деле — нет (и понять, над чем работать). Можно нарисовать кораблик и в игровой форме обсудить свои сильные и слабые стороны. Для команд в стадии forming плюсы-минусы скорее стоит заменить на синхронизацию ожиданий.

Есть куча идей, подходящих для разных целей. Они позволяют сделать ивент более драйвовым и вовлечь команду вместо того, чтобы терзать всех вопросами: «Ну что там из плюсов было в спринте? Что нам надо продолжать делать?». После перезапуска ретро мы попробовали разные форматы, стало весело, продуктивно, мы ушли от монотонных дискуссий, в которых участвует только 1-2 человека, и смогли вовлечь даже удаленных участников.

«Вечные темы» лучше обсуждать отдельно. «Как закрыть спринт без долгов», «как справляться с большими историями» — можно делать бинго, они всплывают у всех команд. Вместо того, чтобы постоянно мусолить их под видом «минусов спринта», мы зарезервировали под них отдельные ретроспективы — остальные стали чище, оживленнее и продуктивнее.

Заранее определять тему и цель ретроспективы. Если ребята бомбят — им не до моих колес баланса, надо разбираться с актуальными проблемами. Лучше выяснить это заранее, особенно если при сборе тем по ходу митинга начинается: «Ох, у меня что-то было на прошлой неделе, но я уже забыл» (туда же, в бинго).

Мы обсудили, что такие вещи лучше записывать по ходу спринта. Кто-то в шутку предложил сделать книгу жалоб.

Шутки шутками, но на следующий день я ее добыл и повесил на доске

Ребята заценили, но, естественно, никто ничего не написал. Зато прижилась книга жалоб в электронном виде — мы заранее создаем отдельную задачу на ретро и в описании фиксируем все моменты, которые нам надо не забыть обсудить. Важно, что ребята заполняют ее, идея прижилась и работает уже целый год.

Например, она может выглядеть вот так, если закрасить все, что должно остаться на самом ретро

Какую пользу принесли нам «обновленные» ретроспективы

За год с того момента мы закрыли десятки экшн айтемов, от понятных «обустроить комнату» и «сходить на тимбилдинг» до сложных «передать скоуп другой команде», «четко прописать план релиза». Мы берем их в спринт и верифицируем в начале следующей ретроспективы, чтобы подтверждать доверие.

За год мы накопили около 50 командных соглашений, к которым пришли через собственный опыт и ошибки:

А как у вас?

У каждой команды своя история ретроспектив и свои взаимоотношения со скрам-мастером. Например, мои друзья не понимают, зачем скрам-мастер нужен в их команде — он только заводит ненужные митинги и целый день пьет кофе. Точно ли это помогает команде вырасти? Точно ли это так видит сам скрам-мастер?

У всех свой положительный или отрицательный опыт. Делитесь своим в комментариях — и удачи в развитии вашей команды!

Источник