Scrum-мастер: Сталин или Ганди?
Сегодня будем пытаться найти идеал скрам-мастера для этапа внедрения методологии Scrum в команде или в компании.
Напомню, что одной из основных функций скрам-мастера является контроль соблюдения практик и процесса в команде.
При внедрении новых процессов (будь это Scrum, новый способ отчётности или что-то ещё) у того кто внедряет часто случается две крайности: педантичный диктатор и «податливый советчик».
Все адепты гибких методологий подчёркивают, что методологии на то и гибкие, что их нужно применять в соответствии с каждой конкретной ситуацией.
С другой стороны, «советчик», который идёт на поводу у команды, также опасен. Например, кто-то из членов команды говорит: «Да и так видно, что все заняты делом, коммиты идут, проблем ни у кого не возникает. Зачем daily scrum проводить?» А ты откуда знаешь, что проблем нет, может, люди просто не говорят о них в надежде решить сами? Да и коммиты далеко не являются показателем прогресса. Да даже если действительно сегодня всё хорошо, завтра тоже, а послезавтра и потом уже по привычке daily scrum не проводится. Тогда о проблемах мы узнаем только в конце спринта на ретроспективе, если, конечно, и от ретроспективы не откажется команда, что тоже очень часто бывает. Очевидно, что неудача проекта здесь практически предрешена, если конечно бюджет его заранее не раздули, как обычно делается в классических водопадах, хотя и то не факт.
Кто виноват? И что делать?
Где же золотая середина? Как её найти?
А надо ли вообще искать золотую середину? Все проекты/команды/компании разные и золотая середина отличается от описанных выше двух крайностей лишь тем, что статистически снижет вероятность ошибки, но в каждом конкретном случае может быть даже хуже одной из крайностей. Вместо золотой середины, найдём «серебряную пулю», как бы это ни амбициозно звучало :).
Источник обеих описанных крайностей в поведении скрам-мастера, как это ни странно, один и тот же - отсутствие досконального знания методологии. Вообще, вы должны знать, что внедрение какого-либо процесса, который внедряющий сам до конца не понимает заведомо опасно. Часто лучше пригласить стороннего консультанта для внедрения Scrum, чем поставить сотрудника, который только что прошёл 2-хдневный тренинг с сертификацией. Точнее вы можете поставить этого сотрудника, даже если он был не на тренинге, а прочитал про Scrum в Интернете, но только на УЧЕБНЫЙ ПРОЕКТ. Пусть набьёт на нём все шишки, получит практику и уж поверьте на реальном проекте он уже не будет скатывается в безоговорочную диктатуру или советничество.
«Серебряная пуля»
Для успешного выполнения своей роли в проекте скрам-мастеру нужно помнить всего две вещи:
Кстати, цели компании всегда важнее целей проекта, но это уже вопрос из другой плоскости знаний, о нём как-нибудь в другой раз.
Почему нужно следовать целям проекта - понятно. Перейдём к знаниям целей каждого артефакта. Если вы точно знаете, для каких целей предназначена каждая практика, каждая роль, каждая часть процесса, каждый артефакт в терминологии Scrum, то вы безошибочно можете определить, имеет ли смысл соблюдать в этом случае методологию, или вы можете, что-то изменить в соответствии целями проекта и особенностями команды.
Например, вы знаете, что состав команды вероятнее всего будет меняться в течение проекта, тогда ведите минимальную необходимую документацию, хотя бы в wiki, даже если вы практикуете парное программирование - бывает, что память «отшибает» у всей команды разом :).
Другой пример, когда важно помнить именно цель проекта. Если у вас учебный проект, то при распределении задач в команде на планировании спринта, следует напомнить команде, что задачу нужно давать не тому, кто знает, как её быстро сделать, а наоборот тому, кто мало знаком с данной технологией - ведь вы же учитесь в первую очередь.
Вместо заключения
Хм… Достаточно интересно и объёмно получилось. Если будет время, постараюсь более-менее регулярно выпускать рубрику Scrum с описанием каждого конкретного артефакта (роли, вехи, процесса и т.п.)
Напомню, что одной из основных функций скрам-мастера является контроль соблюдения практик и процесса в команде.
При внедрении новых процессов (будь это Scrum, новый способ отчётности или что-то ещё) у того кто внедряет часто случается две крайности: педантичный диктатор и «податливый советчик».
- Диктатор слепо педантично следует практикам и следит, чтобы не дай бог не смешивались разные роли, а процессы чётко соответствовали спецификации.
- «Советчик» обычно говорит участникам команды: «Вот по спецификации это нужно делать так… Не хотите? Ну ладно, делайте, как привыкли/как считаете нужным.»
Все адепты гибких методологий подчёркивают, что методологии на то и гибкие, что их нужно применять в соответствии с каждой конкретной ситуацией.
С другой стороны, «советчик», который идёт на поводу у команды, также опасен. Например, кто-то из членов команды говорит: «Да и так видно, что все заняты делом, коммиты идут, проблем ни у кого не возникает. Зачем daily scrum проводить?» А ты откуда знаешь, что проблем нет, может, люди просто не говорят о них в надежде решить сами? Да и коммиты далеко не являются показателем прогресса. Да даже если действительно сегодня всё хорошо, завтра тоже, а послезавтра и потом уже по привычке daily scrum не проводится. Тогда о проблемах мы узнаем только в конце спринта на ретроспективе, если, конечно, и от ретроспективы не откажется команда, что тоже очень часто бывает. Очевидно, что неудача проекта здесь практически предрешена, если конечно бюджет его заранее не раздули, как обычно делается в классических водопадах, хотя и то не факт.
Кто виноват? И что делать?
Где же золотая середина? Как её найти?
А надо ли вообще искать золотую середину? Все проекты/команды/компании разные и золотая середина отличается от описанных выше двух крайностей лишь тем, что статистически снижет вероятность ошибки, но в каждом конкретном случае может быть даже хуже одной из крайностей. Вместо золотой середины, найдём «серебряную пулю», как бы это ни амбициозно звучало :).
Источник обеих описанных крайностей в поведении скрам-мастера, как это ни странно, один и тот же - отсутствие досконального знания методологии. Вообще, вы должны знать, что внедрение какого-либо процесса, который внедряющий сам до конца не понимает заведомо опасно. Часто лучше пригласить стороннего консультанта для внедрения Scrum, чем поставить сотрудника, который только что прошёл 2-хдневный тренинг с сертификацией. Точнее вы можете поставить этого сотрудника, даже если он был не на тренинге, а прочитал про Scrum в Интернете, но только на УЧЕБНЫЙ ПРОЕКТ. Пусть набьёт на нём все шишки, получит практику и уж поверьте на реальном проекте он уже не будет скатывается в безоговорочную диктатуру или советничество.
«Серебряная пуля»
Для успешного выполнения своей роли в проекте скрам-мастеру нужно помнить всего две вещи:
- Цели проекта
- Цели каждого артефакта методологии
Кстати, цели компании всегда важнее целей проекта, но это уже вопрос из другой плоскости знаний, о нём как-нибудь в другой раз.
Почему нужно следовать целям проекта - понятно. Перейдём к знаниям целей каждого артефакта. Если вы точно знаете, для каких целей предназначена каждая практика, каждая роль, каждая часть процесса, каждый артефакт в терминологии Scrum, то вы безошибочно можете определить, имеет ли смысл соблюдать в этом случае методологию, или вы можете, что-то изменить в соответствии целями проекта и особенностями команды.
Например, вы знаете, что состав команды вероятнее всего будет меняться в течение проекта, тогда ведите минимальную необходимую документацию, хотя бы в wiki, даже если вы практикуете парное программирование - бывает, что память «отшибает» у всей команды разом :).
Другой пример, когда важно помнить именно цель проекта. Если у вас учебный проект, то при распределении задач в команде на планировании спринта, следует напомнить команде, что задачу нужно давать не тому, кто знает, как её быстро сделать, а наоборот тому, кто мало знаком с данной технологией - ведь вы же учитесь в первую очередь.
Вместо заключения
Хм… Достаточно интересно и объёмно получилось. Если будет время, постараюсь более-менее регулярно выпускать рубрику Scrum с описанием каждого конкретного артефакта (роли, вехи, процесса и т.п.)