Области бизнес-гибкости

Кратко о том, что входит в agile сегодня

К гибким «методам управления» относятся, в частности, фреймворк Scrum и метод Kanban. Согласно исследованию Agile в России, Канбан сейчас занимает прочное второе место по популярности после Скрама (если не считать самопальных гибких подходов, которые любят изобретать в российских компаниях).

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

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

Kanban — это метод повышения качества сервиса: набор принципов и практик, которые делают сервис (или разработку продукта) более быстрым и лучше соответствующим ожиданиям потребителей.

Канбан отличается от Скрама по многим параметрам, в частности:

• имеет более широкую область применения (не только новые продукты, но и поддержка, операционка);
• в отличие от Scrum, внедряется постепенно (без одномоментного изменения текущих процессов) и более просто (без изменений оргструктуры, например);
• нацелен не только на ускорение, но и на равномерность процессов;
• имеет сильно отличающиеся от Скрама метрики, не требующие оценки трудоемкости задач (например, время прохождения задачи в системе);
• отличается отсутствием фокуса на самоорганизацию команды и отсутствием прямой связи Kanban-практик с Agile-ценностями (у Канбана есть свои ценности, многие из которых вполне согласуются с ценностями Agile, например: клиентоориентированность, сотрудничество, прозрачность).

Подробнее об этом см. в статье про отличия Kanban и Scrum.

Наиболее широко применяется первая из 6 практик Kanban: визуализация процесса — в том числе, с помощью так называемой Канбан-доски. Это физическая или электронная доска со стикерами, обозначающими разные задачи. В отличие от Скрам-доски с 3-мя столбцами, в Канбане принято визуализировать на доске каждый этап процесса, а также делить каждый столбец на две части — «в работе» и «готово к следующему этапу»:

Конечно, Scrum и Kanban — это далеко не единственные подходы, входящие в Agile. Но большинство других активно развивающихся сейчас гибких подходов касаются проблем другого уровня, нежели описанные в этой статье.

Речь про проблемы крупных организаций, которые вынуждены конкурировать со стартапами как по скорости вывода новых продуктов на рынок, так и по скорости принятия решений. Таким организациям помогают, в частности, подходы SAFe (Scaled Agile Framework) и LeSS (Large-Scale Scrum), а также нехитрая практика Scrum of Scrums. Это — тройка наиболее популярных подходов к масштабированию Agile, как показывает то же исследование Agile в России.

Отличительные особенности всех сколь-нибудь популярных в России подходов, имеющих отношение к Agile (а также к более широкому понятию Business Agility), вы можете посмотреть на одном экране, скачав нашу карту гибких подходов для бизнеса в виде картинки и в виде пригодного к печати плаката.

Люди и их взаимодействие важнее процессов и инструментов

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

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

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

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

Речь не идет о том, что старые цели плохи. Наоборот, как правило, они ориентированы на стабильность, поддержание деятельности компании и сохранение статус-кво. Тем не менее работа на эти метрики не приведет компанию к встраиванию в цифровой мир высоких скоростей.

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

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

Работающий продукт важнее исчерпывающей документации

Чтобы клиенты были довольны, им нужен именно работающий продукт. Поэтому разработчики продукта должны фокусироваться именно на том, чтобы продуктом можно было как можно скорее воспользоваться, а не на составлении списков, диаграмм, требований, отчетов перед заказчиком.

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

Сконцентрируйтесь на целях.

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

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

Будьте бесстрашны.

В Dog agility маршрут и отрезки для прохождения
располагаются  каждый раз по-новому, и потому события разворачиваются все время
по-разному. И хотя драгоценный питомец не знает, как дальше пойдут дела, он
уверен в том, что должен быстро бежать и четко реагировать на команды, чтобы
привести своего хозяина к победе.

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

Вместе они принимают наилучшее решение и не боятся «сойти с трассы». Требования
— регуляторы и другие регламентирующие факторы (бизнес-эквиваленты прохождения
определенных этапов) – могут быть включены в набор правил кейса. И когда речь
идет об исключении или совершается какая-то ошибка, кейс-менеджмент
обеспечивает необходимую поддержку, чтобы адаптироваться к изменившимся
условиям или быстро исправить ошибку и продолжать движение.

