Отправляет email-рассылки с помощью сервиса Sendsay

100 ошибок применения Scrum

Рассылка закрыта

При закрытии подписчики были переданы в рассылку "Советы миллионеров - как стать богатым и знаменитым!?" на которую и рекомендуем вам подписаться.

Вы можете найти рассылки сходной тематики в Каталоге рассылок.

  Апрель 2011   →
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
Автор
Денис

Статистика

35 подписчиков
0 за неделю
←   Все выпуски   →

100 ошибок применения Scrum Ошибки daily scrum meeting


 Здравствуйте!

Ошибки, описанные в статье и в первом выпуске рассылки, по большей части связаны с ролью Scrum-мастера в целом. Сегодня же мы поговорим об ошибках, непосредственно связанных  с Daily scrum meeting:

  • Отсутствие daily scrum как таковых
  • Формальные daily scrum
  • Привычка давать «втык» за лень или просрочку
  • Превращение daily scrum в многочасовое заседание

Начнём! 

Самая большая ошибка, связанная с daily scrum meeting'ами – это полное их отсутствие или упразднение.

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

Как я уже писал в статье «Scrum-мастер: Сталин или Ганди?», чтобы правильно применять ту или иную практику методологии, нужно хорошо понимать ее назначение.

Daily scrum meeting – "этот митинг проходит каждое утро в начале дня. Он предназначен для того, чтобы все члены команды знали, кто и чем занимается в проекте. Длительность этого митинга строго ограничена и не должна превышать 15 минут. Цель митинга – поделиться информацией. Он не предназначен для решения проблем в проекте. Все требующие специального обсуждения вопросы должны быть вынесены за пределы митинга."

[http://agileguru.ru/AgileWiki/Daily_Scrum_Meeting]

Исходя из определения и из собственной практики мы убедились, что scrum meeting...

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

Обманчивое спокойствие

Scrum-мастер часто может легко попасться в ловушку: работы идут, все сидят в поте лица трудятся – daily scrum только отвлечёт от работы. Но если вдруг, он решит провести meeting, то выяснится, что кто-то застрял  на одной проблеме и уже 3 дня думает что «вот-вот» её решит, кто-то увлекся разработкой фреймворка, который «поможет в будущих спринтах тратить меньше времени на подобные задачи», но так и не продвинулся в решении текущих задач и многие другие  проблемы. Интересно, что многие проблемы, ставящие в тупик каждого конкретного разработчика, вместе могут быть решены в считанные минуты. В этом плане парное программирование может отчасти заменить daily scrum, но только отчасти.

* * *

Когда же можно обойтись без ежедневного scrum? Я думаю, должны выполняться всего два условия:

  • В команде хорошо налажены коммуникации именно в контексте проекта, а не в контексте того, как вчера сыграл Манчестер Юнайтед с Арсеналом :)
  • Команда стабильно из спринта в спринт укладывается в планы

Теоретически такое возможно и в распределённой команде, но есть ряд уточнений:

  • либо каждый член команды должен быть очень ответственным и результат-ориентированным сотрудником
  • либо все члены команды должны быть давними близкими друзьями
  • либо все члены команды должны проводить длительные деловые или не деловые встречи, что хотя бы раз 1 или 2 недели
* Возможно, есть другие условия, но я пока не сталкивался. Буду рад если поделитесь :)

Формализм

Все мы знаем, что на daily scrum каждый член команды должен ответить на 3 вопроса:

  • Что сделано вчера?
  • Что будет сделано сегодня?
  • С какими затруднениями столкнулся, что помешало продуктивной работе?

Редкий случай, когда что-то в методологии Scrum настолько формализовано. Если члены команды не сильные приверженцы scrum, либо они не до конца понимают целей ежедневных встреч, то нередко scrum-meeting превращается в формальное мероприятие:

  • Каждый отвечает на 3 этих вопроса
  • Про затруднение говорят все неохотно всегда с добавкой: «но это я сегодня точно решу»
  • Не слушают, что говорят другие. Хорошо, если scrum-мастер слушает :)

Толк от таких meeting’ов, конечно, кое-какой есть, это уже лучше, чем полное их отсутствие, но не намного.

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

Есть более быстрый метод – модерировать daily scrum:

  • Спрашивать других членов команды, знают ли они, как решить проблему, возникшую у данного сотрудника.
  • Назначать после daily scrum обсуждение данной проблемы, теми, кто может помочь в ее решении (это может быть не всегда вся команда).
  • Предлагать опережающим график сотрудникам помочь отстающим
  • И т.д. 

«Волшебные» пендюли

По моему опыту, самое страшное, что можно сделать с daily scrum – это превратить его в разбор полётов и раздачу люлей. Это достаточно привычная практика для многих менеджеров, и нередко scrum-мастера даже не осознанно начинают себя вести также на daily scrum:

Кто-то что-то не успевает, ему достаются укоры, строгие вопросы и ультимативные условия. Да, часто это мотивирует сотрудника работать лучше и продуктивнее, но это демотивирует его к участию в scrum meeting’ах. Он перестает говорить правду о реальном статусе, на всякий случай завышает свои оценки задач, замалчивает о проблемах и т.д.

Scrum – это доверительная командная обстановка, если у кого-то что-то не получается, ему помогают, а не ругают его. В идеальном скраме, даже обычную лень  сотрудника стараются «вылечить» мягким способом, чтобы человек сам осознал, что от него зависит успех команды в целом, на него надеются его товарищи. Ясно, что не у каждой команды и не у каждого менеджера это получится. Если сотрудник «не лечится», значит, он ещё не дорос до scrum, дешевле его вывести из команды, чем делать инвалидный scrum, ибо профита применение методологии это не даст. Это ещё один повод задуматься перед началом проекта, а имеет ли смысл применять scrum в этом проекте и в этой команде.

Углубление в детали

Пожалуй, самая часто упоминаемая бага scrum-митингов – это обсуждение возникших проблем прямо на daily scrum. Тем не менее, не смотря на то, что все про неё знают, многие ее постоянно допускаю. Такова уж наша программистская природа – хочется постоянно решать интересные новые задачки и проблемы, особенно если они возникают у другого :).

Здесь я, наверное, нового ничего не посоветую: проводите встречи стоя и не дольше 15 минут.

Здесь главное scrum-мастеру не самому не поддаваться этому соблазну. Чтобы одёргивать себя и членов команды можно завести большой секундомер, отсчитывающий время до конца, еще можно чтобы он пищал каждую минуту. Возможно это будет раздражать, но через 1-2 недели можно отказаться от него, члены команды будут сами помнить и одёргивать других, если они начали забираться в дебри.

Заключение

На сегодня всё. Постарался не утомлять сильно вас :).

Пока писал, пришла мысль о следующем выпуске, написать про то когда  и на каких проектах имеет смысл внедрять Scrum. Наверное, стоило это сделать первым выпуском… но что делать? Будем восполнять пробелы.

Удачи!

Денис Тучин
info@dream-project.ru 
http://dream-project.ru
В избранное