Чаптер agile что это
Масштабирование Agile в Spotify
Масштабирование Agile с помощью кланов, отрядов, отделов и гильдий
Авторы : Henrik Kniberg & Anders Ivarsson
https://dl.dropbox.com/u/1018963/Articles/SpotifyScaling.pdf
(Tribe – клан, Squad – отряд, Chapter – отдел, Guild – гильдия)
Всегда непросто иметь дело с несколькими командами в организации, занимающейся разработкой продуктов!
Один из самых впечатляющий примеров, с которым мы столкнулись – это музыкальный сервис Spotify, в котором был распространен Agile, несмотря на то, что компания разрослась до 30 команд, которые находились в трех городах.
Spotify – это замечательная компания, которая преобразовала всю музыкальную индустрию. Он существует всего 6 лет, при этом у нее уже более 15 миллионов активных пользователей и более 4 миллионов платежей. Сам по себе продукт можно охарактеризовать как «магический музыкальный плеер, в котором вы можете найти и проиграть любую песню в мире».
Итак, как же это организовано?
Мы уже рассказывали об этом на конференциях и участвовали в дискуссиях на эту тему. Многие люди хотят знать, как компания с сотнями разработчиков работает по agile. Поэтому мы решили написать статью.
Замечание: Spotify быстро развивается (как и любая хорошая agile компания). Эта статья показывает, как мы работаем сейчас, но путь еще не пройден до конца. К тому времени, как вы прочитаете об этом, многое уже изменится.
Отряды
Основная единица разработки в Spotify – это Отряд (Squad).
Отряд похож на Scrum команду, она создана так, чтобы было ощущение мини-startup-а. Весь отряд сидит вместе. У них есть все навыки и инструменты для проектирования, разработки, тестирования и сдачи продукта. Они представляют собой самоорганизующуюся команду, и сами определяют, как им лучше работать. Одни используют спринты Scrum, другие используют Kanban, некоторые используют смесь этих подходов.
У каждого отряда есть долгосрочная миссия, такая как создание и улучшение Android клиента, создание радио Spotify, масштабирование серверной части, или создание платежных решений. Картинка ниже показывает, как разные отряды принимают ответственность за разные части пользовательского опыта взаимодействия.
Поощряется применять в отрядах принципы Lean Startup, такие как MVP (minimum viable product – минимальный жизнеспособный продукт) и подтвержденное обучение (validated learning). MVP означает частые и ранние релизы, а подтвержденное обучение означает использование метрик и A/B-тестирования, чтобы понять, что действительно работает, а что не работает. Все это суммируется слоганом: «Подумайте об этом, постройте это, поставьте это и измените это».
У каждого отряда на длительное время есть своя миссия и своя часть продукта, поэтому члены отряда действительно становятся экспертами в своей области. Например, как построить классное радио.
У большинства отрядов есть свое рабочее пространство, включающее письменные столы, гостиную и «личную» комнату. Почти все стены – это доски. Мы никогда не видели лучшего пространства для взаимодействия!
Да, это акула парящая в воздухе, совершенно нормально.
Чтобы стимулировать обучение и инновации, отряды поощряют к тому, чтобы примерно 10% времени отводилось на «хакерские дни». Во время «хакерских дней» люди делают что им хочется, обычно они проверяют новые идеи и обмен мнениями со своими товарищами. У некоторых команд – один хакерский день каждую вторую неделю, другие собирают свои дни в «хакерскую неделю».
Хакерские дни – это не только прекрасное времяпровождение, это также отличный способ узнавать о современных инструментах и практиках, а иногда это ведет к важным инновациям в продукте!
У отряда нет формально назначенного лидер а, но есть product owner. Product owner отвечает за приоритезацию работ команды, но он не вовлекается в то, как выполняется сама работа. Product owner-ы разных отрядов взаимодействуют друг с другом, чтобы поддерживать высокоуровневый документ, который показывает, куда же движется Spotify как единое целое. И каждый product owner отвечает за поддержку баклога продукта для своего отряда.
В отряде также есть agile коуч, который помогает двигаться вперед и улучшать то, как работает команда. Коучи проводят ретроспективы, совещания по планированию спринтов, проводят коучинг 1-на-1, и т.д.
В идеале каждый отряд полностью автономен, напрямую общается со своими заинтересованными лицами, и у него нет блокирующих зависимостей от других отрядов. Это мини-startup. Но с 30 командами – это не просто! Мы прошли длинный путь, но многие улучшения еще впереди.
Чтобы помочь в этом, мы запустили процедуру ежеквартального исследования для каждого отряда. Так мы сможем сконцентрировать наши усилия и понять, какая организационная поддержка нужна. Вот как выглядит такое исследование, для пяти отрядов в клане :
Кружочки показывают текущее состояние, стрелочки показывают тенденцию. Например, мы видим, что три отряда отчитываются о проблемах вокруг поставки и что ситуация не улучшается – эта область требует срочного внимания! Также видно, что у отряда 4 есть проблемы с agile коучем, но ситуация улучшается.
Клан можно представить как “инкубатор” для мини-стартапов-отрядов, у них большая степень свободы и автономии. У каждого клана есть лидер , который отвечает за создание наилучших условий существования отрядов внутри клана. Отряды клана физически находятся в одном офисе, рядом друг с другом, и расположенные рядом гостиные способствуют общению между отрядами.
Размер клана основан на концепции «Числа Данбара», которая говорит о том, что большинство людей не могут поддерживать социальные отношения более чем со 100 людьми или около того (для групп, которые интенсивно борются за выживание это число может быть значительно больше, но это не относится к Spotify, верите вы этому или нет…). Когда группы становятся слишком большими, все больше появляется таких вещей как ограничивающие правила, бюрократия, политика, дополнительные уровни управления, и другие ненужные вещи.
Поэтому кланы сконструированы так, чтобы в них было меньше 100 человек.
В кланах регулярно проводятся собрания, неформальные встречи, где люди показывают, над чем они работают, что они поставили и что может быть интересно другим из их нынешнего опыта. Проводятся демо работающего программного обеспечения, новых инструментов и методов, крутых проектов хакерского дня, и т.д.
Зависимости между отрядами
Во множестве отрядов всегда есть зависимости. Зависимости – это не обязательно плохо. Иногда отрядам нужно работать вместе, чтобы создать что-то действительно необыкновенное. Тем не менее, наша цель – сделать отряды максимально автономными, особенно нужно минимизировать зависимости, которые блокируют или замедляют работу отряда. Мы регулярно опрашиваем отряды, от каких других отрядов они зависят, и до какой степени эти зависимости блокируют или замедляют работу отряда. Вот пример:
Ниже мы обсудим, как убрать проблемные зависимости, особенно блокирующие, а также зависимости между кланами. Часто это ведет к переприоритезации, реорганизации, архитектурным изменениям или техническим решениям.
С помощью этого исследования также можно увидеть шаблоны зависимостей. Например, то что все больше отрядов замедляются из-за зависимости от отряда операций. Мы используем простой граф, чтобы отследить, как разные типы зависимостей увеличиваются или снижаются со временем.
В scrum есть практика «scrum of scrum», синхронизирующее совещание, где собираются по одному от каждой команды для обсуждения зависимостей. Обычно мы не используем «scrum of scrum» в Spotify, в основном потому что большинство отрядов достаточно независимы, и такие координационные совещания просто не нужны. «Scrum of scrum» проводится, если возникает такая потребность. Например, недавно у нас был большой проект, в котором требовалась скоординированная работа множества отрядов на несколько месяцев.
Чтобы это работало, у команд было ежедневное синхронизационное совещание, на котором они идентифицировали и разрешали зависимости между отрядами, и использовали доску с заметками, чтобы отслеживать неразрешенные зависимости.
Во многих компаниях основной источник зависимостей – это взаимодействие разработки и операций. В большинстве компаний, с которыми мы работали, существует связка «разработка-операции», и связанные с этим задержки и трения.
В Spotify есть отдельная операционная команда, но их работа – это не делать релизы для отрядов, их работа – давать отрядам поддержку, с тем что отряды сами выпускали релизы: поддержка в форме инфраструктуры, скриптов, процедур. Они как бы «строят дорогу к выпуску продукта».
Это неформальное, но эффективное взаимодействие, основанное на личном общении, а не на детальной документации.
Отделы и гильдии
Во всем есть обратная сторона, и потенциальная обратная сторона полной автономии – уменьшение экономии. Может быть, что тестировщик в отряде A сражается с проблемой, которую уже решил на прошлой неделе тестировщик из отряда B. Если бы можно было собрать всех тестировщиков из разных отрядов и кланов, они могли бы делиться знаниями и создавать инструменты для пользы всех отрядов.
Если бы каждый отряд был полностью автономен и не общался бы с другими, то зачем вообще их объединять в одну компанию? Spotify можно было бы поделить на 30 разных мелких компаний.
Вот почему у нас есть Отделы (Chapters) и Гильдии (Guilds). Это клей, который держит всю компанию вместе, это дает нам некоторую экономию, не жертвуя автономией.
Отдел – это маленькая семья людей со сходными навыками, работающих в одной сфере компетенции, внутри клана.
Каждый отдел регулярно встречается, чтобы обсуждать их область экспертизы и их специфические проблемы. Например, отдел тестировщиков или отдел web разработчиков.
Руководитель отдела – линейный менеджер для членов этого отдела, с традиционными обязанностями, такими как развитие людей, определение зарплат и т.п. Однако, руководитель отдела- это тоже часть отряда, и также вовлечен в ежедневную работу, что помогает ему оставаться в контакте с реальностью.
Реальность всегда хуже, чем красивые картинки, вроде той, что выше. Например, члены отдела не распределены равномерно по отрядам: в некоторых отрядах много web разработчиков, а в других их нет совсем. Но картинка даст вам общую идею.
Гильдия – это более органичное и более масштабное «сообщество по интересам», группа людей, которые хотят поделиться знаниями, инструментами, кодом и практиками. Отделы всегда внутри клана, а гильдия охватывает специалистов всей организации. Вот некоторые примеры: гильдия web технологий, гильдия тестирования, гильдия agile коучей, и т.д.
Часто гильдия включает все отделы, работающие в этой области. Например, гильдия тестирования включает всех тестировщиков из всех отделов тестирования, но вообще говоря присоединиться к гильдии может любой заинтересованный.
В каждой гильдии есть «координатор гильдии», который координирует работу гильдии :0)
Пример работы гильдии, который у нас был недавно, – «Неконференция web гильдии», событие, на котором все web разработчики Spotify собрались в Стокгольме, чтобы обсудить проблемы и решения, относящиеся к их области.
Другой пример – гильдия agile коучей. Коучи разбросаны по всей организации, но они постоянно обмениваются знаниями и регулярно встречаются, чтобы взаимодействовать в том, что касается высокоуровневых улучшений, которые мы отслеживаем на доске улучшений.
Минуточку, разве это не матричная структура?
Да. Хорошо, что-то в этом роде. Однако, это другой тип матрицы, в отличие от того, к чему привыкло большинство из нас.
Во многих матричных организациях люди с похожими навыками собраны в функциональные отделы, и «выделяются» на проекты, и «отчитываются» функциональному менеджеру.
В Spotify редко делается что-либо подобное. Наша матрица направлена на поставку.
То есть, люди собраны в стабильные отряды, в которых сотрудники с разными навыками взаимодействуют и самоорганизуются для поставки хорошего продукта. Это вертикальное измерение в матрице, и оно основное, люди физически сгруппированы так и так они проводят большую часть своего времени.
Горизонтальное измерение – для обмена знаниями, инструментами и кодом. Работа руководителя отдела – содействовать и поддерживать это.
Это похоже на модель «профессор и антрепренер», рекомендованную Mary и Tom-ом Poppendieck. Product Owner – «антрепренер» или «чемпион по продукту», который фокусируется на поставке отличного продукта, а руководитель отдела – это «профессор» или «лидер по компетенции», который фокусируется на техническом мастерстве.
Между этими ролями существует здоровое напряжение, поскольку антерпренер хочет ускориться и срезать углы, тогда как профессор хочет замедлиться и построить все правильно. Нужны оба аспекта, поэтому напряжение «здоровое».
Что насчет архитектуры?
Технология Spotify ориентирована на сервисы. У нас более 100 разных систем, и каждая может поддерживаться и устанавливаться отдельно. Сюда включаются бэкэнд сервисы, такие как управление плейлистом, поиск или оплата, и клиенты, такие как iPad плейер, специфические компоненты,такие как радио, или секция «Что нового?»музыкального плейера.
Технически, любой может редактировать любую систему. Поскольку отряды – это эффективно функционирующие команды, им нужно модифицировать множество систем, чтобы выпустиь новую фичу.
Риском для этой модели является то, что архитектура системы будет похожа на непонятно что, если никто не фокусируется на целостности всей системы.
Чтобы справиться с этим риском, у нас есть роль «System Owner». У каждой системы есть system owner, или пара system owner-ов (мы поощряем парность). Для критичных систем system owner – это Dev-Ops пара, один – со стороны разработки, а другой – со стороны операций.
System owner – это человек, к которому нужно идти по любым техническим или архитектурным вопросам, связанным с его системой. Он является координатором и направляет людей, которые вносят изменения в код системы, чтобы быть уверенными в том, что они не столкнуться друг с другом. Он фокусируется на таких вещах как качество, документация, технический долг, устойчивость, масштабируемость и процесс релиза.
System Owner – это не узкое место и не «архитектор башни из слоновой кости». Он не должен лично принимать все решения, или писать весь код или делать поставлять все релизы. Это обычный член отряда или руководитель отдела, у которого есть обычные ежедневные обязанности, кроме владения системой. Однако, время от времени, он будет брать «День
system owner-а» и выполнять домашнюю работу в своей системе. Обычно мы стараемся, чтобы время на поддержку своей системы было не больше 10% рабочего времени. Однако это может сильно отличаться от системы к системе.
У нас также есть роль главного архитектора, это человек, который координирует работу по высокоуровневым архитектурным вопросам, которые затрагивают множество систем. Он ревьюирует разработку новых систем, чтобы избегать общих ошибок, и чтобы они были созданы в соответствии с нашим архитектурным видением. Результатом его ревью является предложения и рекомендации, финальное решение по дизайну системы принимает отряд, который строит ее.
Как все это работает?
Компания Spotify выросла очень быстро – более чем за 3 года мы выросли с 30 до 250 человек. Эта модель масштабирования – с отрядами, кланами, отделами и гильдиями – была постепенно введена в течение последнего года, поэтому люди все еще привыкают к ней. Но, судя по опросам и ретроспективам, эта модель масштабирования работает достаточно хорошо!
Несмотря на быстрый рост, удовлетворенность сотрудников постоянно растет: в апреле 2012 она составляла 4.4 из 5 возможных.
Однако, как это бывает с любой растущей организацией, сегодняшние решения рождают завтрашние проблемы. Поэтому следите за обновлениями, история еще не окончена :o)
Agile: сокращаем разрыв между теорией и практикой
Что делать, если сотрудники не понимают (или не хотят понимать) «этот ваш Agile» на этапе внедрения.
Agile – одна из передовых тенденций последних лет. На эту тему уже написано много статей и учебников. Как правило, в них собраны теоретические выкладки относительно того, что такое Agile, как надо работать в условиях Agile и как это помогает сократить «time-to-market» и повысить конкурентоспособность компании.
Однако вряд ли можно найти компанию, в которой внедрение Agile, как и внедрение любого новшества, прошло (или еще проходит) гладко, т. е. прямо так, «как написано в учебниках». И одна из основных причин, как это часто бывает, кроется в зачастую неправильном понимании сотрудниками новых подходов. Или, что не менее распространено, в нежелании их понимать.
В настоящей статье я хочу поделиться своими наблюдениями и обратить внимание на основные моменты, связанные с выстраиванием понимания новой методологии у сотрудников, на которые необходимо обращать внимание при внедрении Agile-методологии в контексте следующих аспектов:
Итак, давайте посмотрим, что заложено в принципах Agile по каждому из данных пунктов, и что может формироваться в головах ваших сотрудников, если вовремя не донести до них правильное толкование и важность следовать этим толкованиям.
Дебоссинг
Идея Agile. Спустить вниз (на уровень команд) полномочия по принятию решений и развитию продуктов, на верхнем уровне менеджмента оставить функции по стратегическому развитию и финансовому управлению компанией.
Руководители же со своей стороны должны развить в себе hard skills по созданию и развитию продуктов для лучшего понимания сотрудников и для общения с ними на одном языке.
Отношение сотрудников. В нашей стране все еще чувствуются отголоски советского периода, когда пропаганда гласила, что самые главные люди – это трудящиеся (в контексте Agile – программисты и аналитики), а руководители – нахлебники, эксплуататоры и пр., которые забирают себе в карман львиную долю дохода ни за что. И поэтому, когда трудящиеся слышат про дебоссинг, то в их глазах сразу же возникает картина, что из руководства должен остаться только руководитель компании (а еще лучше, чтобы не было и его).
Однако на практике в ходе внедрения Agile руководители, разумеется, никуда не деваются, и невыполненное «обещание» дебоссинга разочаровывает сотрудников.
Как исправить / не допустить: Во-первых, я советую вообще не использовать термин «дебоссинг» при внедрении Agile. Он действительно имеет под собой семантическую подоплеку «избавления от руководителей», а Agile в реальности не требует такого избавления. Agile говорит о том, что не от руководителей надо избавляться, а наоборот: сотрудники должны подняться ближе к руководителям и взять часть их функций на себя (в первую очередь, функций по оперативному управлению продуктами и принятию решений по развитию продукта), а руководители должны слегка спуститься на уровень сотрудников и развить в себе hard skills. Как к этому прийти? Стандартными способами: через обучение, через боль, через ошибки, при этом приходится без жалости увольнять тех, кто не готов брать на себя дополнительную ответственность, а также уделять особое внимание наличию данных компетенций при найме новых сотрудников. «Просто хорошие» программисты и «просто хорошие» аналитики в Agile не востребованы: нужны хорошие программисты и аналитики с развитыми soft skills, готовые работать над продуктом самостоятельно. Так же, как и просто хорошие руководители, не обладающие предметными знаниями, в Agile тоже не востребованы.
Гибкость
Идея Agile. Идея гибкости отражена на самом верхнем уровне в основополагающем документе Agile – манифесте.
В нем есть следующие пункты:
О чем это говорит? О том, что нужно идти маленькими итерациями развития продукта, идти в первую очередь от потребностей клиентов, выводить MVP (minimum value product – минимально жизнеспособный продукт), постоянно совершенствовать продукт с учетом мнения клиентов и изменяющихся обстоятельств, причем совершенствовать «без оглядки на документацию» и без лишнего формализма.
Отношение сотрудников. «Работающий продукт важнее исчерпывающей документации» – отлично! Нет и не может быть никаких ТЗ! А значит, не может быть никаких обязательств: что успели сделать за спринт / суперспринт, то и показываем, то и выводим в пром.
«Готовность к изменениям важнее следования первоначальному плану» – еще лучше! Берем в работу любой новый чих, старые требования и договоренности отодвигаем (мы же должны продемонстрировать готовность к изменениям) и говорим, что их не выполнили, т. к. вскрылись новые обстоятельства и поступили новые требования!
При таком подходе никаких целей и стратегии быть не может (мы же должны оперативно реагировать на изменчивость клиентов, в число которых входят и внутренние контрагенты). А значит, не должно быть никакого контроля выполнения целей – все же постоянно меняется.
Как исправить / не допустить. К чему приводит такое отношение, вполне понятно:
Тут важно понимать, что все требования клиентов учесть невозможно (да и не нужно), и поэтому не надо буквально воспринимать посыл «Готовность к изменениям важнее следования первоначальному плану» как руководство к действию при каждой коммуникации с клиентом. Сосредотачиваться надо не на этом, а на том, чтобы регулярно с небольшой периодичностью выпускать новые версии продукта с учтенными критическими (а не всеми!) требованиями.
Хорошим (но сложным) подходом, который может обезопасить команду от неправильного толкования Agile-гибкости, может быть подход, когда оценка и премирование команды напрямую зависит от показателей удовлетворенности клиентов (NPS, CSI или аналогов) и/или от бизнес-показателей, отражающих вклад команды в прибыль компании (прибыль от продукта, доля рынка компании по данному продукту и пр.). В этом случае происходит перелом в мышлении сотрудников, и они начинают отказываться от бездумного подхода по учету всех подряд требований: остаются только требования, влияющие на приписанные к команде показатели.
Работающие вместе команды из бизнеса и ИТ
Идея Agile. Данная идея тоже отражена в манифесте Agile:
Отношение сотрудников. Данные пункты манифеста Agile расслабляют многих сотрудников (либо особо ленивые и хитрые сотрудники начинают использовать их в своих целях). Вместо того, чтобы включать голову и думать самим над функционалом продукта и способом его реализации (в т. ч. с учетом всевозможных архитектурных и других ограничений), все активно начинают «взаимодействовать» и «сотрудничать» друг с другом. В условиях open-space это может превратиться в сущий ад: в течение рабочего дня все друг друга дергают, спрашивают, ставят в копии писем и пр. В течение дня через человека может проходить до сотни, а то и больше, электронных писем (т. е. в среднем человек может получать новое письмо каждые 5 минут), человек может чуть ли ни весь день принимать участие в различных (не всегда эффективных) встречах и совещаниях и пр. В результате каждый занят не своей работой, а реагированием на входящие коммуникации. И получается, что самое эффективное для работы время – это нерабочее время, когда коммуникационные страсти утихают и можно сесть и спокойно, сосредоточенно поработать.
Как исправить / не допустить. Я не говорю о том, что коммуникации надо полностью исключить и ни в коем случае никому ни с кем не взаимодействовать. Нет, конечно же, без взаимодействия и общения никакой командной работы не будет. Но эти взаимодействия должны быть осознанными и качественными. Один из способов повышения качества взаимодействий является внедрение инструментов Time-management. И мне представляется, что при переходе на Agile руководство должно особое внимание уделить внедрению и популяризации Time-management. Количество коммуникаций при переходе на Agile возрастает в десятки или даже сотни раз и без соответствующего инструментария Time-management в новых условиях просто не выжить. А учитывая, что во время коммуникаций, встреч и совещаний (количество которых при переходе на Agile тоже увеличивается) время тратится кратно количеству участников (1 час неэффективного совещания 8 человек – это потерянные 8 человеко-часов, или 1 человеко-день), критичность необходимости внимания к данному вопросу просто зашкаливает.
Agile-офис (пуфики, пространства для общения и пр.)
Идея Agile. Особые требования к Agile-офису ни в каких описаниях Agile, как правило, не встречаются. Иными словами, как такового критерия «Agile-офис» для перехода на Agile-методологию нет. Однако складывается практика и традиция, что для Agile нужен какой-то свой особый офис, и старые классические офисные пространства для Agile не то, чтобы не подходят, но, как минимум, снижают эффективность использования новой методологии. Обычно новые Agile-офисы ассоциируются с творческой атмосферой, большими зонами open-space, пуфиками, кофе-пойнтами, зонами для проведения Agile-церемоний (демо, ретро, стенд-ап) и большим количеством переговорных комнат и зон для проведения «быстрых» встреч.
Отношение сотрудников. Нельзя сказать что это относится ко всем сотрудникам, но ко многим – наверняка: оказавшись в атмосфере такого нового модного офиса, сотрудники расслабляются, живут в атмосфере вольности, не чувствуют никаких корпоративных рамок, на официальных Agile-церемониях (и даже встречах) просто «разваливаются» в пуфиках, ходят в какой попало одежде (прикрывая это модной шуткой, что «люди в дорогих костюмах и галстуках выглядят успешными, пока не выясняется, что они работают на людей в джинсах и футболках»), думают «как же это круто, что у нас офис как Google / Apple / Yandex / Facebook», а не о том, как выполнять свою работу, и пр.
Ожидания некоторых руководителей. Но не менее страшным и опасным является неправильное отношение руководителей и их завышенные ожидания от новых офисов. Некоторые руководители, также ассоциируя новый офис «с офисом как в Google» / «как в Apple» / «как в Yandex» / «как в Facebook» и пр., начинают считать, что похожий офис – это достаточное условие, чтобы компания стала такой же (ну или почти такой же), как и ведущие ИТ-гиганты. Но офис – это только оболочка. Поэтому не стоит думать, что успех Google, Apple, Yandex, Facebook и пр. компаний кроется только в офисе. Наверняка там есть что-то еще, что позволило им добиться таких высот (например, система управления, выстроенные процессы, корпоративная культура и пр.).
Как исправить / не допустить. Все банально – не надо давать вольности в дресс-коде, в поведении, в корпоративной этике и культуре при переходе на Agile. Не важно, Agile у вас в компании или нет, элементарные правила поведения (в т. ч. и офисные) никто не отменял.
Что же касается руководителей, то не надо жить в иллюзии, что без ваших усилий по выстраиванию системы управления, внутренних процессов, правил, корпоративной культуры и пр. сотрудники сами организуются, будут вести себя соответствующе и давать соответствующий результат. Этого не будет. Руководитель должен продолжать быть руководителем и выполнять свои базовые функции руководителя, даже в формате Agile.
Матричная оргструктура: владелец продукта и чаптер-лидер
Идея Agile. Владелец продукта занимается развитием продукта, ведением бэк-лога и постановкой задач команде. Чаптер-лидер – поставщик ресурсов и компетенций в команде: занимается подбором людей и развитием команды.
Отношение чаптер-лидеров. Многие чаптер-лидеры (как правило, это бывшие начальники отделов в ИТ) продолжают «по привычке» ставить задачи «своим» людям, контролируют их, управляют приоритетами, закрытием дефектов разработанного программного кода и пр. А сотрудники, в свою очередь, тоже по привычке идут не к владельцу продукта, а к чаптер-лидеру, чтобы что-то проэскалировать, приоритезировать и пр. В результате получается, что чаптер-лидер не выполняет свои прямые обязанности (или выполняет их по остаточному принципу), вместо этого частично выполняет обязанности владельца продукта и в итоге не понятно кто отвечает за принятые по тем или иным вопросам решения.
Как исправить / не допустить. Необходимо как можно раньше (т. е. с самого начала перехода на Agile) аккуратно расписать, формализовать и привязать KPI и цели к системе стимулирования так, чтобы чаптер-лидеры отвечали только за HR-показатели по своему чаптеру:
При этом понятно, что на первых порах чаптер-лидер может (и, скорее всего) будет оставаться неким советником для команды, который может подсказывать каким образом решать те или иные проблемы.
Наполнение и ведение бэк-лога
Идея Agile. В этой части Agile мало чем не отличается от обычного классического подхода – есть стратегия компании (стратегические цели) на несколько лет, они декомпозируются в четкие цели и задачи на год, год распадается на кварталы и т. д. В итоге с помощью декомпозиции необходимо дойти до бэк-лога с конкретными user-stories. Для удобства user stories можно группировать в эпики/фичи, которые должны быть привязаны к квартальным / годовым целям. Вроде бы все просто и понятно.
Реальность. В реальности удобного единого инструмента, показывающего связь стратегических целей и бэк-лога, просто нет (как его часто не и в классическом подходе – есть только кипа документации). Как правило, стратегические и годовые цели ведутся в одном месте, бэк-лог в виде user-stories в другом месте. И самое страшное в этом даже не то, что необходима ручная синхронизация содержаний в различных источниках. Ключевая проблема в том, что, выполняя user-stories в бэк-логе, команда не видит, как это влияет на «длинные» цели. Команда даже может и не подозревать / забывать, что их user-stories влияют на стратегические цели: ведь стратегические цели – это зона ответственности руководства компании. И сотрудник, приходя на работу и делая привычные ему ежедневные действия, и не думает, что он работает на высокоуровневые «длинные» цели, и по большому счету это означает, что он попросту не понимает, зачем он выполняет свою работу.
Как исправить. Частично проблему позволяет решить кастомизация настройки JIRA (или другого инструмента, в котором ведется бэк-лог): можно настроить даш-борды, показывающие прогресс команды не только в рамках спринта или суперспринта, но и в привязке к целям компании. Также полезно на каждой ретроспективе и/или на каждом планировании, чтобы церемония начиналась с того, что команда анализирует свой прогресс не в привязке к своему бэк-логу, а в привязке к целям компании.
Приоритезация бэк-логов, PI-planning
Идея Agile. Как правило, Agile-команда существует в любой крупной компании не сама по себе и не одна. В компании, работающей по Agile, много таких команд и все они взаимозависимы: чтобы одной команде запустить свой функционал, ей надо, чтобы другая команда что-то сделала в части своего функционала. И таких зависимостей – бесчисленное множество.
Но если одна команда будет делать функционал в интересах другой команды, то ей придется «пожертвовать» частью своих целей и планов – отодвинуть их на более поздний срок.
Как быть? Опять возвращаемся к манифесту Agile, который говорит, что «Люди и взаимодействие важнее процессов и инструментов» и «Сотрудничество с заказчиком важнее согласования условий контракта». Если говорить кратко и прямо – надо договариваться и обсуждать с заказчиком.
Реальность. Бывает, что в реальности происходит следующее: проводится огромная или не очень огромная встреча по вопросам синхронизации (например, Portfolio market place / Project Increment Planning / Product Owner Sync или какая-то еще), на встрече выявляются зависимости, но никаких решений не принимается – все расходятся с «домашним заданием» обсудить друг с другом и с руководством, что и в какие сроки кто кому может сделать. После этой встречи все погружаются в свои текущие дела. От инициаторов встречи начинают приходить напоминания, что «ждем от всех итоги домашнего задания». Под натиском этих напоминаний многие начинают встречаться, но безрезультатно – у всех свои приоритеты и свои задачи. Количество встреч и коммуникаций еще больше зашкаливает, они в итоге ни к чему не приводят и все решается путем обычных эскалаций с привлечением руководства.
Как исправить / не допустить. Во-первых, такие мероприятия по синхронизации необходимо проводить в течение нескольких дней, а не в течение одного дня. Синхронизировать большое количество команд за один день невозможно и не стоит строить на этот счет иллюзии. Причем понятно, что многим руководителям жалко тратить на такие встречи больше одного дня, т. к. они считают, что это потеря времени. Но уверяю вас, что наспех проведенная некачественная синхронизация в дальнейшем украдет у вас и ваших сотрудников гораздо больше времени, чем вы «сэкономите», если уместите ее в один день.
Во-вторых, такие мероприятия должны жестко фасилитироваться, чтобы они не превратились в балаган и не перешли в режим «как же здорово мы тут собрались, давайте просто поговорим».
В-третьих, уходить с таких мероприятий необходимо без «домашних заданий» договориться о чем-то – договариваться необходимо именно на этих мероприятиях, и все договоренности необходимо фиксировать в конце мероприятия протоколом (который необходимо разослать всем участникам и руководству).
В-четвертых, по итогам таких мероприятий должны пересматриваться и верифицироваться стратегические / годовые цели. Очень часто происходит следующее: в ходе синхронизации выявлены зависимости, бэк-логи скорректированы, но цели не пересмотрены. Хотя, когда формулировались цели, о зависимостях еще не было известно, и никаких договоренностей между командами не было. В итоге, когда наступает срок по исполнению целей, становится понятно, что они не будут выполнены (со всеми вытекающими последствиями).
Ну и напоследок: часто в новостях встречаются свидетельства заблуждения многих компаний (особенно государственных), что они внедрили Agile, т. к. собрали вместе людей из разных подразделений, эти люди сидят рядом и работают над решением одной проблемы, а прогресс отслеживают на Scrum-доске.
Но нет, это лишь обычные рабочие группы из представителей разных подразделений. А Agile – это совсем другое. Agile – это когда происходит максимально быстрый вывод MVP в пром с последующим быстрым итерационным обновлением продукта. Доски, бэк-логи, совместное размещение и прочее – это инструменты Agile, которые можно применять и просто в обычной деятельности. Но если вы их применяете, а Agile-результата нет, то называть это Agile нельзя.
Поэтому обращайте в первую очередь внимание на то, что у вас получается в результате деятельности, а не на то, какие инструменты вы используете.