Главное — командная работа.

Члены команды могут компенсировать сильные и слабые стороны
друг друга. Мой пес Хайден завоевал одну из своих наград в Agility в самый
жаркий день в году. Человек, являющийся напарником Хайдена в этом соревновании,
проверил, обмотали ли пса холодным полотенцем перед соревнованием, чтобы он был
на пике своей формы для Agility, но сам пренебрег собственным здоровьем.

И
когда на финишной прямой хозяин, ведущий Хайдена, упал от жары, пес идеально
завершил трассу и ПОБЕДИЛ (поскольку штрафных очков за падение владельца собаки
не предусмотрено). Благодаря кейс-менеджменту, бизнес-команда имеет возможность
работать эффективнее..

Определить операционную модель, организационную структуру, правила работы (cookbook), ИТ-архитектуру и метрики.

Каждая компания уникальна, поэтому нельзя скопировать опыт другой организации. Дизайн трансформации должен быть проработан под внутреннюю специфику.

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

ИТ-архитектура должна быть адаптирована под бизнес-цели компании, под продукты и услуги, которые планируются к реализации, должны быть правильно подготовлены ИТ-мощности, процессы, DevOps, CI/CD и так далее.

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

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

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

Сотрудничество с заказчиком важнее согласований условий контракта

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

Чтобы бизнес-ценность продукта быстро росла, заказчик с разработчиком должны плотно общаться по ходу работы. В этом случае все возникающие изменения и проблемы оперативно обрабатываются обеими сторонами.

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

Готовность к изменениям важнее, чем следование плану

Чтобы не откладывать риски проектов на последние стадии разработки (когда будет уже поздно уменьшать содержание работы, сдвигать срок или усиливать команду), Agile предлагает не только итеративность работы, но и готовность к изменениям на всех стадиях.

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

Что касается готовности к изменениям со стороны представителей заказчика (клиента), то в такой ситуации они могут пожертвовать чем-то запланированным (но менее ценным) ради новых возможностей. Готовность заказчика оперативно жертвовать какой-то частью запланированного также нужна в ситуации, когда исполнители столкнулись с непредвиденными проблемами в ходе разработки.

Непрерывно отслеживать прогресс достижения целей.

Компании предстоит постоянно адаптироваться, не останавливаться на достигнутом, регулярно корректировать цели, анализировать свой продукт, пересматривать процессы.

Обязательно должны определяться и контролироваться промежуточные результаты. Но достижение определенного бизнес-показателя не означает завершение процесса трансформации — организация постоянно развивается и ставит перед командой все более амбициозные цели.

Принимай поражения и празднуй победы.

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

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

За счет кейс-менеджмента больше и больше свершений
становятся реальными за меньшее количество времени и с меньшим числом
затраченных ресурсов. А если добавить к этому понимание того, что было успешным,
– все это может быть заложено в экосистему кейс-менеджмента для того, чтобы
воспользоваться этими знаниями в будущем.

Agile — философия, scrum — ее реализация

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

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

Ценности эти настолько общие и даже абстрактные, что Agile часто называют философией.

Также встречается термин «гибкий образ мышления» (от английского Agile Mindset), который означает понимание человеком ценностей Agile.

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

Образ мышления Agile сейчас чаще всего реализуется через фреймворк Scrum, поэтому неудивительно, что эти два слова очень часто используются вместе.

• Если Agile-мышление не свойственно людям, Scrum приводит лишь к удорожанию разработки, поскольку нужно больше времени выделять на коммуникации и обратную связь, требуются новые роли, нужны ресурсы на обучение, на повышение взаимозаменяемости сотрудников и т.д.
• И наоборот: без конкретного подхода (вроде Scrum) Agile останется лишь красивой философией — абстракцией, которую большинство людей не смогут превратить в руководство для повседневной работы.

Поэтому Agile и Scrum обычно изучают совместно. На нашем сайте десятки статей по гибкому управлению собраны в рубрику Аджайл и Скрам.

Исторически к Agile относится также и метод Kanban. Поэтому самый универсальный международный сертификат по Agile — ICAgile Certified Professional — включает не только Scrum, но и Kanban.

