5 ложных надежд на скрам и как их исправить

Опубликовано: 2022-03-11

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

  1. Процесс может занять центральное место в работе.
  2. Его легко спутать с микроменеджментом под другим названием.
  3. Ежедневный стендап может ощущаться как собрание, на котором нужно оправдать его существование.

В других случаях роли Scrum не представлены должным образом. Иногда владелец продукта хочет слишком много вещей внутри спринта или хочет изменить приоритеты в середине спринта — скрам-мастер, одержимо сосредоточенный на поддержании скорости и внедрении каждой новой скрам-церемонии, которую он изучает. По прошествии некоторого времени с фреймворком, кажется, возникает общий вопрос: «Это мы или методология?»

Ложные надежды на скрам

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

Ложная надежда №1: Scrum заставляет команды работать быстрее

Scrum ассоциируется со скоростью

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

Больше беспокоит то, что многие видят такие термины, как скорость и спринт, и думают о «скорости». Однако цель любой методологии Agile, включая Scrum, — предоставить готовый продукт. В конце концов, когда ваша команда станет более компетентной в Scrum, вы сможете быстрее предоставлять новые функции. Однако скорость не обязательно является основной целью. Это различие должно быть четко сформулировано внутри вашей Скрам-команды, а также при повышении осведомленности в вашей компании о поддержке методологии Скрама.

Вы не продаете скорость; вы продаете завершение.

Ложная надежда № 2: Строгое соблюдение Scrum решит проблемы корпоративной культуры

У всех разные стили работы. Некоторые люди любят встречи. Другие используют такие фразы, как «усердно работай, играй усердно». Важно признать, что какой бы стиль работы ни ценил ваша компания, вы принимаете как его преимущества, так и недостатки. Компания, которая ценит встречи, скорее всего, будет бороться с ежедневными стендапами. Агрессивные и ориентированные на скорость команды будут иметь проблемы с расползанием объема внутри спринта.

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

Ложная надежда № 3. Критически важные участники могут отправлять своих делегатов на встречи

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

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

Ложная надежда № 4: ежедневные стендапы заставят всех быть более сосредоточенными

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

Scrum требует, чтобы определенные роли, в частности мастер Scrum, были напористыми, но не подавляющими. Для Scrum-мастера важно создать позитивную среду, которая ведет к завершенным продуктам.

Ложная надежда № 5: мы добьемся успеха с первой попытки

Внедрение Scrum может оказаться неудачным с первой попытки

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

Как исправить сломанный процесс Scrum

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

Уточните свои ожидания

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

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

Расширьте возможности своих участников

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

Активно решайте проблемы

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

Фреймворк обратной связи Scrum

Одним из таких примеров является схема «Я хочу, интересно, а что, если». Во время групповых обсуждений или ретроспектив член команды может дать отзыв, начав свое заявление с одной из этих трех фраз. Например, они могут сказать: «Я бы хотел, чтобы на встречах в стойке больше внимания уделялось препятствиям, о которых мне, возможно, придется знать в этот день». Вы также можете использовать свой собственный открыватель, такой как «Мне нравится…».

Еще одно решение для структурированной обратной связи, которое может быть полезно во время встреч, — это метод Triage от Holocracy, созданный Брайаном Робертсоном и используемый такими компаниями, как Zappos. Например, участники составляют повестку дня «напряженности» для обсуждения. Каждый участник описывает свою проблему, говоря: «У меня напряженность», а затем перечисляет людей и ресурсы, необходимые для ее решения. Поощряя участников напрямую обращаться к проблемам как к «напряженности», холократия позволяет участникам свободно общаться, не создавая атмосферы конфликта.

Метод сортировки от холократии

Используйте ретроспективы для решения проблем и повторения процесса

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

Ретроспективы важны в Scrum

Не менее важно избегать вложений в статические процессы. То, что сработало однажды, может не работать вечно. Многие команды борются с текучестью участников. Это распространено во многих компаниях, поскольку участники переводятся в другие команды, получают повышение или вообще покидают компанию. По мере того, как состав команды меняется, важно не оставаться приверженным тому, что в Scrum все повторяется. Ошибки будут происходить, но, надеюсь, они будут недолгими, пока вы итерируете.

Scrum работает лучше всего, когда присутствуют руководители

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

Резюме: вы можете исправить сломанный процесс Scrum

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

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

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

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