Стыд и Скрам. Идеальный скрам-коуч

Agile, scrum, agile-coach, scrum-master… Что только люди не придумают, чтобы казаться продуктивнее, верно? Когда вы читаете описание вакансии, то там почти наверняка будет упоминание, что «наша команда работает исключительно по методологии agile», как будто это то единственное, на чем стоит сделать отдельный акцент. Сам по себе аджайл – это не хорошо и не плохо, это просто очередная модель, которую многие находят эффективной. Но при этом многие попадают в ловушку и больший упор делают на следование определенным процессам, а не достижение результата. Скрам ради скрама, аджайл ради аджайла. Есть даже отдельный вид нечисти – это скрам коучи. Эти злобные, маленькие и противные существа преследуют только одну цель – сидеть на вашей шее, постоянно говорить, как «надо» и грести деньжата из вашего кармана. В этом посте порассуждаем на тему полезности коучей.

Коучи бывают разные

В основном, все коучи делают только одну вещь. Они говорят, чтобы ты что-нибудь сделал. Ты хочешь купить новую машину? Ну так пойди и купи ее! Нет денег? Так заработай! Да это же, черт возьми, гениально просто!

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

Коучи бывают двух видов:

1. Полезные. Они выступают как консультанты и помогают наладить процессы. Один раз и за денежку. Они нацелены на результат, и после их ухода команде становится предельно ясно, как взаимодействовать для достижения лучшего (и скорого) результата.
2. Бесполезные. Они устраиваются к вам в штат либо приходят слишком часто. Они на постоянной основе сосут из вас денежки. Они говорят вам, как выстроить процессы так, чтобы они были идеальными. Но при этом вся идеальность процессов ничуть не влияет на достижение реальных целей. Другими словами, коучи бесполезные стремятся лишь подстроить всех под свою идеальную картину взаимодействия внутри команды без оглядки на результат. Выкатили вовремя релиз, но при этом кто-то действовал не по инструкции? Ай-ай. Профакапили сроки, но следовали процессам и действовали как единое целое? Одобряю!

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

Коучи полезные

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

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

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

На самом деле, много проблем приходит в команду сверху. Это довольно логично и понятно, ведь бизнесу нужно развиваться. Скрам-коуч не в праве указывать, какой скоуп работ должен быть выполнен, однако, он может помочь менеджеру проекта (или продукт оунеру) минимизировать хаос в команде. Он поможет приоретизировать задачи и дать понять руководству, что не все их желания реализуемы в течение ближайшего спринта. Чему-то стоит дать приоритет выше, чему-то – ниже, чтобы объем работ согласовывался с имеющимися в распоряжении человеко-часами. И после согласования приоритеты уже не меняются, иначе в команде воцарится самый настоящий хаос.

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

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

Плохие коучи

Практически наверняка это сертифицированный специалист в области agile, scrum и прочей ереси. Он знает, как должен выглядеть образцовый спринт, сколько стори-поинтов в нем должно быть, сколько эпиков и тасков. Как, вы используете часы для оценки задач? Чушь, теперь вы используете стори-поинты!

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

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

Один такой скрам (срам) коуч решил кардинально пересмотреть работу всей команды и заявил, что разработчики должны сами писать себе требования. А затем по ним реализовывать функциональность. Якобы, так будет быстрее и проще, ибо только сам разработчик может максимально коротко и понятно описать, что нужно сделать.

Аналитики в это время:

Почему это глупо? Потому что аналитика берется не с потолка, это долгий и сложный процесс. В случае проектной работы, это как минимум:

1. Общение с заказчиком с целью выявить его (скрытые) желания.
2. Приоритезация требований и детальная проработка каждого из них.
3. Написание понятной документации, по которой будет вестись разработка и согласно которой будет осуществляться тестирование.

В случае продукта все то же самое, только вместо заказчика выступает продукт оунер. Если вы сами из аналитики, то наверняка вы сможете добавить к этим трем пунктам еще несколько других. Это значит, что провести аналитику – это не просто сесть и написать требования на листке бумаги.

И теперь представим, что разработчики будут проводить еще и аналитику. Здесь сплошные минусы:

1. Человек устраивается на работу по конкретному профилю. В данном случае разработчиков заставят делать то, что им совершенно не интересно.
2. К тому же, как мы уже выяснили, аналитика – большая и сложная область. Разработчики в ней совершенно некомпетентны.
3. Обычно время разработчика (хорошего) стоит дорого. Зачастую даже дороже, чем время менеджера проекта. В таком случае это невыгодно даже финансово – оплачивать время на аналитику по ставке разработчика.

Но что, если разработчики все-таки будут писать требования, короткие и понятные? Тогда спустя некоторое (непродолжительное) время на проекте воцарится хаос, потому что никто не сможет объяснить, откуда взялось то или иное требование.

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

Хорошего скрам-коуча не видно

Хороший коуч – он как фотограф на свадьбе. Он весь день делает свою работу, но вы его не замечаете. Он не достает вас и не тянет на себя внимание, а спустя пару недель вы видите результат.

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

Хороший коуч – он как коридорный из фильма «Отель “Гранд Будапешт”»:

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

А плохой коуч постоянно хочет применить что-то особенное, как-то оправдать свою зарплату, но при этом не видит, что команде нужно на самом деле. 

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

Хороший коуч ставит команду превыше процесса. Это процессы должны служить команде, а не команда – процессу. Хороший скрам-коуч всегда дает команде понять, зачем он вводит те или иные изменения, и как это повлияет на производительность и комфорт.

Кстати, для коучей тоже справедлива проблемы опыта и стажа.

Команда – это конструктор Lego

У Lego есть разные наборы с разным количеством деталей. Есть набор с замком из Гарри Поттера, состоящий из 500 деталей. Есть набор с Ferrari, состоящий из 5000 деталей. Есть набор со Звездой Смерти из Звездных Войн, состоящий из 25000 деталей.

Если вы – скрам-коуч, и у вас в распоряжении набор из Гарри Поттера, пожалуйста, не лепите из него Звезду Смерти.

Понравилось? Подписывайтесь на меня в соцсетях!