Современные тренды и рекомендации по аджайлизации крупных финансовых институтов

12-15 Мая 2019 в Дублине состоялся PMI EMEA Congress 2019, который был организован одним из лидеров отрасли в области разработки методологии управления проектами – Project Management Institute (PMI). Конгресс собрал более 700 делегатов из 70 стран и 450 организаций и стал мировой площадкой по обмену знаниями и опытом в применении современных методов и подходов в области управления изменениями. Во многих крупных российских банках и финансовых учреждениях на текущий момент происходит Agile трансформация структуры управления изменениями, поэтому анализ опыта аджайлизации в других подобных организациях является важным фактором успешного и эффективного внедрения Agile.

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

  • Методология Agile изначально разрабатывалась для гибкого управления небольшими продуктами с помощью команд 7-15 человек для эффективного использования имеющихся ресурсов. Масштабирование подхода на большие организации требует изменения подходов корпоративного управления, стратегического планирования, бюджетирования и мышления сотрудников внутри организации.
  • Внедрение методологии Agile в некоторых крупных организациях привели как к позитивным результатам, а именно, к повышению эффективности, уменьшению показателей Time to Market (T2M) и к уменьшению затрат на изменения, а в отдельных, к негативным последствиям: ухудшению сроков реализации проектов, качества планирования и увеличению операционных затрат.
  • Эффективным способом при внедрении методологии Agile является совмещение классических подходов проектного управления с гибкими методиками.
  • Необходимо учитывать национальный и региональный менталитет сотрудников при внедрении методологии Agile. Национальные особенности должны отражаться в программах обучения Agile.
  • В общем случае недооценивается роль обучения философии Agile и изменению мышления сотрудников организации. Для успешного внедрения необходимо кардинально поменять отношение персонала к процессам внутри организации, к роли работы в команде, при этом высококвалифицированные индивидуумы могут покинуть компанию, поскольку они теряют ощущение незаменимости и уникальности, возможности быть единственным умеющим плавать на пляже героем-спасателем.
  • Для успешного использования Agile зачастую требуется кардинально пересмотреть бизнес-модель и структуру организации.
  • Роль проектного офиса, программного и портфельного управления проектами при переходе на Agile обычно упраздняется в процессе трансформации, что является негативным фактором. В результате происходит потеря связи между стратегическим планированием, развитием организации и реальной деятельностью Agile команд.
  • Отсутствует явное бюджетирование новых инициатив, поскольку бюджет выделяется на цели и задачи трайба. Механизмы расширения и видоизменяя трайба не являются ключевыми в методологии. Это приводит к замедлению внедрения инноваций внутри организации.
  • Качество продуктов снижается из-за выделенном акценте на уменьшении T2M.
  • Регуляторные требования могут реализовываться с использованием Agile принципов, но с особым акцентом на качество конечного результата.
  • Уровень и качество коммуникаций между подразделениями при использовании Agile должны быть существенно увеличены. При недолжном уровне взаимодействия и взаимопонимания использования Agile только увеличит T2M и стоимость внедрения изменений.
  • Использование специализированного программного обеспечения для единого управления задачами, проектами, портфелем и программой проектов, целевыми показателями эффективности организации, интеграция процессов изменения с ERP и CRM системами, существенно увеличивает эффективность применения Agile и взаимодействия команд.
  • Во всех Agile практиках особое внимание уделяется обратной связи, анализу спринтов внутри команд, но на уровне выше (продукты, программы, трайбы) эта связь теряется для рядовых членов команд.
  • Внедрение Agile в крупной организации это не вопрос одного месяца, полугода или года. Это системная стратегическая работа на несколько лет с кардинальным изменением всех процессов и принципов работы организации.

