Когда правильные люди в правильных командах имеют правильный контекст, они, естественно, поступают правильно.
Могут ли agile практики работать в большом портфолио из множества команд и множества разработчиков? Абсолютно. Netflix ввел фразу «сильно выровненный, слабо связанный», чтобы описать хорошо настроенную agile разработку в пределах большой организации. Давайте посмотрим на роль контекста и автономии, а также на некоторые общие характеристики, обнаруживаемые среди высокопроизводительных agile портфолио.
Установите правильный контекст
С таким большим вниманием к команде старшее руководство в крупной маштабируемой agile организации часто задается вопросом, какова их роль. Будучи драйверами стратегии и направления, старшее руководство может быть ключевыми лидерами agile культуры для всей организации. Для agile разработки всего портфолио продуктов стратегия и направление проявляются как «темы»: большие области целенаправленной работы, определенные в течение определенного периода времени. Темы помогают нескольким группам, работающим над одной бизнес-инициативой, эффективно сотрудничать и достигать целей организации.
ТВИИТ:
Старшие лидеры успешных гибких портфолио также поддерживают культуру прозрачности и открытости.
Прозрачная культура скрывает задачи, не опасаясь мести, и сводит к минимуму негативные аспекты политики компании. В результате легче найти правильное решение и заставить команды двигаться вперед.
Расширить agile практики в рамках всей организации
Наиболее успешные компании, работающие с agile в масштабе, имеют три общих черты. Во-первых, вся программа является итеративной. Традиционное управление портфолио ориентировано на нисходящее планирование с работой, распределенной в течение длительных периодов времени, но agile управление портфолио берет концепцию циклов сборки-измерения-обучения, используемых отдельными agile командами, и применяет ее в более широком масштабе. Команды работают вместе, используют модульный дизайн и обмениваются результатами с регулярным ритмом. Это приводит к огромной гибкости, которая смещает акцент с продолжения выполнения негибкого плана на обеспечение ценности и достижение ощутимого прогресса в соответствии с бизнес-стратегией и целями.
Во-вторых, успешные организации общаются через портфолио. Они делятся знаниями и преодолевают барьеры между организационными хранилищами. Подобно agile церемониям на уровне команды, необходимо постоянно обмениваться контекстом во всей организации, чтобы цели, прогресс и препятствия были прозрачными для всех. Это воспитывает уважение между товарищами по команде и коллегами, независимо от роли в организации, и поощряет взаимодействие, основанное на сочувствии и понимании.
В-третьих, самые agile организации часто выпускают релизы по всему портфолио, даже если выпуск релиза включает работу нескольких программ. Выровненные циклы спринта, работа, вложенная в надежные API-интерфейсы и техническую развязку, а также эффективный конвейер автоматического тестирования и развертывания - все это гарантирует постоянный контроль над тем, кто что отправляет и когда.
Разделите одно видение, но охватите разнообразие
Как и в традиционной agile разработке, работа в портфолио agile разработки делегируется командам, а не отдельным лицам. Каждая команда понимает большие цели организации, и каждая команда также развивает яркую культуру, которая оптимизирует ее собственные процессы и предоставление.
Например, сюжетные точки - это общий способ, которым команды оценивают работу и используют набор значений на основе последовательности Фибоначчи (0,5, 1, 2, 3, 5, 8, 13, 20, 40, 100). Идея команды А о том, что означает 8, вероятно, будет отличаться от идеи команды В.
По этой причине старшее руководство не должно измерять команды только по числовой скорости. (Числовая скорость - это количество сюжетных точек, которые команда может завершить в спринте.) Они должны понимать, что скорость каждой команды будет уникальной, потому что каждая команда калибрует значения сюжетных точек по-разному.
Аналогично, agile команды имеют разные культуры выпуска релиза. Команды Scrum обычно выпускают программное обеспечение в конце каждого спринта, в то время как команды kanban выпускают постоянно или когда владелец продукта требует, чтобы сборка была запущена в производство. Один из больших вызовах в agile портфолио - релиз большого количества кода за один раз, или, скорее, избежание этого. В конце концов, никто не хочет релизов, которые требуют всего технического персонала на палубе. Разделение кода на независимые потоки выпусков релизов с помощью модульного, а не монолитного дизайна имеет большое значение с точки зрения гибкости и автономности между бизнес-единицами. Модульный дизайн также снижает риск в каждом релизе, поскольку с каждым релизом меняется меньше кода. Это облегчает диагностику и устранение проблем впоследствии.
Автономия также распространяется на рабочие процессы для портфолио организаций. Команды, которые работают в разных частях бизнеса, могут иметь уникальные рабочие процессы. Хорошая ставка на то, что у команды разработчиков программного обеспечения будет иной рабочий процесс и процесс, чем у команды маркетинга, даже если оба отдела следуют agile принципам, таким как итеративная разработка и регулярная ретроспекция (размышление о прошлом). Или две команды разработчиков могут разделить рабочий процесс на разные состояния. И это нормально! Это разнообразие дает большие гибкие выгоды портфолио от обмена знаниями. Попытка использовать большое количество вещей означает, что вы изучаете больше вещей, которыми можно поделиться в рамках всей организации.
Расширяйте гибкость по мере роста
Agile структура для большого портфолио означает масштабирование agile принципов, используемых на уровне команды в рамках всей организации. Agile культура - это умножитель силы: она естественно масштабируется вверх и наружу, когда ее основные принципы соблюдаются и разделяются. Но портфолио будет таким же успешным, как и его самая слабая команда. Для обеспечения успеха старшее руководство должно работать в партнерстве со всеми командами, чтобы создать здоровую agile культуру.
По материалам Agile Coach "Managing an agile portfolio"