Почему Scrum не сработал, или Уверены ли вы, что точно знаете, что такое фреймворк?

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

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

Как Scrum появился в вашей компании?

Последние лет 5 Scrum стал настолько популярен, что о нём не говорит разве что моя бабушка. И это логично, ведь основные причины такой популярности в том, что Scrum прост для понимания, и для его применения есть подробное Руководство (Scrum Guide), помогающее командам эффективно создавать сложные продукты с высокой ценностью и в условиях высокой неопределённости. Более того, Scrum уже давно выходит за пределы разработки программных продуктов. Сами основатели этого фреймворка в обновлённой версии Scrum Guide от ноября 2020г., признаются, что «следят за тем, как Scrum всё больше используется в постоянно растущем комплексном мире». Но есть и подводные камни –например, из-за такой популярности на этот фреймворк его часто применяют совершенно не подкованные в нём люди.

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

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

Если вы действительно хотите применить гибкие подходы к управлению, то начинать следует с изменения структуры управления в организации, меняющую среду работы людей. Только в этом случае их образ мышления будет меняться, а новые методы работы будут соответствовать их восприятию собственных действий. В пример можно взять «Сбербанк»: результатом полноценного внедрения Scrum которого стало создание глобальной структуры, обеспечивающей необходимый уровень гибкости организации. Изменяя способ выполнения работы, мы меняем и тип мышления сотрудников. Scrum не может возникнуть из неоткуда, он должен поддерживаться и внедряться в первую очередь со стороны руководства организации – а иначе он обречён.

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

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

Из этого вытекает следующий вопрос: а действительно ли он вам так нужен? Чтобы понять это и выбрать верный путь управления, необходимо понять, в какой системе вы существуете.

В какой системе Вы существуете?

Ист. Кеневин (Cynefin): способ думать о ситуациях, проблемах, системах

Часто бывает так, что мы не знаем, когда применять Scrum и в какой среде он совершенно бессмыслен – а из-за этого “таких делов можно наворотить”. Да, Scrum нужен не всегда и не во всём. Чтобы узнать, подходит именно вам Scrum или нет, можно воспользоваться моделью «Кеневин» или Cynefin (англ. Среда обитания), которая позволяет компании определить, в какой системе она существует, а значит выбрать верную модель управления, коррелирующую с компетенцией команды. Разработал методику Дейв Сноуден, в прошлом возглавлявший Институт управления знаниями на базе IBM, а ныне сооснователь центра Cognitive Edge и консультант по вопросам менеджмента знаний.

Схематично модель построения систем представлена на рисунке, мы видим расположенные по периметру окружности, символизирующие системы:
• упорядоченные – простые и сложные;
• неупорядоченные, или комплексные;
• хаотичные.

В центре схемы – зона неопределенности, которую нужно как можно быстрее покинуть.

Опишу каждую подробнее, чтобы понять, в каких системах Agile и фреймворк Sсrum не подходят, а какая – та самая, в которой нужен именно Scrum.

1. Упорядоченные простые системы (Simple, Obvious)
Они понятны, для их решения у команды есть опыт. Уже на старте понятно, что получится в результате, за какие деньги и в какие сроки. Нередко есть инструкция по выполнению этого действия. Самый простой пример – сборка комплектующих на заводе или производство стульев.
Формула принятия решений также проста: Определяем – Классифицируем – Реагируем.

2. Упорядоченные сложные системы (Complicated)
В этом случае заранее не понятно, как решать проблему. Задача не уникальна, однако именно ее команда ранее не решала. Показательным может быть пример создания типового сайта, у команды есть согласованное ТЗ от заказчика, шаблон, план работ, а изменения в процессе работы скорее всего не потребуются. И на выходе получится готовый продукт, по которому предлагаются корректировки и поддержка некоторое время.
Формула принятия решения: Определяем – Анализируем – Реагируем.

3. Комплексные, сложные системы (Complex)
Если проецировать систему на задачу, то речь идет о непонятной, сложной задаче, но при этом команда с подобной проблемой уже сталкивалась и имеет опыт ее решения. Например, у заказчика есть видение продукта, но мы никогда ранее этого не делали. Это может быть эксперимент или модель или работающий прототип на основе его идеи.

В жизни это может выглядеть следующим образом, заказчик пришёл с идеей о замене старой неэффективной платформы по подсчёту сельскохозяйственных животных, на новую, основанную на искусственном интеллекте, необходимо предложить решение и прототип для того, чтобы заказчик остался с нами. Чем быстрее мы сориентируемся в комплексной среде и предоставим результат, тем выше шанс оставить конкурентов позади. А в реализации прототипа и вовсе может оказаться, что сначала заказчик хотел видеть многостраничное решение, потом более лаконичное на одну страницу, а потом и вовсе может смениться руководство и выдвинуть идею подсчитывать не только животных.
Формула принятия решения: Измеряем – Определяем – Реагируем.

4. Хаотичные системы (Chaotic)
Здесь хорошо работает экспериментальный подход. Хаотичные – абсолютно новые задачи, которые никто и никогда не решал раньше. Попытка разобраться с такой системой – путь к инновациям. Любой способ решения (стабилизации системы) будет новым. Порой нужно действовать вразрез с традиционными методами менеджмента. В реальной жизни это может быть стартап или падающие стены в момент, когда вы читаете эту статью и здесь остаётся только действовать, причём как можно скорее!
Формула принятия решения: Действуем – Определяем – Реагируем.