Agile сложнее, чем 4 ценности

Во-первых, помимо ценностей, в Agile-манифесте есть также 12 принципов, которые уточняют и дополняют ценности.

Во-вторых, в статье «Что такое Agile-подход и зачем он нужен бизнесу» вы найдете подробное изложение 6 признаков работы по Agile, которые намного более конкретны, чем ценности и даже принципы. Приведу их здесь кратко:

1. Потребности клиента понятны всем. Важно, что при Agile-подходе на нуждах клиента фокусируется не только бизнес и менеджер продукта, но и вся команда. То есть, каждый из разработчиков понимает: кто клиенты, что им нужно и какие их проблемы решает новый продукт. Это помогает находить более адекватные решения.
2. Процессы и оргструктуры максимально упрощены. Правила и процессы, по которым работают Agile-команды, должны быть простыми, чтобы люди смогли сфокусироваться на клиентах и на создаваемом продукте.
3. Работа короткими циклами (итерациями). Продолжительность цикла — порядка недели или месяца, за это время разработчики выдают какой-либо полезный для клиента результат.
4. Системное получение и использование обратной связи. Разработчики демонстрируют продукт заказчику, получают обратную связь на продукт и сведения об изменениях планов заказчика, затем дорабатывают, добавляют что-то полезное и так далее по циклу. Но также цикл обратной связи работает и для совершенствования самого процесса разработки: для избавления от потерь, задержек и иных препятствий, мешающих повышению производительности.
5. Максимум полномочий у исполнителей. В идеале, люди самостоятельно принимают решения и несут за них ответственность. Когда команда или даже отдельный сотрудник сам(а) может, хочет и имеет право решить какую-то проблему без ожидания действий извне, это значительно ускоряет работу.
6. Внутренняя мотивация вместо «кнута и пряника». Agile-методы помогают настроить процессы таким образом, что сотрудники становятся более свободны и счастливы на работе, видят востребованность своего труда клиентами, ценят доверие и предоставленные им возможности для саморазвития. Люди с такой внутренней мотивацией эффективнее справляются с работой, особенно если это сложная творческая работа.

Эти 6 признаков характерны для многих гибких подходов, если они правильно применяются. Рассмотрим теперь чуть подробнее, что это за гибкие подходы.

Business agility — достижение гибкости за счёт вовлечения бизнеса

Business agility — статьи в блоге scrumtrek

Гибкость видов деятельности

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

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

«Организация не может более гибкой, чем ее наименее гибкое подразделение», — Эван Лейборн

Посмотрим на организацию как на поток. С одной стороны есть спрос на продукты или услуги. С другой — поставка их конечным потребителям. Где-то на этом потоке есть ограничение пропускной способности и гибкости. 20 лет назад ограничением гибкости были ИТ и команды разработки программного обеспечения.

Именно поэтому agile стал так популярен в этой отрасли. Теперь гибкость ограничивается другими функциями: проектным офисом, службой HR, продажами, финансами. Эти функции должны стать гибкими. К примеру, в организациях есть бюджетный цикл. Если вашего проекта нет в бюджете, вы не сможете запустить его до того, как будет принят следующий бюджет. Нужно подождать 12-18 месяцев.

Простых решений здесь нет. Нужно пропагандировать гибкий образ мышления и помогать создавать гибкие практики вне ИТ. Только так можно достичь подлинной гибкости на уровне организации.

Гибкость процессов

Процесс — это совокупность отдельных операций, которые объединяются в поток создания ценности для клиента.

Когда говорят о гибкости, чаще всего подразумевают именно эту гибкость — гибкость процессов. Популярные фреймворки и методы работают на этом уровне: Scrum, Kanban, SAFe, LeSS, Lean Six Sigma. Некоторые из них частично работают и на уровне видов деятельности.

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

Деятельность

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

Кейс менеджмент – владелец соревнований мирового уровня

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

«Dog agility» — это соревновательный вид спорта, в котором
владельцы ведут своих питомцев через препятствия. В гонке учитываются время и
точность прохождения. Маршруты настолько сложные, что собака не в состоянии
пройти их верно без указаний человека.

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

