5 причин, почему подход Scrum работает неправильно

В последнее время Scrum притянул к себе много негативного внимания. И вполне заслуженно. Но мы в LeadStartup - оптимисты. И считаем, что главное — учиться и предотвращать будущие бедствия, если понимать, что именно пошло не так и почему.

Если вернуться в конец 20-ого века к первоначальному Скраму, то обнаружим там целостный подход с упором на скорость и гибкость производства, отказ от «долгих ящиков» и последовательных задач. Звучит впечатляюще, не так ли?

Некоторые даже утверждали, что «новый подход может действовать как агент изменений: он является средством для внедрения творческих рыночных идей и процессов в старую, жёсткую организацию». В то время такие заявления были довольно радикальны, если не еретичны.

Но эти предприятия сумели выжить. И сегодня Scrum для них — лишь «гибкое» покрывало, которым они укрывают «водопадные» процессы. Scrum не изменил старые, жёсткие организации — старые, жёсткие организации изменили Scrum.

Хотя акцент на эмпирическом управлении логически обоснован. И когда обстоятельства и приоритеты быстро меняются, традиционная модель производства терпит неудачу, поэтому нужно постоянно наблюдать и адаптироваться.

Похоже, что связь Scrum с Agile воспринимается скорее как косвенная, чем непосредственная. Роковой недостаток Scrum заключается в том, что он внешняя оболочка, обёртка Аджайл. Agile описывается набором принципов и ценностей, а не церемоний и процессов. Agile управляется манифестом, а не руководством по процессу. Это две совершенно разные вещи, но даже сегодня многие люди до сих пор смущены путаницей.

Сегодня мы хотим обсудить 5 причин, почему внедрение Scrum проваливается. Из-за перечисленных ниже факторов вложенные в Аджайл деньги могут не дать возврат инвестиций. Кому-то нравится называть их анти-паттернами, кто-то может называть их «Not scrum». Но иногда нам приходится работать с тем, что у нас есть, и всё ещё находить способы добиться успеха.

Работу должны выполнять высоко мотивированные профессионалы. Скрам — это не только стенд-апы, планирования, ретроспективы и демонстрации. Если вы считаете, что основной эффект дают именно эти мероприятия, то вы ошибаетесь.

Всё дело в людях, которые могут брать на себя сложные задачи и совместно решать нетипичные проблемы за счёт совместного сотрудничества профессионалов. Договориться между собой им помогает скрам-мастер, который работает и на уровне организации, и на уровне команды. Без этого человека Scrum останется лишь инструментом, способным сократить только очереди задач. А об улучшении продуктивности речи быть не может.

Люди, работающие в команде, часто не являются командой. Они не движутся к общей цели.

В Скрам-гайде есть понятие «Цели спринта». Это крайне важный элемент, который и делает Скрам Скрамом. В переводе с английского это слово означает схватку. В начале матча по американскому футболу возникает борьба за мяч после его розыгрыша. У команды должна быть цель наподобие той, что в спорте — добыть мяч, приносящий очки в игре.

Это ведь не про «поделать задачи». Это про то, чтобы направить все усилия, чтобы достичь единственной цели. Цель «сделать все задачи» не является целью.

Это не тот человек, который ставит команде задачи. И не тот, кто контролирует их выполнение. Владелец продукта (Product Owner) понимает, каким образом команда может заработать деньги. Он несёт ответственность перед инвесторами, что их ресурсы будут возвращены назад в кратном размере. Если его нет, то люди не могут принести весомую пользу, поскольку у них сразу же находятся какие-то дела и включается режим «сделать все задачи».

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

Есть много разнообразных возможностей для каждого, начиная от стартапов и заканчивая федеральным правительством, переходящим к гибкому делопроизводству. «Ложный Agile» смертелен, но его довольно легко обнаружить: продукт-менеджеры начинают беспокоиться о приближающихся сроках. Хотя 15-ти минут достаточно, чтобы продвинуть проект вперёд — это лучше длительных дискуссий и переговоров.

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

Если результаты работы скрам-команды попадают в медленное подразделение, которое работает с низкой пропускной способностью, то команда завалит это подразделение работой, а компания получит прибыль тогда, когда это медленное подразделение выполнит все свои обязанности.

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

Так, например, во время двухнедельного спринта ведущий разработчик и ВП могут проводить часовые встречи каждый четверг в 13:00. Это может включать в себя другие заинтересованные стороны, чтобы предоставить им более подробную информацию. При планировании следующей итерации появится чёткое представление о характере и направленности усилий, которые дадут нужный результат.

Когда предприятия сталкиваются с необходимостью «делать Аджайл» (а не «быть Аджайл»), они ищут своеобразное лекарство — и находят Scrum. Такое мышление демонстрирует, что ситуация уже вышла из-под контроля. Лучше признать, что Scrum без Agile — это катастрофа. И перестать притворяться, что одного этого инструмента достаточно для изменений.

Лучшая альтернатива — думать, а не слепо следовать чужой «лучшей» практике. Чтобы напрямую связать команду с клиентами и генерировать бизнес-ценности, необходимо

• сосредоточиться на продукте, а не на проекте;
• создать среду, в которой команде не только разрешено, но и поощряется адаптироваться и пробовать, терпеть неудачи, учиться и расти.
  

Помните: вам не нужен Scrum, чтобы быть Agile! Это Scrum нуждается в вашем гибком мышлении!

Хорошая новость заключается в том, что «ложную гибкость» легко обнаружить. Если ваш проект сошёл с пути - знайте, что многие команды были там, где вы находитесь, и успешно нашли свой путь. Будьте бдительны, прагматичны и Agile!