Успели сориентироваться в какой из систем подходят именно гибкие практики управления? Ответ очевиден, даже если оттолкнуться от определения Scrum – «это лёгкий фреймворк, который помогает людям, командам и организациям создавать ценность с помощью адаптивных решений комплексных проблем», и поэтому его можно применить только в Комплексной, сложной системе: в остальных он будет чувствовать себя не так уверенно, или же будет совершенно бессмысленным, что принесёт большую потерю в деньгах и времени.

Фреймворк намеренно не полный, гибкий и определяет только правила, которые задают ориентиры для отношений и взаимодействий людей, что помогает быстрой адаптации, опять же, в комплексной среде.

Попробуйте спросить себя: действительно ли у меня настолько большая изменчивость, для внедрения Scrum? Если ответ отрицательный, не усложняйте, приглядитесь к другим более эффективным практикам, которые существуют для каждой из этих систем. Для упорядоченных простых подходит каскадная методология управления проектами, для упорядоченных сложных систем – подходы PMI, Prince2 и PMBoK, а в хаотичных необходимо действовать как можно скорее, чтобы выжить – поэтому подойдёт экспериментальный метод управления основанный на новых ещё не зарекомендовавших себя подходах.

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

Дальше необходимо определиться с тем, кто будет нести ответственность за применение Scrum в соответствие сo Scrum Guide, и ключевая в этом плане ответственность лежит на Scrum-мастере.

Нашли ли Вы своего Scrum-мастера?

Ист. Разница между хорошим Скрам Мастером и отличным Скрам Мастером

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

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

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

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

Scrum-мастер помогает людям договариваться между собой, как на уровне организации, так и на уровне команды. Помните один из принципов Agile “люди важнее процессов и инструментов”? Всё дело в них – людях, которые могут брать на себя сложные задачи и совместно решать нетипичные проблемы; но без Scrum-мастера, без возможности договариваться Scrum останется лишь инструментом, способным сократить лишь очереди задач без улучшения продуктивности.

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

Примерные вопросы, которые могут вам помочь:

1. Оцените, насколько Scrum-мастер помогает команде достигать целей (0 – никак, 10 – есть ощутимая помощь)

2. Оцените полезность Scrum-церемоний (0 – трата времени, 10 – есть ощутимая польза):
a. Планирование
b. Дейли
c. Спринт ревью (демо)
d. Ретроспективы

3. Были ли конфликтные ситуации в команде?
a. Если да, как Scrum-мастер помог их разрешению? (0 – никак не помог, 10 – помог команде конструктивно решить конфликт)

4. Насколько согласны с утверждениями (0 – вообще не согласен, 10 – абсолютная правда):
a. «При общении со Scrum-мастером я чувствую, что мою позицию слышат и понимают»
b. «Scrum-мастер помогает нам справляться с возникающими сложностями»
c. «Scrum-мастер стремится сделать нашу команду лучше»

5. Ощущаете ли вы, что продуктивность команды растет?

6. (опционально) Три вещи, за которые вы могли бы поблагодарить своего Scrum-мастера

7. (опционально) Три вещи, которые Scrum-мастеру стоит улучшить

Самым сложным в работе Scrum-мастера, на мой взгляд, является изменение образа мышления не только команды, но и своего – т. к. основная его цель – делать команды более самостоятельными (самоорганизованными), то есть учить команду обходиться без него.
И последнее, наиболее важное из-за чего что-то может пойти не так – это пренебрежение практиками, прописанными в Руководстве.

Играете ли вы по правилам?

Вы пробовали играть в шахматы 20 фигурками вместо 32? «Зачем мне это делать,» – скажете вы, – «ведь тогда это станет совсем другой игрой с неизвестным исходом». Но, почему-то не задумываясь над этим, мы продолжаем выкидывать, как фигурки с шахматной доски, события или ценности из фреймворка Scrum.

Чтобы правильно внедрить Scrum, важно следовать чётким правилам и работать в рамках практик фреймворка. Кен Швабер в своём блоге пишет: «Scrum – это как игра в шахматы. Вы либо играете по правилам, либо не играете совсем».

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

Уверена, найдутся те внимательные, кто скажет: «а как же гибкость?» Здесь уместно сказать, что Scrum – это фреймворк практик, связанных небольшим набором чётко определённых правил. Фреймворк, в отличии от метода, предлагает более гибкую платформу, обуславливая ряд правил, но не ограничивает применение любых других практик и подходов в зависимости от той или иной рабочей среды. Например, в Guide представлены следующие события Sprint, Sprint planning, daily scrum, sprint review, sprint retrospective, исполнение которых обязательно, но этоне ограничивает проведения любых иных событий (например, встреч Brainstorm ideas или встреч, связанных с Research и шаринга знаний на команду или команды).

Резюмируя

Пожалуйста, не поддавайтесь моде, проанализируйте и соотносите риски с возможностями. Подумайте, в какой системе находитесь и какой стиль управления подходит именно вам.

Определились с тем, что у вас высокоизменчивая комплексная среда, отлично – вливайтесь в Agile! Но помните, что работать в направлении трансформаций должны высокомотивированные профессионалы и особенно тщательно нужно подходить к выбору Scrum-мастера. И конечно же, не поддавайтесь соблазну отменять те правила, что написаны в Руководстве. Может быть, не сразу, но постепенно внедряйте best practice в свой быт и будет вам счастье.