Agile Results — новый подход к личной эффективности. Описание основных приемов и принципов / GTD / Betteri.ru

В статье рассмотрена система личной эффективности — Agile Results, которая была описана в книге «Getting Results the Agile Way». Данная методика является отличным дополнением или даже альтернативой GTD.

Статья разделена на три блока:

— Краткое описание, ключевые особенности Agile Results;

— Основная часть: методы, приемы и принципы Agile Results;

— Заключение: полезные ссылки, мнение автора статьи.

Приблизительный размер статьи ≈ 9 страниц.

1. Введение

Суть Agile Results

Agile Results — это подход к личной эффективности, направленный на достижение значимых результатов.
Автором системы является J.D. Meier — топ-менеджер в команде разработчиков Microsoft Enterprise Strategy и автор книги «Getting Results the Agile Way».
(Список всех статей по Agile Results на Betteri.ru)

Как понятно из названия, для разработки своего подхода J.D. Meier вдохновлялся методикой Agile software development, с которой он тесно связан по роду основной деятельности.

Ключевыми особенностями подхода Agile Results являются:

• ориентация на достижение результатов, а не на выполнение задач;
• гибкость, постоянная адаптация к происходящим изменениям;
• простая, но эффективная методика расстановки приоритетов;
• ограничение временных и энергетических ресурсов для достижения лучших результатов;
• непрерывное совершенствование и развитие всех аспектов личности и самой системы.

Почему я решил написать про Agile Results

Во-первых, потому что после подробного изучения книги «Getting results the Agile Way» я сам активно применяю основные принципы Agile Results в своей жизни и считаю этот подход простым и гениальным.

Во-вторых, потому что я удивлен, насколько незаслуженно Agile Results обделен вниманием в рунете.

В-третьих, потому что я хорошо разбираюсь в существующих системах и методиках в области личной эффективности, меня трудно удивить и обрадовать чем-то новым в этой сфере — Agile Results это удалось.

И в-четвертых (и это не просто бла-бла-бла), Agile Results — это невероятно гибкая и универсальная методика. Она не нуждается ни в специальном софте, ни в специфических навыках, ни в длительном изучении и настройке. Я — заядлый GTD-шник со стажем — смог сразу же абсолютно безболезненно внедрить ее основные принципы в свою жизнь.

Не дайте кажущейся простоте Agile Results ввести вас в заблуждение, все описанные принципы и практики действительно представляют собой Целостный Системный Подход.

2. Описание основных аспектов Agile Results

# 1. Правило 3-ех результатов

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

• 3 результата дня
• 3 результата недели
• 3 результата месяца
• 3 результата года.

Результаты каждого уровня поддерживают друг друга, что позволяет рассмотреть «лес среди деревьев». Соблюдение «правила 3-х результатов» научило меня концентрироваться на цели, а не на средствах ее достижения, иными словами быть гибким в своем подходе, но постоянно помнить о своих приоритетах.

# 2. План в Понедельник → Результаты Дня → Пятничный Обзор

«План в Понедельник → Результаты Дня → Пятничный Обзор» — это простой, но невероятно эффективный шаблон недели. Сердцевина Agile Results.

• План в Понедельник. Каждая неделя начинается с чистого листа. Определите 3 самых ценных результата, которых хотите достичь на этой неделе. Они будут «вести за собой» вашу активность на этой неделе. Для определения 3 результатов задайте себе вопрос: «Если бы сегодня была пятница, какие три вещи я бы хотел видеть сделанными?» Примеры: «составлен бизнес-план проекта», «я провел как минимум 5 часов в спортзале», «моя статья написана».

• Результаты Дня. Каждый день начинается с чистого листа. Определите три самых ценных результата, которых вы хотите достичь сегодня. В идеале они должны быть согласованы с запланированными результатами недели. Знание того, что каждое мое действие согласовано с вышестоящими целями, а значит наполнено смыслом — дорогого стоит.
  
  Что делать, если дел больше 3-ех? Все просто: три главных желаемых результата расположите в вашем списке дел выше всех остальных. Приступайте к другим задачам только после достижения главных целей.

• Пятничный Обзор. Во время Пятничного Обзора вы подводите итоги недели: чего удалось достичь, что не получилось и по какой причине. Всю неделю вы действуете, в пятницу вы оцениваете сделанное. Определите три сферы, в которых дела идут хорошо. Определите три, положение которых нуждается в улучшении. Используйте полученные знания в следующий понедельник при составлении плана на неделю.

#3. Сферы Влияния

Сферы Влияния — это взгляд с высоты птичьего полета на все самые важные сферы вашей жизни. Это возможность увидеть общую картину и решить, куда стоит инвестировать силы и время. Карта Сфер Влияния позволяет согласовать ваши краткосрочные результаты с долгосрочными приоритетами при планировании.
Автор Agile Results предлагает начать с такого деления: Жизненная Сфера, Личная Сфера и Рабочая Сфера.

#4. 10 ключевых ценностей Agile Results

• Действие приоритетнее Планирования. Действие — лучшее противоядие против аналитического паралича. Вместо того, чтобы все досконально спроектировать и продумать каждый шаг наперед, начните действовать. Результаты вашей активности направят ваше мышление в нужную сторону и, если понадобится, вы сможете сменить курс.

• Подход важнее Результата. Вы не всегда можете контролировать результаты ваших действий. Что вы можете контролировать, так это свое отношение, поступки и ответную реакцию. Используйте полученные результаты как обратную связь для калибровки своего подхода.

• Энергия приоритетнее Времени. Сфокусируйтесь на поддержании высокого уровня энергии. За час такой работы вы будете достигать больше, чем за несколько часов обычной. В дополнение к правильному питанию, хорошему сну и физнагрузкам ключом к высокому уровню энергии является следование за своими увлечениями и жизнь по личным ценностям.

• Концентрация важнее Количества. Выполнить как можно больше — не верная цель. Важно концентрироваться на выполнении самых важных дел. Концентрация — множитель силы.

• Достаточно Хорошо лучше, чем Идеально. Нельзя давать перфекционизму взять верх. Лучше выполнить что-либо, а после постоянно улучшать, чем постоянно откладывать это на потом в поисках идеала.

• Мышление Развития бьет Мышление Предопределенности. Мыслить категориями развития значит быть способным учиться и делать выводы. Мыслить предопределенно означает верить в то, что, если что-то создано определенным образом, то это нельзя изменить. Мышление Развития помогает избежать явления, которое известно как приобретенная беспомощность. Еще оно помогает оставаться гибким, а гибкость является ключом к хорошим результатам.

• Результат важнее Действия. Провести больше времени на работе или выполнить большее количество задач еще не значит увеличить продуктивность. Результат — вот лучшее мерило продуктивности. Ясное понимание желаемого результата позволяет оставаться гибким в его достижении.

• Сила приоритетнее Слабости. Уделяйте больше внимания своим сильным сторонам, а не слабостям. Вместо того, чтобы тратить все силы на исправление недостатков, выжимайте максимум из своих достоинств. Это даст большую отдачу.

• Система приоритетнее Временного Решения. Наличие системы крайне важно. Вам есть на что опереться в случае, если вы сбиваетесь с пути. Значит вы можете позволить себе больше экспериментировать. Прочный фундамент в виде системы позволяет подняться над рутиной и уделить внимание положению дел на высших уровнях.

• Создание Ценности приоритетнее Выполнения Дела. Вместо простого вычеркивания задач из списков дел, больше думайте о создании ценностей. Размышляя о том, какую ценность создают выполняемые дела, вы приучаете себя думать о самом важном.

#5. 10 главных принципов Agile Results

• 80/20 действий. Вместо того, чтобы тратить 80 процентов времени на размышления и 20 на действия, вы начинаете проводить 80 процентов своего времени за активными действиями.

• Меняйте свой Подход. Настраивайте его и приспосабливайтесь по ходу дела. Если что-то не работает — оставьте это.

• Постоянное Обучение. Мир вокруг нас и мы сами постоянно меняемся. Из всего нужно делать выводы и использовать их для улучшения своих результатов.

• Создайте Поток Ценностей. Поставьте создание ценных результатов на поток. Постоянно подбрасывайте топливо в виде ценных результатов, чтобы локомотив вашей жизни всегда шел на полном ходу. Не гонитесь за одним крупным результатом, лучше организуйте непрерывный поток мелких побед.

• Меньше значит больше. Откусывайте ровно столько, сколько сможете прожевать.

• Разделите Действия и Справочную Информацию. Научитесь разделять задачи и вспомогательные материалы. Это поможет уменьшить отношение сигнал/шум.

