Основные Трудности

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

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

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

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

Другой распространенной ошибкой является предположение, что какая-либо практика не приветствуется или запрещена только потому, что Скрам явно не требует этого. Например, Скрам не требует, чтобы Владелец Продукта устанавливал долгосрочную стратегию для своего продукта; так же как и не требуется, чтобы инженеры обращались за советом к более опытным коллегам по поводу сложных технических проблем. Скрам оставляет за участниками право принимать правильное решение; и в большинстве случаев рекомендуется использовать обе эти практики (наряду со многими другими).

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

Хорошая новость заключается в том, что, хотя первый Спринт обычно очень сложен для Команды, но преимущества Скрама обычно становятся заметными к его концу, что заставляет многие новые Скрам-команды восклицать: “Скраму сложно следовать, но безусловно это в целом намного лучше того, что мы делали раньше!”

Перевод статьи осуществлён Кротовым Артёмом и Романом Лапаевым.