Перевод статьи Evan Leybourn «Domain of Agility» выполнен Лилией Алексеевой (Agile-евангелист, Сбербанк) с разрешения автора.
Agile не означает Scrum, а Agility нельзя свести только к Agile.
На протяжении нескольких последних месяцев я пытался сформировать простую модель, которая помогла бы раскрыть понятие Agility и взаимодействие между составляющими его элементами. Теперь я хочу представить вам результат этой работы — три различные формы гибкости (Agility) — бизнеса, техническую и процессную. На мой взгляд только наличие всех трех элементов позволяет нам создать Agile-организацию.
Гибкость процессов (Process Agility). Я начну с нее, потому что именно эта область обычно ассоциируется у людей с понятием Agile. Эта область фокусируется на работе команд и проектов, то есть на поставке ценности. Большая часть существующих фреймворков: Scrum, SAFe, LeSS – преимущественно фокусируется на этом уровне (справедливо, впрочем, отметить, что многие фреймворки масштабирования Agile частично охватывают также и область Business Agility).
Техническая гибкость (Technical Agility). Техническая зрелость изначально считается краеугольным камнем гибкости. Один из самых ранних и основополагающих фреймворков Agile — Экстремальное программирование (XP) — почти полностью посвящен технической гибкости. Большинство современных инженерных практик таких как Test-Driven Development (разработка через тестирование), парное программирование и даже рефакторинг берут свои корни из XP. Но техническая гибкость не ограничивается инженерными практиками из отрасли разработки программного обеспечения. Любая область работы может и должна стать «технически» гибкой. В первую очередь это касается всех поддерживающих процессов, например, таких как финансирование, функционирование хозяйственных служб и прочих. Что значит для них гибкость? Это их собственный внутренний Time-to-Market. Пример, знакомый любому руководителю отдела любой крупной компании: план по подбору новых сотрудников подается в отдел по персоналу и утверждается с ними на год вперед. А если в середине года неожиданно стартовал новый проект, и требуются люди, то ставок на них нет, и подбор можно будет начать только в новом году. (Примечание переводчика). Изменение таких процессов поддерживаются новыми Agile-практиками: Beyond Budgeting и прочими.
Гибкость бизнеса в целом (Business Agility). Это самая молодая область. По большому счету организации только сейчас начинают думать о гибкости бизнеса как об отдельной области. На протяжении последних двадцати лет пока отдельные команды становились гибкими, основным сдерживающим фактором, как правило, было взаимодействие с соседними командами в пределах одного подразделения. Сегодня же, когда целые подразделения и части компаний становятся гибкими, ключевым ограничивающим фактором становится вся остальная организация. По моему опыту, такие подразделения как финансы, HR и проектный офис становятся основными источниками ограничений на пути к гибкости организации в целом.
Гибкость бизнеса (Business Agility) в целом находится на стадии становления. В отличие от двух других областей здесь почти нет формальных методов и подходов, описанных в рамках каких-либо фреймворков. Beyond Budgeting, Холакратия и Лидерство как служение (Servant Leadership) — вероятно, три наиболее сформировавшихся и ставших узнаваемыми концепции из области Business Agility. Лично я считаю, что в течение следующих 5-10 лет мы увидим взрывной рост различных методов, инструментов и подходов к обеспечению гибкости бизнеса, которые консолидируются в стройные фреймворки.
PS. Если вам интересны материалы по трансформации процессов в крупных компаниях, рекомендуем группу Enterprise Agile Russia в Facebook. Будем обсуждать подходы к масштабированию, такие как SAFe и LeSS.
Agile не означает Scrum, а Agility нельзя свести только к Agile.
На протяжении нескольких последних месяцев я пытался сформировать простую модель, которая помогла бы раскрыть понятие Agility и взаимодействие между составляющими его элементами. Теперь я хочу представить вам результат этой работы — три различные формы гибкости (Agility) — бизнеса, техническую и процессную. На мой взгляд только наличие всех трех элементов позволяет нам создать Agile-организацию.
Гибкость процессов (Process Agility). Я начну с нее, потому что именно эта область обычно ассоциируется у людей с понятием Agile. Эта область фокусируется на работе команд и проектов, то есть на поставке ценности. Большая часть существующих фреймворков: Scrum, SAFe, LeSS – преимущественно фокусируется на этом уровне (справедливо, впрочем, отметить, что многие фреймворки масштабирования Agile частично охватывают также и область Business Agility).
Техническая гибкость (Technical Agility). Техническая зрелость изначально считается краеугольным камнем гибкости. Один из самых ранних и основополагающих фреймворков Agile — Экстремальное программирование (XP) — почти полностью посвящен технической гибкости. Большинство современных инженерных практик таких как Test-Driven Development (разработка через тестирование), парное программирование и даже рефакторинг берут свои корни из XP. Но техническая гибкость не ограничивается инженерными практиками из отрасли разработки программного обеспечения. Любая область работы может и должна стать «технически» гибкой. В первую очередь это касается всех поддерживающих процессов, например, таких как финансирование, функционирование хозяйственных служб и прочих. Что значит для них гибкость? Это их собственный внутренний Time-to-Market. Пример, знакомый любому руководителю отдела любой крупной компании: план по подбору новых сотрудников подается в отдел по персоналу и утверждается с ними на год вперед. А если в середине года неожиданно стартовал новый проект, и требуются люди, то ставок на них нет, и подбор можно будет начать только в новом году. (Примечание переводчика). Изменение таких процессов поддерживаются новыми Agile-практиками: Beyond Budgeting и прочими.
Гибкость бизнеса в целом (Business Agility). Это самая молодая область. По большому счету организации только сейчас начинают думать о гибкости бизнеса как об отдельной области. На протяжении последних двадцати лет пока отдельные команды становились гибкими, основным сдерживающим фактором, как правило, было взаимодействие с соседними командами в пределах одного подразделения. Сегодня же, когда целые подразделения и части компаний становятся гибкими, ключевым ограничивающим фактором становится вся остальная организация. По моему опыту, такие подразделения как финансы, HR и проектный офис становятся основными источниками ограничений на пути к гибкости организации в целом.
Гибкость бизнеса (Business Agility) в целом находится на стадии становления. В отличие от двух других областей здесь почти нет формальных методов и подходов, описанных в рамках каких-либо фреймворков. Beyond Budgeting, Холакратия и Лидерство как служение (Servant Leadership) — вероятно, три наиболее сформировавшихся и ставших узнаваемыми концепции из области Business Agility. Лично я считаю, что в течение следующих 5-10 лет мы увидим взрывной рост различных методов, инструментов и подходов к обеспечению гибкости бизнеса, которые консолидируются в стройные фреймворки.
PS. Если вам интересны материалы по трансформации процессов в крупных компаниях, рекомендуем группу Enterprise Agile Russia в Facebook. Будем обсуждать подходы к масштабированию, такие как SAFe и LeSS.
Поделиться с друзьями
Комментарии (4)
Toshiro
25.01.2017 00:04У меня рябит в глазах от слова "гибкий" в этой статье, она "гибче" танцовщиц в Лас-Вегасе.
zirf
25.01.2017 10:15Одного понять не могу зачем переносить что-то из очень специфической области (разработка ПО) на бизнес? Там есть свои четкие понятия: организационная зрелость, процессный подход. Гибкость бизнеса — это свойство отвечать на вызовы рынка и не что-то другое.
Cromathaar
Мне кажется, данная статья (не в обиду переводчику, перевод хороший) — яркий пример того, как различного рода «управленцы» подхватили хайповую в начале 2000-х тему «гибкости» и уже почти двадцать лет тулят ее, куда надо и куда не надо, забывая, что все это было про разработку ПО, а не про управление и бизнес-процессы. Agile-манифест создавали и подписывали программисты, и отражает оный манифест их взгляд на изменения в подходах к разработке ПО в эпоху, когда потребности бизнеса становились все более и более динамичными (привет эра доткомов).
Но как это осознать, когда большинство этих «управленцев» никогда не были программистами и так и не смогли понять, в чем же суть, пытаясь сразу спроецировать Agile-принципы на свою деятельность (отчасти, а может и в основном, из страха остаться за бортом)? Ничего не имею против автора, но судя про профилю на LinkedIn, он пару лет отмотал сисадмином, потом ушел в BI, а потом заделался Agile-тренером. Ослепительная карьера. Наверное поэтому XP у нас вдруг ни с того ни с сего превратилось в фрэймворк, коим никогда не являлось. Слово-то модное, а значение его знать не обязательно. Зато, как обычно, очень много воды про общую гибкость, ценности, стэндапы среди уборщиц и канбаны среди эйчаров.
serg_p
Камент — круче статьи