Недавно ко мне обратился знакомый ScrumMaster и участник моих тренингов с просьбой посоветовать что-то в его ситуации. Тема любопытная и неоднозначная, поэтому мы с ним решили вынести ситуацию как кейс на обсуждение, и оба будем признательны читателям за ваши комментарии, которые вы оставите к этой статье.
Кейс о “поломанном” Daily Scrum
Кажется, что я или поломал нам Daily Scrum или, наоборот выявил проблему. В некоторый момент времени мне показалось, что daily scrum не имеет достаточной ценности для команды и к тому же проходит слишком долго (порой до 40 минут на 7 человек) и, после нашей встречи, я предложил еще меньше углубляться в подробности и просто отмечать сделано/не сделано. Но команда сказала – нет, нам это не нравится, зачем он тогда вообще нужен, если без подробностей. Тогда я сказал – ОК, давайте делать “два круга”. Первый по классическому daily scrum – три вопроса плюс очень небольшие комментарий. Второй круг – все, кто хотел что-то рассказать рассказывают или интересуются у коллег подробностями.
DailyScrum по такой схеме прошел ОЧЕНЬ быстро (как раз 15 минут плюс-минус), но оказалось, что никто больше ничего не хочет добавить. С одной стороны – WIN! Время уменьшилось, но с другой стороны кажется, будто команде не очень интересны вопросы друг друга.
Выдвину рискованное предположение, что каждый, в принципе может (и с интересом) рассказывать о своей задаче, но не всегда человеку интересно то, что происходит вокруг. Т.е. получается, что как только мы убрали необходимость делиться техническими подробностями (а оно сначала воспринималось у нас именно так), то коммуникация ухудшилась.
Теперь я думаю, что лучше сделать:
- Оставить все как есть сейчас (только отчет по трем вопросам) и не париться, что должно уменьшить ценность daily scrum в глазах команды;
- Вернуть обратно получасовые daily scrum, исходя из логики, что раз команда такой выработала, то это и есть оптимальный вариант;
- Постараться ввести на второй круг (который, по сути, лежит за рамками обычного формата) примерно такое правило: “Задай как минимум один вопрос коллеге, из того, чем он занимается и что тебе было бы максимально интересно услышать”;
- Попробовать как-то повернуть ситуацию из “я расскажу, а там, кто слушал, кто нет, не важно” в ситуацию “расскажу то, о чем спрашивают”.
Несколько слов об общей ситуации. Одна команда разработчиков в рамках большого бизнес-холдинга разрабатывает и поддерживает несколько систем одновременно. Исторически сложилось, что есть “эксперты” в той или иной системе, хотя когда бизнес выставляет требования им все равно, кто из команды будет его делать.
После внедрения Scrum подхода, уже проявились позитивные моменты: упорядочилась работа, команда смогла лучше планировать свои работы и выравнивать обещания бизнесу с реальностью. Тем не менее, “трансформация” еще идет и у Скрам Мастера возникает ряд вопросов.
Уверен, кто-нибудь из читателей сталкивался с похожей ситуаций или хотя бы может поделиться мыслями о том, что еще попробовать. Оставляйте свои комментарии внизу статьи.
P.S.
Если комментариев будет много, то мы их потом опубликуем отдельной статьей для всеобщего использования 🙂
У нас в 908 иногда возникает желание обсудить всё на стэндапе и это не очень хорошо. Как правило обсуждение выходит за рамки формата, поэтому в таких ситуациях SM берет на себя инициативу и выносит это обсуждение за пределы стэндапа – “Обсудим после” У нас такой подход работает, всё что нужно обсудить – обсуждается сразу же после митинга и в более комфортной обстановке, как минимум сидя 🙂
Рискну предположить, что долгая дискуссия пораждается недостаточной коммуникацией во время планирования спринта (сколько вы тратите времини на планинг сессию?), тем самым команда восполняет те пробелы в виденьи технической реализации, которые можно было заполнить чуть ранее.
Кроме этого, возникающие вопросы на стендапе фиксируются на вайтборде, и сразу после окончания стендапа команда может разбиться по комитетам и обсудить все, что необходимо – агенда ведь уже готова и записана на доску.
А может быть члены команды просто любят свою работу и любят о ней рассказывать друг другу 🙂
То есть команде в первую очередь интересно не то, ЧТО делается, а то КАК? Иначе откуда такая тяга в углублении в технические вопросы (что само по себе может и неплохо). Другими словами вопросы у команды появляются (и как следствие активное обсуждение), только когда она слышит подробности тех.реализациии. Тогда может проблема в кол-ве одновременно решаемых одним человеком задач или в их сложности? Уменьшение размера или кол-ва задач поможет уменьшить время затрачиваемое одним членом команды на описание того что сделал и планирует.
У нас применяется похожий формат: как только обсуждение на стендапе выходит за рамки “что сделал, что сделаешь, какие проблемы” я как скрам мастер прерываю выступающего фразой “хотите поговорить об этом?”
Ключевой момент здесь – не забыть кто и о чем хотел поговорить. Мы записываем на доске кто, с кем и о чем хотел поговорить. Получается списочек вопросов или проблем.
Следующий ключевой момент – проследить чтобы эти пункты действительно обсудили. В течение дня я спрашиваю указанных людей – этот вопрос решили? Если нет – решайте.
Таким образом, скрам укладывается в отведенные 15 мин. и в решении дополнительных проблем участвуют только те, кому это актуально. В случае команды из 7 человек обычно вопросы актуальны не всем.
По кейсу: я бы оставила как есть, плюс возможно попробовала бы записывать вопросы если они все-таки возникают.
А еще стоит подумать: зачем вам эти обсуждения (по 40 минут). Что они вам давали? Чего вы лишились войдя в сжатый формат? Это может быть темой для обсуждения на ретроспективе. Воспользуйтесь техникой “5 Почему”, возможно проблема вовсе не во времени стендапа.
Тим, твоя ситуация свидетельсвует о двух вещах :
1. команде явно не хватает неформальноего общения
2. Планнинг митинги проводятся некачественно и твой второй скрам митинг – попытка это компенсировать
Согласен с Eugen Veselov: похоже команда не наговаривается или не чувствует, что их работа appreciated со стороны тимлида менеджера заказчика. Ещё похоже, что процессом владеет не команда, а скраммастер (почему?)
У меня два вопроса ))
Первый – а почему это проблема?
И второй – чья собственно это проблема? ))
Я бы постарался (с помощью спец инструментов) сделать это проблемой команды и дать им полную свободу решить и воплотить свою собственную процедуру дейли скрама.
1. Проблема – отсутствие /недостаток неформального общения , говорят и я им верю, препятсвует командообразованию
2.Это проблема проекта, на котором ребята работают. а значит – проблема компании в целом -)
Продолжим ))
1. А почему препятствия к командообразованию – это проблема? Какие-то нежелателные явления уже заметны? И это ли проблема на самом деле ))
2. Я тут имел в виду другое. Кто “владеет” проблемой, тот её и решает. Похоже тут этой проблемой “владеет” скраммастер. А хотелось бы, чтобы команда.
Иначе может случиться, что поломаный дейли скрам – проблема только для скраммастера, и он её сам и решает (за счет команды, проекта и т.п.).
Обычно это следствие более глубокой проблемы – сведения Scrum к небольшому числу ритуалов (Планирование-Стэндап-Демо-Ретро). На самом деле самое важное поле для взаимодействий – сотрудничество и обмен информацией в явном и неявном(“tacit” по Nonaka и Konno) виде на уровне эпизода разработки, в то время как Стэндап это просто safety net. Соответственно решать нужно корневую проблему, а не ее симптом – “как лучше проводить Скрам митинги”.
Мы часто забываем, что Регби как метафора, был избран далеко не из-за “Скрама” как формы розыграша мяча, а потому, что в хорошей Регби команде до того, как мяч пересечет противоположную линию поля, он пройдет чрез целую серию пасов и передач. Точно так же в Скрам (вспомним еще древнюю-древнюю статью в Гарвард Бизнес Ривью “New New Product Development Game”) суть в том, чтобы члены команды интенсивно сотрудничали на уровне имплементации пользовательской истории, а не каждый член команды брал по истории, теряя эффективность без должного низкоуровневого сотрудничества.
Для Скрам мастера именно эта область всегда наиболее сложна для фасилитации и коучинга, но пересекая эту черту команды становятся действительно “Гибкими”.
сложно ставить диагноз по фотографии, но
ухудшилось ли хоть что-то, когда детали перестали озвучиваться? (если они просто проговаривались, но их никто не слушал, то это проблема не девелопмент процесса, а личного общения, все хотят, чтоб их слушали)
а вообще – информации много не бывает, когда я теряю какой-то поток инфы, который мне прям щас не нужен, меня колбасит. но ничего – живу. я про то, что возможно всё ок.
В моем случае начали проводить Daily Scrum и скатились до 30-40 минут. А толку все-равно не много!
Принесла на митинг 15-минутные песочные часы. Напомнила, что главное
это ответить на 3 вопроса. Ситуация приблизилась к описаной в статье.
На Ретроспективе подняли вопрос о неэфективности DS. Команда сама решила что и как нужно делать, а SM только создал условия).
Думали-думали и пришли к простой истине: 1. 15 минут на DS (следим по часам), 2. Обсуждаем по кругу “кто и что сделал”, и сразу оговариваем red flags. Результат – вся команда знает проблемные места 3. Говорим о том, что будем делать 4. После митинга остаются те кому НУЖНО обсудить детальнее red flags, остальные “по матрешкам”
мне кажется, что лучше оставить как стало – дейли на то и дейли, чтоб все синхронизировались, озвучили блоки, получили информацию о том, кто какой блок может/должен снять и пошли работать зная, кто на ком завязан и первоочередность задач.
раньше не хотели таких перемен, возможно, от непривычки – не понимали нужности просто синхронизации. сейчас какраз, может, привыкнут.
не знаю, что значит “что должно уменьшить ценность daily scrum в глазах команды” – команда не будет посещать дейли? не будет озвучивать на нем всю актуальную информацию? если нет – имхо оставляйте все как есть. если да – в команде есть проблемы, ибо что это за детский сад?
для утряски технических моментов нужны локальные митинги, на ретроспективе нужно вытягивать максимум недовольства кодом/принятыми решениями с каждого участника команды, чтоб обозначить места, в которые надо вводить общее проговаривание перед реализацией важных решений. и чтоб выявлять проблемы коммуникации в команде.
если все-таки надо на втором кругу вытянуть прежние разговоры – СМ может попробовать на первом круге, после каждой отчитки чаловека, спросить команду – у кого какие есть вопросы, запомнить кто кого про что хотел спросить, и второй круг начинать вести с этих вопросов.
У меня какое-то дежавю после прочтения комментариев) Где-то уже это было…
думаю, для того чтобы давать советы, у нас недостаточно входящих данных. Любая команда – уникальна, ведь в ней работают ЛИЧНОСТИ! единственное, что сразу бросается в глаза – им мало общения, отсюда вопросы: – сидит ли команда в одной комнате (физически)? – что обсуждается на ретроспективе? – как долго они работают вместе? (все симптомы “юной” команды на лицо)
Да, Лина. Я потому и обратился за “помощью зала”, что слышал идеи от разных людей.
Команда не молодая по опыту в системе, хотя, как я писал внизу кейса – работают в командном стиле (по Scrum) относительно недавно. Быстро учатся 🙂
У нас была подобная ситуация. Через полгодика из 40 мин само собой устаканилось в 15 мин. Ибо всем надоело бесполезно втыкать по полчаса на день. Предлагаю для начала каждого ограничить по времени (по 2 мин на брата), и все, привычка быть кратким войдет в норму.
Создается ощущение, что члены команды сидят в разных помещениях и не сотрудничают, а видятся только на DS.
Насколько часто команда собирается вне снад-апа?
Насколько вндрен peer-programming? Если нет, то его внедрение сократит количество вопросов как минимум в два раза.
Насколько люди “сработавшиеся” и желающие работать вместе?
Насколько доверяющие друг другу?
ИМХО, вопросы обусловлены либо недоверием либо недостаком общения и collaboration вне DS.
СУВЖ,
Aquarius.
Не увидел какая это комманда распределенная или нет. И соответсвенно как проходит митинг по скайпу или стендап?
Если дейли скрам не приносит ничего, кроме следования скрам-методолигии – УБЕРИТЕ ЕГО. Это waste.
Может вся комманда сидит в одной комнате, постоянно общается и знает статусы и так. Так зачем тогда их мучать каким то формальными скрам-процедурами?
Согласен с Artem Serdyuk – не вижу толком проблемы – продуктивность и качество при длинных митингах ухудшается или улудшается? А при коротких? А если их убрать вообще? И действительно дайте комманде решить, что им нужно для максимально продуктивной работы. То что пишется в книгах – это хорошо, но применять не надо все слепо как написано в крутой книге, применять надо то, что работает. Определить это можно только одним способом – проверить, померять, сравнить.
Если коммуникация ухудшилась, то никакой это не WIN, даже если выглядит похоже на то, как описано в книгах 🙂
Вообще, я придерживаюсь точки зрения, что если у Scrum Master’а о чём-то слишком сильно болит голова, скорее всего это не его проблема. Посоветуйте знакомому обсудить ситуацию с командой. Пусть он как Скрам-Мастер объяснит что именно и почему именно, ему казалось странным, пусть обсудят было ли это на самом деле проблемой и решилась ли она сейчас.
В конце-концов ваш знакомый сокращал скрам не потому что так написано в книге [я надеюсь], а потому что видел в этом опасность, скажем, того, что из-за слишком длинных обсуждений одних другие будут забывать о своих вопросах.
Программисты обычно весьма толковые люди. Если рассказать им о том, что именно и *почему именно* напрягает, часто команда может придумать гораздо лучшее именно для неё решение, чем Скрам-Мастер.