Зомби-Scrum: симптомы, причины и их лечение
Что такое зомби-Scrum и как понять, что Ваша команда им заражена? Почему Вы могли им «заразиться» и есть ли возможность исцелиться? Погружаемся в концепцию зомби-Scrum, придуманную Вервайсом, Шартау и Оверримом, и ищем ответы на вопросы в их «руководстве по выживанию»
В наше время Scrum стал настолько популярен, что сейчас его пытаются внедрять практически повсюду. Большие и маленькие компании видят Scrum как инструмент повышения их эффективности, а также решения большинства текущих проблем проектного управления, например, медленного реагирования на изменения или отсутствия прозрачности процессов для стейкхолдеров. Зачастую Scrum также внедряют ради отчетности или для того, чтобы казаться «прогрессивным». В результате получается ситуация, когда на выходе вместо ожидаемых видимых качественных улучшений оказывается тот самый зомби-Scrum.
На первый взгляд, зомби-Scrum легко спутать с обычным Scrum. В чем же их различия? Зомби-Scrum — это использование практик Agile, не будучи Agile. То самое «сердце Agile» (Collaborate, Deliver, Reflect and Improve), описанное автором манифеста Алистером Кокберном, попросту отсутствует. Неправильное использование или неправильное понимание Scrum приводит к внедрению бессмысленных практик, где отсутствует командная работа, приносится незначительная польза, ретроспективы оказываются неэффективны, а какие-либо улучшения практически полностью отсутствуют. Мощный, вдохновляющий и живой Scrum не может нормально работать и развиваться, из-за чего постепенно умирает и, таким образом, не приносит никакой пользы компании. Вместо этого он тащится за сотрудниками, как зомби, и в худшем случае «заражает» рабочую атмосферу.
Как понять, что Вы заражены зомби-вирусом?
У зомби-Scrum, как и у любой болезни, есть симптомы. Лидеры бизнеса должны следить за их появлением, чтобы вовремя начать с ними бороться. Если «запустить» симптомы, болезнь, как и в реальной жизни, будет прогрессировать с все нарастающим шансом того, что излечить ее станет невозможно. Давайте рассмотрим 4 ключевых симптома зомби-Scrum.
Симптом 1 — У Scrum «не бьется сердце»
Для зомби-Scrum команд характерен стиль работы, при котором функциональный продукт не является ключевой целью. Зомби относятся к нему как к чему-то необязательному и могут не выдавать функциональных инкрементов в конце спринта. Более того, у такой команды нет четкого понимания, что значит «законченная работа», из-за чего продукт и его функции не выходят из стадии разработки. Такие Scrum-команды не фокусируются на проблемах стейкхолдеров и клиентов, что подрывает саму концепцию Scrum.
Симптом 2 — Нежелание контактировать с внешним миром
Как было сказано ранее, зомби-Scrum команды не интересует доставка ценности. Более того, такие команды не волнует и то, что происходит до и после их работы в цепочке ценности. Они предпочитают фокусироваться только на своей картинке и не желают смотреть на свою работу в контексте всей организации. Ключевые стейкхолдеры в таких командах почти не участвуют в работе и даже не появляются на ревью спринтов. Более того, в самой команде встречи по планированию и ревью также откладываются, переносятся и нередко отменяются совсем. Дейли-митинги также посещают не все, и в том числе из-за этого создается среда, в которой важная для работы информация не доносится до каждого члена команды.
Симптом 3 — Безразличие к успеху и неудачам
У «зомби-команды» нет никакой реакции на провалы и удачи (которые, впрочем, редки) на каждом спринте. Их моральный дух подорван, а бэклог подтягивается от спринта к спринту, и он расширяется до критически больших масштабов, теряя свою ценность. Роли Scrum Master’a и Product Owner’a в таких зомби-Scrum командах скорее формальность, которая скрывает за собой типичных контролирующих менеджеров, которые не поддерживают команду, а лишь выполняют KPI.
Симптом 4 — У команды нет желания развиваться
Последний, но едва ли не самый серьезный симптом — это нежелание изменить сложившуюся ситуацию. Члены команды не готовы признаваться в своих ошибках, а Scrum Master (если он вообще присутствует в зомби-команде) и PO не помогают команде работать над своими ошибками и достигать более высокого качества инкрементов на выходе. Работа не структурирована и рушится за счет того, что члены команды даже не всегда присутствуют в спринтах (поскольку нет должной структуры управления, некому «защитить» членов команды от того, чтобы их постоянно одалживали на другие проекты). В совокупности эти симптомы делают команду практически полностью нефункциональной бизнес-единицей, в которой не видят ценности не только менеджмент, но и сами члены команды.
Как Вы могли им заразиться и почему?
Как правило, компании неосознанно развивают зомби-Scrum внутри себя. Это происходит не столько по вине отдельных людей, сколько из-за глубоко укоренившихся в компаниях принципов и механизмов, противоречащих фундаментальным ценностям Agile. Получается, что заражение зомби-вирусом происходит на этапе, когда компания решает меняться и становиться более гибкой, при этом меняя лишь оболочку процессов, не затрагивая их глубинное понимание и восприятие сотрудниками.
Предлагаем рассмотреть несколько примеров — потенциальных очагов заболевания «зомби-вирусом», позволяющие ему в дальнейшем прогрессировать в компании:
- Отсутствие доверия и контроль. Если прежним руководителям трудно позволить командам свободно работать и самоорганизовываться под их же ответственность, то быстрое реагирование на изменения не сможет быть реализовано должным образом. Сюда же относится и недоверие к клиентам — оно мешает самоуправляемым командам постоянно совершенствоваться;
- Изменения всегда даются с трудом. Особенно в традиционных компаниях — внедрение новых методов работы воспринимается как угроза и вызывает сильное сопротивление, не всегда явное;
- Отсутствие здоровой культуры ошибок. Ошибки воспринимаются ни как потенциальные возможности для быстрого улучшения, а как то, чего необходимо стыдиться, избегать и скрывать;
- Не полное, а фрагментарное внедрение Scrum. Например, только команда разработчиков работает по Scrum, а остальные сотрудники не понимают, зачем это необходимо, просто не видят смысла. Это усложняет процессы совместной работы в компании, как и зависимость от других команд или руководства;
- Отсутствие ясности и преимуществ Scrum. Если основы и преимущества Scrum понятны не всем сотрудникам, то желания принимать это изменение будет отсутствовать;
- Отсутствие фокуса на желаемом результате. Если Scrum внедряются только по той причине, что «сейчас это модно» и «все так делают», то скорее всего, такое внедрение бессмысленно, а для решения большинства задач подошло бы другое решение;
- Отсутствие общих целей и ориентации на ценность. В рабочем контексте, где нет ясных целей и понимания доносимой до клиента ценности, Scrum не сможет эффективно функционировать.
Можно ли вылечится от зомби-вируса и как?
Зомби-Scrum и его симптомы выглядят так, будто они неизлечимы, но это далеко не так. Существует несколько способов, как можно улучшить ситуацию в команде и привести ее в рабочее «здоровое» состояние.
В первую очередь, надо прояснить, что зомби-Scrum — это не проблема подхода, а результат разрыва между ценностями Scrum и ценностями организации. Поэтому «лечение» необходимо начать с разговора с командой. Необходимо обсудить с ними сложившуюся ситуацию и что с ней делать. Вероятно, в процессе обсуждения Вы сможете построить план развития команды.
Далее, покажите команде, что такое настоящий, «здоровый» Scrum — наймите сотрудника с опытом работы по Scrum, устройте Scrum-сафари (выездные сессии в других компаниях, где ваши сотрудники смогут познакомиться с командами, которые успешно внедрили этот подход) — общение и наблюдение за «здоровым» Scrum’ом поможет Вам начать повторять полезные практики.
Еще одним способом борьбы с болезнью является внедрение освобождающей структуры. Примером такой практики является «What? So what? Now What?» — фреймворк позволяет говорить с коллегами о результатах и дальнейших действиях в заданной структуре: что есть сейчас (факты, наблюдения, результаты), какие выводы можно сделать из данных, и какие действия необходимо предпринять для достижения цели спринта. Особенно полезен этот фреймворк на ревью спринта, где с командой необходимо обсудить поставку прошедшего спринта и полученный фидбек, и решить, как двигаться дальше и на чем сфокусироваться.
Наконец, еще одним способом борьбы с зомби-Scrum является «встряска». Для его реализации необходимо резко изменить условия работы команды, чтобы ее члены встрепенулись от «зомби-сна». В таких командах полезно, например, сократить время спринтов до 1-2 недель, смещать фокус Daily Scrum на прогресс команды в достижении цели спринта, а также обсуждения того, какой вклад в разработку хочет нести команда в текущем спринте на Sprint Planning. Этот список не конечен: есть множество способов улучшить ситуацию в команде, ведь зомби-Scrum — это не приговор, а маркер того, что нужно предпринять определенные действия. Начните с этих способов и наблюдайте за прогрессом команды.
Заключение
Резюмируя, скажем, что зомби-Scrum уже здесь, он среди нас. Скорее всего, прочитав эту статью, вы вспомнили компании/команды, которые подходят под описание «зараженных». К счастью, Вы теперь знаете, что проблема не в самом Scrum, а в его «бессердечной» интерпретации. С этим определенно можно что-то сделать, и мы надеемся, что наша статья вдохновит вас на изменения. А если вы хотите глубже погрузиться в тематику и узнать больше практических кейсов, то рекомендуем ознакомиться с книгой «Zombie Scrum Survival Guide» Кристиана Вервайса, Йоханнеса Шартау и Барри Оверрима.
Сталкивались ли вы с своей команде с симптомами зомби-Scrum и как удалось от них избавиться? Будем рады вашим комментариям и вопросам к статье!
Agile подразумевает смену культуры и изменение мышления, поэтому убедить в необходимости этого руководителей порой бывает очень сложной задачей. Более того, просьба перейти на гибкий подход иногда воспринимается как критика. Давайте разберемся, как можно сделать этот процесс проще и эффективнее.
К сожалению, до сих пор многие руководители компаний имеют представление о Scrum только как о фреймворке, который используют в разработке цифровых продуктов. В этой статье мы рассмотрим опыт применения методологий Agile в армии США и попробуем объяснить, что данные методологии — это лишь способ организации гибкости работы команды или организации, и они не привязаны только к одному привычному продукту — программному обеспечению.
Как помочь команде планировать спринты и устанавливать реальные сроки, грамотно распределять усилия и отслеживать собственный прогресс? В статье поговорим о том, что такое гибкие оценки и рассмотрим лучшие техники оценки трудоемкости в Agile: попробуйте покер планирования, размер футболки, голосование по точкам и еще 7 других интересных техник.