3 грубых ошибки при планировании спринта, которые убивают продуктивность сотрудников

Повышение производительности труда сотрудников - серьезная проблема для малого бизнеса. В нашем недавнем обзоре основных технологических тенденций * малые и средние предприятия (СМБ) оценили повышение производительности труда сотрудников как одну из своих главных бизнес-целей на следующие один-два года.

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

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

Однако не все Agile-проекты успешны. Согласно 6point6 отчету , компании в Соединенном Королевстве будут вероятно впустую примерно $ 50 млрд на неудачных проектах Agile IT в течение последних 12 месяцев. В отчете рассматривались в основном крупные предприятия, но малому и среднему бизнесу следовало бы учиться на ошибках, которые приводят к неудачам .

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

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

Эффективное планирование спринта - это разница между успехом и неудачей

Малые предприятия, практикующие Scrum, завершают проекты в рамках ограниченных по времени мероприятий, называемых «спринтами», которые длятся от недели до целого месяца. Планирование спринта включает в себя владельца продукта, мастера Scrum и команду разработчиков, которые обязуются выполнить набор задач (например, разработку новых функций или исправление ошибок).

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

Однако предприятиям часто не удается создать эффективные планы спринтов из-за отсутствия опыта Agile. Отчет VersionOne, в котором изучались подходы Agile на крупных предприятиях, показал, что 80% ответивших организаций все еще не достигли зрелости Agile.

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

Вот 3 распространенных ошибки при планировании спринта, о которых малый бизнес должен знать и избегать:

1. Установление нереалистичных ожиданий из-за чрезмерных обязательств перед чрезмерно нетерпеливыми владельцами продукта.

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

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

Как технологии могут помочь:

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

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

• Делитесь ключевыми метриками проекта и производительности: оцените, что команда может выполнить во время спринта, отслеживая ее историческую производительность в диаграммах выработки и скорости. Поделитесь этими идеями с заинтересованными сторонами проекта, чтобы обосновать приверженность вашей команды (объем) конкретному спринту.

График скорости в СпираПлан ( Источник )

2. Проведение совещаний по планированию спринта без приоритетного отставания по продукту.

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

Приоритезация означает выбор функций продукта, которые нужно создать в первую очередь. Для этого предприятиям малого и среднего бизнеса следует проанализировать простые в создании функции, представляющие наибольшую ценность для пользователей. Это объясняет Девин Дин (мастер Agile Scrum и эксперт по управлению проектами):

Как технологии могут помочь:

При приоритизации накопившихся продуктов, Deen говорит предприятия должны помнить принцип Парето: U ГКР получит 80% от стоимости вашего продукта с 20% своих возможностей . Используйте гибкие инструменты управления проектами, чтобы определить функции, которые попадают в эти важные 20%.

• Приоритезация функций с помощью очков истории: в инструментах Scrum, таких как VivifyScrum , функция оценки, называемая покером планирования, позволяет каждому члену команды присваивать очки истории пользователя. Это помогает им оценить сложность и усилия, необходимые для создания этой функции; более высокие баллы означают более высокую сложность. Затем команды могут определить функции, требующие наименьших затрат или усилий, что определяет, какие пользовательские истории будут приоритетными и включены в данный спринт.

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

Документ требований к продукту в Confluence ( Источник )

3. Слишком много времени на собраниях по планированию спринтов.

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

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

Как технологии могут помочь:

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

• Подготовьте команду к собраниям по планированию спринта: Кон говорит, что ключевая ошибка, которую делают команды, - это приходить неподготовленными к собраниям по планированию спринта. Чтобы избежать этого, владельцы продуктов должны обмениваться ключевой проектной документацией, такой как список невыполненных работ по продукту, чтобы команды знали, что обсуждать на встречах. Здесь пригодятся инструменты для обмена файлами , поскольку они позволяют владельцам продуктов обмениваться документами, связанными с проектом, с соответствующими командами в безопасном и централизованном месте.
• Следите за расписанием своей команды и избегайте ненужных встреч: встречи по планированию спринтов обычно бывают длительными, потому что у команд нет достаточно времени для подготовки к ним. Это из-за чрезмерного количества времени, которое они проводят на других ненужных встречах. Мастера Scrum могут использовать инструменты планирования, которые имеют встроенные календари и информационные панели для отчетности, чтобы отслеживать доступность членов команды и определять наиболее важные встречи, на которых они должны присутствовать.

Календарь команды в Wrike ( Источник )

Выводы и следующие шаги

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

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

Вот краткое изложение основных выводов:

* Информация об исследовании Gartner о технологических тенденциях:

Gartner провела это исследование в апреле и мае 2017 года среди 699 американских компаний малого и среднего бизнеса с более чем 10 сотрудниками и годовой выручкой менее 100 миллионов долларов. В опрос не были включены некоммерческие организации. Квалифицированные респонденты принимают решения или оказывают значительное влияние на решения, связанные с приобретением технологий для своей организации.