• Установите Границы. Ограничивайте затраты времени и энергии. Например, определите лимиты в следующих Сферах Влияния: разум, тело, эмоции, карьера, финансы, отношения и развлечения. Важно четко представлять минимумы и максимумы, которые вы отводите для каждой сферы.

• Фиксированное время — гибкие возможности. Цените свое время. Сначала определите границы, потом решите, сколько дел вы способны выполнить за отведенное время.
• Ритм результатов. Сконцентрируйтесь на результатах дня, недели, месяца и года. Жизнь в ритме результатов превращается в привычку, о которой не приходится постоянно думать.

• Версии Результата. Результаты можно и нужно постоянно улучшать. Версия 3 будет лучше, чем версия 2, которая в свою очередь лучше, чем версия 1. Такой подход помогает в борьбе с перфекционизмом и способствует достижению постоянных результатов.

#6. 12 основных приемов Agile Results

• Правило 3-ех результатов. Правило 3-ех результатов учит фокусироваться на самом важном. Определите три ключевых желаемых результата каждого дня, недели, месяца и года. Это поможет «рассмотреть лес среди деревьев». Слишком часто мы берем на себя больше дел, чем способны выполнить. Вместо этого выделите только три результата, которых вы хотите добиться, и только после этого приступайте к остальным делам. Думайте об этом как о шведском столе результатов, к которому всегда можно вернуться за новой порцией — нет нужды каждый раз наполнять тарелку до краев.

• Структура недели. Решите, каких трех результатов вы хотите добиться на этой неделе. После этого решите, каких трех результатов вы хотите достичь в каждый конкретный день недели. Ежедневно двигайтесь к своим целям. В конце недели проведите разбор полетов.

• Радар Результатов. Подумайте, как можно организовать что-то вроде радара планируемых результатов. Вы должны иметь возможность с одного взгляда увидеть, чего вы собираетесь достичь и куда вам предстоит инвестировать ваше время и силы. Предполагаемые результаты должны руководить вашими действиями. Разделите результаты по Сферам Влияния. Например, создайте список желаемых результатов для вашей Жизненной Сферы: тела, карьеры, эмоций, финансов, развлечений, разума и отношений.

• Результаты Дня. Воспринимайте каждый день как новый шанс для достижения результатов. Каждый день создавайте новый список дел, в который в первую очередь вносите три главных результата дня («Правило 3-ех»), а уже после этого остальные дела. Таким образом, вы всегда будете помнить о том, что является для вас наиболее приоритетным.

• Результаты недели. Создавайте новый список на каждую неделю. Каждая неделя начинается с чистого листа — если вы оступились, у вас всегда должен быть шанс вернуться в строй. Всегда начинайте с трех самых важных результатов недели.

• Сильная Неделя. В течение недели старайтесь как можно больше времени заниматься делами, которые делают вас сильнее и как можно меньше теми, что делают вас слабее. Планируйте дела, которые заставляют вас почувствовать слабость, на начало дня. Установите границы — задачи, которые делают вас слабее, должны иметь жесткие временные ограничения. Не давайте таким задачам отнимать больше 20 процентов дня — либо ограничьте их количество, либо отведенное им время. Планируйте самые сложные, сильнее всего напрягающие задачи на начало недели. Будьте осторожны: не путайте дела, которые делают нас слабее со сложными вызовами, которые всегда укрепляют нас.

• Определение Границ Дня. Установите лимиты того, сколько времени вы будете уделять тем или иным делам. Ощущение того, что день это постоянная величина с неизменными границами, помогает расставлять приоритеты и управлять рабочим временем. Для старта можно поделить день на несколько крупных отрезков: управление, рабочее время, время для раздумий и время для общения.

• Разделение Задач. Делите предстоящие задачи на 4 группы: выполнить прямо сейчас, отложить, внести в календарь или делегировать. Выполните задачу немедленно, если сейчас это самое важное для вас дело или если выполнение этого дела в будущем отнимет у вас больше времени и потребует больших усилий. Отложите, если вам точно необходимо выполнить это дело, но сейчас не совсем подходящее время. Внесите в календарь, если вам понадобится определенный отрезок времени для выполнения этого дела. Делегируйте, если это дело должен выполнить кто-то другой.

• Месячный Спринт Улучшений. Выберите одну сферу, которую хотите улучшить за месяц. Каждый месяц выбирайте что-то новое, это позволит охватить 12 сфер за год. А если будет необходимо, вы всегда сможете повторить определенный спринт. Смысл в том, что тридцати дней как раз достаточно для эксперимента — за пару недель можно и не успеть рассмотреть прогресс, а вот через месяц все становится понятно.

• Мышление Развития. Решите, что вы всегда будете учиться и расти — такое решение должно быть вашим осознанным выбором. Решите, что если вас отправят в нокаут, вы подниметесь снова. Решите, что ни одну из проблем вы не будете считать слишком личной и нерешаемой.

• Списки дел. Группируйте дела по спискам. Подумайте о создании следующих списков: Результаты Дня, Результаты Недели, Отложенные Дела и Скрипты (списки часто выполняемых задач в рамках определенного проекта).

• Справочная информация. Не вся информация требует действий с вашей стороны. Да, она может быть очень ценной, но если она не требует действий, то она относится к Справочной информации. Отделите ее от задач и храните в виде отдельных заметок или списков.

3. Заключение

Полезные ссылки

Книга «Getting Results the Agile Way» доступна для бесплатного ознакомления онлайн на сайте GettingResults.
Там же можно почитать отзывы и кейсы, ознакомиться с базой знаний по методике, получить более подробное представление об основных принципах.

В печатном виде и в Kindle-версии книга есть на амазоне.

В блоге автора методики можно прочесть много полезного о личной эффективности и в частности, скачать pdf-брошюру (129 страниц) «30 Days of Getting Results», где он объясняет как освоить методику, изучая по одному ключевому уроку в течение 30 дней.

Мое мнение о книге «Getting Results the Agile Way»

Книга хорошая. Возможно, слегка суховата: никаких тебе веселых историй и лирических отступлений, хотя как по мне, так это скорее плюс. Автор не делает из своей системы секту и не использует прилагательные «восхитительная», «исключительная» и «феноменальная» не к месту.

Основным минусом книги для меня было то, что она написана как для чтения «от корки до корки» (как читал ее я), так и для использования в качестве руководства — можно открыть любую главу и начать внедрять, не читая остальные. И для того, чтобы книгу можно было использовать в качестве руководства, автору пришлось местами дублировать информацию об основных принципах и техниках между главами. Это минус, но не жирный.

Нужны ли подробности? Дайте фидбэк

Чтобы понять, стоит ли в следующих статьях углубляться в Agile Results (есть идеи по детальному рассмотрению системы — подробное саммари книги, практика использования, инструменты и т.д.), дайте мне знать, что вы хотите это прочитать.
Вершиной заинтересованности буду считать коммент к этой статье, но ретвиты, лайки и плюсодинки тоже сгодятся:) Спасибо за внимание.

Еще полезно прочитать по теме:

«Agile Results + Evernote. Как J.D. Meier использует Evernote для управления своей жизнью»

«Свежее Молоко — моя система использования Remember The Milk (GTD + Agile Results)»

«Agile Results + Mind Maps. Пример реализации»

«Реформируем понятие контекста в GTD: новая система из 7 контекстов»

