Перевод статьи 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.
