Четыре колеса Scrum

Многие скрам-команды стоят на месте, не подозревая, что “едут” на одном из четырех колес, в то время как продвижение вперед требует синергического действия всех четырех. Что за “колеса”? Что делать, когда одно вышло из строя? Кто и как должен ремонтировать “автомобиль” под названием Scrum?

ЧЕТЫРЕ КОЛЕСА SCRUM

Существуют четыре неотъемлемые составляющие скрам-подхода, которые условно назовем “колесами”. Устранить хотя бы одно означает нивелировать Scrum. Вот они:

1. Теория
2. Практика
3. Правила
4. ценности

Рассмотрим каждое «колесо» и выясним, что делать, когда оно не крутится.

КОЛЕСО ТЕОРИИ

В целом Scrum предусматривает изменение подхода к разработке продукта. Ведь внедрение цифровых технологий в бизнес, создание новых технологических решений для компаний как в IT, так и в других отраслях, свидетельствует о сложной интеллектуальной деятельности, которую профессиональным жаргоном называют “комплексным доменом”.

Комплексный (от англ. Complex – сложный, многогранный) домен предусматривает высокий уровень неопределенности при разработке цифрового продукта.

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

Что это значит? Те компании, которые осознают высокий уровень неопределенности в сложном домене, способны быстрее и успешнее адаптировать продукт (не в конце разработки, а во время, если не после первой же итерации!), повышая его ценность.

Это также означает, что компании, которые этого не понимают – с одной стороны, хотят ввести новейшей скрам-подход, а с другой – крутить старую шарманку (или катеринку – от французского названия первой песни “Шармонт Катрин” – очаровательная Катрин [Charmante Catherine], которая выполнялась на Катеринке – шарманке). Правда, вместо прекрасной Катрин, их песня называется “Командно-административный стиль”.

На самом деле такие новаторы ничего не хотят менять в стиле и философии управления, руками и ногами держась за прогнозируемость и контроль.

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

Два противоположных подхода

Итак, существует старый подход с командно-административным стилем управления – “по протоколу”, “в соответствии с инструкциями”, “по согласованию”, “в соответствии с планом”, который в сложном домене или не работает, или работает ужасно, либо не выдерживает конкуренции со стороны гибких команд. Этот подход также называют предиктивным (от англ. Predictable – прогнозируемый), а в совокупности с вертикальной моделью управления и контроля можем назвать его директивно-предиктивным.

В противоположность прекрасной, но уже немолодой Катрин, существует другой подход – эмпирический. Именно на него опирается Scrum. Эмпиризм, как известно, является основой науки (верим в то, что можем выяснить на основе реального опыта – увидеть, услышать, почувствовать на ощупь, измерить, выявить характеристики объекта исследования и т.д.).

По какой-то причине сторонники директовно-предиктивного подхода склонны приписывать эмпирическому скрам-подходу хаос.

На самом деле восприятие скрам-подхода как хаотического не соответствует действительности. Ведь сам термин framework (рама картины) указывает на четко очерченные границы, в которых участники разработки рисуют “картину”. Эти рамки предусматривают четкие правила игры, приемлемую практику и ценности. Некоторые евангелисты скрама (Гюнтер) даже отмечают, что скрам – не методология (закрытая система, в которой все прописано и предсказуемо), а фреймворк (четко очерченные границы и правила, но как “играть”, решают игроки).

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

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

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

Задача лидера в таком случае – обеспечить их всеми необходимыми инструментами для успешной реализации задач. “Мой успех зависит от успеха всей команды” – вот лозунг лидера в парадигме Scrum (в противоположность старому подходу “Без гения моей персоны команда не сможет реализовать проект»).

Таким образом, эмпирический подход имеет четко очерченные границы и сформулированные правила, однако он одновременно гибкий. Это означает, что:

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

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

ПРОБЛЕМА КОЛЕСА ТЕОРИИ

Самая большая проблема в этом контексте – нежелание лидеров организаций менять привычные подходы к управлению. Назовем это “колесом теории”. Что это значит?

• Внедряя скрам, руководители не собираются ничего менять в своей практике управления проектами (в Scrum разработку интеллектуального продукта проблематично называть “проектом”, ведь классический проект обычно прописан от “А” до “Я” и не предусматривает изменений и адаптаций, в то время как Scrum подчеркивает постоянную адаптацию продукта с учетом свежих эмпирических данных, полученных в каждой итерации).
• Многие руководители даже не догадываются о необходимости менять собственную практику управления и подходы к разработке.
• Многие руководители не до конца понимают преимущества и недостатки подходов, по которым привыкли работать.

Существует даже термин антиаджайл (против гибкости), которым характеризуют жесткое планирование с недопущением отклонений от плана и ориентацией на результат, определенный заранее. Иными словами, соблюдение предварительно определенных процедур, спецификаций и сроков важнее, чем сам продукт, не говоря о его ценности для конечных пользователей.

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

Как в таком случае извлечь палку с колеса теории?

Если для читателей роль скрам-мастера вызывает больше вопросов, чем ответов, то вот и первый ответ. Устранение препятствий в работе скрам-команды – это прерогатива скрам-мастера. “Палки” в колесе теории – пример таких препятствий. (Подробнее о роли в скрам-подходе см. в статье “Ролевая модель Scrum“).

КОЛЕСО ПРАКТИКИ СКРАМА

Одна из ошибок новичков – это непонимание разницы между элементами скрам-подхода и его практиками.

