✓ сопротивления заинтересованных сторон Scrum;
✓ управления организацией, которое слишком ограничивает экосистему.
Для первых двух причин команда обычно может найти решения самостоятельно. Третья и четвертая касаются экосистемы.
22.2 Закрепление практик на уровне экосистемы
Ретроспектива спринта – это практика, направленная на регулярное улучшение и поддержание духа Scrum-команды. Но эта практика ограничивается рамками одной команды.
Цель ретроспективы сезона – в развитии всей экосистемы.
Благодаря паттерну сезонного ритма эта ретроспектива имеет регулярный характер. На нее приглашаются все участники экосистемы. Она длится полдня или полный рабочий день.
Она может проходить как ретроспектива спринта, разве что занимать больше времени, так как она охватывает более длительный период и проводится с большим количеством участников.
Чтобы установить курс на постоянное улучшение экосистемы, я рекомендую использовать модель Agile Fluency и практиковать Ката Совершенствования [64], которые побуждают оценивать прогресс в течение всего сезона, а не только в конце.
• Модель Agile Fluency
Эта модель [Шор, Fluency] использует восприятие бизнес-ценности, создаваемой командой, чтобы определить уровень владения Agility. Модель любопытна тем, что помогает согласовать усилия с ожиданиями. Применяемая для команды, она показывает, что амбициозные цели требуют изменений в организации.
Рисунок 22.1 – Модель Agile Fluency (перевод и адаптация Джеймса Шора и Дианы Ларсен © 2018).
Каждая зона соответствует уровню владения Agile.
Модель помогает команде определить свой текущий уровень и уровень, который она стремится достичь.
Внимание: это не модель определения опытности команды. Она не содержит список практик, необходимых для достижения того или иного уровня. Эта модель помогает определить почему, не углубляясь в детали как.
• Ката Совершенствования
Ката Совершенствования [65] появилась на основе концепции Lean. Майк Ротер, разработчик Ката, предлагает четырехфазный подход:
✓ Определить ожидаемое воздействие (что мы хотим?).
✓ Определить текущую ситуацию (где мы сейчас?).
✓ Определить промежуточную цель на пути к ожидаемому воздействию.
✓ Экспериментировать с целью достижения поставленной цели.
В нашем контексте Ката Совершенствования представляет собой дополнительный инструмент для проведения ретроспективы сезона.
Вместе с моделью Agile Fluency она помогает ответить на два поставленных вопроса и определить промежуточную цель, учитывая продолжительность сезона.
Вот как выглядит процесс в первый раз:
✓ Участники знакомятся с моделью Agile Fluency (отлично срабатывает аналогия с музыкальными группами).
✓ Затем они вместе думают, в каком направлении хотят двигаться по модели. Они устанавливают курс на один-два года. Участники фокусируются на ожидаемом воздействии (этот этап может быть проведен в виде рабочей встречи под названием ретро-футуристическое воздействие, представленной в главе 15).
✓ Они определяют свой уровень на данный момент и решают, на каком уровне модели хотят оказаться.
✓ Они договариваются о промежуточной цели на три месяца (продолжительность сезона), которая способствовала бы достижению воздействия. Для этого полезно опираться на практики и паттерны, которые, по мнению участников, могут помочь им на пути к цели.
Ката и Agile Fluency, применяемые в команде Peetic: наша цель – перейти в зону МАКСИМИЗАЦИЯ ЦЕННОСТИ за один год, на данный момент мы находимся в зоне ФОКУС НА ЦЕННОСТЬ и в следующем сезоне хотим внедрить непрерывное развертывание.
По мере развития экосистемы команда может привлечь одного или двух новых людей, но в какой-то момент придется разбить состав на две команды. Участники сами решают, как им организоваться. Для поддержания экосистемы важно сохранять баланс между командами и обмен между участниками.
Рисунок 22.2 – Роение
Роение практикуется, когда Scrum-мастер (или кто-либо из участников) запускает новую команду для разработки другого продукта.
Лучший для этого момент – конец сезона. Таким образом, новый сезон начинается с новыми с командами.
Чтобы устранить препятствие, иногда приходится его передавать на уровень руководства организации.
Сбор препятствий внутри организации позволяет их приоритизировать и сообщить всем участникам процесса.
С первой главы мы советовали начинать с фазы Shu, то есть приступать к внедрению Scrum со следования практикам, и уже много страниц спустя – контекстуализировать Scrum. Одно не противоречит другому. Возникающее таким образом трение позволяет быстро преодолевать препятствия в двух классических ситуациях:
✓ если команде не удается начать с фазы Shu из-за контекста;
✓ если она хочет перейти с Shu на На.
Разрешение этих препятствий требует участия руководства или других лиц. А для их окончательного устранения часто необходима трансформация организации.
В большинстве случаев трансформация организации начинается с выявления препятствий.
Не всегда достаточно изменений на уровне экосистемы. Когда существует большой культурный разрыв между культурой организации и духом Scrum, приходится задать себе вопрос об Agile-трансформации всей организации.
22.3 Трансформация организации
Напомним себе цель Scrum, о которой мы говорили в первой главе:
Scrum помогает людям улучшить их способы работы.
Внедрение Scrum в рабочий процесс одной команды, или даже нескольких команд, начинается без трансформации всей организации. Вопрос об Agile-трансформации встает, когда организация осознает: для достижения результата ей нужно меняться, в частности, изменить свою структуру, а иногда и культуру. Вернемся к нашему определению Agility:
Agility – это способность организации как можно раньше и чаще предоставлять услуги, оказывающие реальное воздействие на пользователей, при этом своевременно адаптируясь к изменениям в своей среде.
Это определение позволяет нам выразить, что такое Agile-трансформация:
Agile-трансформация соответствует процессу, осуществляемому организацией для приобретения этой способности.
Можно заменить слово Agile на Digital или любое другое, что сейчас в моде. Фактически, чтобы закрепить Scrum в экосистеме, необходимо провести культурное выравнивание организации.
Рисунок 22.3 – Scrum-мастер добивается успеха в Agile-трансформации
При устранении организационных препятствий часто оказывается, что их первопричина кроется в проблемах, связанных с культурой. И если ничего не менять в культуре организации, вероятнее всего, препятствия вернутся.
Корпоративной культурой часто пренебрегают. Поставив на первый план краткосрочные финансовые цели, компании не стремятся стать слаженными коллективами, группами взаимодополняющих людей с осознанием принадлежности – как у настоящей Scrum-команды.
Корпоративная культура – важный параметр Agile-трансформации. Внедрение Scrum с его новым языком и новыми обычаями неизбежно влияет на культуру организации.
Компании, уделяющие внимание корпоративной культуре, лучше других подготовлены к трансформации. Те, кто рассматривает Scrum в качестве инструмента повышения производительности и игнорируют культурный аспект, с большей вероятностью потерпят неудачу.
Трансформация будет тяжелой в тех компаниях, где не разделяют культуру Scrum – культуру сотрудничества. Процесс может быть непростым и занять больше времени в организациях, которые придерживаются культуры контроля, а не индивидуальных компетенций [Сахота, «Transformation»].
А вообще, вместо того, чтобы трансформировать организации, не пора ли открывать организации будущего?
• Модель Reinventing Organizations
В книге об организациях будущего («Reinventing Organizations») Фредерик Лалу представляет пять стадий развития компании. Каждая стадия соответствует определенному цвету:
✓ Красная (импульсивная)
✓ Фиолетовая (традиционная)
✓ Оранжевая (успешная)
✓ Зеленая (плюралистическая)
✓ Бирюзовая (эволюционная)
При помощи этой модели можно разобраться в причинах трения, возникающего между Scrum-командой и ее окружением.
Бирюзовая организация, по определению Лалу, полностью соответствует Agile-культуре. Scrum-команда в такой организации может успешно развиваться и адаптироваться.
В зеленой организации возможны неслаженность и разногласия. В оранжевой организации будет больше конфликтов, а в фиолетовой – еще больше. В таких случаях необходимо выравнивать организацию либо путем ее изменения, либо через предоставление экосистеме полной автономии.
Трансформация – это управление изменениями. При классическом управлении в крупной организации цикл имплементации изменения через пилотный проект выглядит следующим образом:
Рисунок 22.4 – Классический процесс управления изменениями
Этот подход можно применить и для нашей Agile-трансформации. Вот только он чрезмерно линейный и скорее нисходящий, что делает его не совсем пригодным для сложной трансформации. Кроме того, все организации разные, и у каждой трансформация своя.