Внедрение Scrum в компании 🚀 — примеры внедрения скрама с результатами

Большим достоинством Scrum является то, что его всегда можно адаптировать к конкретной компании и проектам. Именно поэтому вопрос того, как внедряется Scrum в других компаниях может дать ясное понимание того, что может быть применено и в вашем бизнесе.

Команда адаптировала подход и было решено проводить планирование с каждым членом команды в отдельности. Такой подход может поставить под сомнение ключевые принципы Скрама, но при этом команда отметила повышение предсказуемости в работе: ошибок стало меньше.

Нужно не увеличивать спринт в зависимости от объема задач, а подбирать задачи в соответствии с временем спринта Product Owner и Скрам–мастер имеют разный функционал, эти роли должны быть различными.

Большим достоинством и одновременно недостатком Scrum является то, что его всегда можно и нужно адаптировать к конкретной компании и к конкретным проектам.

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

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

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

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

Команда адаптировала подход под «свои реалии». В результате некоторые мероприятия были введены (ежедневные митинги), а некоторые трансформировались (планирование спринта).

Разберем планирование спринта. У команды возникла проблема в соблюдении сроков из–за того, что планирование спринта в присутствие всей команды занимало «слишком много времени».

Было решено проводить планирование с каждым членом команды в отдельности. Такой подход может поставить под сомнение реализацию прозрачность и инспекцию — ключевые принципы Скрама, создающие общий каркас и ценности командной работы.

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

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

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

Возможное решение — за соблюдением процесса планирования спринта и других мероприятий должен отвечать Скрам–мастер.

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

Время всегда утекает: на отвлеченные разговоры, на решение посторонних и коммуникативных вопросов, и даже на личные разборки. Именно поэтому так важна роль Скрам–мастера в команде, который фасилитирует мероприятия Scrum.

Важно отметить, что несмотря на эту особенность внедрения, команда отметила повышение предсказуемости в работе: ошибок в работе стало меньше.

Это обычный эффект внедрения Scrum, так как новые версии продукта выходят чаще, и появляется возможность начать вносить изменения раньше, если это требуется.

• Нужно не увеличивать спринт в зависимости от объема задач, а подбирать задачи в соответствии с временем спринта

• Product Owner и Скрам–мастер имеют разный функционал, эти роли должны быть различными. Именно после разделения этих ролей в команде улучшились процессы в команде и качество беклога

Scrum позволил команде разработки сократить количество микроменеджмента и сфокусироваться на задачах.

Особенно отметим, что в данном кейсе при внедрении Scrum было активное сопротивление отдельных членов команды появившимся нововведениям.

Такая ситуация является достаточно нормальной. Стремление к стабильности и привычному укладу имеется у каждого человека. У кого–то это стремление может быть сильнее, чем интерес и драйв от нововведений.

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

Хочется особенно отметить, что чаще всего негативно настроенных к изменениям сотрудников как правило удается убедить в полезности и ценности новых изменений в том числе для них самих (сокращение микроменеджмента, больше степеней свободы, большее пространство для самовыражения и т.д.).

Мы можем предположить, что такие проблемы возникли на первых этапах (на этапе внедрения), когда роль Владельца Продукта и Скрам–мастера совмещал один человек, что плохо не только для качества беклога, но и для групповой динамики — ведь одному человеку не хватает времени на обе задачи.

Именно после добавления роли Скрам–мастера как отдельного специалиста Скрам в данном кейсе начал показывать свою эффективность, скорость разработки начала повышаться.

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

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

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