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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Тренинг о Скраме

Статьи хороши для первого знакомства со Скрамом.

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

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

Рассказываем, как устроен Скрам, и предлагаем создать настоящий Продукт, чтобы участники увидели Скрам в действии.

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

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