Проблемы при внедрении SCRUM

В этой статье я хочу рассказать как избежать самых болезненных неприятностей при внедрении чего-то нового в компании на примере фреймворка SCRUM. Также рассмотрим какие средства могут помочь в борьбе и как избегать подобных неприятностей.

Некоторые сотрудники против изменений

Фреймворк SCRUM как правило внедряют чтобы уменьшить TTM (time to market). Как и при любом внедрении чего-то нового всегда находятся люди которые не готовы к этому. Они не понимают зачем это надо и это это даст в первую очередь им. И даже получив ответы на волну своих вопросов в духе “Раньше все было и так нормально” все равно замкнутый круг сопротивоения продолжается.

Если вы видите что получив логичные ответы и достаточное объяснение сотрудник не успокаивается – надо задуматься о его переводе на другой проект (если есть такая возможность). Даже один человек излучающий негатив влияет на всех. Исключив людей сопротивляющихся внедрению на проекте чего-то нового и взяв на их место, тех кто готов к переменам – вы избавитесь от напряжения в команде и получите команду настроенную на восприятие новой информации и готовности к переменам.

Важно понимать, что негативная реакция на изменения никак не зависит от возраста. Сопротивляться могут сотрудники которым около 30 лет, в то время как те кому за 50 с готовностью берутся за что-то новое.

Сложность взаимодействия с живущими не по SCRUM

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

С этой проблемой лучше всего ничего не пытаться решить. Не нужно лезть в чужой огород со своим SCRUM. Достаточно просто попросить сделать то что вам нужно. Когда к вам придут с решением – увязывайте со своими задачами. Не усложняйте взаимодействие, если в корпоративной культуре SCRUM еще не стал повсеместным явлением. Конечно после первых скрам-тренингов появляется желание поменять абсолютно все, но надо вовремя остановиться.

Мы ничего не успеем за спринт

С приходом SCRUM чаще всего все переходят с месячных отчетных периодов на двухнедельные спринты. Вначале конечно же возникает желание не сжимать сроки задач из-за их масштабности, но подгонять размер спринта под то, что необходимо реализовать – очень большая ошибка. Нужно как раз таки наоборот, подгонять планы под длительность спринта. Для этого достаточно декомпозировать масштабные задачи. И как только задачи уменьшатся в размерах их станет проще расставить по плану, задать приоритетность выполнения. Небольшие партии кода быстрее тестировать и проверять на безопасность. В идеале по возможности длительность спринта должна составлять одну неделю.

Конечно кто-то из команды не успевает к концу спринта сделать все запланированное и возникает естественное желение отложить демо – чтобы оказаться к нему готовым во всеоружии. Но даже в таком случае необходимо придерживаться графика. В любом случае стоит рассказывать о результатах работы: что сделано, а что не успели, что предпринимается, чтобы релиз успел в срок. Таким образом вы не убегаете от проблем, а выступаете с ними лицом к лицу и потом находите им решение.

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

Для чего нужны ежедневные стендапы?

Вначале все участники команды скептически будут относится к тому, чтобы каждый день отвлекаться от работы на 10-минутные встречи.

Для решения данной проблемы можно использовать символическкое поощрение тем, кто находит с командой общий язык. Например, можно сказать, что будете отмечать на отдельном календарике тех кто пришел плюсиками. Не желая получить минус люди сами будут приходить. Со временем это может перерасти во внутреннюю шутку и уже разработчики будет намекать ПМу или тим-лиду что поставят ему минус если он по какой-либо причине не сможет придти на собрание.

Многие считают что встреча – это много времени. На самом деле – это не так. СКРАМ встреча длится 10-15 минут, в виде исключений 20, но не более. При максимальной средней продолжительности в 15 минут мы получаем что в неделю встречи отнимут один час с четвертью из сорока. Это не так много для организации работы и получения представления о ходе дел на проекте.

Если вся команда не хочет идти на встречу или они затягиваются дольше чем на 20 минут, значит что-то в работе идет не так. Рассказ одного человека на встрече не должен превышать 3 минут, 5 в виде исключения.

Это можно дополнить правилом тайм-менеджмента – если встреча занимает более, скажем 30 минут – она прекращается. Это сигнал к тому, что задачи еще не проработаны и не декомпозированы, и требуют дополнительного внимания. Ограничение в 30 минут – условно, каждая компания как правило устанавливает собственный барьер.

Хаос в бэклоге

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

Микроменеджмент

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

О чем не пишут и не говорят

Явная проблема провалов всех внедрений скрама – попытка объединить в одного человека роли скрам-мастера и product owner. Последний отвечает за бизнес составляющую проекта, прорабатывает бэклог, выполняет KPI. Его основная задача – проработка бэклога и требований к продукту. Если он начинает погружаться в другие детали у него не остается на это время. В результате – получаем непроработанный бэклог и отсутсвие четкого плана. Без хороших требований – хороший продукт не получится и ни у кого не будет представления куда двигаться дальше.

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