Я считаю, что кейс-менеджмент в бизнесе — это отличный
партнер по Agility для высококвалифицированного специалиста в сфере анализа и
обработки информации, выполняющий множество тех же функций, что и владелец
собаки, участвующий в Agility мирового уровня.

И если кейс-менеджмент представляет
собой «владельца», то, используя эту же аналогию, высококвалифицированные
специалисты в сфере анализа и обработки информации —  это мой любимый пес.
(Прошу прощения у тех специалистов данной сферы, кого может обидеть это
сравнение; прошу также учесть и то, что в моем понимании – это один из лучших
комплиментов)

Я уверен в том, что бизнес может немало узнать о том, как
добиться успеха, от моего Золотого-ретривера. Далее я представлю вашему вниманию
четыре истины об Agility.

Книги об agile по-русски

Список литературы по Agile на русском языке может насчитывать два десятка изданий. Но я приведу лишь 4 книги, которые слабо пересекаются друг с другом по назначению. Две первые книги подходят для первого ознакомления с Agile, две вторые — скорее для тех, кто уже применяет гибкие подходы в работе.

Лидерская гибкость

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

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

Области бизнес-гибкости

Область применения agile

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

Судя по числу участников исследования Agile в России 2022, IT-отрасль теряет свою монополию на Agile, имея долю менее 50% от общего числа людей, вовлеченных в Agile-трансформации.

Agile — это уже давно не только про разработку программного обеспечения.

Но это не значит, что гибкие подходы есть смысл применять везде без ограничений.

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

• Agile целесообразно применять в ситуации, когда первую версию продукта нужно выпустить на рынок как можно быстрее, иначе конкурентная борьба может быть проиграна.
• Другая ситуация, когда ценности Agile будут наиболее эффективны: инновационный продукт с заранее непредсказуемыми свойствами и/или с нестандартными средствами (новыми технологиями) для его разработки.

Про область применимости Agile и про основные проблемы, которые влечет за собой Agile, смотрите в 5-минутном видео Алексея Пименова:

Подробнее о том, зачем и когда нужны гибкие подходы, вы узнаете из бесплатных видеоуроков про Agile (11 видео, 65 минут).

Отношения

Следующие три области гибкости отвечают за отношения как внутри, так и вне организации:

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

Празднование победы

Один из моих любимых гуру однажды сказал: «Празднуйте то,
чего хотите еще больше» — Том Питерс.

Или, как однажды  сказал мой любимый питомец: «Гав» —
Талисман Хайден О’Брайрлэнд.

Перевод: Коновалова Мария, DIRECTUM.

Резюме. место agile среди родственных управленческих подходов

Итак, Agile — это не методология, не свод рецептов, не доски со стикерами и не стандартизованный набор встреч команды, предписанный в Scrum.

Это слово сейчас имеет два основных значения:

• Agile — это система ценностей (или образ мышления, или философия, если вам так больше нравится), которая способствует быстрой разработке новых продуктов, максимально отвечающих потребностям клиентов.
• Agile — это также собирательное название очень разных подходов к управлению разработкой, некоторые из которых даже не разделяют все 4 ценности Agile (пример — Kanban). Так уж исторически сложилось.

Agile фокусируется именно на разработке — точнее, на реализации и поставке готовых продуктов. Тогда как для генерации и проверки идей новых продуктов Agile следует дополнить различными продуктовыми подходами: Customer Development, Design Thinking и т.п.

С другой стороны, Agile — это про организацию процесса разработки, а не про технические детали реализации, зависящие от индустрии. Например, в IT-индустрии с той же целью (быстрая поставка ценности клиенту) применяются так называемые инженерные практики и DevOps, но они в Agile не входят.

Agile помогает решить две основные задачи, типичные для современного бизнеса:

1. сократить время вывода продуктов на рынок / время их поставки потребителю;
2. ускорить принятие решений на уровне команд и выше.

Для подходов к ускорению на уровне программ и портфелей проектов (в крупных организациях) грамотнее применять термин Enterprise Agility, хотя во многих контекстах их тоже относят к Agile.