90000 What is Agile Software Development? 90001
90002 Pre 2001 — Practices and Methods Develop Independently through Experience 90003
90004 A lot of people peg the start of Agile software development, and to some extent Agile in general, to a meeting that occurred in 2001 when the term Agile software development was coined. 90005
90004 However, people started working in an Agile fashion prior to that 2001 meeting. Starting in the mid-nineties, there were various practitioners, either people working inside organizations developing software products or consultants helping organizations build software who thought, «You know what? The way we’ve been building software just is not working for us.We’ve got to come up with something different. » 90005
90004 These software developers started mixing old and new ideas, and when they found a combination that worked, they created a methodology for their team to help them remember the combination of ideas that worked in a given situation. 90005
90004 These methodologies emphasized close collaboration between the development team and business stakeholders; frequent delivery of business value, tight, self-organizing teams; and smart ways to craft, confirm, and deliver code.90005
90004 The people who created those methodologies figured that others may be interested in getting some of the same benefits they were experiencing, so they created frameworks to spread the ideas to other teams in other organizations and contexts. This is where frameworks such as Scrum, Extreme Programing, Feature-Driven Development (FDD), and Dynamic Systems Development Method (DSDM), among others, started to appear. 90005
90004 The spread of the ideas at this time was very organic, and all of those different approaches started to grow in a very grassroots manner.People borrowed the original frameworks and tweaked them with different practices in order to make them appropriate for their own contexts. 90005
90002 2001 — Agile Manifesto Authored 90003
90004 There was not a consistent way of describing these different ways to develop software until a group of 17 people thought, «We’re all doing these different approaches to developing software. We ought to get together and see where there are commonalities in what we’re thinking about. » The result was a meeting at a ski resort in Snowbird, Utah in 2001.90005
90004 When they got together, they did some skiing and also discussed where their approaches to software development had commonalities and differences. 90005
90004 There were a lot of things that they did not agree upon, but there were a few things that they were able to agree upon, and that ended up becoming the Manifesto for Agile Software Development. The two main things the Agile Manifesto did was to provide a set of value statements that form the foundation for Agile software development and to coin the term Agile software development itself.90005
90004 In the months afterward, the authors expanded on the ideas of the Agile Manifesto with the 12 Principles Behind the Agile Manifesto. 90005
90004 Some of the authors, including Martin Fowler, Dave Thomas, Jim Highsmith, and Bob Martin, wrote up their recollections of writing the Agile Manifesto. 16 of the 17 authors met at Agile2011 and shared their recollections of the event and their views on the state of Agile up to that point. 90005
90002 Post 2001 — Adoption Started Grassroots, Became Mainstream 90003
90004 After the authors got back from Snowbird, Ward Cunningham posted the Agile Manifesto, and later the 12 Principles online at AgileManifesto.org. People could go online and sign it to show their support. 90005
90004 Agile Alliance was officially formed in late 2001 as a place for people who are developing software and helping others develop software explore and share ideas and experiences. 90005
90004 Teams and organizations started to adopt Agile, led primarily by people doing the development work in the teams. Gradually, managers of those teams also started introducing Agile approaches in their organizations. 90005
90004 As Agile became more widely known, an ecosystem formed that included the people who were doing Agile software development and the people and organizations who helped them through consulting, training, frameworks, and tools.90005
90004 As the ecosystem began to grow and Agile ideas began to spread, some adopters lost sight of the values ​​and principles espoused in the manifesto and corresponding principles. Instead of following an «agile» mindset, they instead began insisting that certain practices be done exactly in a certain way. 90005
90004 Organizations that focus solely on the practices and the rituals experience difficulties working in an Agile fashion. Organizations that are serious about living up to the Agile values ​​and principles tend to realize the benefits they sought and find that working in an Agile fashion is no longer something that’s new and different.Instead, it simply becomes the way they approach work. 90005
90004 Agile Alliance continues to curate resources to help you adopt Agile practices and improve your ability to develop software with agility. The Agile Alliance website provides access to those resources including videos and presentations from our conferences, experience reports, an Agile Glossary, a directory of local community groups and several other resources. 90005

.90000 System and Solution Architect / Engineering — Scaled Agile Framework 90001
90002 90003 90004
90005 90002 Engineering is a great profession. There is the satisfaction of watching a figment of the imagination emerge through the aid of science to a plan on paper. Then it moves to realization in stone or metal or energy. Then it brings homes to men or women. Then it elevates the standard of living and adds to the comforts of life. This is the engineer’s high privilege. 90004
90002 -Herbert Hoover 90004 90010

90011 90012 Find a Course 90013: 90014
Implementing SAFeLeading SAFeSAFe for ArchitectsSAFe for TeamsSAFe Scrum MasterSAFe Advanced Scrum MasterSAFe Product Owner / Product ManagerSAFe Release Train EngineerSAFe DevOps 90015 Go
90002 90017 90004

90002 90020 System Architect / Engineering 90021 is responsible for defining and communicating a shared technical and architectural vision for an Agile Release Train (ART) to help ensure the system or Solution under development is fit for its intended purpose.90004
90002 Solution Architect / Engineering is responsible for defining and communicating a shared technical and architectural vision across a Solution Train to help ensure the system or Solution under development is fit for its intended purpose. 90004
90002 System and Solution Architects describe the Solution Context and Solution Intent, analyze technical trade-offs, determine the primary components and subsystems, identify the interfaces and collaborations between them, define Nonfunctional Requirements (NFRs), guide Enablers through the Program and Solution Kanban systems , and work with Product and Solution Management, customers and Suppliers to help ensure fitness for purpose.90004
90002 They play a critical role in aligning teams on the ART and Solution Train to a shared technical direction and partner with those teams in elaborating the solution, validating technology assumptions, evaluating implementation alternatives, and creating the Continuous Delivery Pipeline. In ARTs that are not part of a Solution Train, System Architects also perform many of the activities of Solution Architects. 90004
90002 This article describes the roles that System Architect / Engineering and Solution Architect / Engineering play in SAFe.While the roles are similar in most respects, they manage different levels of concern. In some cases, there is more than one System Architect for an ART or Solution Architect for a Solution Train, thus these roles can be realized by an individual or a small team of people. 90004

