Все статьи
Кто такой Agile-лидер?
Дата: 13.01.2018
Иногда, для работы над чем-то большим и сложным, вам действительно нужно собрать большую группу команд, представителей разных отделов и поставщиков. Если так, то, скорее всего, вам нужен лидер!
Создание продукта в соответствии с принципами Agile уже стало нормой во многих отраслях (особенно связанных с разработкой программного обеспечения). Это означает, что продукты создаются небольшими, самоорганизующимися, кросс-функциональными командами, поставки делаются небольшими инкрементами и улучшения проводятся непрерывно на основании обратной связи от реальных пользователей. Почти так, как описано в Agile-манифесте, только замените слово «программное обеспечение» на «продукт», так как это не специфика только разработки программного обеспечения.
Все это здорово и круто, но, разрастаясь до десятков команд, взаимодействующих через организационные барьеры, все очевидно усложняется и дальнейшее развитие становится мучительным. И даже если вся компания состоит из аккуратно и красиво организованных Scrum-команд, вы все равно можете прийти к полнейшему беспорядку! Вот картинка, которая может показаться вам знакомой:
Прежде чем пытаться всем этим «руководить», спросите себя: «А действительно ли организация должна быть такой большой и сложной?» Возможно, вы пытаетесь за один шаг построить целого слона. Возможно, ваши команды разделены по функциям, что порождает большое число зависимостей. А, возможно, ваша архитектура не слишком гибкая, слишком хрупкая или имеет слишком большое число внутренних связей.
Поэтому для начала попробуйте упростить ситуацию. Кто-то из мудрых сказал: «Не масштабируйте Agile — упрощайте организацию». Может быть вам удастся реорганизоваться в одну или две команды с нужным набором навыков, не распределенных территориально, на 100% вовлеченных и имеющих прямой контакт с клиентом. И, может быть, они смогут создать такой же (или даже лучший) продукт вдвое быстрее и вдвое дешевле! Не попадайтесь на психологическую ловушку, что больше людей = лучше. Больше людей иногда, может быть, и лучше, но единственное, что можно сказать наверняка — больше людей = больше затрат и больше сложностей. А потенциальные выгоды — это всего лишь потенциальные выгоды.
Но хорошо. Иногда, для работы над чем-то большим и сложным, вам действительно нужно собрать большую группу команд, представителей разных отделов и поставщиков. Давайте представим, что перед нами именно такой случай, а вы уже сами решайте, подходит ли это под вашу конкретную ситуацию.
Если так, то, скорее всего, вам нужен лидер! Кто-то, кто будет полностью сконцентрирован на координации между командами, кто будет следить за тем, чтобы все движущиеся механизмы работали синхронно, и будет сохранять видение всей картинки. И эта статья именно об этом.
Agile опирается на самоорганизацию, которая (при правильном использовании) действительно является супер-эффективной. Но при растущем числе команд для самоорганизации иногда требуется рука помощи — кто-то, кто будет создавать и поддерживать среду, способствующую самоорганизации, включающую такие вещи как ясность цели, быстрое получение обратной связи, эффективные каналы коммуникации и т.д. Тот, кто будет делать «1 + 1 = 3» (благодаря синергии) вместо «1 + 1 = 1.5» (вследствие несогласованности).
Давайте назовем его Agile-лидером. И его основная задача — обеспечивать согласованность!
На уровне команды Agile-подходы описывают лидерские роли, такие как Владелец Продукта и Scrum-мастер. Но на мультикомандном уровне роль формального лидера не определена. Это происходит потому, что небольшие инициативы обычно не требуют выделенного лидера — успешность Scrum показала, что эффективное управление возможно и без выделенного лидера. Однако, с ростом числа людей, вовлеченных в процесс, вы, вероятно, придете к необходимости иметь отдельного лидера, полностью вовлеченного и сфокусированного только на вашей мультикомандной организации, как бы вы ее ни назвали: «проект», «программа», «сделка», «продукт» и т.д.
При этом лидер не обязательно должен быть один, это может быть пара или даже группа людей, до тех пор, пока они могут взаимодействовать тесно и выступать единым голосом. Для этой статьи предположим, что это один человек.
Термин «Agile-лидер» весьма условный. В зависимости от того, как организована ваша работа, вам могут подойти разные названия для этой роли: Главный Инженер, Главный Владелец Продукта, Руководитель Проекта (если это проект), Руководитель Программы, Главный Scrum-мастер, Release Train Engineer, Управляющий Хаосом, Менеджер Великого Пути, Мастер Дзен, Координатор, Пилот, Проектный Коуч, Катализатор и т.д. Как бы вы его ни называли, эта функция является критически необходимой и требуется для любой достаточно крупной кросс-функциональной инициативы. Человек (один или несколько) в этой роли должен быть мотивирован, вовлечен и иметь необходимый опыт.
В этой статье я намеренно называю эту роль «Agile-лидер». Слово «Agile» тут нужно, чтобы подчеркнуть, что статья про гибкую разработку продукта, а термин «лидер» я использую вместо «менеджера», потому что в хорошо функционирующих Agile-организациях роль менеджера и управление в целом осуществляется командами самостоятельно. Поэтому основная цель этой роли — лидерство, а не управление. Но провести четкую границу между ними, конечно, не получится.
Цель этой статьи — описать портрет великого Agile-лидера, чтобы вам было легче найти, вырастить или стать таким человеком и помогать вашим мультикомандным инициативам становиться еще более успешными! Это не формальное определение этой роли — это исключительно мое видение того, какой она должна быть.
Итак, вкратце: старайтесь уменьшить необходимость в больших, сложных и мультикомандных инициативах. Но, если это невозможно — убедитесь, что у вас есть потрясающий Agile-лидер!
А разве это не Руководитель Проекта?
Может быть, но совсем не обязательно так. «Проект» — это лишь один из множества способов организовать работу, и зачастую — не самый подходящий, когда речь идет о разработке продуктов. Однако, если вы работаете в Проектной системе и ваши проекты большие и сложные, подразумевающие синхронизацию множества разных команд и организаций, тогда Agile-лидер для вас — это действительно Лидер Agile-проектов. У меня есть отдельная статья What is an Agile Project Leader, где я рассуждаю о проектной модели в принципе. Но в описании самой роли в той статье я ссылаюсь на эту, поэтому постарайтесь не уйти в бесконечный цикл.
Повторю: то, как называть эту роль, целиком зависит от контекста. А цель этой статьи — описать, какого рода лидер вам нужен, чтобы решить поставленную задачу в стиле Agile.
Что делает Agile-лидер?
Бабар, мой коллега из Spotify, привел отличную аналогию из спорта:
- Как выглядит победа? Видение/Миссия.
- Что есть план? Стратегия и тактика.
- Как выглядят оценки? Прогресс, статус, циклы обратной связи.
- Что мешает нам победить? Непрерывные улучшения, люди, команды, стратегия, тактика.
Знаем ли мы, зачем мы здесь и как выглядит победа? Есть ли у нас план, стратегия? Есть ли у нас возможность увидеть, где мы находимся сейчас? Видим ли мы препятствия и то, что замедляет наш прогресс? Стараемся ли мы непрерывно устранять эти препятствия?
Вероятно, на часть этих вопросов вы ответите «нет» (в противном случае — поздравляю, продолжайте в том же духе). И задача Agile-лидера состоит в том, чтобы везде стояло «да». Это не гарантирует успех, но несомненно увеличит его шансы.
В небольших инициативах, следующих Scrum, эти задачи покрываются существующими ролями и кросс-командным взаимодействием по принципу «снизу-вверх». В более крупных инициативах мы сталкиваемся с несогласованностью между командами и разрывами между отдельными частями организации, которые не позволяют процессу проходить гладко. Поэтому Agile-лидер концентрируется на коммуникации и построении единой ясной картинки. Если у всех участников процесса будет единое видение того, где мы находимся, куда идем и зачем, то мы с большей вероятностью будем работать вместе и двигаться в этом направлении.
Поконкретнее, пожалуйста. Чем на самом деле занимается Agile-лидер?
Итак, что же все это означает на практике? Чем реально занимается Agile-лидер?
Терпеть не могу эту фразу, но… это зависит! Все. Сказал.
Зависит от контекста и от того, что сегодня уже работает хорошо и что нет.
Не переставайте спрашивать себя: «Что должно происходить такого, чего еще не происходит? Что я могу сделать, чтобы это произошло, не став при этом узким местом процесса?»
Хотя я не могу однозначно сказать, что Agile-лидер должен делать, я приведу несколько примеров. Воспринимайте это как разные «линзы», которые вы, как лидер, можете надевать. Часть из перечисленных вещей вы, возможно, будете делать самостоятельно, но для большинства вам необходимо будет создать контекст, в котором они будут делаться без вашего участия.
Итак, вот список. Сделайте глубокий вдох:
- Видение/миссия. Вам необходимо обеспечить, чтобы работа выполнялась с четким пониманием цели, проверяемые гипотезы были ясными, активность имела обозначенные границы и периметр («чего мы НЕ ДЕЛАЕМ») и четкие критерии успеха, основанные на влиянии на бизнес, а не на фактах поставок. Необходимо обеспечить, чтобы все это было кристально ясно всем участникам процесса: не только командам, но и клиентам, и остальным ключевым лицам.
- Итеративные и инкрементальные поставки. Необходимо обеспечить деление работы на части, чтобы процесс поставки был итеративным и инкрементальным, а не превращался в большой взрыв. По возможности избегайте больших проектов, вместо этого — старайтесь делить работу на группы проектов, меньших по размеру.
- Адаптивное планирование. Обеспечьте создание планов и их распространение между всеми участниками процесса. Планы должны быть адаптивными, а не прогнозирующими, и должны меняться по мере получения новых знаний. Обеспечьте осведомленность про ограничения сроков и прогнозирование, если оно необходимо, и обновляйте прогнозы по мере получения опытных данных в результате выполнения работы. Убедитесь, что любые ограничения (сроки или объем работ) понятны каждому.
- Обратная связь. Обеспечьте короткий цикл обратной связи с тесной регулярной коммуникацией между командами и клиентами. Совместное планирование, демонстрации и т.д. Обеспечьте ранние полевые испытания для гипотез и непрерывное обучение. Обеспечьте измерение прогресса на основании реальных поставок, обратной связи от клиентов и влияния на бизнес, а не на основании соответствия планам.
- Непрерывные улучшения и обмен знаниями. Обеспечьте обучение и улучшения в ходе активной работы (а не только по ее завершении) и передачу ключевых знаний между командами, а также между различными частями организации.
- Фокус и выравнивание. Обеспечьте сфокусированность и вовлеченность (не многозадачность) участников и их единое понимание списка приоритетов. Стирайте организационные барьеры. Обеспечьте фокусировку людей на достижении максимального влияния на бизнес с помощью минимально возможных усилий и выпуска (лучше работать головой, чем по десять часов в день).
- Устранение препятствий. Обеспечьте визуализацию, приоритизацию и систематическое устранение лишних трат и препятствий. Мотивируйте команды брать ответственность и по возможности решать возникающие препятствия самостоятельно. Взаимодействуйте с другими руководителями и берите на себя ответственность по преодолению препятствий, которые команды не могут решить самостоятельно.
- Принятие решений. Обеспечьте своевременное принятие решений наиболее компетентными людьми с максимально возможной децентрализацией. Убедитесь, что никто (включая вас) не является узким горлышком процесса принятия решений. Минимизируйте число решений, которое необходимо принимать вам.
- Визуализируйте статус и прогресс. Ваша задача — обеспечить, чтобы каждый участник процесса видел «полную картину», в этом помогут доски и панели, показывающие, куда мы идем и зачем, где мы сейчас, препятствия и т.д. Пусть информация будет верхнеуровневой, оставьте детали командам.
- Поток. Оптимизируйте не загрузку ресурсов, а поток ценности, от начала и до конца. Выискивайте узкие места и возникающие очереди, применяйте системное мышление и принципы бережливой разработки, чтобы поставка ценности стала максимально простой.
- Самоорганизация и автономность. Сделайте так, чтобы цель и текущее положение дел были понятны каждому, и люди могли думать и действовать автономно, без необходимости вам указывать им, что делать. Ваша задача — обеспечить, чтобы на вход люди получали проблемы, требующие решения, а не задачи для выполнения. Используйте коллективный разум группы вместо того, чтобы пытаться быть супермозгом самостоятельно.
- Подбор персонала и планирование загрузки. Работайте с менеджерами, чтобы обеспечить доступность нужных людей и команд в нужное время, чтобы максимизировать скорость работы и шансы на успех.
- Бюджетирование и оценки. Ваша задача — обеспечить, чтобы все бюджетные и контрактные ограничения были известны и проработаны. Организуйте, чтобы оценки выполнялись командой, наиболее близкой к реальной работе; они должны быть верхнеуровневыми и корректироваться по мере необходимости. Обеспечьте, чтобы оценки воспринимались именно как оценки, а не как обязательства. Сделайте ценообразование прозрачным.
- Зависимости. Ваша задача — обеспечить, чтобы все кросс-командные и общие для нескольких подразделений зависимости были визуализированы и эффективно управлялись: команды не должны простаивать, ожидая друг друга.
- Кросс-функциональное взаимодействие. Используйте техники, такие как совместное размещение и кросс-функциональные каналы коммуникации, чтобы уменьшить разрозненность и повысить мотивацию участников к совместной работе.
- Коммуникация. Создайте среду, обеспечивающую широкополосную коммуникацию лицом к лицу и минимизирующую потребность в ненужных документах, письмах и прочей узкой коммуникации. Документы должны поддерживать общение, а не замещать его.
- Быстрый провал. Создайте контекст, в котором небольшие провалы могут случаться часто и на ранних этапах, таким образом снижая риск возникновения большого провала в конце.
Особый пункт — Мотивация. Мотивация является ключевой валютой в любой креативной и сложной инициативе – она гораздо важнее человеко-часов. Мотивированные люди создают лучшие продукты и делают это быстрее. Разница бывает впечатляющей! Но при этом мотивация — это не отдельный пункт, вы не можете просто «мотивировать людей». Вместо этого люди будут зажигаться и мотивироваться такими вещами как Автономность, Влияние и Цель.
Следуйте хорошему принципу: «Не мотивируйте людей — убирайте то, что их демотивирует». Если люди будут видеть, как вы устраняете реальные препятствия на их пути и создаете среду с высоким уровнем доверия, помогающую им работать эффективнее — это, вероятно, будет мотивировать их куда больше, чем вечеринки в гавайских футболках по пятницам, бесплатные напитки или теннисные столы.
Ууу, какой длииииинный список! С чего бы начать?
Превратите его в более короткий, соответствующий вашей конкретной ситуации!
Например, можете собраться с несколькими ребятами и оценить каждый элемент по шкалам «насколько это важно для нас» и «насколько хорошо это работает сейчас». А затем ограничьте список, оставив в нем только топ-5 вещей, которые важны и сейчас не работают. Используйте полученный список как основу для поиска Agile-лидера (или приоритизации своей работы, если Agile-лидер — это вы).
А что насчет ответственности?
Итак, является ли Agile-лидер единой точкой ответственности и должен ли он один отвечать своей головой в случае провала (и что считать «провалом»…)?
Конечно же нет! Все, кто вовлечен в процесс, являются ответственными. Но люди должны отвечать за свои поступки, а не за результаты.
На первый взгляд это может показаться сумасшествием, но подумайте секунду…
Продукт может провалиться, несмотря на самые старательные усилия — он может провалиться по случайным причинам или вследствие действий, находящихся за пределами контроля команд. И, наоборот, продукт может выстрелить, несмотря на ужасную работу команды и руководства, просто благодаря удаче или отсутствию конкурентов. Это сложно, как сложно определить абсолютный провал или успех — между ними есть гигантская область серого.
Agile-лидер должен обеспечить, что, если провал происходит, то происходит он на ранних этапах! Это делается за счет введения цикла быстрой обратной связи (частые поставки клиентам, обучение через практику и т.д.). Его задача — чтобы участники учились на своих ошибках и использовали эти знания в следующих продуктах или на следующих итерациях текущего.
Наказывая за провалы, мы вынуждаем людей скрывать их и таким образом сводим обучение на нет. Наказывая за провалы, мы вынуждаем людей избегать рисков и убиваем на корню всю инновации. Провал (и извлеченные из него опыт и обучение) нужно праздновать, а не наказывать за него! Но, разумеется, в разумных пределах. И следите за тем, чтобы цикл обратной связи был коротким, чтобы провалы не были фатальными…
Итак, хотя Agile-лидер и может выступать в роли «визитной карточки» проекта/программы/продукта/еще чего-то для внешних стейкхолдеров, он не несет личной ответственности за успех или в случае провала. Однако, он отвечает за то, чтобы сделать все возможное, чтобы увеличить шансы на успех. И это относится ко всем участникам, не только к Agile-лидеру.
Какими качествами должен обладать человек, чтобы успешно справляться с этой ролью?
Как минимум, Agile-лидер должен быть (как мне кажется):
- Страстно увлечен продуктом, клиентами и влиянием на бизнес.
- Заряженным ролью Agile-лидера и хотеть отдаваться ей на все 100%.
- Согласен с большинством пунктов из описания роли и хочет развиваться в этом направлении.
- Иметь хотя бы какой-то реальный опыт лидерства (в любом контексте).
- Иметь хотя бы какой-то опыт работы с Agile (в любой роли).
- Хотеть развивать свои навыки, если они недостаточны или отсутствуют.
- Быть готовым тратить время на обучение и непрерывное совершенствование своих навыков Agile-лидера.
Очевидно, что «идеального» Agile-лидера не существует, но ниже представлено «Определение Совершенства». Я бы не стал ожидать, что кто-либо будет соответствовать всем перечисленным пунктам, но чем больше — тем лучше. :o)
В идеальном мире:
- Вы мыслите на бизнес-уровне и страстно увлечены тем, чтобы люди были настроены и стремились к единой цели.
- У вас есть опыт управления крупными кросс-функциональными инициативами (в таких широких областях как проектирование, маркетинг, контент, право и т.д.). С использованием Agile или нет. Некоторые из лучших лидеров, которых я встречал, имели за спиной опыт крупных провалившихся проектов — они преуспели, потому что отлично знали, как не надо делать проекты.
- Вы гибки и прагматичны в выборе подходов и процессов и способны самостоятельно выбрать модель и подход, наиболее подходящий в конкретной ситуации.
- У вас глубокое понимание и опыт Agile и Lean-мышления, а также есть опыт работы с конкретными фреймворками и подходами, такими как Scrum, Kanban, Lean Startup и Непрерывные Поставки.
- Вы не допускаете каскадного управления проектами, но понимаете, что Agile не означает Отсутствие Планирования или Архитектуры.
- Вы знаете, как обеспечивать сильное лидерство и руководство, не замыкая все на себе.
- Вы знаете, как вдохновлять людей и направлять их движение к высшей цели.
- Вы понимаете, что люди — это люди, а не просто ресурсы, и что фокус и мотивация значат намного больше, чем человеко-часы.
- Вы понимаете, что люди работают гораздо эффективнее и с большей мотивацией, когда перед ними проблемы, требующие решения, а не задачи, требующие простого выполнения.
- Вы знаете, как стимулировать людей общаться между отделами или через другие организационные барьеры. Политика вас не пугает.
- Вы знаете, как запустить самоорганизацию в крупных кросс-функциональных инициативах, и как на практике работает вытягивающее планирование.
- Вы знаете, как сделать важное видимым.
- Ваш опыт позволяет вам отмечать слабые места и вскрывать их.
- Вы осознаете важность планов, но понимаете также, что планы — это инструмент, а не цель, и они должны меняться по мере приобретения опыта.
- Вы понимаете, что неопределенность неразрывно связана с инновационными проектами, и лучший способ управлять ей — иметь быстрый цикл обратной связи, а не детальные планы на годы вперед.
- Вы считаете, что люди должны отвечать за свои действия, а не за конечный результат. Вы вознаграждаете людей за приобретение опыта, а не наказываете за провалы.
Итоги
Надеюсь, эта статья поможет вам увеличить процент успешно внедренных крупных мультикомандных инициатив. Но не забывайте, масштабирование — это крайняя мера. Масштабирование проходит болезненно вне зависимости от того, как вы его делаете, поэтому сохраняйте все настолько маленьким, насколько это возможно (но не меньше, чем…).
Большое спасибо Алистеру Коберну, Мэри и Тому Поппендик, Андерсу Хаугето, и еще целой команде из Spotify и Crisp, помогавшим улучшать эту статью. Для меня большая честь иметь таких замечательных советчиков!
Я описал свое личное мнение относительно того, кто такой Agile-лидер (или кем он должен быть). Кто-то может со мной не согласиться, и это нормально. Я всегда рад отзывам, хоть и не всегда успеваю на них отвечать.
Рекомендую к прочтению (существует масса материалов об Agile-лидерстве, но здесь приведено то, что я сам прочитал и мне понравилось):
- Becoming a Technical Leader (превосходная книга на все времена от Джерри Вайнберга).
- Management in Mayberry (лучшая статья о лидерстве, которую я читал).
- Lean-Agile leaders (из SAFe).
- Agile-манифест разработки программного обеспечения (вы недавно в Agile? Начните с этого, это даст вам исторический контекст).
- Declaration of Interdependence (манифест для проектных лидеров).
- Быстрая разработка программного обеспечения (глубокая книга от Алистер Коберн).
- Драйв! Что на самом деле нас мотивирует (смотреть всем лидерам!).
- …или просто наберите в поисковике «What is an Agile Leader» и вы найдёте множество интересных статей, в которых написано примерно то же, что и в этой. Заставляет задуматься, и чего это я так заморачиваюсь?
