Собрание в Scrum (или Scrum Stand Up) — плановая встреча, которая помогает продуктовым группам быть более эффективными и актуализировать ежедневные процессы. Рекомендуется, чтобы митинг не продолжался более 15 минут. Помимо product owner и Scrum master во встрече также участвуют другие члены команды.
Основная идея собрания в Scrum — провести 15 продуктивных минут всей командой, сообщая друг другу статус работы. Во время собрания каждый член команды рассказывает собравшимся о текущем положении своих дел.
Формат проведения Scrum meeting не предполагает наличия стола и стульев. Все происходит стоя, чтобы не “растягивать” встречу на продолжительное время. Если некоторые вопросы требуют дополнительного внимания, они могут обсуждаться теми, кто вовлечен, после собрания.
Сегодня ежедневное собрание в Scrum часто подвергается критике, его иногда считают устаревшей практикой. Однако Scrum meeting остается довольно популярным среди многих команд разработчиков. Собственники продуктов во всем мире подтверждают, что такой формат встречи помогает более эффективно управлять командой.
Организация эффективной Scrum-встречи для собственников продуктов не является уникальным талантом. Грамотной подготовке и проведению можно научиться, практиковать и постоянно улучшать этот навык. Следующие советы помогут начинающим product owners или тем, кто много раз организовывал Scrum meeting, но что-то пошло не так.
8 простых советов для организации эффективного Scrum-собрания
Определите формат митинга
В Agile-контексте ежедневный Stand up происходит в течение спринта, который является периодом работы в 2-4 недели. Во время спринта определяется набор фич и требований из бэклога для новой итерации.
Важная задача — четко определить временные рамки встречи, и помнить, что ежедневный Stand Up отличается от других встреч (например от retrospective meeting).
Пригласите команду и определите участников встречи
Лучшее решение для Scrum-собрания — это 8-12 человек, заинтересованных в обсуждении. Это упрощает коммуникацию и не затягивает встречу. На собрании рекомендуется присутствовать трем основным заинтересованным сторонам, которые выполняют главные роли в Scrum-команде:
- Scrum master, который выступает в качестве коуча команды и помогает оптимизировать работу.
- Собственник продукта (product owner) или менеджер продукта (product manager), которые представляет ключевую заинтересованную сторону в продукте. Он/она отвечает за приоритизацию и общается с другими заинтересованными сторонами и экспертами.
- Непосредственно команда, которая включает разных сотрудников с важными для продукта навыками и обязанностями (разработчики, маркетологи, поддержка и т.д.)
Часто к собранию приглашаются сторонние участники или удаленные сотрудники. Однако важно помнить про ограничение посещаемости собрания — это действительно может способствовать укреплению доверия и уверенности членов команды.
Разберитесь с местом и временем
Как отмечалось выше, место проведения Stand Up не нуждается в определенной технике и атрибутах. Полезной может быть доска со стикерами или монитор для использования специального инструмента или сервиса для управления проектами, где будут отмечаться статусы и записываться заметки. По сути, нужно просто свободное помещение.
Эксперты советуют проводить ежедневный Scrum митинг в одно и то же время каждый день. Лучше это сделать в начале дня — тогда у всех будет четкое представление о том, чему будет посвящен день.
Если у вас есть удаленные члены команды, заранее убедитесь, что они уведомлены о собрании и смогут участвовать. Во многих компаниях для работы с распределенными сотрудниками используются специальные удобные сервисы. Один из них — Standuply. Инструмент помогает проводить собрания или опросы в Slack, а потом отправлять результаты в таск-трекер.
Стоя, зато быстро
Многие согласятся, что собрание стоя не будет затягиваться никем. Кроме того, это помогает сфокусировать внимание на самом главном.
В некоторых креативных командах стало модным проводить короткие собрания в планке или выполняя другие полезные физические упражнения.
Соблюдайте повестку дня
Ежедневное собрание в Scrum должно быть основано на трех основных вопросах, на которые должен ответить каждый член команды:
- Что было сделано вчера?
- Что будет сделано сегодня?
- Что мешает справиться с планом дня? (если что-то мешает)
Отвечая на эти простые вопросы, команда быстро может выявить проблемы, которые требуют особого внимания и оптимизации.
Не забудьте делать пометки и расшарить их, чтобы все были в курсе и своевременно реагировали.
Упростите процесс
Повестку дня ежедневного Scrum-собрания и статусы желательно визуализировать. Для этого придуманы полезные инструменты управления. Например, Канбан-доски, которые не позволят упустить не один рабочий вопрос и все разложить “по полочкам”. Вот как это выглядит в некоторых сервисах:
Очень важно видеть, что и когда заканчивается, что ждет своей очереди, а от чего вообще лучше избавиться. В этом смысле собственникам продуктов не обойтись без графиков для известных техник приоритизации.
Сотрудничайте и коммуницируйте
Помните, что ваше ежедневное Scrum-собрание — это ценное время, которое следует рассматривать как совместное усилие всей команды. Каждый участник собрания должен понимать, что все, что он говорит, должно быть полезным и эффективным для всех собравшихся. Правильно выстроенная коммуникация — залог продуктивности.
Избегайте типичных ошибок
К наиболее частым ошибкам при проведении Scrum-митинга отнесем следующие:
- Долгое ожидание команды. Для продуктивной встречи важно четко соблюдать тайминг и появляться вовремя. Не тратьте драгоценные минуты на ожидание всех. Кто не успел — тот опоздал.
- Новые темы и идеи. Scrum meeting — это не планирование, а статус-собрание. Не забывайте об этом.
- Долгое “плавание” в разных направлениях. Любители долго и много говорить должны помнить, что каждое “лирическое отступление” вредит общей эффективности встречи. Все, что члены команды говорят, должно быть ценным для всех.
В этих простых советах нет ничего нового, однако на старте карьеры они наверняка помогут выстроить качественное и эффективное собрание в любой Scrum-команде. Со временем, соблюдая простые хитрости и постоянно думая о команде, product owner действительно сможет обеспечить команде интересные и продуктивные 15 минут встречи, на которую будут приходить с удовольствием, а не ради “галочки”.
А какие ваши секреты проведения собрания в Scrum-команде?
Комментарии (28)
time2rfc
19.06.2018 16:16-1Ежедневное собрание в Scrum-команде должно помочь собственнику и менеджеру продукта
менеджеру продуктаНечасто вижу людей которые так умело дискредитировали свою экспертизу с первых строк.
В scrum команде нет роли менеджер. Тут либо крестик снимать либо плавки надеть нужно.nodonutsforyou
20.06.2018 16:55Если вы судите о процессах по обертке, то это вы себя дискредитируете.
Первый принцип agile — человеческие отношения которые важнее учебника.
Есть два места, где понятие менеджер входит в scum:
1) Есть люди которые больше делают технические вещи а есть люди которые больше взаимодействуют с людьми. Первых логично назвать разработчиками, вторых менеджерами. Если назвать собственника и scrum master'а менеджерами — по сути ничего не измениться. Придираться нужно к сути, к тому как выстроены процессы, а не к названиям.
2) Вне скрама есть своя организационная структура — и у проекта есть человек который отвечает за проект/продукт. Этот человек может быть собственником, может скрам-мастером, а может быть частью команды — не суть важно. Но роль такая есть в жизни. Это задача скрама ее в себя включить, а не наоборот.time2rfc
21.06.2018 00:30Извините меня за мою глупость, и поверхностность.
Спасибо что процитировали слова, которые я слышу раз за разом в 9 случаях из 10 когда мне объясняют зачем нужен менеджер в их версии scrum'на.
Мне повезло, когда компания решила оплатить мою сертификацю scrum-мастера международной тренинговой конторой. Так получилось что в scrum нет менеджеров, использования слова менеджер сильно ошибочно. Если Вы подразумаевте под менеджером переговорщика, то странного называть его менеджером. Проактивный разработчик договаривается с соседними командами и пилит функционал, от того что он договорился стал ли он менеджером ?nodonutsforyou
21.06.2018 12:56-1Если Вы подразумаевте под менеджером переговорщика, то странного называть его менеджером
Я согласен, что странно. Но так есть. Человека который пошел в софт скилы вместо хард скилов у нас принято называть менеджерами. Так называется должность в платежной ведомости, так пишут в вакансиях на хэдхантере и так называет таких людей уборщица баба Маня. Не важно, оправдано это или нет.
Я лишь утверждаю, что можно сделать правильный скрам, продолжая использовать слово менеджер. И можно провалить скрам польностью отказавшись от этого слова. Не в слове дело.
Так получилось что в scrum нет менеджеров, использования слова менеджер сильно ошибочно.
Менеджер проекта/продукта есть в реальной жизни. Всегда есть человек который принимает решение, что проект будет и несет за него ответственность. До того как команда стала делать скрам должен быть человек, который принял решение делать скрам. И этот человек может быть на разных ролях в скраме, или, например, стэйкхолдером без явной роли. И в контексте статьи явно говориться про этого человека. Как еще его назвать?time2rfc
21.06.2018 13:44Но так есть. Человека который пошел в софт скилы вместо хард скилов у нас принято называть менеджерами.
У вас в компании? Софт скилл и управленец принимающий решения — это разные вещи. Развитый софт-скилл не делает меня менеджером, он делает меня человеком с сильным софт-скиллом.
Проект стартует и строит бизнесс.
Бизнесс платит зп команде разработки, ПО и scrum-мастеру.
Бизнесс принимает решение. Вы жалуетесь на сложность натянуть scrum на вертикальные директивные компании, но это конкретная проблема натягивания scrum на вертикальную компанию, в горизонтальных таких проблем нету.nodonutsforyou
21.06.2018 14:19Развитый софт-скилл не делает меня менеджером
Вы меня не услышали. Я не готов рассуждать что делает менджера менеджером. В индустрии используется такое слово — не важно используют его правильно или нет. В реализации скрама люди делают много ошибок. Посмотрите соседние ветки — там притензии к статье по делу. Использование слова менеджер, к месту или нет — это шашки. Вам шашечки или ехать?
Проект стартует и строит бизнесс.
Бизнес — это кто?
В любой, даже горизонтальной структуре всегда будет человек, принимающий конкретное решение.
Бизнесс не может принять решение — бизнесс не личность.
Вы жалуетесь на сложность натянуть scrum на вертикальные директивные компании
Я не жалуюсь. Я работаю на аутстафе и часто меняю компании, поэтому вижу разные ситуации.
Я предложил конкретный пример, когда понятие проект менджера применимо к scrum — что ПМ создает scrum команду и становится собственником или стейкхолдером. Мне кажется, что это вполне рабочий вариант. Вы в ответ предлагаете менять всю вертикальную структуру компании?
У горизинтальный компаний есть свои проблемы — горизонтальность нельзя назвать универсальным решением.time2rfc
21.06.2018 14:35CEO решил начать проект
собрали dev — команду, позвали ПО и скрам-мастера, где в этой истории менеджер ?nodonutsforyou
21.06.2018 15:07CEO — менеджер вот прям по определению. Если CEO не менеджер, то не понятно кто вообще менеджер.
Затем. Обычная ситуация, у ПО обычно в этой истории есть визитка, в которой написано: «продакт менеджер». И зарплату в бухгалтерии когда он получает — в ведомости написано «продакт менеджер». И когда члены команды уходят в отпуск — ПМ подписывает бумажку, где написано что он «продакт менеджер» и отпускает члена команды в отпуск. И самое главное, если проект провалится, то ПО не получит премию и нагоняй получит именно ПО в первую очередь.
Я не говорю, что ПО в этой истории ПМ или что так и должно быть всегда. Я говорю, что если вы приходите на аудит в эту историю, и первая ваша претензия: «у вас есть ПМ и скрам у вас неправильный потому что у вас есть ПМ», то вы явно упустили смысл скрама.time2rfc
21.06.2018 15:34что делать тем людям у которх на визитки ПО нет слова менеджер, в рассчетной ведомости ПО тоже нет слова менеджер, а еще он не подписывает мне отпускные ?
Пускай каждый окажеться при своем, вам кажеться что в скрам нормально иметь менеджера, мне нет. Взрослые люди должны остаться при своем мнение.
nodonutsforyou
21.06.2018 15:56что делать тем людям у которх на визитки ПО нет слова менеджер
Так я говорю, что это вообще не важно. Скрам это про взаимодействия и итеративное улучшение. А не про роли, отпускные и слова в визитке.time2rfc
21.06.2018 17:39Снова с вами не соглашусь. Про взаимодействие это agile.
Agile это идеология или mindset которая говорит о важности взаимодействия и итерактивности.
Scrum очень конкретный фреймворк, с определенным списком ролей и мероприятий, артефактов и правил.
Не поучатильства ради а достоверности информации в интернете для.
nodonutsforyou
21.06.2018 18:10Так ведь Scrum это фреймворк для применения Agile.
Если делать Scrum без Agile mindset'a то скрама не получиться по определению. Пиратский кодекс-это всего лишь свод указаний, а не правил.
Тут же вопрос в том, что люди берут внешние части скрама теряя суть.
SkylineIT
19.06.2018 16:24Хорошо, когда у нас есть пул задач и мы под них выбираем методологию разработки… Но в текущей компании (название умолчу) происходит всё наоборот — под методологию загоняется спринт и происходит чёрти что.
Ну и не хватает в этом тексте то, что Scrum master обязан контролировать эти миттинги, потому что всяко без лидера — все в команде начинают разглагольствовать и эти встречи затягиваются от 40 минут до 1 часу.time2rfc
19.06.2018 16:52а сколько у вас человек в команде ?
SkylineIT
19.06.2018 17:0215 человек. Мастер у нас мёртвый, просто потому что опыта не было. Иной раз рявкать приходится, потому что невозможно это. Как по мне, ежедневные Stand Up'ы, Ретро — это пустая трата времени, если команда не умеет взаимодействовать друг с другом. За рабочую неделю — мы рабочий день, извините за выражение, пустословим (п**дим) ни о чём. Я бы лучше это время потратил на разработку или ещё какое-либо полезное занятие, но нет, ты обязан слушать о том, как дизайнер или контентмейкер мусолит свою задачу, посещать собрания на которых мы очередной раз профукали спринт, потому что кто-то чё-то тормозит и вообще команда ужасная и плохая.
Не спорю, Scrum идеально вписывается под сплоченную команду, которая готова включатся и бросаться на любую проблему. Но когда у тебя коллектив забитых интровертов, которые хотят реализовывать только тот объем задач, который на них висит, да ещё сверху добитых бюрократией — по такой схеме невозможно работать. Да, и как описал выше, нужно выбирать методологию под задачи, а не подгонять задачи под методологию. Со стороны это жесть как весело смотрится, а работать в этом безобразие — вообще одно удовольствие.time2rfc
19.06.2018 17:10Все что Вы описали — это проблемы конкретной конторы.
Неясно только зачем вы продолжаете там работать.SkylineIT
19.06.2018 17:12В пассивном поиске, мой друг, в поиске)
Поэтому, в последнее время больше склоняюсь к методологии waterfall. Так спокойно работается и каждый понимает свою зону ответственности. Лиды на своих местах, разрабы и другие на своих.
SkylineIT
19.06.2018 17:11А еще классно, когда Master не может надовить на product owner'a))) Пример. Я, как разработчик вижу, что эту задачу могу сделать за 8 часов, но product owner считает, что тут можно и за 2 часа всё сделать, поэтому ставит своё время. Я смело могу с наглой рожей сказать, чтобы он сам задачу делал за 2 часа. А master стоит и хлопает глазами, потому что не понимает как работают процессы. Это его команда и он должен ей рулить, он должен диктовать правила, а не owner. Конечно, не стоит идти в штыки с owner'ом, а уметь взаимодействовать с ним. Поэтому, такой вот у нас бардак.
reinvent
19.06.2018 21:39Если стендап превращается в никому не нужную рутину, вероятно, командная работа отсутствует. Обычно члены команды заинтересованы знать, кто что делает и какие сложности. Возможно, команда не была запущена.
sotnikdv
20.06.2018 09:09Отзыв будет несколько резковатым, но это реакция больше на всю индустрию, статья — только отражение ситуации.
> Во время спринта определяется набор фич и требований из бэклога для новой итерации.
Простите, а в чем разница между спринтом и итерацией?
Почему два понятия?
Это вы так груминг и планирование изволили смешать вместе?!
> На практике — Scrum meeting может быстро превратиться из эффективной короткой встречи в никому не понятную рутину
Это потому непонятную, что большинство менеджеров занимаются «наукой самолетопоклонников», т.е. делают ритуалы, суть которых они не понимают и не в состоянии обьяснить. Например, а зачем вообще нужны ежедневные стендапы? Какой от них толк? Люди, в отличие от менеджеров (sic!), не любят делать бессмысленные действия. Поэтому, если они не понимают зачем это нужно, они делают это формально.
У меня никогда не было подобной проблемы, т.к. суть стендапа обьяснялась сразу и для всех. Что мы делаем, что мы с этого имеем.
> Отвечая на эти простые вопросы, команда быстро может выявить проблемы, которые требуют особого внимания и оптимизации.
Общие слова, которые никоим образом не раскрывают суть и даже близко к сути не стояли.
Менеджер это понимает (хотя часть, как собака, все знают, но выразить не могут), люди это понимают. Но книжка требует говорить вот так, следуем ритуалу. «Потому что здесь так заведено»
> В некоторых креативных командах стало модным проводить короткие собрания в планке или выполняя другие полезные физические упражнения.
Т.е. креативный менеджер не только не понимает сути, но и не выполняет свою работу модератора? Прелестно.
Тупо режем по физическим способностям? Дабл-килл!
Вместо обсуждения занимаемся приседаниями! Трипл-килл!
Но вообще логично, да, одну бессмысленную активность заменяем другой.
> Лучшее решение для Scrum-собрания — это 8-10 человек, заинтересованных в обсуждении.
Нет, вот Вы серьезно? Если у меня команда на 12 человек, то нужно пригласить 8, кому интересно? Вы точно понимаете суть стендапа?
<---------------------------------------------------------------------------------------->
Окей, начнем сначала, стендап, это процесс короткого обсуждения командой прогресса, работы и блокеров.
Стендап позволяет:
1. члену команды рассказать другим о том, над чем он работает и дать статус;
2. команде понять, кто чем занимается и какие знания и опыт у кого; это поможет понять, кто в нужной тебе теме, если нужна помощь;
3. члену команды поднять технический блокер и либо сразу получить ответ либо быстро найти того, кто сможет помочь и уже работать с ним после стендапа (сильно помогает №1 и №2);
4. озвучить блокер, который требует внимания scrum master или product owner
5. всей команде понять, на треке ли они или нужно менять приоритеты и т.д. (у менеджера есть burndown, но он дает понимание наличия, а не сути проблемы)
6. менеджеру понять статус и иметь возможность разруливать проблемы по конкретным блокерам, а не пялиться в burndown и ныть, типа вы не успеваете.
7. членам команды понять, где они пересекаются в активностях и скоординировать действия (что планируешь)
Scrum master должен сводить разговор к простым вещам:
— что сделал
— что будешь делать
— блокеры
Самое важное, вдалбливать и каждый раз говорить одну фразу, «ты не мне рассказывай, ты команде рассказывай, это им нужно. А вы слушайте, т.к. может завтра это уже ВАМ будет нужно или ВЫ можете помочь сейчас».
Задача scrum master-а модерировать обсуждения и самое главное его оружие это две фразы:
1. это обсуждение за стендап
2. так, кто может помочь? окей, ты, ты и топикстартер, плз, пообщайтесь после стендапа.
Стендап заканчивается двумя фразами:
1. Мы закончили стендап, кому не интересно обсуждение поднятых вопросов, спасибо, можете переключаться на свою работу.
2. Господа, мы начинаем краткое обсуждение поднятый вопросов. <И дальше по списку>
При таком простом подходе, стендапы становятся короткими, эффективными и люди на них ОЧЕНЬ внимательны, т.к. теперь это живой синк, на котором мы быстро рассказываем где мы и подымаем\решаем проблемы.
И они очень хорошо понимают, нафига говорить о том, что ты делал и сделал. Что-бы остальные понимали, что и где ты меняешь, что ты знаешь, с чем работал. Что-бы быстро найти помощь. Что бы менеджер, который DM, по определению, в отличие от DoE, рулит не по чартам, а изнутри, мог бы помогать решать поднятые проблемы немедленно.
P.S. Поначалу приходится людей возвращать к формату, но не глупым «ты должен говорить так», а «Смотри, всем нужно понять, что ты знаешь, что ты менял, где ты можешь помочь или тебе и может скоординироваться по будущим действиям. Поэтому расскажи, что делал, что планируешь и блокеры.»
P.P.S. Куда все ушло? Десятки лет развития менеджерских практик, оттачивания методологий. Куда все эти люди ушли? Пришли какие-то креативные…, которые предлагают держать гирю, иначе типа стендап не такой, как в книжке.time2rfc
20.06.2018 15:10не хочу выглядеть бестактным, но почему Вы используете словов менеджер говоря про scrum ?
sotnikdv
21.06.2018 00:16Вы АБСОЛЮТНО правы.
Я пытаюсь говорить на языке команд и менеджмента, которые, блин, не только не понимают, что такое self-organizing team, но и, как правило, scrum manifest не видела в глаза.
Поэтому у них все еще есть понятие development manager, там, где вроде как чистый scrum.
Да, нет менеджера, есть scrum master, задача которого больше процедурная. Но в реальности возникают жуткие гибриды, в которых сова натягивается на глобус и есть DM, который заодно и играет роль scrum master.
В особо прекрасных случаях он еще и микроменеджит
askad
20.06.2018 15:45когда 15 человек в команде не знают, что делает каждый из них, это не команда, а соплежуи-индивидуалы. Тут Scrum не поможет.
sotnikdv
21.06.2018 00:18Вообще-то стендап, в нормальной команде, именно эту проблему и решает, в том числе.
Решал. Пока не пришли креативные менеджеры, без понимания, зачем эти процессы, зато с гирей
terrier
Классная идея — через 30 секунд пузатенький менеджер упал с планки, все собрание закончено, возвращаемся к работе.