Рекомендации:

  • Высший менеджмент организации должен стать проводником, лидером Agile изменений. Необходимо ежемесячно на уровне каждого трайба выступать перед сотрудниками с обзором текущих целей, прогрессом их выполнения, анализом текущих уроков. Ежеквартально организовывать аналогичные meetup между лидерами трайбов с веб-трансляцией и открытым участием всех желающих сотрудников организации.
  • Необходимо усилить роль и объем обучения Agile методикам. Обучение должно акцентироваться не только на техниках, таких как Scrum, Kanban, но и идеологии и философии Agile, изменению принципов мышления, инновационным и нестандартным аналитическим подходам. Обучение должно опираться на конкретные примеры и практики крупных финансовых институтов, стран и регионов. Дополнительно необходимо проводить психологическое тестирование и выявлять сотрудников, которые не готовы к новым изменениям внутри компании.
  • Проектный офис должен выполнять координационную и коммуникативную роль (ежемесячные и ежеквартальные meetup), быть во главе стратегического планирования и обеспечивать мониторинг качества деятельности трайбов.
  • Agile принципы не должны быть обязательны для всех проектов, особенно если речь идет о регуляторных и нормативных изменениях. В каждом конкретном случае необходимо принимать обоснованное решения при использовании Agile в таких случаях. Допускается совмещение классических и гибких подходов к реализации проектов.
  • Необходимо уделять особый и выборочный акцент качеству конечного продукта. Работающий продукт важнее исчерпывающей документации, но качественно работающий продукт невозможно создать без должной документации и QA, поэтому необходимо постоянно балансировать на этой грани, при этом не в ущерб качеству продукта.
  • Взаимодействие между подразделениями необходимо вывести на новый уровень. Бюрократические препоны, беспочвенные отсылки на процессы и ВНД во взаимодействии должны жестко пресекаться высшим руководством трайбов, и оперативно разрешаться. Должен быть создан соответствующий on-line механизм внутри трайба и между трайбами с соотвествующими КПЭ у всех руководителей. Необходимо создать атмосферу общей командной работы внутри организации, а не перекладывания ответственности между подразделениями и блоками. Принцип люди и взаимодействие важнее процессов и инструментов необходимо сделать базовым при коммуникации между трайбами.
  • Мотивационная составляющая работы, нацеленность на изменения, нестандартность мышления должны быть объединены в единой оценке сотрудников всех уровней с понятной и прозрачной обратной связью. При этом, чтобы выражение таких идей не воспринималось, как увеличение нагрузки на чаптеры, кластеры и трайбы, должны быть созданы прозрачные механизмы расширения команд, увеличение бюджета, а не его перераспределение внутри уже выделенного.
  • Используемые ИТ-решения для ведения бэклога, дашборды для Scrum, Kanban не должны ограничиваться только в их использовании для DevOps процессов и реализации спринтов, а являться информационной основой для выполнения пользовательских историй и проектов, портфелей и программ проектов, иметь связь с ERP системой, связь с КПЭ чаптеров, кластеров, трайбов и организации в целом.

Использованные материалы:

Презентации PMI Leadership Institute Meeting 2019 — EMEA and PMI EMEA Congress 2019:
  • Design Thinking to Improve Your Agile Process, Presenter: Denis Vukosav
  • Artificial Intelligence Horizons in Portfolio Planning, Presenters: Umut Sezen, Christopher Reeves
  • The Journey Towards Agility: Lessons Learned From Successes and Failures, Presenter: Simona Bonghez
  • Product Theatre: Successfully Integrating Agile Jira Projects into a Hybrid PMI/PMBOK-based PPM Environment, Presenter: Gerald Aquila
  • Possible Mission: Escape from Earth – Agile Edition – Business Simulation, Presenters: Santi Alcaide, Alfred Maeso Aztarain
  • Survival of the Fittest: Taking Organisational Agility to the Next Level, Presenter: Leonor Viturro
  • Dynamic Governance for Portfolios/Programmes/Projects, Presenters: Teodor Darabaneanu, John Buck
  • Agilely Vaulting Over Waterfalls: Applying Agile to Waterfall and Vice Versa, Presenters: Karthik Ramamurthy, Sripriya Narayanasamy
  • A Framework for Applying Agile Practices Within Projects, Programmes and Portfolios, Presenter: Nicholas Clemens
  • Planning Matters — Even if You Are Agile!, Presenters: Christopher Worsley, Louise Worsley
  • Embedding Quality Processes in Agile Product Delivery, Presenter: Geetanjali Bhat
  • Product Education Session: Opportunities for Project Managers in the Lean-Agile Enterprise with SAFe, Presenter: Richard Knaster