90002 System and Solution Architect / Engineering support solution development by providing, communicating and evolving the broader technology and architectural view of the solution. 90004
90002 System Architect / Engineering operates mainly in the context of the ART, where they work with Agile Teams and provide technical enablement concerning subsystems and capability areas for an ART.Solution Architect / Engineering provide technical leadership for the evolving architectural capabilities of the entire solution in the context of a Solution Train. 90004
90002 Both involve close collaboration with business stakeholders, teams, customers, suppliers, and third-party stakeholders in defining the technology infrastructure, decomposing solutions, and systems into components and subsystems, and defining and managing their interfaces and APIs. While providing a general view of solution architecture, Architect / Engineering enables those who implement value by empowering them to make local decisions, allowing faster flow of work and better economics.90004
90011 An Agile Approach to Designing and Building Systems 90014
90002 Serving in an Architect / Engineering role in a Lean Enterprise often requires adopting new mindsets and habits in how people approach their work. This approach changes how architects apply their technical expertise and requires a systems-thinking mindset. These new habits fall into five areas, described below. For a more complete view of designing system and solutions in an agile manner, see Agile Architecture. 90004
90041
90042 90012 Customer-Centricity and Design Thinking 90013 — The choices made by architects have profound effects on the utility and usability of systems.A customer-centric mindset ensures that the needs of the users are first and foremost when making architectural choices. Design Thinking provides a common set of tools and practices to enable architects to collaborate with Product and Solution Management in ensuring that proposed solutions meet user, customer, and market needs. 90045
90042 90012 Decentralize decision-making 90013 — In a traditional approach, Architect / Engineering make critical design decisions relatively early in solution development, expecting teams working on different components to follow their designs.In the Agile approach, however, many technical details are left to evolve over time based on learning, with decisions finalized later in the lifecycle following a Set-Based Design approach. As a result, teams are trusted to make the local design decisions that adapt to changing needs without waiting for architects to produce new designs. 90045
90042 90012 Enable the Continuous Delivery Pipeline and DevOps 90013 — Making effective decisions in the face of changing or unknown needs requires Agile teams to receive fast feedback on the solution’s effectiveness.Architect / Engineering support this need by advocating for, and steering the development and improvement of, the Continuous Delivery Pipeline, as well as helping to enable Release on Demand. 90045
90042 90012 Embrace a Leadership role 90013 — Architect / Engineering are Lean-Agile Leaders who tend to operate more through influence than authority in a Lean enterprise. They have the greatest impact by teaching, mentoring, and helping improve the effectiveness of the Agile teams, rather than directly specifying the solution designs.And they contribute to the Vision and Roadmap in order to chart a course for the solution. 90045
90042 90012 Act as change agents 90013 — Architect / Engineering also acts on the human system that creates the technology to ensure greater agility and effectiveness. As Lean-Agile Leaders, Architect / Engineering ensure the organization operates effectively by participating as members of the Lean-Agile Center of Excellence (LACE). contributing to Value Stream Mapping workshops, and training and coaching engineers in achieving Technical Agility.90045
90062
90011 Responsibilities of System / Architect Engineering 90014
90002 System Architect / Engineering are Lean-Agile Leaders who typically have the following responsibilities: 90004
90041
90042 Participate in planning, definition, and high-level design of the solution and exploration of solution alternatives 90045
90042 Enable the Continuous Delivery Pipeline through appropriate design guidelines and investment advocacy 90045
90042 Actively participate in the Continuous Exploration process as part of the Continuous Delivery Pipeline, especially with enabler Epics 90045
90042 Define subsystems and their interfaces, allocate responsibilities to subsystems, understand solution deployment, and communicate requirements for interactions with solution context 90045
90042 Work with customers, stakeholders, and suppliers to establish high-level solution intent, and the solution intent information models and documentation requirements 90045
90042 Establish critical NFRs for the solution and participate in the definition of others 90045
90042 Operate within an economic framework when analyzing the impact of design decisions 90045
90042 Work with portfolio stakeholders, notably the Enterprise Architect, to develop, analyze, split, and realize the implementation of enabler epics 90045
90042 Participate in Program Increment (PI) Planning and Pre- and Post-PI Planning, System and Solution Demos, and Inspect and Adapt (I & A) events 90045
90042 Define, explore, and support the implementation of enablers to evolve solution intent, working directly with Agile teams to implement them 90045
90042 Plan and develop the Architectural Runway in support of new business Features and Capabilities 90045
90042 Work with Product and Solution Management to determine the capacity allocation for enablement work 90045
90042 Support technology / engineering aspects of program and solution Kanbans 90045
90042 Provide oversight and foster Built-In Quality and Team and Technical Agility 90045
90062
90011 System Architect / Engineering’s Participation in Large Value Streams 90014
90002 The above section highlights the role of System Architect / Engineering in the context of the ART.For Large Solutions that require multiple ARTs, System Architect / Engineering gains additional responsibilities that support alignment, including: 90004
90041
90042 90012 Collaborate with Solution Architect / Engineering 90013 — System Architect / Engineering collaborate with Solution Architect / Engineering to ensure discrete solutions created by each ART and supplier fit into and support the larger capabilities and direction of the overall solution. This involves participation in Solution Backlog refinement and prioritization, defining enabler capabilities and NFRs, and assigning architectural responsibilities to the various components and subsystems.A description of the relationship between these roles and the role of the Enterprise Architect can be found in the Enterprise Architect article. 90045
90042 90012 Participate in Pre- and Post-PI Planning 90013 — System Architect / Engineering participates in the pre-PI planning event, working with the Solution Train stakeholders to define the architectural approach, capability roadmap, and high-level objectives for the upcoming PI planning. In the post-PI planning event, System Architect / Engineering helps summarize findings into an agreed-to set of solution PI objectives and validates alignment of the various ART technical directions.90045
90042 90012 Participate in the Architecture Sync — 90013 System Architect / Engineering participates in the Architecture Sync to ensure consistency in how emerging designs and tradeoffs are managed across the Solution Train, allowing frequent opportunities to steer implementation approaches without becoming a source of delays. 90045
90042 90012 Participate in the Solution Demo 90013 — System Architect / Engineering participates in the solution demo, often demonstrating the capabilities that their ART has contributed and reviewing the contributions of the other ARTs, taking a systems view with an eye toward fitness for purpose.90045
90042 90012 Collaborate with release management 90013 — In larger-scale systems, release management also plays a significant role. System Architect / Engineers collaborate with Product Management and key stakeholders on progress, budget, release strategy, and releasability of elements of the solution. 90045
90042 90012 Aligning technology approaches across ARTs 90013 — System Architect / Engineering works actively with the Agile teams to ensure that emergent design choices are made with an understanding of the overall solution and minimize technology complexity and avoid unnecessary duplication of capabilities.90045
90062
90011 Responsibilities of Solution Architect / Engineering 90014
90002 Solution Architect / Engineering plays a similar role to System Architect / Engineering, but for large solutions, and are focused on creating technical alignment for the full solution rather than concerns for specific components. Responsibilities include working with portfolio stakeholders, customers, suppliers, ARTs and Solution Train stakeholders to align the architectural direction with the solution intent. They have similar responsibilities for solution vision, solution roadmap, solution Kanban, NFRs, enabler capabilities and solution demo activities as well.90004
90002 Solution Architect / Engineering has a crucial role in pre- and post-PI planning, as well as solution train I & A events. They also work with suppliers, making sure the technical characteristics for supplier-delivered capabilities are understood and assisting with the architectural integration of these concerns. 90004
90002 Solution Architect / Engineering works alongside Solution Management and the Solution Train Engineer as part of a trio that shares much of the responsibility for the success of a Solution Train.90004
90135
90011 Learn More 90014
[1] International Council on Systems Engineering. «What Is Systems Engineering?» https://www.incose.org/systems-engineering.
[2] Leffingwell, Dean. 90020 Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. 90021 Addison-Wesley, 2011 року.
[3] Kim, Gene and Jez Humble, Patrick Debois, John Willis. The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations. IT Revolution Press.Kindle Edition.
90002 Last update: 30 December 2019 90004
90002 90004

The information on this page is © 2010-2020 Scaled Agile, Inc. and is protected by US and International copyright laws. Neither images nor text can be copied from this site without the express written permission of the copyright holder. Scaled Agile Framework and SAFe are registered trademarks of Scaled Agile, Inc. Please visit Permissions FAQs and contact us for permissions.

.90000 Organizational Agility — Scaled Agile Framework 90001
90002 90003 90004
90005 90002 «Agility is the ability to adapt and respond to change … agile organizations view change as an opportunity, not a threat.» 90007 -Jim Highsmith 90004 90009

90002 90004

