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

 

Кейс о «поломанном» Daily Scrum

Кажется, что я или поломал нам Daily Scrum или, наоборот выявил проблему. В некоторый момент времени мне показалось, что daily scrum не имеет достаточной ценности для команды и к тому же проходит слишком долго (порой до 40 минут на 7 человек) и, после нашей встречи, я предложил еще меньше углубляться в подробности и просто отмечать сделано/не сделано. Но команда сказала — нет, нам это не нравится, зачем он тогда вообще нужен, если без подробностей. Тогда я сказал — ОК, давайте делать «два круга». Первый по классическому daily scrum — три вопроса плюс очень небольшие комментарий. Второй круг — все, кто хотел что-то рассказать рассказывают или интересуются у коллег подробностями.

DailyScrum по такой схеме прошел ОЧЕНЬ быстро (как раз 15 минут плюс-минус), но оказалось, что никто больше ничего не хочет добавить. С одной стороны — WIN! Время уменьшилось, но с другой стороны кажется, будто команде не очень интересны вопросы друг друга.

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

Теперь я думаю, что лучше сделать:

  • Оставить все как есть сейчас (только отчет по трем вопросам) и не париться, что должно уменьшить ценность daily scrum в глазах команды;
  • Вернуть обратно получасовые daily scrum, исходя из логики, что раз команда такой выработала, то это и есть оптимальный вариант;
  • Постараться ввести на второй круг (который, по сути, лежит за рамками обычного формата) примерно такое правило: «Задай как минимум один вопрос коллеге, из того, чем он занимается и что тебе было бы максимально интересно услышать»;
  • Попробовать как-то повернуть ситуацию из «я расскажу, а там, кто слушал, кто нет, не важно» в ситуацию «расскажу то, о чем спрашивают».

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

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

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

P.S.

Если комментариев будет много, то мы их потом опубликуем отдельной статьей для всеобщего использования 🙂

