Избирательная гибкость или Agile только в R&D

Представьте, что вы гимнаст. У вас гибкая спина, но руки, ноги и шея, будто свинцом налиты. Сможете ли вы с такой конституцией тела добиться высоких результатов в мире спорта? А что происходит с компаниями, которые внедряют Agile исключительно в R&D, оставаясь при этом строго иерархическими, классически менеджерскими на других уровнях?

Первый вопрос, который должен задавать организационный коуч главам организации, чьи светлые умы посетила мысль стать на путь Agile — “Зачем это вам нужно?” Т.е. необходимо четко прояснить, ЗАЧЕМ нужно тратить деньги, усилия, время, лишаться части сотрудников (это неизбежный природный процесс при любой трансформации). Если вы услышите в ответ, что-то вроде: “Чтобы выпускать большее количество фичь за единицу времени”, то пожмите друг другу руки, выйдите из офиса и отряхните пыль с подошв ваших сандалий.

Но, допустим, главу организации прельщают такие процессы, как продуктовые открытия (product discovery), лавирование на волнах изменчивого рынка, покорение новых горизонтов, счастье людей в своей команде. Тогда, смахнув слезу радости, соглашайтесь и становитесь рядом с ним у руля.

А теперь представим, что организационная трансформация началась задолго до вашего появления в компании. Вы оказались, что называется, в гуще событий. Ваше поле деятельности — R&D, это естественно. Вы начинаете работать на командном уровне, на индивидуальном — все идет хорошо. Вы проводите 1:1ы с членами команд, узнаете их движущие мотиваторы (moving motivators). Проводите коучинговые командные встречи (exploration hours), еще раз при необходимости проясняете роли и обязанности, делегирование (delegation board). Меряете “температуру” команды по средствам health check, рисуете персональные карты (personal maps), чтобы лучше познакомиться и т.д. и т.п. В общем, хороший старт.

Но при соприкосновении с организационным уровнем вы начинаете наблюдать следующее:

• Ваши инициативы блокируются кем-то, кто принимает решения, и подолгу зависают в колонке Impairment в Trello (холодок подозрительности закрадывается в сердце)
• Поддержки менеджмента, которая так необходима при трансформации, нет. Все происходит снизу-вверх (bottom-top). При чем позиция тех, кто сверху, звучит как: “Докажите, что это работает и что это нам нужно” (Фрустрация)
• Пересмотр организационной структуры звучит как мятеж (Отчаяние)
• Апогей: вам открытым текстом говорят, что мы не Agile организация, мы делаем бизнес так, как деды завещали, и вообще Agile нужен только в R&D (белый шум на фоне)

“Но что здесь такого страшного?”, — спросите вы. Давайте рассмотрим детальнее, в разрезе каждой из ролей-участниц процесса.

Владелец Продукта (Product Owner)

Человек с самым незавидным положением при описанном выше раскладе. РО находится между молотом и наковальней — посредник между иерархическим миром старших-, младших-, средних-, еще Бог знает каких, менеджеров и Agile миром команды разработки со СкрамМастером. Он, как никто, чувствует на собственной шкуре, как это, когда низы могут, а верхи не хотят.

Грамотный РО всегда пребывает в процессе product discovery, валидации идей, анализе рынка, конкурентов, глубинного понимания нужд конечных пользователей. Он не стыдится подключать к этому процессу команду разработки. И это прекрасный акт совместного творчества, в результате которого рождается концепция, требующая пробной реализации и обкатки на пользователях. Но, перед этим идею нужно миллион раз согласовать с начальством, ее могут отвергнуть, изменить до неузнаваемости. Либо, еще лучше, — концепции уже спускаются на РО свыше. Таким образом Владелец Продукта превращается в обезьянку, обслуживающую систему Jira. Также, когда Agile не применен во всех сферах компании, РО никак не контактирует с конечными пользователями, что снижает возможность получения конструктивной обратной связи, необходимой для адаптации развития продукта.

Еще одной проблемой для Владельца Продукта в таком сетапе является так называемый “проектный подход” (заметьте, до этого момента слово “проект” не упоминалось ни разу, мы оперировали только термином “продукт”). Т.е. вся работа РМО (project management office) построена на составлении годовых (!) планов в виде диаграмм Ганта, что уже противоречит итерационному продукто-исследовательскому подходу разработки.

ScrumMaster

Этой роли повезло больше. Если выход на организационный уровень закрыт, то всегда есть уровни командной и индивидуальной работы. Здесь всегда будет непаханое поле для постоянных улучшений (kaizen). Но, не стоит ждать поддержки артиллерии в лице глав организации для масштабных изменений (kaikaku) и расшатывании статуса кво. Все, что удастся сделать команде СкрамМастеров в таких условиях — создать эффективный (на сколько это возможно) Agile pocket, избирательная гибкость, о которой мы упоминали вначале.

Один из основных вызовов, который стоит перед СкрамМасетром — получить согласие от членов Скрам команд на их коучинг. Как бы странно это не звучало, но если такой “договор” не заключается, то любые действия СкрамМастера будут восприниматься как насилие.

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

Команда Разработки

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

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

Тим Лидер

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

Не все Тим Лиды отваживаются облегчить свою участь и разделить зоны влияния со СкрамМастером. И их можно понять, ведь в случае пожара кому прилетит по шапке от руководства? Тим Лиду (кнут и пряник — еще одно негативное проявление избирательной гибкости).

Итоги

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