90002 The Organizational Agility competency describes how Lean-thinking people and Agile teams optimize their business processes, evolve strategy with clear and decisive new commitments, and quickly adapt the organization as needed to capitalize on new opportunities.90004 It is one of the seven core competencies of the Lean Enterprise, each of which is essential to achieving Business Agility.
90002 The Organizational Agility Self-Assessment, included at the end of this article, enables the enterprise to assess their proficiency in this competency and identify potential areas for improvement. The assessment is augmented by a set of ‘Organizational Agility Grows’, which are recommended improvement opportunities for developing mastery in this competency. 90004
90016 Why Organizational Agility? 90017
90002 In today’s digital economy, the only truly sustainable competitive advantage is the speed at which an organization can sense and respond to the needs of its customers.Its strength is its ability to deliver value in the shortest sustainable lead time, to evolve and implement new strategies quickly, and to reorganize to better address emerging opportunities. 90004
90002 Organizational agility is critical to respond sufficiently to the challenges. Unfortunately, the organizational structures, processes, and cultures of most businesses were developed more than a century ago. They were built for control and stability, not for innovation, speed, and agility. Small incremental changes to how businesses manage, strategize, and execute are insufficient to remain competitive.This requires a leaner and more agile approach which, in turn, requires sweeping changes that have a positive, long-lasting impact on the entire enterprise. 90004
90002 The SAFe approach to addressing the challenge of digital transformation is the ‘dual operating system’, (see Business Agility) one that leverages the stability and resources of the existing organizational hierarchy while implementing a value stream network that leverages the entrepreneurial drive still present in every organization.By organizing and reorganizing the enterprise around the flow of value instead of the traditional organizational silos, SAFe restores the second (network) operating system. It allows organizations to focus on both the innovation and growth of new ideas as well as the execution, delivery, operation, and support of existing solutions. 90004
90002 The organizational agility competency is instrumental in bringing the power of the second operating system to support the opportunities and threats of the digital age.This competency is expressed in three dimensions (Figure 1): 90004
90026 Figure 1. Three dimensions of organizational agility
90002 90028 Lean-Thinking People and Agile Teams 90029 — Everyone involved in solution delivery is trained in Lean and Agile methods and embraces their values, principles, and practices. 90007 90028 Lean Business Operations 90029 — Teams apply Lean principles to understand, map, and continuously improve the processes that deliver and support businesses solutions. 90007 90028 Strategy Agility 90029 — The enterprise is Agile enough to continuously sense the market, and quickly change strategy when necessary.90004
90002 Each of these dimensions is described in the sections that follow. 90004
90016 Lean-Thinking People and Agile Teams 90017
90002 Lean-thinking people and Agile teams is the first dimension of organizational agility. This dimension is critical to delivering business solutions-not just the software applications and digital systems, but all of the supporting activities (e.g., privacy, security, support, availability) necessary to continually address the business problem. Even the solution itself is not stand alone, it lives in the larger context of its environment-including other hardware, software, network systems, and more.90004
90002 Figure 2 illustrates how everyone involved in the delivery of business solutions-operations, legal, marketing, people operations, finance, development, and others-can apply effective Lean and Agile methods and embrace the mindset, principles, and practices. 90004
90045 Figure 2. Extending Lean and Agile thinking to the enterprise
90046 Extending the Mindset and Principles to the Enterprise 90047
90002 Extending the Lean-Agile mindset to the entire enterprise forms the cornerstone of a new management approach and results in an enhanced company culture that enables business agility.It provides leaders and practitioners throughout the enterprise with the thinking tools and behaviors needed to drive a successful SAFe transformation, helping individuals and the entire enterprise achieve their goals. 90004
90002 The Lean-Agile mindset establishes the right thinking, but it’s the ten underlying SAFe principles that guide effective roles, practices, and behaviors. These principles are fundamental to organizational agility and the Lean-thinking people and Agile teams who enable it.Everyone in the enterprise can apply these principles to their daily work, and thereby become part of the leaner, and more Agile, operating system. 90004
90046 Agile Technical Teams 90047
90002 As described in the Team and Technical Agility competency article, the emergence of Agile software development is fairly advanced and well understood. Now, with the advent of the DevSecOps movement, IT operations and security are also rapidly adopting Agile. Agile is also making its way to other technical domains, such as networking, operations, hardware, electronics, and more.After all, Agile technical teams typically achieve a degree of unprecedented performance and personal satisfaction with their work. Who does not want to be on a high-performing Agile team? 90004
90046 Agile Business Teams 90047
90002 Once the business understands this new way of working, it begins to recognize that the same benefits apply and typically starts creating cross-functional Agile business teams. These teams may be involved in any of the functions necessary to support developing and delivering business solutions, including the following: 90004
90060
90061 Sales, product marketing, and corporate marketing 90062
90061 Sourcing and supply chain management 90062
90061 Operations, legal, contracts, finance, and compliance 90062
90061 People operations (HR), training, and facilities 90062
90061 Receiving, production, fulfillment, and shipping 90062
90061 Customer service, support, and maintenance 90062
90073
90002 We’ve often observed a ‘three-step maturity cycle’ which illustrates how Agile business teams typically form and mature (Figure 3): 90004
90076 Figure 3.Agile business team maturity cycle
90077 Step 1: Be Agile 90078
90002 First, the teams adopt and master the Lean-Agile mindset and practices. This creates a universal value system and a shared understanding of what Agile is. But it goes beyond that. The SAFe Lean-Agile principles are equally important and, in some cases, even more so, guiding the right behaviors for business teams and their leaders. Just as the North Star guides people when they do not have a compass or a visible landmark to follow, the SAFe principles point the way to being Agile, even when specific Agile guidance does not exist for that function.90004
90077 Step 2: Join the Value Stream 90078
90002 Step 1 is a great start to help business teams become Agile, in both the mindset and the execution. However, if they only optimize and improve their efficiencies locally, the larger, end-to-end system may not improve. To optimize the system as a whole (Principle # 2, Apply systems thinking), most Agile business teams join the value stream by becoming part of an Agile Release Train (ART), which builds the business solutions they support. 90004
90002 How that works in practice depends on the scope and the nature of the work the teams do.For example, product marketing may be directly embedded in ARTs, as whole teams or inside other teams. In other cases, the marketing function may operate as a shared service, supporting several ARTs. Regardless, a common view of work, an alignment of terminology, a shared cadence, and synchronization across all of the teams all help the value streams deliver quickly and predictably with better quality. 90004
90002 In addition, system integration becomes even more integrated when supporting policies and procedures (e.g., licensing, privacy, security) become embedded in code, legal documents, operational workflows, and other artifacts which are part of the business solution. 90004
90077 Step 3: Specialize the Principles and Practices 90078
90002 The first two steps move the enterprise further on the path to business agility. However, as business teams mature, it becomes increasingly important for them to evolve their practices to define what Agile and built-in quality means in their context. In this way, they make it their own.Agile marketing is a good example. Since it is so tightly coupled to solution development, a set of Agile marketing principles has emerged that focuses on, among other things, validated learning, customer discovery, and iterative campaigns [1]. 90004
90046 Agile People Operations 90047
90002 All this new agility puts substantial pressure on how new employees are recruited and on changing policies and procedures for managing compensation and career growth. But addressing the needs of knowledge workers challenges many traditional human resources (HR) practices.In their place, ‘Agile HR’ brings the Lean-Agile mindset, values, and principles to hiring, engaging, and retaining people. 90004
90002 The advanced topic article, Agile HR with SAFe: Bringing People Operations into the 21st Century with Lean-Agile Values ​​and Principles, describes six themes for modernizing people operations. They are summarized below. 90004
90099
90061 90028 Embrace the new talent contract — 90029 This agreement recognizes the unique needs of knowledge workers and provides the engagement, empowerment, and autonomy they require to reach their full potential.90062
90061 90028 Foster continuous engagement — 90029 Continuous employee engagement occurs when everyone in the enterprise understands the business mission, is engaged in meaningful work, and is fully empowered to do their part. 90062
90061 90028 Hire for attitude and cultural fit — 90029 Identify, attract, hire, and retain people who will be most successful in the dynamic team environment of an Agile culture. 90062
90061 90028 Move to iterative performance flow — 90029 Many Lean enterprises have eliminated the annual performance review.Instead, leaders and managers offer fast, continuous, feedback and also solicit and receive feedback in return. 90062
90061 90028 Take the issue of money off the table — 90029 Replacing traditional, individual incentives with ‘the right’ incentives helps tailor compensation and motivation to the differing needs of roles and individuals in the next-generation workforce. 90062
90061 90028 Support impactful learning and growth — 90029 Modern careers are fueled more by personal choices and meaningful growth than by climbing a hierarchical ladder.Successful employers need to respond by providing rewarding work, more fluid roles, and personal growth paths. 90062
90124
90046 Agile Working Environments 90047
90002 In addition to more contemporary HR practices, experience and research have shown that working environments and physical spaces are vital to highly productive Agile teams (see Agile Workspaces and reference [2]). Physical space considerations include: 90004
90060
90061 Providing focused individual areas that enhance the state of mental flow 90062
90061 Supporting the need for constant informal team collaboration 90062
90061 Supporting the need for occasional privacy 90062
90061 Supporting distributed teams and working from home 90062
90061 Providing room for Daily Stand-ups, whiteboards, and walls to post objectives 90062
90061 Dedicating communication channels to support remote team members and other teams 90062
90073
90002 In addition, PI planning is a critical event in SAFe.As such, a semi-dedicated physical space for PI planning is recommended and will pay for itself over time. This topic, including some recommendations for physical space design and accommodations, is further described in the advanced topic article, Agile Workspaces: Facilities that Enhance Business Agility. 90004
90046 Visualizing Work 90047
90002 Frequently, during various SAFe training forums, attendees ask, «But if I was to leave here and do only one thing to start implementing Lean-Agile development at scale, what would it be?» Our answer is always the same: visualize the work.That is why when you visit an Agile enterprise, you see work everywhere-on walls, whiteboards, desktops, monitors, hallways, and wherever you look. Visualization converts the abstract to tangible; flushes out unnecessary, unplanned, unapproved, or duplicate work; and aligns everyone to the actual current state. 90004
90002 The common thread across all these approaches is that the information is always available: no effort is needed to go and discover it. Based on our experiences, we’ve recommended some starting points: 90004
90060
90061 90028 Visualize customers.90029 Agile teams use personas to bring the customer to life and post their representations on the walls of their team area, so they are always top of mind. 90062
90061 90028 Visualize the flow of work. 90029 Making the current work visible using Kanban systems exposes the amount of Work In Process (WIP), bottlenecks, and what people are really doing as opposed to what others think they are doing. 90062
90061 90028 Visualize solution health. 90029 Customer support teams have long seen the value in displaying the number of waiting calls, daily closed and open tickets, and current Service Level Agreements performance prominently on monitors close to the teams who rely on that information.This approach has been adopted by Agile teams to include metrics on the state of the current solution. 90062
90061 90028 Visualize strategy. 90029 Another example of visualizing work is an ‘investment corridor’ (Figure 4) that identifies all current and potential epics in flight. Rather than confining the portfolio visualizations to a room, information in the corridor is outside, making it easy for people to walk up and add their thoughts and suggestions. 90062
90073
90169 Figure 4. The investment corridor for a portfolio prioritization workshop (Courtesy of Travelport International LTD)
90046 Tooling and Automation 90047
90002 Organizations also invest in tooling to support productivity and automate processes, and to better support a distributed workforce.This tooling typically includes: 90004
90099
90061 90028 Agile Lifecyle Management solutions 90029 instantiate and connect the various backlogs and Kanbans teams use to manage their local work and provide enterprise-wide visibility. 90062
90061 90028 Continuous delivery pipeline 90029 tools support the large number of artifacts-primarily code, tests, scripts, metadata-and provide the automation that is needed to efficiently build and run the system. 90062
90061 90028 Integrated development environments 90029 provide the tools developers need to author, edit, compile, and debug software.90062
90061 90028 Collaboration tools 90029 support local and distributed development and the intense degree of interaction and cooperation that is required. 90062
90061 90028 Systems engineering tools 90029 support the modeling and information requirements of large systems and establish traceability across the elements supporting of quality assurance and compliance. 90062
90124
90002 Tooling also provides the enterprise with the opportunity to measure and improve these processes. Moreover, Lean-Thinking people and Agile teams have specific training and insights on how work flows through the system.They understand that optimizing one activity does not optimize the whole, and that delays in the process (see ‘mapping value streams’ below) have far more impact than the efficiency of any one step. 90004
90002 To combat this, Agile enterprises connect these tools to create an integrated toolchain or ‘tool network’ [3]. Only then will they be able to 90199 see 90200 the work as it flows through the system and to identify bottlenecks and opportunities for improving the entire value stream. 90004
90016 Lean Business Operations 90017
90002 Lean business operations is the second dimension of organizational agility.Organizational agility requires enterprises to understand both the operational value streams that deliver business solutions to their customers, as well as the development value streams (which are the primary focus of SAFe) that develop those solutions. 90004
90002 Figure 5 illustrates the relationship between operational and development value streams. 90004
90208 Figure 5. Operational and development value streams
90002 A trigger (e.g., product order or new feature request) starts the flow of value, and there’s some form of value delivered at the end.The steps in the middle are the activities used to develop or deliver the value. 90004
90002 For many developers, the people who run the operational value streams are the customers of the development value streams. They directly use, operate and support the solutions that support the flow of value to the end user. This requires that developers: 90004
90060
90061 Understand (and often help analyze and map) the operational value streams they support 90062
90061 Apply customer-centricity and design thinking to internal 90199 and 90200 external solutions 90062
90061 Include the business teams that support the solution in the development process 90062
90073
90002 These responsibilities help assure that the business solutions developed provide a ‘whole-product solution’ to satisfy the needs of both internal and external customers.90004
90046 Mapping Value Streams 90047
90002 90199 «Lean companies focus on value streams to eliminate non-value-creating activities. Good development systems consistently create profitable (operational) value streams 90200. «90004
90002 -Alan Ward 90004
90002 Identifying operational and development value streams is a critical task for every Lean enterprise. Once identified, value stream mapping is used to analyze and improve business operations [4]. Figure 6 illustrates a simplified example of value stream mapping, which, in this case, shows a few of the steps in a marketing program launch.90004
90235 Figure 6. Value stream mapping showing total lead time, total processing time, and time efficiency
90002 Teams look for the opportunity to improve the efficiency of each step, consequently reducing the total lead time. This includes reducing process time, as well as improving the quality of each step measured by the percent complete and accurate. (The percent complete and accurate represents the percentage of work that the next step can process without it needing to go back for rework.) 90004
90002 As is the case in the figure above, the delay time (the waiting time between steps) is often the biggest source of waste. If the team above wanted to deliver a marketing campaign faster, they would need to reduce the delay times, as the processing steps are only a small part of the total lead time. Reducing delays is typically the fastest and easiest way to shorten the total lead time and improve time to market. 90004
90046 Implementing Flow 90047
90002 In addition to mapping the value stream, the entire process can be visualized with a Kanban system as a means to continuously improve performance and identify bottlenecks.SAFe Principle # 6, Visualize and limit Work In Process (WIP), reduce batch sizes, and manage queue lengths, is then applied to optimize flow. Figure 7 illustrates a simplified Kanban system for a set of marketing campaigns associated with a major product launch. 90004
90244 Figure 7. A simple Kanban system for promotional campaigns for a new product launch
90002 Each marketing campaign, represented by a card, works its way through the system from the backlog to done. WIP limits (the numbers in parentheses in Figure 7) help control the amount of work in the system.90004
90016 Strategy Agility 90017
90002 Strategy agility is the third dimension of the organizational agility competency. Strategy agility is the ability to sense changes in market conditions and implement new strategies quickly and decisively when necessary. It also includes the good sense to persevere on the things that are working-or will work-if given sufficient time and focus. Figure 8 illustrates how strategy must respond to market dynamics to successfully realize the enterprise’s mission.90004
90251 Figure 8. Strategy responds to market dynamics
90002 Enterprises that have mastered strategy agility typically exhibit a number of capabilities, including those described in the following sections. 90004
90046 Market Sensing 90047
90002 Market sensing represents the culture and practice of understanding changing market dynamics based on the following: 90004
90060
90061 Market research 90062
90061 Analysis of quantitative and qualitative data 90062
90061 Direct and indirect customer feedback 90062
90061 Direct observation of the customers in the marketplace 90062
90073
90002 Savvy, Lean-thinking leaders ‘go see’ and spend significant time in the place where the customer’s work is actually performed.They return with current, relevant, and specific information about the realities of their products and services, instead of opinions filtered through other perspectives. 90004
90046 Innovating Like a Lean Startup 90047
90002 After sensing opportunities, the Lean enterprise visualizes and manages the flow of new initiatives and investment by adopting a ‘build-measure-learn’ Lean startup cycle. These initiatives are often new business solutions, but they may also be new business processes and capabilities that use existing solutions.Testing the outcome hypothesis via a Minimum Viable Product (MVP) before committing to a more significant investment reduces risk while generating useful feedback. 90004
90046 Implementing Changes in Strategy 90047
90002 Identifying and defining a new strategy is only the first step. Once determined, the strategy must be communicated to all stakeholders in a new vision and roadmap and then, of course, be implemented. After all, significant changes to strategy often affect multiple solutions in the portfolio and require coordination and alignment.Consequently, most large strategy changes require new epics to implement the change across value streams. 90004
90002 Figure 9 illustrates how new epics go through the various Kanban systems and backlogs that manage the flow of work. During the normal course of work all backlogs are continuously reprioritized. Kanban systems help changes in strategy move quickly across value streams to the teams who do the implementation. This way, execution is aligned-and constantly realigned-to the evolving business strategy.90004
90002 90004
90282 Figure 9. Strategy change makes its way quickly through the network of dynamic backlogs
90002 However, other smaller, local changes may require only new stories or features and will go directly in the team or program backlogs. 90004
90046 Innovation Accounting 90047
90002 It can take a long time to evaluate the benefits of a change in strategy. Traditional financial and accounting metrics Profit and Loss (P & L) and Return On Investment (ROI) are lagging economic indicators that occur too late in the life cycle to inform the evolving strategy.In their place, Innovation Accounting applies leading indicators-actionable metrics focused on measuring specific early outcomes using objective data. They are an essential part of the economic framework that drives business agility. 90004
90046 Ignoring Sunk Costs 90047
90002 A key factor in strategy agility is ignoring sunk costs, the expenses that have already occurred in the course of solution development. Sunk costs can not be recovered or changed and are independent of any future costs a company may incur [5].Because strategic decision-making affects only the future course of business, sunk costs are absolutely irrelevant when evaluating a change in strategy. Instead, decision-makers should base all strategy decisions solely on the future costs of the initiatives necessary to achieve the change. When stakeholders do not have to waste energy to defend past spending, the organization can pivot more quickly to a new strategy. 90004
90046 Organizing and Reorganizing Around Value 90047
90002 Finally, SAFe Principle # 10 — Organize around value guides enterprises to align their development efforts around the full, end-to-end flow of value.This principle highlights the ‘dual operating system,’ one that leverages the benefits of the existing hierarchy but also creates a value stream network (Figure 10 below). This network assembles the people who need to work together, aligns them to the needs of the business and customer, minimizes delays and handoffs, and increases quality. 90004
90297 Figure 10. The network operating system of SAFe can be reorganized quickly around changing strategy
90002 But as strategy moves, future value moves with it; new people and resources must be applied.In other words, some degree of reorganization is required. Indeed, in some cases, this will require entirely new value streams be formed to develop and maintain new solutions. Other value streams may need to be adjusted, and some will be eliminated entirely as solutions are decommissioned. Fortunately, the people and teams of an increasingly Agile enterprise see those changes coming through the portfolio. They can then use their new knowledge and skills to reorganize Agile teams and ARTs around value whenever it makes sense.90004
90016 Agile Contracts 90017
90002 No portfolio is an island. Instead, each typically depends on other portfolios, suppliers, partners, operational support, and more, all of which require implicit or explicit contracts for the value to be delivered. Traditionally, these contracts are based on the assumption that requirements, deliverables, and service levels are known up front and will remain stable. We know from experience that is just not true. As strategy changes, these traditional contracts can become enormous impediments that lock the business into assumptions of a former strategy.Although the business would like to change strategy, it is blocked by existing contracts. 90004
90002 Achieving business agility requires a more flexible approach to all types of contracts. How this is achieved depends on the nature and type of contract, but each must be considered in terms of the adaptability that may be required as strategy evolves. Contracts for suppliers that provide components, subsystems, or services for enterprise solutions are particularly critical as they may tend to lock solution elements into requirements that were fixed long before.The Agile Contracts advanced topic article provides guidance on contracting strategies that can provide the needed flexibility 90004
90016 Measure and Grow 90017
90002 In order to provide further insights into an organization’s proficiency in the practices of Organizational Agility, a detailed assessment for this competency can be downloaded from the link below. 90004
Download Organizational Agility Assessment
90002 Based on the results of this self-assessment, the Organizational Agility Grows are a set of recommended improvement opportunities that support the development of mastery in this competency.90004
90002 The Measure and Grow article further describes how enterprises can assess where they are on their journey to Business Agility and provides a downloadable self-assessment for that purpose. That assessment is a high-level view that measures the seven competencies and briefly touches on each dimension of Business Agility. 90004
90016 Summary 90017
90002 Without organizational agility, enterprises can not react fast when things happen. To be fully responsive to threats and opportunities requires Lean and Agile ways of working to spread throughout the entire organization.This change demands a workforce that is not only trained in Lean-Agile practices, but one that understands and embodies the culture, values, and principles. 90004
90002 Lean business operations recognize that delighting customers goes further than purely solution development. The entire customer journey, which includes delivering, operating, and supporting business solutions, needs to be continually optimized to reduce time to market and increase customer satisfaction. Strategy agility provides the ability to sense and respond to changes in the market, to evolve and implement new strategies quickly, and to reorganize when necessary to address emerging opportunities.As a result, ‘change becomes an opportunity, not a threat.’ 90004
90002 90004
90322
90016 Learn More 90017
[1] https://agilemarketingmanifesto.org/
[2] Hesselberg, Jorgen. 90199 Unlocking Agility: An Insider’s Guide to Agile Enterprise Transformation 90200 (Addison-Wesley Signature Series (Cohn)) Pearson Education. Kindle Edition.
[3] Kersten, Mik. 90199 Project to Product. 90200 IT Revolution Press. Kindle Edition.
[4] Martin, Karen. 90199 Value Stream Mapping: How to Visualize Work and Align Leadership for Organizational Transformation.90200 McGraw-Hill Education. Kindle Edition.
[5] https://www.investopedia.com/ask/answers/042115/why-should-sunk-costs-be-ignored-future-decision-making.asp
90002 Last updated: 6 July 2020 90004
90002 90004

The information on this page is © 2010-2020 Scaled Agile, Inc. and is protected by US and International copyright laws. Neither images nor text can be copied from this site without the express written permission of the copyright holder. Scaled Agile Framework and SAFe are registered trademarks of Scaled Agile, Inc.Please visit Permissions FAQs and contact us for permissions.

.90000 Team and Technical Agility — Scaled Agile Framework 90001
90002 90003 90004
90005 90002 Continuous attention to technical excellence and good design enhances agility. 90007 -Agile Manifesto 90004 90009

90002 90004

90002 The Team and Technical Agility competency describes the critical skills and Lean-Agile principles and practices that high-performing Agile teams and Teams of Agile teams use to create high-quality solutions for their customers. 90004
90002 It is one of the seven core competencies of the Lean Enterprise, each of which is essential to Business Agility.The Team and Technical Agility Self-Assessment, included at the end of this article, enables the enterprise to assess their proficiency in this competency and identify potential areas for improvement. 90004
90002 In support of this, the Team and Technical Agility Grows are a set of recommended improvement opportunities for developing mastery in this competency. 90004
90018 Why Team and Technical Agility? 90019
90002 Agile teams and teams of Agile teams create and support the business solutions that deliver value to the enterprise’s customers.Consequently, an organization’s ability to thrive in the digital age is entirely dependent on the ability of its teams to deliver solutions that reliably meet a customer’s needs. The team and technical agility competency is the real cornerstone of Business Agility. It consists of three dimensions, as illustrated in Figure 1. 90004
90022 Figure 1. The three dimensions of team and technical agility
90023
90024 Agile Teams — High-performing, cross-functional teams anchor the competency by applying effective Agile principles and practices.90025
90024 Team of Agile Teams — Agile teams operate within the context of a SAFe Agile Release Train (ART), a long-lived, team of Agile teams that provides a shared vision and direction and is ultimately responsible for delivering solution outcomes. 90025
90024 Built-in Quality — All Agile teams apply defined Agile practices to create high-quality, well-designed solutions that support current and future business needs. 90025
90030
90002 Agile teams create an environment that maximizes innovation, value delivery, and sustainability.Teams unite around a shared purpose and apply a Lean-Agile, flow-based delivery model. ARTs provide the structure needed to align multiple teams to a common mission. Built-in quality guarantees that team members have the skills and practices to create the best possible solutions. These three dimensions are complementary and dependent forces that shape the high-performing units that power SAFe and, ultimately, the entire enterprise. 90004
90018 Agile Teams 90019
90002 The Agile team is the basic building block of Agile development.It is the first dimension of this competency. The SAFe Agile team is a cross-functional group of 5-11 individuals who can define, build, test, and deliver an increment of value in a brief timebox. These teams have the authority and accountability to manage their own work, which increases productivity and reduces time-to-market. Agile teams commit to small batches of work, allowing them to shorten feedback cycles and adjust to changing needs. 90004
90002 Although originally envisioned for software teams, the Agile Manifesto’s values ​​(Figure 2) and principles have proven invaluable in guiding the creation of high-performing teams of all types in technology and business.Its insights, shown below, apply to and will benefit any type of team: 90004
90023
90024 Be collaborative 90025
90024 Ship frequently 90025
90024 Use objective measures for progress 90025
90024 Interact with customers frequently 90025
90024 Expect and support change 90025
90030
90002 Many other disciplines have already successfully applied the Manifesto to their domains, including hardware development, marketing, and supply chain management, to name a few. 90004
90053 Figure 2.Agile Manifesto four values
90002 While organizations commonly align for functional excellence, value delivery spans functional silos. Therefore, all Agile teams are cross-functional, with all the people and skills needed to deliver value 90055 across 90056 traditional organizational silos, largely eliminating handoffs and delays (Figure 3). Individual members are committed full time to one team, which reduces multiplexing, reduces overhead, and provides singleminded purpose. 90004
90058 Figure 3.Agile teams are cross-functional
90002 90004
90002 Agile teams have two specialty roles (Figure 4). 90062 The Product Owner 90063 defines Stories (along with other team members) and prioritizes the team backlog to streamline the execution of program priorities, while also maintaining the conceptual and technical integrity of the Features or components the team is responsible for. 90062 The Scrum Master 90063 is a servant leader and coach for the team, instilling the agreed-to Agile process, removing impediments, and fostering an environment for high performance, continuous flow, and relentless improvement.90004
90067 Figure 4. Agile teams include two specialty roles
90002 Agile teams have all the skills necessary to define, build, test, and deploy value in short iterations. They are empowered, collaborative, and focused on shared goals. To deliver and sustain value to customers, they can be software teams, hardware teams, business teams, operations teams, support teams, or a cross-cutting team of multiple disciplines. 90004
90002 Typically, Agile teams employ a blend of Agile methods, including Scrum, XP, and Kanban.Most configure their work events using the following Scrum practices: 90004
90023
90024 Work in short iterations, typical two-week 90025
90024 Break work into small user stories managed in team backlogs 90025
90024 Plan the work together for the upcoming iteration 90025
90024 Have Daily Stand-Up (DSU) meetings to communicate and assess progress towards iteration goals 90025
90024 Demonstrate working solutions continuously, or at the end of each iteration 90025
90024 Discuss how to improve the process before starting the iteration cycle 90025
90030
90002 To optimize flow, teams visualize and manage their work progress using a Kanban system.Kanban boards help teams identify bottlenecks to improve flow and limit work-in-process (WIP) to ensure teams finish work before starting new stories. An example appears in Figure 5 below. 90004
90088 Figure 5. One team’s initial Kanban board
90018 Teams of Agile Teams 90019
90002 Building enterprise-class solutions typically requires more scope and breadth of skills than a single Agile team can provide. No lone team has the capacity to build and deliver large systems within a reasonable timeframe.And significant systems require a broad range of specialty skills that can not be contained within a single Agile team. Therefore, multiple Agile teams must collaborate. SAFe’s Agile Release Train (ART) is a long-lived team-of-Agile-teams, which-along with other stakeholders-incrementally develops, delivers, and where applicable operates, one or more solutions (Figure 6). 90004
90093 Figure 6. Agile Release Trains build, deliver, and support significant solutions
90002 Organized around the enterprise’s value streams, ARTs align teams to a common business and technology mission.They exist to realize the promise of value by building and delivering solutions that benefit the end user. In order to ‘build and run’ significant systems, ARTs require broad skills, including operations, supply chain, security, compliance, product marketing, distribution, training, support, legal, finance, licensing, product management, R & D, procurement, contracts, suppliers, manufacturing, and engineering. These members may form their own teams, join other teams, or function as a Shared Service (specialty roles, people, and services required for value delivery, but are not required full-time on any one team).Wherever they appear, all are members of the ART and participate in all ART events and commit to the ART’s plans and deliverables with other members. 90004
90002 The SAFe core value of Alignment ensures that teams work toward a common objective and to create value together. Short iterations provide a regular heartbeat that synchronizes all work and events. Like Agile teams, ARTs plan together, commit together, execute together, and retrospect 90055 together 90056. 90004
90100 Portfolio Alignment 90101
90002 The ART focuses on fast execution and value delivery.To ensure it creates the right value, the ART aligns to the portfolio vision, and through it, to the Enterprise strategy. This connection of strategy to execution permits decentralized decision-making and allows the ART to achieve its intended purpose with near autonomy. 90004
90002 Alignment with the portfolio, however, requires constant engagement with the portfolio stakeholders responsible for the direction of the train. Business Owners are involved in ART events and continuously provide guidance, communicating back to the rest of the portfolio about where the train is headed and why.90004
90018 Built-in Quality 90019
90002 Built-in Quality powers the lean goal of 90055 delivering value in the shortest sustainable lead time 90056. It should be no surprise, then, that it’s one of the SAFe Core Values, as well as the third dimension of the Team and Technical Agility competency. 90004
90002 All Agile teams-software, hardware, business, or other-must create quality solutions and define their own built-in quality practices. Work quality also directly affects the ability to deliver predictably and meet commitments.To avoid rework and delays, quality must be ‘built into’ value creation, not ‘inspected in’ later. In addition, by working in small batches, different individuals in cross-functional teams will be able to update work artifacts frequently. To support their ‘collective ownership’ of artifacts, code, and other content, Agile teams adhere to standards and processes. They also continually improve their product quality through refactoring and by reducing technical debt. 90004
90002 The remainder of this section presents general quality practices that apply to all types of Agile teams.For more information, SAFe’s Built-in Quality article describes software and hardware development quality practices. And several SAFe Advanced Topics articles discuss quality practices, including: 90004

90002 Non-development teams can use these articles as guidance on best practices to adopt for their discipline and work products. 90004
90100 Establish Flow 90101
90002 To develop and release high-quality work products quickly, Agile teams operate in a fast, flow-based environment. Creating flow requires eliminating the traditional start-stop-start project initiation and development process, along with the incumbent phase gates that hinder progress.Instead, 90055 teams visualize and limit work in process (WIP), reduce the batch sizes of work items, and manage queue lengths 90056 (SAFe Principle # 6). They also base milestones and measures on 90055 objective evaluation of working systems 90056 (SAFe Principle # 5). 90004
90002 Teams build a Continuous Delivery Pipeline (CDP) to shepherd new pieces of functionality from ideation to an on-demand release of value to the end user. Unlike traditional project management, where success is measured by completing an entire initiative on time and on budget, Agile teams quickly release small, 90055 Minimal Marketable Features (MMF) 90056 to learn and adapt.Small features flow through the system quickly to provide feedback and allow course correction. 90004
90100 Peer Review and Pairing 90101
90002 Peer review and pairing create built-in quality 90055 during 90056 development. Peer review provides feedback on another team member’s WIP before release. When pairing, two or more team members work on the same item together. Both create and maintain quality because the work will contain knowledge, perspectives, and best practices from multiple members.They also raise and broaden the skillset for the entire team as teammates learn from each other. 90004
90002 Teams often apply both practices, with some teams pairing frequently. Other teams use reviews for feedback and pair when addressing a challenging problem or performing an activity that requires diverse skills. Regardless of the approach, all artifacts are subject to multiple sets of eyes and perspectives before ever being accepted or released. 90004
90100 Collective Ownership and Standards 90101
90002 Collective ownership means that anyone can change an artifact to improve its quality.This reduces dependencies between and within teams, and ensures that a member’s absence does not block progress. 90004
90002 Because the work is not ‘owned’ by one team or individual, standards are required to assure consistency, enabling everyone to understand and maintain the quality of each work product. Standards also provide lightweight governance to help assure that individuals do not make a local change that has an unintended, system-level consequence. 90004
90100 Automation 90101
90002 Agile teams automate repetitive, manual tasks to increase speed and ensure they are performed accurately and consistently.Teams typically automate in two ways. 90004
90148
90024 They automate the processes that build, deploy, and release the solution. This process takes the teams ‘raw artifacts (code, models, images, content, etc.), generates production versions as necessary, integrates them across teams and ARTs, and makes them available in a production environment. 90025
90024 They automate the quality checks along this path to ensure standards are followed, artifacts meet quality levels (e.g., broken link and spelling checkers), etc.90025
90153
90002 Some disciplines have products that provide these types of automation (e.g., software development, content creation, and publishing). However, these solutions are rarely complete and almost always require some form of scripting or development. In the spirit of cross-functional teams and ARTs, it’s common to see software developers join non-software teams and ARTs to support their automation needs. 90004
90002 SAFe’s Systems Team supports teams and ARTs by developing and maintaining many of the automation practices discussed here.Those Systems Team members have prior experiences automating in multiple domains and provide a unique perspective on the approach and the technology needed to support automation goals. 90004
90100 Definition of Done 90101
90002 Agreeing on a ‘Definition of Done’ (DoD) is a standard way to ensure that artifacts and larger increments of value can only be considered finished when they demonstrate the agreed level of quality and completeness. Teams and ARTs use the DoD to ensure they agree on and follow a common set of practices when completing work.For example, a few DoD conditions might be to: 90004
90023
90024 Require work to be peer-reviewed 90025
90024 Show all quality tests passed successfully (ideally automated) 90025
90024 Ensure that all associated files have been checked-in and delivered 90025
90024 Ensure all versions have been generated and published 90025
90024 Check that email notifications have been sent 90025
90030
90002 These agreements align teams around 90055 what 90056 quality means and 90055 how 90056 it is built into the solution.90004
90018 Measure and Grow 90019
90002 In order to provide further insights into an organization’s proficiency in the practices of Team and Technical Agility, a detailed assessment for this competency can be downloaded from the link below. 90004
Download Team and Technical Agility Assessment
90002 Based on the results of this self-assessment, the Team and Technical Agility Grows are a set of recommended improvement opportunities that support the development of mastery in this competency.90004
90002 The Measure and Grow article further describes how enterprises can assess where they are on their journey to Business Agility and provides a downloadable self-assessment for that purpose. That assessment is a high-level view that measures the seven competencies and briefly touches on each dimension of Business Agility. 90004
90018 Summary 90019
90002 Although organizational hierarchies and organization by function provide time tested structures, practices, and policies, they simply can not provide the speed and quality needed for the digital age.In contrast, team and technical agility focuses on organizing cross-functional Agile teams that apply the best of Agile methods and techniques, without being bound to any one specific Agile way of working. This approach creates long lived teams that apply built-in quality practices throughout the product lifecycle; they learn together and grow together. 90004
90002 Further, these teams form cross-functional teams of Agile teams (ARTs) that are aligned along the enterprise value streams and are thereby able to cover the full development lifecycle, from inception, to deployment and production.90004
90002 These teaming constructs help instantiate the second operating system, which gives the enterprise the resiliency and adaptability it needs to deliver value directly, with far fewer dependencies, handoffs, and delays. The result is more innovative business solutions, delivered to the market more quickly than ever before. 90004
90002 90004
90198
90018 Learn More 90019
[1] Manifesto for Agile Software Development. http://agilemanifesto.org/.
[2] Leffingwell, Dean. Scaling Software Agility: Best Practices for Large Enterprises.Addison-Wesley, 2007.
[3] Beck, Kent. Test-driven Development: By Example. Addison-Wesley. 2000
90002 90004
90002 Last update: 24 September 2019 90004
90002 90004

The information on this page is © 2010-2020 Scaled Agile, Inc. and is protected by US and International copyright laws. Neither images nor text can be copied from this site without the express written permission of the copyright holder. Scaled Agile Framework and SAFe are registered trademarks of Scaled Agile, Inc. Please visit Permissions FAQs and contact us for permissions..