Дополнительные статьи по теме:

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

Подробнее
Реклама

Комментарии 9

    0
    Качество продуктов снижается из-за выделенном акценте на уменьшении T2M.


    Это проблема конкретных реализаций с которыми вы столкнулись, проблема Agile в целом или вовсе не считается проблемой в контексте данной методологии?
      0

      Только, если отсутствует должное QA. Именно на этом сделан акцент. Суть вывода и рекомендации: Agile эффективно работает в связке с качественным производственным циклом, в котором используются все виды тестирования. Если не используется DevOps, нет автоматизированных тестов, то жди проблем в Agile.

        0
        тут скорее проблема DoD-а, чем жестче прописано, тем выше качество и на долгосрочной перспективе уменьшение t2m
          0
          Чем более детальные DoD, тем выше качество, но тем больше времени требуется на его поддержку и происходит увеличение T2M. Тут вечный баланс. Но у многих компаний банально отсутсвует качественное QA для продуктов, а они при этом идут в Agile, пытаясь этим решить свои проблемы и в сроках и качестве.
          0
          Agile эффективно работает в связке с качественным производственным циклом, в котором используются все виды тестирования.

          А разве в таких условиях не будет любая методология работать?
            +1
            Безусловно, но в Agile можно при этом уменьшить T2M. В умелых руках и при правильной организации любой подход будет работать хорошо. Я сделал некоторый обзор выступлений, Lessons Learned, а не сравнивал Agile и Waterfall. Последние годы трендом является уход от классики в Agile при отсутсвие готовности организации к смене подходов, что приводит к отрицательным результатам. А консалтерам только это и нужно: «впарить» и заработать. Коллеги делились сложностями, с которыми они столкнулись. Я считаю, что далеко не всегда нужно использовать Agile.
          0
          Качество снижается не столько из-за стремления уменьшить t2m, а сколько из-за изменения подхода к созданию продуктов. Выкатываем MVP, и смотрим на реакцию. Дальше допиливаем по мере понимания что допиливать.
          Ну и консьюмеризация. Средний уровень ит-знаний у массовых аудиторий постепенно уменьшается, продукты следуя этому тренду становятся все более простыми (внешне). Вероятность что появится какая-то фича удобная ит-продвинутым пользователям, все время уменьшается.
          0
          TL;DR
          Критикую Ваш пост, но стараюсь при этом не развести холивар!

          Читая Ваш пост у меня сложилось впечатление, что Вы довольно далеки от темы и возможно интерпретировали материалы в ”своем” ключе (ну или выступления были не качественные).

          Хочу сделать пару комментариев со своей стороны:
          1) Вы несколько раз упоминаете Трайбы, которые являются аттрибутом Spotify Engineering Culture. В списке литературы у Вас упомянается только SAFe и кастомные внедрения (от Delloitte например). Всё это Scaled Agile Methodologies. Значит если я правильно понимаю тему — рекомендации по внедрению Scaled Agile Methodologies, а не Agile-тренды или Agile трансформации.
          2) ”Методология Agile изначально разрабатывалась для гибкого управления небольшими продуктами с помощью команд 7-15 человек для эффективного использования имеющихся ресурсов."
          а) «небольшими» — есть много примеров необычайно сложных (комплексных систем) сделаных по Agile методологиям — например интегрированная система данных FBI или любой сервис Google, Facebook etc.
          б) «продуктами» — ключевое слово. Все современные Agile методологии по умолчанию оперируют в продуктовых средах разработки (Productized environment в терминах PMI). Поэтому конечно комично что PROJECT management institute проводит такой эвент).
          с) «команд 7-15 человек» — хммм странное число, никогда такого не слышал. 5-9 в Scrum, до 8 команд по 8 человек в LeSS на 1 продукт и т.д.
          д) «имеющихся ресурсов» — не знаю сколько еще ревизий PMBoK нужно PMI чтобы перестать называть людей ресурсами!
          3) «Масштабирование подхода на большие организации требует изменения подходов корпоративного управления, стратегического планирования, бюджетирования и мышления сотрудников внутри организации.»
          a) «Масштабирование подхода на большие организации» — всё таки мы говорим про Scaled Agile Methodologies, которые более высокая ступень Agile трансформации и для успеха требуют некоторого уровня зрелости с Team Level Agile, Agile in Business Processes, Agile HR и пр.
          б) «требует изменения подходов корпоративного управления, стратегического планирования, бюджетирования и мышления сотрудников внутри организации.» — любая Scaled Agile методология это маленькая революция — изменение ролей и обязанностей, изменение процессов, изменение подходов к бизнессу и разработке. Так что в моем понимании внедрение Scaled Agile методологии = изменения подходов корпоративного управления, стратегического планирования, бюджетирования и мышления сотрудников внутри организации + еще куча всего прочего
          4) «повышению эффективности, уменьшению показателей Time to Market (T2M) и к уменьшению затрат на изменения, а в отдельных, к негативным последствиям: ухудшению сроков реализации проектов, качества планирования и увеличению операционных затрат»
          a) «к негативным последствиям» — согласно исследованиям HBR 2/3 всех Agile инициатив провальные (согласно моему опыту намного выше))
          б) «повышению эффективности» — смотря что мерить и как вы определяете эффективность
          с) «уменьшению показателей Time to Market (T2M)» — у Вас может быть супер эффективная разработка — быстро и качественно, но это не сделает Вашу компанию успешной. Доставляя быстро то что никому не нужно! Agile фокусируется на Value. T2M второстепенная метрика Вашего flow, которая обычно сама подтягивается при успешной адаптации Agile
          д) «ухудшению сроков реализации проектов»
          — в продуктовой разработке нет финального срока vs. классический Project Management
          — Вы же знаете что в Project Constraints если Time фиксировано --> Scope flexible. Видимо проблема на Продуктовой стороне в этом случаею
          5) «Эффективным способом при внедрении методологии Agile является совмещение классических подходов проектного управления с гибкими методиками» — это ну очень спорное утверждение. Я легко могу представить практики из Agile внедренные в классический Project Management (сам так делал), а вот наоборот?!? У Вас есть примеры в Вашем исследовании?
          6) «Роль проектного офиса, программного и портфельного управления проектами при переходе на Agile обычно упраздняется в процессе трансформации, что является негативным фактором. В результате происходит потеря связи между стратегическим планированием, развитием организации и реальной деятельностью Agile команд» — тоже очень спорное утверждение.
          — Старые роли упраздняются в силу их «несовместимости» с внедряемыми фреймворками, а их обязаности перераспределяются между новыми ролями. Часть ложится на команды, часть на продуктовиков, часть на leadership team (логично же — мы делаем революцию)
          — «происходит потеря связи между стратегическим планированием, развитием организации и реальной деятельностью Agile команд» — каждая Scaled Agile методология предлагает решение этой проблемы (это посути и есть смысл их внедрения).
          7) «Отсутствует явное бюджетирование новых инициатив, поскольку бюджет выделяется на цели и задачи трайба. Механизмы расширения и видоизменяя трайба не являются ключевыми в методологии. Это приводит к замедлению внедрения инноваций внутри организации» — простите, но это ересь!
          — Когда Spotify выкатывали свою Engineering Culture они уже были Agile компанией (разработка по Scrum, Agile HR, Agile business processes etc.). Многие говорят про Spotify Model, считая её Scaled Agile Methodology — что в моем представлении не правильно. Spotify Engineering Culture предлагает в первую очередь новую модель Organizational Management --> которая формирует принципы постоянных инноваций и закладывает фундамент для Scaled Agile.
          — Spotify Engineering Culture самая инновационно-ориентированная организационная структура из всех что я знаю — если это у кого-то не работает — не значит что это проблема модели — скорее проблема её понимания и внедрения (нельзя просто так взять и скопировать))
          8) «Качество продуктов снижается из-за выделенном акценте на уменьшении T2M» — хочу обратить внимание на Agile Manifesto --> WORKING software is the primary measure of progress. В Agile качество это априори, а не переменная. На какой метрике делать акцент это индивидуальный выбор — но если разработчики софта доставляют не работающий софт — какой в них смысл (пусть даже и быстро)?
          9) «Регуляторные требования могут реализовываться с использованием Agile принципов, но с особым акцентом на качество конечного результата» — я рад что это получилось у кого-то из презентующих. Я часто встречаю людей, которые уверяют меня что это не возможно. При этом большинство не знакомо с точной формулировкой регуляторных требований или же документов это предписывающих — мне так сказали! — говорят они.
          10) «Уровень и качество коммуникаций между подразделениями при использовании Agile должны быть существенно увеличены. При недолжном уровне взаимодействия и взаимопонимания использования Agile только увеличит T2M и стоимость внедрения изменений» — а в не Agile не так? Отсутствие коммуникации и взаимодействия может привести к уменьшению T2M если мы можем доставить результат без вмешательства «тормозящих» подразделений — автономия, кросс-функциональность, самоорганизация — такое возможно по вашему?
          11) «Использование специализированного программного обеспечения для единого управления задачами, проектами, портфелем и программой проектов, целевыми показателями эффективности организации, интеграция процессов изменения с ERP и CRM системами, существенно увеличивает эффективность применения Agile и взаимодействия команд» — в теории да, никогда такого не видел на практике. Централизация vs. децентрализация. Автономные команды, которые сами формируют процесс, позволяющий быль эффекивными или централизованые инструменты контроля выполнения — что больше вписывается в Agile Manifesto (Individuals and interactions over processes and tools). Не поймите меня неправильно, я не против программных инструментов как ERP и CRM, но я против полной стандартизации. Должна быть «золотая середины» в стандартизации, достигнутая обсуждением между командами, а не какого-либо центрального органа (PMO и пр.)
          12) «Во всех Agile практиках особое внимание уделяется обратной связи, анализу спринтов внутри команд, но на уровне выше (продукты, программы, трайбы) эта связь теряется для рядовых членов команд» — опять же каждая Scaled Agile Methodology предлагает решение этой проблеме (потому что для решения этих проблем и были придуманы!). Я мог бы перечислить ряд методик из SAFe, LeSS, Spotify, SoS, SatS, Nexus — но вы можете их лучше меня нагуглить.
          13) «Внедрение Agile в крупной организации это не вопрос одного месяца, полугода или года. Это системная стратегическая работа на несколько лет с кардинальным изменением всех процессов и принципов работы организации» — так то это навсегда. Не будет такого что однажды Вы проснетесь и скажете — мы теперь Agile компания можно больше ничего не делать! Так не получится). Вы всегда будете искать где и что улучшить, попробовать новые практики, обучить новых сотрудников и пр. Все течёт, все меняется.

          Рекомендации:
          1) «Высший менеджмент организации должен стать проводником, лидером Agile изменений. Необходимо ежемесячно на уровне каждого трайба выступать перед сотрудниками с обзором текущих целей, прогрессом их выполнения, анализом текущих уроков. Ежеквартально организовывать аналогичные meetup между лидерами трайбов с веб-трансляцией и открытым участием всех желающих сотрудников организации» — а вне Agile это не рекомендуется?
          2) «Необходимо усилить роль и объем обучения Agile методикам» — можно бесконечно обучать — это не гарантирует успешного внедрения. А вот содействовать внедрению и паралельно обучать на практике — звучит как больше шансов на успех.
          3) «Дополнительно необходимо проводить психологическое тестирование и выявлять сотрудников, которые не готовы к новым изменениям внутри компании» — таких людей легко выявить и без психологического тестирования. И Ваше предложение что с ними делать?
          4) «Проектный офис должен выполнять координационную и коммуникативную роль (ежемесячные и ежеквартальные meetup), быть во главе стратегического планирования и обеспечивать мониторинг качества деятельности трайбов» — лично я не согласен (я думаю вы уже поняли мою позицию про централизацию)
          — «быть во главе стратегического планирования» — а продукт менеджеры что будут делать?
          — «обеспечивать мониторинг качества деятельности трайбов» — хммм что именно? Качество — а сами разработчики на что? Value — а продукт менеджеры на что? Ну я думаю вы поняли мою идею — PMO обязанности будут перераспределены на другие роли.
          5) «Должен быть создан соответствующий on-line механизм внутри трайба и между трайбами с соотвествующими КПЭ у всех руководителей. » — круть! On-line, а не F2F и KPI на качество взаимодействия и коммуникаций между людьми (простите РЕСУРСАМИ по PMI). Ну а что? Мы же должны это контролировать! Не доверять же РЕСУРСАМ на самом деле. Шутки-шутками, но я только в 1 Agile трансформации видел такой KPI внедренным более-меннее успешно.
          6) «должны быть объединены в единой оценке сотрудников всех уровней» — бам! Команда то, команда сё. Взаимодейстие, коммуникации — оцениваем каждого индивидуально! Agile HR на Вас нет! (https://www.agilehrmanifesto.org/)
          7) «Используемые ИТ-решения для ведения бэклога, дашборды для Scrum, Kanban не должны ограничиваться только в их использовании для DevOps процессов и реализации спринтов, а являться информационной основой для выполнения пользовательских историй и проектов, портфелей и программ проектов, иметь связь с ERP системой, связь с КПЭ чаптеров, кластеров, трайбов и организации в целом» — ни одна из этих систем не позволит Вам контролировать действительно важные KPI. Только второстепенные, которые не отражают реальности.

          Извините я под конец похоже устал и стал писать в более сжато-агрессивном формате. Это статья в очередной раз напомнила мне почему я больше не посещаю PMI эвенты.
          Я восхищаюсь Вашим желанием распространять полученные знания.
            0
            Большое спасибо за столь подробные комментарии. Внимательно прочитал все ваши замечания, и хотел бы отметить, что они не критические и агрессивные, как вы упомянули, а в большинстве случаев расширяют или уточняют мои тезисы. Многостраничные книги написаны по всей этой тематике, а я сжал все до двух страниц. Конечно данные выводы должны вызывать желание спорить и дискутировать. Это и является моей целью. Отвечая на ваш общий вопрос, да, выступления были низкого качества, и PMI вынужденно притягивает Agile к своей деятельности, следуя вызовам времени. Я, безусловно, структурировал и интерпретировал материалы, исходя из своего понимания процессов, опыта и подал их, исходя из своего представления и «прекрасном». Я полностью в этой теме, XP для своих команд я использую с девяностых, и, как только начали появляться статьи на эту тему, оказалось, что мы с товарищами так и делаем программы, как они описывают. C нулевых уже пошли проекты по стандартам PMI и PRINCE2. Теперь всех «бросило» в Agile, и на моей текущей работе мы находимся в данном процессе, поэтому все оцениваю, интерпретирую, анализирую, чтобы добиться позитивного результата. Расплескать воду легко, собрать ее трудно.

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

          Самое читаемое