Текст книги "Agile, который работает. Как правильно трансформировать бизнес во времена радикальных перемен"

Определение последовательности перехода

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

Некоторые компании, столкнувшись с серьезными стратегическими угрозами и нуждаясь в радикальных переменах, провели в некоторых подразделениях масштабные Agile-преобразования «одним махом». Среди них была компания ING, которую мы упоминали во введении. Барт Шлатман, прежний операционный директор, размышлял об этом периоде в интервью:

«Я помню январь 2015 года, когда мы объявили, что все сотрудники в штаб-квартире будут переведены на “мобильность”; фактически это означало, что они остались без работы. Мы попросили каждого вновь подать заявление о приеме на работу в новой организации. Процесс отбора был интенсивным, и мы больше внимания уделяли культуре и мышлению кандидатов, а не их знаниям или опыту. Каждый из наших сегодняшних 2 500 сотрудников прошел отбор, и почти 40 % из них занимают не ту должность, которую занимали раньше. Да, мы расстались с теми, у кого были хорошие знания, но отсутствовало правильное мышление; ведь знания можно восполнить, если у человека есть способности».^[3]

Понятно, что Барт несколько приукрашивает то, как все происходило. Но вы представляете, какой ужас и боль эта инициатива должна была вызвать у персонала? Зачем начинать с такого рискованного и дорогостоящего шага? При подобном подходе акцент делается скорее на экономии затрат, а не на инновациях и росте. Внедрение новых методов, когда люди опасаются за свои рабочие места, а 40 % из них получают новую должность, – это довольно драматичное начало проекта. Уже не говоря о том, что такие действия команды руководителей прямо противоречат ценностям Agile.

Радикальные переходы – вообще дело трудное. Нужна абсолютная приверженность руководства, восприимчивая культура, достаточное число талантливых и опытных практиков Agile, чтобы укомплектовать сотни команд, не истощая другие направления деятельности, и предписывающая техническая документация для согласования подходов всех участников. Подобные переходы также требуют высокой устойчивости к риску, наряду с планами на случай непредвиденных срывов. Компаниям, которым этого не хватает, скорее следует внедрять Agile в ходе последовательных шагов, когда каждое подразделение соотносит реализацию со своими возможностями. Имея начальный вариант видения и упорядоченный бэклог, руководители высшего звена могут создать начальную группу Agile-команд, собрать данные о создаваемой ими ценности и ограничениях, с которыми они сталкиваются, а затем решить, следует ли делать следующий шаг, и если да, то когда и как. Более подробно вопрос «как далеко и как быстро» будет рассмотрен в Главе 3.

Планирование взаимозависимостей

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

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

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

Тем не менее, ни одну Agile-команду нельзя запускать в работу до тех пор, пока она не будет готова. Готовность не означает детального планирования и гарантированного успеха. Это означает, что команда:

• сосредоточена на крупных возможностях развития бизнеса, когда многое поставлено на карту;

• отвечает за конкретные результаты;

• уполномочена работать автономно, руководствуясь четкими правами на принятие решений;

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

• привержена применению ценностей, принципов и практик Agile;

• имеет возможность тесно сотрудничать с клиентами;

• способна оперативно создавать прототипы и петли быстрой обратной связи;

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

Какой бы ни была скорость или конечная точка, результаты начнут проявляться быстро. Разве что для появления финансовых результатов может потребоваться некоторое время. Джефф Безос считает, что Amazon начинает получать дивиденды от большинства инициатив через 5–7 лет, но позитивные изменения в поведении клиентов и в решении проблем команды – это раннее свидетельство, что организация на правильном пути. В начале своей Agile-инициативы группа передовых технологий в компании 3M Health Information Systems создавала от восьми до десяти команд каждый месяц или два; через пару лет было создано и функционировало более девяноста команд. Лаборатория корпоративных исследовательских систем 3M (Corporate Research Systems Lab) начала работать позже, но за три месяца создала двадцать команд. «Внедрение Agile уже позволило ускорить поставки продуктов и выпустить бета-версию приложения на шесть месяцев раньше, чем первоначально планировалось», – рассказывает Тэмми Спэрроу, старший менеджер программ в 3M Health Information Systems. ^[4]

Согласование бюрократии и инноваций

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

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

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

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

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

Десять вопросов, которые следует задать при создании новых agile-команд

Масштабирование Agile – это всегда сложная задача. Следующие вопросы помогут вам правильно начать работу.

1. Как можно осмотрительно предоставить людям большую автономию и полномочия для принятия решений?

2. Следует ли большему числу сотрудников учиться создавать бэклоги, позволяющие расставлять приоритеты и устанавливать последовательность работ?

3. Как получать больше обратной связи от клиентов?

4. Как сотрудники могут сводить к минимуму количество незавершенной работы?

5. Можно ли использовать собрания команды с обзором проделанной работы для поиска более эффективных способов ее выполнения?

6. Повлияют ли на слаженность работы пятнадцатиминутные координационные собрания по утрам?

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

8. Как быстро получать обратную связь о результатах работы?

9. Где устранять малоценную работу?

10. Как использовать эксперименты и поэтапную, итерационную разработку?

Это позволяет людям, работающим в сложных системах, быстро начать, остановить или переориентировать деятельность в ответ на изменения или новые требования. Спринты действуют во многом подобно сцеплению автомобиля для синхронизации больших, медленно и быстро движущихся механизмов. Когда компания использует спринты, прорывным инновациям не обязательно быть пятилетними авантюрами, наводящими ужас на бюрократов; это короткие «броски», которые можно регулярно пересматривать и адаптировать. Точно так же трудоемкие мероприятия по планированию и финансированию не обязательно должны происходить в рамках ежегодных циклов, которые заставляют инновационные команды откладывать свои старты или отмену не оправдавших себя инициатив. Если разобрать длительный монолитный процесс планирования и бюджетирования на квартальные спринты, это сведет к минимуму время ожидания и повысит эффективность потока. Компании, скорее всего, могут найти возможности повышения гибкости не только в планировании и бюджетировании, но и в оценке эффективности, анализе бизнес-процессов, структурных изменениях, коммуникационных программах и многом другом.