Что же касается подходов к повышению гибкости/скорости принятия решений на уровне всего бизнеса, то это намного шире Agile. Так что для обозначения таких подходов следует использовать термин Business Agility, получивший распространение в конце 2022-х годов.

Среди 12 доменов бизнес-гибкости, показанных на рисунке, Agile полностью покрывает домен «Гибкость процессов», но также связан в той или иной степени с 5-ю другими доменами, по меньшей мере.

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

Рыночная гибкость

Организации непрерывно борются за право существования на рынке. Рынки становятся все менее предсказуемыми, а входные барьеры снижаются. Теперь уже нельзя рассчитывать на устойчивость конкурентных преимуществ. Гибкие организации внимательно изучают новые рыночные возможности и очень быстро их используют.

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

Структурная гибкость

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

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

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

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

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

Техническая гибкость

Десятилетиями agile-команды продвигали техническую гибкость как первооснову гибкости. Быть гибким — это увеличивать качество и продуктивность в условиях неопределенности и изменений. Многие инструменты технической гибкости созданы в последние 20 лет, такие как Экстремальное программирование (XP), BDD, TDD, DevOps.

Техническая гибкость не ограничивается сферой разработки программного обеспечения. Любая область деятельности может быть технически гибкой. Так в маркетинге, продажах, финансах возникают собственные гибкие практики: agile-маркетинг, beyond budgeting и другие.

Для достижения технической гибкости практики выполнения работы должны быть клиентоориентированными, адаптивными к изменениям, и поощрять сотрудничество. Техническая гибкость — хорошее начало, но для получения максимальной пользы организациям нужно развивать и остальные 8 областей.

Ценности agile простыми словами

Ценности Agile родились в 2001 году в Agile-манифесте — в результате обобщения многих тогдашних «методологий разработки» их авторами.

Ценности — это то общее, что определяет приоритеты в работе, независимо от конкретного процесса и предмета работы. Каждая из 4-х ценностей Agile сформулирована в виде «X важнее Y», где X — это:

1. люди,
2. работающий продукт,
3. сотрудничество с заказчиком,
4. готовность к изменениям.

Посмотрим, зачем нужны эти ценности Agile.

Чем agile отличается от методологий

Термин «методология» применяется к Agile по аналогии с предшествующими подходами к организации разработки программного обеспечения: RAD, RUP, XP и другими.

Однако те, кто сталкивался с Аджайлом, понимают: он не похож на предшествующие подходы, которые описывали процесс разработки в деталях. Agile краток: состоит из 4-х ценностей и 12-ти принципов. А описание методологии RUP, например, занимает десятки страниц, — это много приемов и алгоритмов действий.

RUP (Rational Unified Process) включает разбиение жизненного цикла разработки на 4 фазы, рекомендованные соотношения объемов работы по 9-ти потокам (workflows) на каждой фазе, а также конкретные инструменты для каждого потока. OpenUP — последняя методология-наследница RUP — короче и гибче, но все равно до краткости Agile ей далеко.

Методология — это совокупность методов и приемов, которые используются в разных сферах деятельности.

Метод — это способ достижения какой-либо цели.

Agile сам по себе не дает алгоритмов, способов и приемов. При этом входящие в Agile «гибкие» подходы нередко предписывают конкретные приемы:

В отличие от методологий, методов и фреймворков разработки ПО, в основе Agile — не конкретные процессы и даже не элементы процессов, а высокоуровневые ценности.

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

Показанная выше условная схема гибких подходов взята из книги Бориса Вольфсона «Гибкие методологии разработки». Этот краткий справочник по огромному числу гибких управленческих инструментов весьма неплох для своего времени (2022), когда Agile применялся лишь в той индустрии, где он появился — в разработке программного обеспечения. Если же вы не связаны с этой индустрией, для углубления читайте более современные книги без IT-специфики.

Четыре шага на пути к agile

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

Читать по теме

Начало в части 1Окончание в части 3Оригинальный источник

Вывод

Планируя agile-трансформацию, помните, что любое изменение организационного дизайна требует значительных изменений организационного мышления. Такие изменения оказывают большое влияние на людей, команды, структуру и управление.

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

Фото на обложке: Pasuwan / Shutterstock