Пять ошибок работы по Скраму

Мы неправильно применяем правила Скрама

Скрам очень часто используют неверно. Например, размер Команды Разработки больше девяти человек, Владелец Продукта не обладает властью и возможностями принимать решения по Продукту, Команда не проводит Ретроспективу Спринта. Стоит ли удивляться, что в этих случаях толку от Скрама не будет?

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

Мы не готовы к боли, которую причиняет Скрам

Скрам выводит на поверхность существующие проблемы, и нам кажется, что именно Скрам всё испортил.

Например, Владелец Продукта закрыл проект после первого Спринта. Можно сказать: «Смотрите, как только они начали делать Скрам, проект разнесло!» Это не совсем так. Основываясь на скорости Команды и оценках её будущей скорости, Владелец Продукта понял, что проект затянется и не будет выгодным. Скрам сэкономил компании кучу денег, остановив плохой проект на ранней стадии. Скрам причинил доброкачественную боль.

Мы думаем, что всё отлично заработает с первого Спринта

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

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

Мы пытаемся адаптировать Скрам под себя

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

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

Мы используем Скрам там, где он не подходит

Существуют области, в которых Скрам просто-напросто не подходит.

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

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

Скрам — не единственный способ стать аджайл. Попробуйте Канбан.

Погрузиться в тему

Разобраться в Канбане мы помогаем на базовом тренинге. Он полезен всем, кто всерьёз заинтересовался гибкими подходами.

Объясняем тему понятным языком, поэтому специальная подготовка не нужна.

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

Текст: Сергей Дмитриев

Линкануть
Поделиться
Класснуть
Отправить