Практика скрама – явление не статичное, а переменное. Ретроспектива, например, – обязательный элемент Scrum, но способов их проводить множество. Последний, что я использовал – “Пицца-ретроспектива”. Благодаря творческому подходу и разнообразию способов использования элементов скрама, участникам значительно интереснее работать и сохранять внимание на цели.

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

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

Другой “палкой” может быть навязывание любимых практик одной персоны. Например, метод оценивания заданий (например, story points). Специалист посетил тренинг или прочитал книгу о методах оценки в Agile, после чего навязывает его остальным участникам команды как единственно правильный. То же самое может касаться коллег, которые привыкли оценивать задачи в человекочасах или человекоднях.

В последнее время в моду вошел термин no estimate. Заключается он в том, что заранее оценивать ничего не надо, нужно формировать задачи так, чтобы все они были примерно одного уровня нагрузки. Идея заслуживает внимания, но некоторые специалисты почему-то ее абсолютизируют, считая ее единственным правильным решением, а все остальные практики – устаревшими. Это неправильно.

Столбы, постулаты, принципы, ценности Scrum – понятие фундаментальные, в то время как практики (способы реализации, механизмы, методы) – гибкие.

См. например, примеры визуализации различных способов организации ретроспективы в Scrum:

КОЛЕСО ПРАВИЛ

В Скрам они как раз четко прописаны. Нарушение этих правил всегда имеет негативные последствия.

Например, “Организация должна уважать решения, принятые владельцем продукта“. Это правило означает, что компания действительно обязана это делать. Владелец продукта – ее авторитетный представитель, с которым она тесно сотрудничает при разработке.

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

Неуважение к этого правила может проявляться в:

• вмешательстве в работу команды со стороны руководства компании;
• лишении стратегических функций (права на разработку стратегии, установленные приоритетов и т.п.);
• отмене или замене решений владельца продукта.

Другое правило – “Только скрам-команда может планировать спринт”. Представим ситуацию, где руководитель нарушил первое правило – раз втыкал свой нос в чужое дело (вмешивался в процесс разработки и мешал людям работать, сам указывал владельцу продукта на то, какую стратегию внедрять и какие приоритеты расставлять, отменял его решение). В таком случае, что мешает ему нарушить и другое? Например, приходить на ежедневные встречи (Daily Scrum) и проталкивать свои “идеи”, “советы” или “рекомендации”, демотивирующие и дезориентирующие команду?

Важно заметить, что правонарушителями скрама могут выступать не только руководители, но и любые участники команды, включая скрам-мастеров и владельцев продукта! (Вот почему Scrum сертифицирует специалистов, подчеркивая профессиональное использование подхода).

КОЛЕСО ЦЕННОСТЕЙ СКРАМА

Иногда автомобиль не едет, потому что полностью вздулось четвёртый колесо – ценностей.

Напомню о пяти ценностей Scrum:

1. Уважение.
2. Преданность делу и соблюдение слова (commitment).
3. Концентрация внимания на продукте и его разработке (focus).
4. Открытость (openness).
5. Отвага (courage – смелость озвучивать правду).

Речь идет об определенной поведенческой модели всех участников разработки по скрам-подходу.

От того, как взаимодействуют между собой участники команды, зависит, будут ли ценности Scrum нивелированы, или наоборот – реализованы с соответствующим положительным эффектом.

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

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

Ценности прямо касаются системы мотивации. Например, метод кнута и пряника в Scrum не работает.

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

Бихевиористы провели подобные параллели с людьми. Методы дельфинов, пингвинов, голубей в сложном домене, где идет речь о высокоинтеллектуальном продукте, вызывают больше вреда, чем приносят пользы. Без прозрачности, честности, правдивой картины не стоит рассчитывать на настоящий успех.

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

Заметим, что скрывать правду могут не только отдельные участники команды, но и руководители. Так или иначе, практику сокрытия проблем следует искоренять. Все члены команды обязаны лелеять культуру честности в работе.

ЧТО ДЕЛАТЬ

Для того чтобы все четыре колеса скрама работали отлично, вот что стоит сделать:

1. Придерживаться системы ролей в Scrum. Это означает, что в команде обязательно должен быть профессиональный скрам-мастер или по крайней мере специалист, который выполняет эту роль (в таком случае стоит повысить его компетентность на профессиональном тренинге с соответствующей сертификацией).
2. Развивать скрам-команду. Сама по себе команда разработчиков не станет профессиональной скрам-командой, ей нужен тренер (скрам-мастер), а также постоянный рост во внутренней коммуникации, формировании скрам-культуры, кросс-функциональности, самоорганизации и автономности.
3. Осмыслить и хорошо знать “четыре колеса” Scrum – теорию, практику, правила и ценности, совершенствуя компетентность каждого участника команды в каждой из этих сфер.
4. Осознать разницу между “Прекрасной Катрин” и эмпирическим подходом.
5. Выяснить сущность гибкого подхода и его преимущества в эпоху стремительного развития цифровых технологий.

ПРИСОЕДИНЯЙТЕСЬ К AGILE.LIVE

Ближайшие сертификационные тренинги Agile.Live: Professional Scrum Master (PSM), Advanced Scrum Master with PSM II Certification, Professional Agile Leadership Essentials (PAL-E)
Подписаться на страницу в LinkedIn
Подписаться на Telegram-канал Agile.Live
Подписаться на YouTube-канал Agile.Live