Фреймворки для масштабирования Agile

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

К сожалению, у нас нет простого ответа. Существуют десятки Agile-фреймворков. Конечно, легче управлять командами, если все они используют одну и ту же разновидность Agile, но разве это необходимость? Могут ли некоторые команды использовать Scrum, в то время как другие используют Kanban, Экстремальное программирование (XP), Crystal, метод разработки динамических систем (DSDM) или какой-либо гибридный метод? Как всегда, истина кроется в балансе и компромиссах. С одной стороны, навязывать последовательность – значит пытаться внедрить бюрократию в Agile – а это скользкий путь. С другой стороны, существуют реальные затраты на повышение числа Agile-фреймворков. Это увеличивает расходы на обучение, растет сложность обмена людьми между командами, которая мешает распространению передового опыта внутри групп. Умножаются затраты на координацию и связь, а также усложняется планирование дорожных карт и сроков выпуска.

Выбор одного или двух подходов для отдельных Agile-команд относительно прост, и Scrum, скорее всего, будет в их числе. Для справки: Scrum Inc. и Scrum@Scale в настоящее время имеют партнерские отношения с Bain&Company. У Scrum в десять раз больше пользователей, чем у фреймворка Kanban, занимающего второе место. Scrum тестировался и совершенствовался десятками тысяч пользователей на протяжении более чем двадцати пяти лет. Это гибкий фреймворк, который часто и легко комбинируют с другими подходами, включая Kanban и XP. Есть отличные учебные материалы, а также множество инструкций по Scrum. Почти все программное обеспечение для управления проектами и все системы масштабирования исходят из того, что их пользователи будут работать в Scrum-командах.

Выбор структуры масштабирования – очень сложное дело. Масштабирование фреймворков началось только в 2010 году. Недавние опросы пользователей показывают, что четыре самых популярных фреймворка – это Scaled Agile Framework (SAFe), «Don’t know», Scrum of Scrum (он же Scrum@Scale) и «Внутренние методы» (Internally created methods).^[5] Другими словами, это пространство все еще открыто, и новые игроки продолжают появляться. Последние новички – это Модель Spotify, Disciplined Agile Delivery (DAD, Дисциплинированная гибкая разработка), Large Scale Scrum (LeSS, Scrum больших масштабов), Enterprise Scrum (Scrum на предприятии), Lean Management (Бережливое управление), Agile Portfolio Management (APM, Гибкое управление портфолио), Nexus и Recipes for Agile Governance in the Enterprise (RAGE, Рецепты гибкого управления на предприятии). Видите? Можно легко запутаться.

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

Scaled Agile Framework (SAFe)

SAFe официально запущен в 2011 году, и на момент выхода этой книги имеет шесть крупных печатных обновлений. Около 30 % компаний, масштабирующих Agile, утверждают, что они используют фреймворк SAFe. Это, безусловно, самый подробный и регламентированный подход. Тех, кто в первый раз заходит на сайт SAFe, может ошеломить объем и подробность доступных рекомендаций. (Поиск в Google показывает 2390 пронумерованных страниц на веб-сайте Scaled Agile Framework против 41 страницы для Enterprise Scrum.) SAFe опирается на прочную основу Scrum и предлагает предписания для четырех уровней масштабирования: команд, программ, больших решений и портфеля. Его основная идея заключается в том, что менеджеры должны разделить инновационную работу на потоки для создания ценности, ориентированную на потребности клиентов. В работе большинства потоков создания ценности участвуют от пяти до десяти Agile-команд (50—150 человек), все вместе они называются «релизный поезд». Если требуется больше команд, создаются дополнительные релизные поезда. SAFe вводит несколько новых позиций, включая менеджеров бережливого управления портфелем, владельцев эпиков (крупных этапов работы), архитекторов корпоративных приложений, архитекторов решений, менеджеров решений, инженеров по «поездам решений», менеджеров продуктов, системных архитекторов, инженеров по «релизным поездам» и владельцев бизнеса. SAFe также добавляет ряд событий и артефактов к масштабированию Scrum. Выпуск 2018 года (SAFe 4.6) был сосредоточен на укреплении пяти основных компетенций: бережливого Agile-лидерства, командной и технической гибкости, методов разработки программного обеспечения (известных как DevOps и релиз по потребности), разработки бизнес-решений и бережливых систем, а также бережливого управления портфелем (SAFe 5.0 запущен в январе 2020 года).

Сильные стороны SAFe – глубина и широта предписаний, учебные программы, общий взгляд на производительность за пределами уровня команды, привлекательность для руководителей, ориентированных на контроль, и способность координировать взаимозависимости между командами. SAFe отлично справляется с разработкой и управлением таксономией команд. Многих пользователей этого фреймворка привлекают процессы согласования и координации, такие как планирование приращения программы (или планирование Big Room), синхронизирующие команды каждые восемь-двенадцать недель. Слабые стороны SAFe – жесткость предписаний; ограниченная применимость к инновациям, выходящим за рамки разработки технологий и программного обеспечения; количество времени и затрат, необходимых для планирования и координации деятельности; количество нисходящей бюрократии, которая переносится на процессы масштабирования; недостаточное внимание к гармонизации таких функций поддержки и контроля, как управление персоналом, маркетинг и обслуживание клиентов.

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