Коллеги, всем привет!
В сегодняшней статье хотелось бы поговорить о нескольких наиболее «популярных» ошибках при переходе на Scrum, в результате которых у участников команд возникает разочарование в этом framework-е и они теряют веру в его эффективность. Эти ошибки давно входят в «золотой фонд» анти-паттернов scrum, но совершаются с завидной регулярностью, поэтому, думаю, имеет смысл рассмотреть их еще раз.
Способ номер 0. Внедрять scrum там, где он вообще не нужен.
На практике часто бывает так, что идея перехода на Scrum приходит «сверху» - кто-то в руководстве компании хочет повысить эффективность разработки, узнает про Agile и Scrum, после чего начинается agile-изация всего и вся. При этом зачастую качество agile-трансформации определяется просто количеством запущенных scrum команд.
Но стоит ли применять Scrum везде, где только можно?
Scrum – это framework для решения комплексных задач, где есть много неопределенности – мы строим гипотезы, проверяем результат, адаптируемся и идем к цели шаг за шагом, получая каждый раз обратную связь. Такой метод хорошо подходит для разработки нового продукта или проекта, где ожидания в начале пути могут сильно отличаться от итогового результата, который на самом деле будет нужен конечным пользователям.
Предположим, у вас нет как такового продукта, ценность которого вы постепенно увеличиваете, а есть просто некий поток разрозненных «хотелок» от совершенно несвязанных stakeholder-ов, и ваша задача –закрывать эти «хотелки» быстро и качественно.. Или предположим, что вы занимаетесь внедрением и развертыванием типового решения, и это внедрение всегда состоит из одинаковых шагов фиксированной длительности.
В принципе, при желании можно разбить такие «хотелки» и задачи на спринты, но вот получится ли у вас выделить product goal и sprint goal, которые не будут выглядеть искусственными или «высосанными из пальца»? И как определить роль Product owner-а в этом процессе? И насколько велика будет польза от самоорганизации команды при решении этих задач?
Если ответ на эти вопросы «нет», то следующий вопрос, который надо задать «а зачем вам Scrum»? И если вы не найдете другого ответа кроме как «нам сделали предложение, от которого нельзя отказаться», то стоит подумать, а нужен ли он вам все-таки? Зачем «насиловать» людей тем, что не принесет им и бизнесу пользу? Вполне возможно, вам будет достаточно просто оптимизировать управление потоком задач, и для этого достаточно будет настроить Kanban-процесс.
Способ номер 1. Внедрить scrum, не предоставив команде необходимые полномочия.
Предложим, вы взяли группу разработчиков, назначили им scrum-мастера и product owner-а, после чего торжественно объявили команде, что теперь они каждый день собираются у доски со стикерами, а еще раз в две недели должны «делать ретроспективу», планирование и product backlog refinement. Достаточно ли этого для того, что бы вы могли сказать, что запустили scrum-команду?
Прежде чем отвечать на этот вопрос, давайте посмотрим на него под другим углом.
Основа Scrum – это Scrum team:
Product owner – отвечает за повышение ценности продукта и имеет полномочия решать, какое из изменений будет нести наибольшую ценность.
Developers – отвечают за создание инкремента продукта, который соответствует принятым критериям качества, при этом имеют полномочия выбирать способ достижения цели спринта и совместно с PO формируют эту цель. Также в команде есть все навыки, необходимые для решения поставленных задач.
Scrum мастер – имеет полномочия организовать работу по scrum в соответствие с принципами Scrum guide.
Также Scrum team имеет право:
самостоятельно организовывать свою работу так, чтоб повышать эффективность и устранять препятствия в своей работе по итогам регулярных инспекций и адаптаций,
отвечать за последствия принятых решений и вносить корректировки, если принятые решения оказались неудачными.
Именно такое сочетание обязанностей и полномочий делает команду эффективной и помогает ей повышать ценность продукта и решать комплексные задачи.
Теперь рассмотрим следующую ситуацию:
Product owner – не может самостоятельно решать, что является полезным для продукта, и у команды большое количество задач от разных stakeholder-ов с «первым» приоритетом, которые надо сделать «вчера».
Developers – набор разработчиков, которые сами не имеют право ничего решать, делают не то, что приносит пользу, а то, что попросил начальник с самым «громким голосом» или самыми «большими погонами». При этом сделать это все надо было тоже еще «вчера», потому что так решил самый «большой» начальник.
Scrum-мастер – «секретарь», который назначает кучу разных встреч, на которых люди поговорят о том, что никогда не смогут сделать, и каждый участник встречи будет ждать, когда же она закончится, т.к. у него еще 5 задач, которые надо было сделать также еще «вчера».
Т.е. участники команды на самом деле не решают ничего, и просто делают то, что им сказали, пытаясь «осчастливить» тех, кто «спустил» идею перехода на Scrum.
Насколько эффективная эта команда?
Можно ли считать, что она действительно работает по Scrum?
Ответ на первый вопрос «хз, но она точно могла бы лучше», ответ на второй – «нет». Но участники команды и ее руководители будут считать, что у них Scrum (есть ведь доска со стикерами), но Srcum не работает в "наших" реалиях.
Поэтому прежде чем внедрять Scrum необходимо понять, готовы ли вы дать людям соответствующие полномочия и независимость (и что немаловажно – готовы ли люди эти полномочия принять).
Если по какой-то причине не готовы, то снова возникает вопрос «Нужен ли вам Scrum?». Если ваша цель – просто сделать прозрачным и эффективным поток создания ценности, то может вам достаточно, опять же, просто организовать правильный Kanban процесс.
Способ номер 2. Устройте из daily scrum ежедневный статусный отчет на 60+ минут
На моей практике один из самых частых комментариев на тему негативного отношения к Scrum – «Как задолбали эти ежедневные встречи, когда каждый день нужно стоять у доски по часу, вместо того, чтоб делать что-то полезное». Знакомая картина:)?
О чем это может говорить? Ответ очевиден - о том, что такие встречи не несут никакой практической пользы, и команде жалко времени, которое тратится впустую.
В Scrum guide-е явно написано, что ежедневная встреча должна длиться 15 минут, и этого достаточно для того, чтоб были достигнуты основные цели daily scrum – участники команды узнают, кто из них и над чем работает, у кого какие проблемы, и как команда продвигается к целям спринта. И ничего более – все остальные вопросы решаются отдельно.
На практике такие встречи зачастую превращаются в разговор всех сразу и обо всем, где в ходе встречи участники пытаются решать производственные вопросы, которые могут требовать большего количества времени для эффективной проработки.
Зачастую в этих обсуждениях участвует не вся команда, а только 2-3 человека, и что еще хуже – эти вопросы можно было решить еще до встречи. Как результат – встреча затягивается, а вопросы не решаются, т.к. все равно надо собираться отдельно с другими людьми, и участники выходят со встречи с чувством потерянного времени.
Что можно сделать:
Однозначно договориться о том, какая цель Daily scrum и какие вопросы должны решаться на этой встрече (Scrum guide явно говорит о том, какие это вопросы).
Если во время встречи возникает вопрос, который не получается полноценно решить за 2-3 минуты обсуждения (а в идеале вообще за минуту), то выносить такой вопрос на «парковку» после встречи, где в обсуждении будут участвовать только те, кого вопрос касается напрямую.
Если на daily scrum возникает вопрос, который на самом деле возник еще вчера, то «подсвечивать» такие ситуации отдельно и явно спрашивать у команды, почему подобные вопросы не решаются сразу. Возможно, причина в какой-то комплексной проблеме (например, участники команды взаимодействуют друг с другом только на daily scrum).
Предложить команде заранее думать о том, что рассказать на Daily scrum. При этом важно помнить, что Daily scrum – это не рассказ про все, что ты делал по шагам, а про то, что ты сделал в итоге. Как показывает практика, рассказ про итоговый результат занимает меньше времени, чем рассказ о том, как ты к этому результату пришел.
Если команда не довольна длительностью Daily scrum предложить им самим подумать о том, как сделать такие встречи эффективнее, и взять на себя ответственность за реализацию этих идей.
Способ номер 3. Постоянно расширять sprint backlog по ходу спринта, добавляя в него новые задачи.
История из реальной жизни:
Когда слова Agile и scrum стали звучать из каждого «ИТ-утюга», в одной компании решили, что разработка большого и важного проекта обязательно должна вестись в ногу со временем, т.е по Scrum, т.к. это «модно, стильно и молодежно».
Перед началом спринта команда оценивала объем работ, который может выполнить за спринт, и исходя из оценки формировала sprint backlog.
После этого приходил «большой начальник» (хороший и неглупый человек, кстати) и говорил, что надо «поднапрячься» и взять в спринт еще несколько задач в дополнение к уже запланированным, потому что один очень уважаемый человек пообещал другому еще более уважаемому человеку сделать это все еще в прошлом спринте.
Ситуация из п.3 могла повторяться несколько раз за один спринт:)
А самое чудесное в этой истории аргумент, которым это все подкреплялось – «мы работаем по гибким методологиям, значит мы должны гибко корректировать свои планы, у нас ведь Agile».
Думаю, не сложно догадаться, насколько эффективный был такой процесс и насколько довольна была команда таким подходом:) К слову сказать, когда обещания «уважаемым людям» не выполнялись, то все сваливалось на Scrum, по которому нельзя нормально работать в российских реалиях, т.к. у нас "другой менталитет".
Какие выводы можно сделать из этой истории? Вполне простые:
В Scrum мире «здорового человека» Product owner формулирует задачи на спринт на основании Product goal, а дальше совместно с командой определяет, в каком виде и в каком объеме эти задачи можно реализовать за спринт с учетом скорости команды.
В ходе этого обсуждения команда определяет цели спринта и наиболее ценный инкремент продукта, на основании этого формируется sprint backlog.
Бессмысленно пытаться сделать вид, что команда может сделать за спринт больше, чем ее реальная скорость – в первую очередь, это самообман, а также обман ожиданий всех заинтересованных лиц.
По ходу спринта в sprint backlog вносятся те и только те изменения, которые помогают достичь согласованных целей спринта.
Недопустимо расширять объем работ, жертвуя качеством.
Команда должна иметь полномочия для выполнения описанных выше шагов.
Что мешает воплотить эти простые вещи в жизнь? – недоверие. Product owner-ы или stakeholder-ы не доверяют команде и считают, что «любой нормальный человек» будет пытаться занижать свои возможности, чтоб меньше напрягаться и не перерабатывать.
Могут ли подобные опасения иметь реальную основу? – конечно, более чем.
Закроет ли этот риск постоянное «раздувание» backlog-а спринта, с целью нагрузить команду в соответствие с ее «реальными» возможностями? – не факт. Но вот что скорее всего произойдет, так это создание дополнительной нервозности и недоверия друг к другу и к scrum-у как к процессу.
Если есть риск искусственного занижения командой своей скорости, то нет смысла закрывать его нарушая базовые принципы Scrum – в этом случае, и риск не уйдет, и Scrum работать не будет. Что делать в этом случае – это уже тема для отдельного разговора.
Вот собственно и все. На самом деле количество анти-паттернов Scrum гораздо больше, в этой статье описал наиболее частые и критичные из них, которые наблюдал на практике. Надеюсь, что мысли и идеи из этой статьи помогут вам их избежать.
Интересные статьи
Интересные статьи
