Софт за 30 дней. Как Scrum делает невозможное возможным

Люди, применявшие Scrum, в большинстве случаев делали это, потому что в этом нуждались. Если бы их метод работал, им не нужно было бы меняться. Изменения – это всегда трудно, травматично и рискованно. Только отчаявшиеся или дальновидные люди берутся за это. Проблемы должны ощущаться сильнее, чем трудности или риски. Более того, многие руководители квалифицированы в текущем управлении, но не в управлении изменениями. К счастью, одним из умений Стива Дэйви было управление изменениями. В 2005 году он опробовал Scrum на одном продукте: новом, основанном на использовании интернета, нацеленном на рынок социальных средств коммуникаций. Scrum показал себя очень хорошо, и продукт был быстро разработан. К сожалению, ниша этого продукта оказалась неактуальной до 2009 года, поэтому его отложили. Тем не менее SeaChange получила уверенность в пользе Scrum.

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

Руководству поручили содействовать, но не направлять. Функция руководства изменилась: больше нет необходимости заставлять сотрудников делать то, что указано в плане, – надо было просто помогать им уложиться в план. «Ресурсами» стали творческие люди. Подобные изменения в корпоративном мировоззрении оказались особенно сложны для менеджеров среднего звена, поэтому они сопротивлялись переменам. Один из менеджеров покинул компанию, потому что не смог работать по-новому.

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

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

Результаты

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

Распространение Scrum в Iron Mountain

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