ность их применения к собственным функциям. Приведенные ниже вопросы – один из способов помочь людям понять принципы 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 – жесткость предписаний; ограниченная применимость к инновациям, выходящим за рамки разработки технологий и программного обеспечения; количество времени и затрат, необходимых для планирования и координации деятельности; количество нисходящей бюрократии, которая переносится на процессы масштабирования; недостаточное внимание к гармонизации таких функций поддержки и контроля, как управление персоналом, маркетинг и обслуживание клиентов.