Кейс о "поломанном" Daily Scrum
Tagged on:                 
  • У нас в 908 иногда возникает желание обсудить всё на стэндапе и это не очень хорошо. Как правило обсуждение выходит за рамки формата, поэтому в таких ситуациях SM берет на себя инициативу и выносит это обсуждение за пределы стэндапа — «Обсудим после» У нас такой подход работает, всё что нужно обсудить — обсуждается сразу же после митинга и в более комфортной обстановке, как минимум сидя 🙂

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

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

    А может быть члены команды просто любят свою работу и любят о ней рассказывать друг другу 🙂

  • То есть команде в первую очередь интересно не то, ЧТО делается, а то КАК? Иначе откуда такая тяга в углублении в технические вопросы (что само по себе может и неплохо). Другими словами вопросы у команды появляются (и как следствие активное обсуждение), только когда она слышит подробности тех.реализациии. Тогда может проблема в кол-ве одновременно решаемых одним человеком задач или в их сложности? Уменьшение размера или кол-ва задач поможет уменьшить время затрачиваемое одним членом команды на описание того что сделал и планирует.

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

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

    Следующий ключевой момент — проследить чтобы эти пункты действительно обсудили. В течение дня я спрашиваю указанных людей — этот вопрос решили? Если нет — решайте.

    Таким образом, скрам укладывается в отведенные 15 мин. и в решении дополнительных проблем участвуют только те, кому это актуально. В случае команды из 7 человек обычно вопросы актуальны не всем.

    По кейсу: я бы оставила как есть, плюс возможно попробовала бы записывать вопросы если они все-таки возникают. 

    А еще стоит подумать: зачем вам эти обсуждения (по 40 минут). Что они вам давали? Чего вы лишились войдя в сжатый формат? Это может быть темой для обсуждения на ретроспективе. Воспользуйтесь техникой «5 Почему», возможно проблема вовсе не во времени стендапа.

  • Тим, твоя ситуация свидетельсвует о двух вещах : 
    1. команде явно не хватает неформальноего общения
    2. Планнинг митинги проводятся некачественно и твой второй скрам митинг — попытка это компенсировать

  • Artem Serdyuk

    Согласен с Eugen Veselov: похоже команда не наговаривается или не чувствует, что их работа appreciated со стороны тимлида менеджера заказчика. Ещё похоже, что процессом владеет не команда, а скраммастер (почему?)

    У меня два вопроса ))
    Первый — а почему это проблема?
    И второй — чья собственно это проблема? ))

    Я бы постарался (с помощью спец инструментов) сделать это проблемой команды и дать им полную свободу решить и воплотить свою собственную процедуру дейли скрама.

    • 1. Проблема — отсутствие /недостаток неформального общения , говорят и я им верю, препятсвует командообразованию
      2.Это проблема проекта, на котором ребята работают. а значит — проблема компании в целом -)

      • Artem Serdyuk

        Продолжим ))

        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, остальные «по матрешкам»

  • Svitovyda

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

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

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

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

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

  • У меня какое-то дежавю после прочтения комментариев) Где-то уже это было…
    думаю, для того чтобы давать советы, у нас недостаточно входящих данных. Любая команда — уникальна, ведь в ней работают ЛИЧНОСТИ! единственное, что сразу бросается в глаза — им мало общения, отсюда вопросы: — сидит ли команда в одной комнате (физически)? — что обсуждается на ретроспективе? — как долго они работают вместе? (все симптомы «юной» команды на лицо)   

    • Да, Лина. Я потому и обратился за «помощью зала», что слышал идеи от разных людей.

      Команда не молодая по опыту в системе, хотя, как я писал внизу кейса — работают в командном стиле (по Scrum) относительно недавно. Быстро учатся 🙂

  • Kore Sar

    У нас была подобная ситуация. Через полгодика из 40 мин само собой устаканилось в 15 мин. Ибо всем надоело бесполезно втыкать по полчаса на день. Предлагаю для начала каждого ограничить по времени (по 2 мин на брата), и все, привычка быть кратким войдет в норму.

  • Aquarius

    Создается ощущение, что члены команды сидят в разных помещениях и не сотрудничают, а видятся только на DS.

    Насколько часто команда собирается вне снад-апа?
    Насколько вндрен peer-programming? Если нет, то его внедрение сократит количество вопросов как минимум в два раза.
    Насколько люди «сработавшиеся» и желающие работать вместе?
    Насколько доверяющие друг другу?

    ИМХО, вопросы обусловлены либо недоверием либо недостаком общения и collaboration вне DS.

    СУВЖ,
    Aquarius.

  • Anton Maryukhnenko

    Не увидел какая это комманда распределенная или нет. И соответсвенно как проходит митинг по скайпу или стендап? 
    Если дейли скрам не приносит ничего, кроме следования скрам-методолигии — УБЕРИТЕ ЕГО. Это waste. 
    Может вся комманда сидит в одной комнате, постоянно общается и знает статусы и так. Так зачем тогда их мучать каким то формальными скрам-процедурами? 
    Согласен с Artem Serdyuk — не вижу толком проблемы — продуктивность и качество при длинных митингах ухудшается или улудшается? А при коротких? А если их убрать вообще? И действительно дайте комманде решить, что им нужно для максимально продуктивной работы. То что пишется в книгах — это хорошо, но применять не надо все слепо как написано в крутой книге, применять надо то, что работает. Определить это можно только одним способом — проверить, померять, сравнить.

  • Если коммуникация ухудшилась, то никакой это не WIN, даже если выглядит похоже на то, как описано в книгах 🙂

    Вообще, я придерживаюсь точки зрения, что если у Scrum Master’а о чём-то слишком сильно болит голова, скорее всего это не его проблема. Посоветуйте знакомому обсудить ситуацию с командой. Пусть он как Скрам-Мастер объяснит что именно и почему именно, ему казалось странным, пусть обсудят было ли это на самом деле проблемой и решилась ли она сейчас.
    В конце-концов ваш знакомый сокращал скрам не потому что так написано в книге [я надеюсь], а потому что видел в этом опасность, скажем, того, что из-за слишком длинных обсуждений одних другие будут забывать о своих вопросах.

    Программисты обычно весьма толковые люди. Если рассказать им о том, что именно и *почему именно* напрягает, часто команда может придумать гораздо лучшее именно для неё решение, чем Скрам-Мастер.

  • Pingback: Советы читателей на «Кейс о поломанном Daily Scrum» | The Improved Methods()