Agile система: Что такое Agile, зачем и где используется, разница Scrum и Kanban

Топ-5 инструментов управления Agile-проектами / Блог компании DataArt / Хабр

Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта.

Agile-манифест

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

Процесс разработки со стороны не кажется таким уж сложным: команда программистов получает задание и финансирование, на выходе выдает продукт, который нужен заказчику.


Идеальный рабочий процесс.

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

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

Для небольшого проекта обнаружить причин ухудшения — задача не сверхсложная. К сожалению, это нельзя сказать о проектах, в которых сразу несколько команд вовлечены в процесс разработки одного и того же продукта.


Эффективность и качество разработки зависят от целого ряда факторов:

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

Вне сомнений, неотъемлемая часть выпуска успешного программного продукта — грамотная организация рабочего процесса. Инструменты управления проектами как раз и призваны помогать в решении подобных проблем.

Использование хороших инструментов управления позволяет клиенту получить ясную картину, как команда справляется с поставленным задачами, оценить степень готовности продукта к концу очередного спринта/итерации.


Содержание

Обзор

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

В опросе участвовали 39 человек из 32 проектов, их роли распределились следующим образом:


Роли респондентов.

Среди инструментов управления Agile-проектами самыми популярными стали:

  • Jira
  • TFS
  • Version One
  • Rally
  • Spreadsheet


































Параметр
Лицензия
Proprietary/Free community licenses for open source and academic projects
Proprietary, hosted
Proprietary/Free trial
Proprietary, Commercial
ICU license
Цена
Гибкая ценовая политика/бесплатная пробная версия
Гибкая ценовая политика/бесплатная пробная версия
Гибкая ценовая политика/бесплатная пробная версия
Гибкая ценовая политика
бесплатная
Платформа
Web-Based/Installed
Web-Based
Web-Based
Web-Based/Installed
Web-Based
Предполагаемые пользователи
фрилансеры крупный/средние/мелкие компании, некоммерческие компании
фрилансеры крупный/средние/мелкие компании, некоммерческие компании
фрилансеры крупный/средние/мелкие компании
крупный/средние/мелкие компании
фрилансеры, мелкие компании
Управление бэклогом через Drag-and-drop
Полная поддержка
Полная поддержка
Полная поддержка
Полная поддержка
Отсутствует
Просмотр доски задач
Присутствует
Присутствует
Присутствует
Присутствует
Присутствует
 
 
 
 
 
 
Диаграмма сгорания задач на итерацию
Присутствует
Присутствует
Присутствует
Присутствует
Отсутствует
Epics (hierarchy of backlog items)
Частичная поддержка
Полная поддержка
Частичная поддержка
Частичная поддержка
Отсутствует
Поддержка Rollup’ов
Частичная поддержка
Полная поддержка
Частичная поддержка
Частичная поддержка
Отсутствует
Планирование и  отслеживание релиза/итерации

Частичная поддержка
Полная поддержка
Полная поддержка
Полная поддержка
Частичная поддержка
Роадмаппинг продукта(multiple releases)
Отсутствует
Полная поддержка
Полная поддержка
Отсутствует
Частичная поддержка
Несколько продуктов/проектов
Полная поддержка
Полная поддержка
Полная поддержка
Полная поддержка
Частичная поддержка
Portfolio planning
Отсутствует
Полная поддержка
Полная поддержка
Частичная поддержка
Отсутствует
Управление процессом тестирования (Acceptance and Regression)

Частичная поддержка
Полная поддержка
Полная поддержка
Полная поддержка
Частичная поддержка
Средства оповещения
Email
Email
Email
Email
Отсутствует
Отслеживание сдерживающих факторов
Отсутствует
Полная поддержка
Полная поддержка
Полная поддержка
Частичная поддержка
Отслеживание дефектов
Частичная поддержка
Полная поддержка
Полная поддержка
Полная поддержка
Частичная поддержка
Пользовательские роли
Отсутствует
PO, SM, Team Member, Stakeholder, plus custom roles.
SM, PO, Team Member.
Отсутствует
Отсутствует
Интеграция, API(s), SDK
Присутствует(REST API)
SDK.Java, SDK.NET, SDK.Python, SDK.Javascript
SDK.Java, SDK.NET, SDK.Ruby, SDK.Nodejs
SDK.Java, SDK.NET
SDK.Java, SDK.NET
Поддержка
Email/Phone Community Website
Email/Phone Community Website
Email/Phone Community Website
Email/Phone Community Website
форумы
Дополнительный сервис
Отсутствует
Тренинги и сертификация
Отсутствует
Тренинги и сертификация
Отсутствует

Документация
****
**
**
**
***
Удобство использования
***
**
***
***
***
Плюсы
Большое пользовательское сообщество, поддержка различных языков,, 600+ plugins and add-on, мобильный
Бесплатная пробная версия для команды до 10 человек.

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

Наличие roll-up  для юзер стори и фич;

Наличие интегрированного в среду инструмента для менеджмента дефектов

 
Обладает полезными фичами для управления agile проектами
Отлично подходит для небольших команд и относительно простых процессов
Минусы
Недостаточно информативный бэклог и средства по sprint management tools

 отсутствие burndown и информативного репортинга из коробки

 
Сложный User Interface

Отсутствие возможности работать с мобильного девайса;

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

нет простого механизма для линковки стори и фич к айтемам более высого уровня.

Отсутствие удобного средства доя репортинга из коробки
решение очень сильно завязан на другие продукты из линейки Microsoft
Много ручной работы

 

VersionOne

URL: www.versionone.com
Ключевые особенности VersionOne

  • управление Agile Portfolio;
  • репортинг и аналитика;
  • планирование и роадмаппинг продукта;
  • планирование и роадмаппинг релиза;
  • планирование спринта;
  • управление процессом тестирования;
  • открытый API для интеграции.

Краткий обзор VersionOne

Универсальный инструмент управления проектами и командами любого размера. VersionOne считаются пионерами в производстве ПО для управления Agile-продуктами. По сей день они остаются компанией, всецело преданной философии Aglie.

Тарифы VersionOne

www.versionone.com/pricing_and_editions





Team
Catalyst
Enterprise
Ultimate
10 user pack free
20 user pack($175/month)
$29 user/month
$39 user/month

 

Механизм ценообразования: фримиум бизнес-модель, согласно которой основные услуги предоставляются бесплатно, но за дополнительные нужно заплатить.

Преимущества использования

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


Скриншоты

JIRA

Ключевые особенности JIRA

  • Контроль проекта.
  • Agile, Scrum, Kanban.
  • Планирование проекта.
  • Учет ошибок (Issue Tracking).
  • Возможность интеграции с кодом.
  • Служба техподдержки.
  • Доступность с мобильных девайсов.
  • Возможность кастомизации рабочего процесса.
  • Составление отчетности.
  • Аутентификация через LDAP и Active Directory.
  • Система учета ошибок (Bug Tracking).
  • Интеграция с Git.
  • 1000+ всевозможных дополнений, расширений, плагинов.
  • Email-уведомления.
  • Возможность самостоятельно определять и изменять вычислительные потребности (On Demand).
  • Бесплатна для Open source-проектов.

Краткий обзор JIRA

Тысячи команд выбрали JIRA, чтобы организовать процесс, распределять работу и отслеживать деятельность команды. Используя стационарный или мобильный интерфейс, JIRA помогает команде выполнять работу.

Отслеживание ошибок достигается во многом за счет глубокой интеграции с исходным кодом и средой разработки.

Отслеживание проекта: JIRA позволяет централизованно управлять всеми проектами, не теряя из виду общую картину.

Разработка ПО

После системы контроля версий JIRA — самое важное приложение в для команды разработчиков, поскольку позволяет достаточно легко адаптироваться к использованию scrum и Kanban.

Рабочий процесс

Используйте JIRA, чтобы грамотно организовать работу команды, расставить приоритеты и поскорей приступить к решению наиболее важных задач, оставаясь в курсе происходящего вокруг.С JIRA это все получается достаточно просто, т.ч. ваша команда может тратить меньше времени на администрирование работы и уделять больше внимания созданию продукта.

Работа внутри команды

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

Сбор ошибок

С JIRA Service Desk команда получает современный гибкий сервис поддержки, который способен оптимально организовать запросы от клиентов.

Детали








Потенциальные пользователи
Крупные предприятия, предприятия среднего бизнеса, некоммерческие организации, государственные органы, предприятия малого бизнеса
Поддерживаемые страны
Азия, Австралия, Канада, Китай, Европа, Индия, Латинская Америка, Ближний Восток и Африка, Соединенное Королевство, Соединенные Штаты Америки
Поддерживаемые языки
Китайский (традиционный), чешский, датский, английский, французский, немецкий, итальянский, японский, польский, португальский, русский, испанский
Варианты поддержки
FAQs, Forum, Knowledge Base, Online Support, Phone Support, Video Tutorials
Категории
Project Management Software • Project Collaboration Software • Issue Tracking Software • Agile Project Management Software • Startup solutions Software •Bug Tracking Software

 

Тарифы JIRA

www.atlassian.com/software/jira/agile

Облако





10 users
15 users
25 users
50 users
100 users
500 users
2,000 users
$ 10/mo
$ 25/mo
$ 50/mo
$ 100/mo
$ 150/mo
$ 250/mo
$500/mo

Сервер





10 users
25 users
50 users
100 users
101+ users
$ 10 Starter
$ 600
$ 1,100
$ 2,000
$4,000

 

Механизм ценообразования: подписка.

Бесплатная пробная версия: доступна.

Преимущества использования:

Agile в масштабе

Scrum и Kanban повышают вероятность успеха проекта. JIRA интегрируется с GitHub, чтобы связать дефекты с соответствующими исправлениями.

Движок для создания рабочего процесса.

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

Пользовательский опыт

Создавайте, обновляйте и работайте с дефектами, используя быстрый и интуитивно понятный веб-интерфейс с большим набором горячих клавиш.

Гибкие панели мониторинга (Dashboards)

Создавайте свой личный JIRA дашборд, позволяющий в удобном для вас виде отслеживать состояние проекта, создавать пользовательские отчеты.

Мощный инструмент поиска и отчетности

Используйте JIRA’s Query Language (JQL) с автозаполнения для создания расширенных запросов. Такие запросы позволяют отслеживать статус проекта, включать необходимые метрики в отчеты, отслеживать прогресс команды.

Варианты развертывания

Доступны инсталлеры под Windows и Linux для решения OnPremise. Есть возможность начать с JIRA OnDemand а позже перейти на OnPremise.

Интеграция

Получите больше от JIRA с гибким REST и Java API — плюс более 600 плагинов и дополнений в Atlassian Marketplace, чтобы соединиться с приложениями и инструментами, которые вы используете каждый день.

Скриншоты

Rally Software

Ключевые особенности Rally Software

  • Гибкая ценовая политика.
  • Дополнения и расширения Rally Apps.

Краткий обзор Rally Software

Rally Software — инструмент управления проектами, которая использует Agile- и lean-методы, чтобы помочь предприятиям в разработке ПО. С акцентом на Aglie-методологии, ралли помогает предприятиям всех размеров постепенно внедрять полезные практики, позволяющие сокращать циклы разработки и улучшать сотрудничать в распределенных командах.

Под влиянием Agile и Lean принципов, Rally представляет первое решение для управления Agile-портфолио, которое позволяет:

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

Скриншоты

Тарифы Rally Software

Механизм ценообразования: Фримиум, подписка





Community
Enterprise
Unlimited
10 user, 5 projects
$35 user/month
$49 user/month

 
FREE for up to 10 users

Преимущества использования

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

Ключевые особенности

  • Система контроля версий.
  • Agile-планирование.
  • Управление тест-кейсами.
  • Репортинг.

Управлять репозиториями, выстраивать процессы, инфраструктуру тестирования и развертывания, получать статус и репортинг — все это легко с Team Foundation Server, инструментом управления жизненным циклом приложения в Visual Studio. Оно позволяет всем заинтересованным сторонам участвовать разработке, используя единое решение. Используйте TFS, чтобы управлять разнородными проектами и командами.

Система контроля версий

Поддержка централизованной (Team Foundation Version Control) или распределенной (Git) системы в Team Foundation Server дает команде возможность гибко использовать технологию контроля версий, которая лучше подходит для нее.

Agile-планирование и взаимодействие

Адаптируйте Agile-практики в подходящем вам темпе, используя шаблоны для Scrum, Agile или CMMI®. Можно скачать шаблоны процессов или создать собственные. Все участники проекта вовлекаются в рабочий процесс с помощью Kanban-досок и постоянно получают друг от друга обратную связь.

Билды

TFS помогает выявить ошибки и проблемы с качеством продукта на ранней стадии. Настройка непрерывной интеграции (continuous integration) с запуском интеграционных тестов повышает уверенность в качестве билдов.

А еще TFS позволяет получить информацию о статусе последней сборки и на домашней странице проекта, и через Visual Studio.

Веб интерфейс для управления тест-кейсами

Система позволяет контролировать качество через веб-интерфейс, создавать и выполнять тестовые сценарии удаленно, что облегчит ревью для команды. Еще можно профилировать модульные тесты для отслеживания непрерывного исполнения кода, в том числе, самого модульного тестирования.

Отчетность

Механизм репортинга в Team Foundation Server 2013 отслеживает различные виды работ, чтобы создавать отчеты на основе текущего состояния. А шаблоны для получения информации можно брать готовые или составлять самим.

TFS Цена





Покупка
Upgrade
$ 499
$ 399

 
Ценовая политика: подписка, бесплатная 90-дневная версия.

Скриншоты


Google Docs

Особенности

  • Бэклог и диаграмма сгорания продукта.
  • Бэклог и диаграмма сгорания для спринта.
  • Бэклог для сдерживающих факторов.
  • Burndown chart, team velocity.

Специально созданные Scrum-темплейты помогают управлять небольшим проектом. Самое главное достоинство решения — простота: не требуется никакой дополнительной инсталяции и настройки. Google Docs — отличный выбор для распределенных команд.

Скриншоты


Цена Google Docs

Ценовая модель: бесплатно (1 Гб дискового пространства).

Заключение

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

  • Как много людей работает у вас в команде, сколько сотрудников будут пользоваться инструментом.
  • Есть ли сотрудники, работающие удаленно.
  • Насколько решение масштабируемо при росте количества пользователей.
  • Насколько гибка ценовая политика компании, предлагающей услугу.
  • Как планируете внедрять инструмент и на какой уровень поддержки рассчитываете.

У рассмотренных продуктов (кроме Google Docs) есть бесплатная пробная версия. За это время команда может проверить инструмент в действии на реальном проекте и посмотреть, насколько инструмент помогает в решении вопросов разработки и планирования.

Подводя итог, можно отметить, что компании VersionOne и Rally обеспечивают широкий выбор инструментов управления Agile-проектами. С их помощью заказчик может отслеживать прогресс команды и видеть, с какими трудностями сталкиваются разработчики в процессе выполнения заданий.Поскольку удаленная работа в сфере IT в наше время сильно распространена, продукты от VersionOne и Rally помогают сделать работу в распределенной команде максимально удобной.

Microsoft TFS не отстает от конкурентов. Преимущества продукта особенно ощутимы, когда команда уже использует другие решения от Microsoft.

Atlassian JIRA хорошо подходит и для управления проектами, и для процесса багтрекинга. Множество плагинов позволяет кастомизировать и оптимизировать процессы под свои нужды.

Google Docs — удобный инструмент для небольших команд со сравнительно простыми процессами. Основное преимущество (кроме бесплатности) — легкость в использовании и интуитивно понятные интерфейс.

Надеюсь, обзор был полезен и поможет выбрать правильный инструмент.

Автор: Евгений Толбаков.

LEAN + AGILE = AGILEAN или собираем целое по частям / Хабр


1. Неправильный полёт неправильного шмеля. (Вступление)

Откуда взялись науки математика и физика?

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

В сегодняшнем состоянии математика и физика не совершенны — это просто системы нашей интерпретации окружающего мира, и они переплетаются и взаимодополняются в вещах, которые просты и нам понятны и начинают расходиться и противоречить друг другу и себе там, где появляются силы, феномены и законы нам непонятные или до конца не познанные. Для того чтобы объяснить эту добавочную сложность, проявляющуюся в мире, приходится вводить новые понятия и системы интерпретации (пример: квантовая физика и математика Лобачевского). И чем глубже простирается наше понимание устройства Вселенной, тем больше правок нам приходится вносить в то, что раньше считалось незыблемым законом.

Есть известный случай, когда на заре аэродинамики учёные попытались рассчитать по её законам полёт шмеля, оказалось, что он летает против законов физики. Причиной, конечно, была не «неправильность» шмеля, а несовершенная научная интерпретация законов природы, которая потом была исправлена, и счастливый шмель вновь залетал, но теперь уже в строгом соответствии с аэродинамикой.

Наверное, самый полезный вывод из этого будет звучать следующим образом: за любой закономерностью или отдельным феноменом стоит система, где все гармонично и взаимосвязано. Это утверждение применимо как к науке, так и к бизнесу.

2. Бизнес как слон

Бизнес организации тоже являются гармоничными системами, функционирующими по строгим законам, представление у человечества, о которых пока далеко не полное.

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



В этом смысле Agile и Lean это разные системы интерпретации одного большого сложного «слона' или живого мира человеческой организации.

Производственники ухватили этого «слона» за процессы и получился Lean, IT-шники схватили многострадальное животное за человеческое взаимодействие вокруг этих процессов, и получился Agile.

И, несмотря на то, что в процессе развития Lean его приверженцы начали понимать, что без правильного вовлечения и организации взаимодействия людей даже самые совершенные процессы не заработают, а сторонники Agile постепенно приходят к мнению, что практикам Lean есть очень органичное применение в системах Agile, всё равно ещё существуют люди, которые уверенно утверждают, что «место Agile только в IT» или считающие что «внедрили бережливое производство», развесив таблички 5C и проведя несколько тренингов для своих сотрудников.

3. Lean и Agile – есть ли разница?

На первый взгляд она несомненно есть. Lean – сфокусирован на выстраивании идеальных процессов без потерь и их непрерывном улучшении. Agile фокусируется на быстром и эффективном взаимодействии людей вокруг этих процессов, на создании человеческих структур, способных гибко и креативно реагировать на любые изменения и запросы бизнеса.

Но если подумать, разве не очевидно, что две данные системы не просто органично дополняют друг друга, но буквально являются двумя половинками одного целого?

Эффективная, увлечённая и вовлечённая, гибко реагирующая на изменения, команда самоорганизованная вокруг идеальных процессов на принципах непрерывного улучшения – это ли не идеальная форма бизнеса?

Более того, стоит только попытаться начать смешивать эти два подхода на практике, и вы весьма органично вольётесь в царство Agilean. Как насчёт DMAIC в Scrum-формате? Или kaizen-сессии вместо ретроспектив? А может вы хотите вывешивать мероприятия по непрерывным улучшениям на Kanban-доску и отслеживать их выполнение, собираясь около неё всем отделом, перемещая карточки из бэклога в «Done»?

Любая подобная практика показывает отличные результаты и говорит о том, что здесь только sky is the limit.

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

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

Как же всё-таки начать её строить и что скрывается за фразой «если вы знаете, как это делать правильно»?

4. Ценности и задачи vs Фреймворки и инструкции

Как попытка построить механизм без знаний законов физики, так и попытка внедрить бизнес-инструмент без знания, какие ценности он олицетворяет и насаждает, обречена на провал.

Наверное, многие сталкивались с феноменом карго-культа при внедрении различных новых бизнес-методологий, когда, к примеру, над кучами мусора висят плакаты 5С или «самоорганизующаяся» команда находится под плотным контролем микроменеджмента руководства. Результатом таких карго-культ внедрений всегда становится недостижение поставленных задач и запланированных эффектов от изменений. Что ещё хуже – организация прививает себе в результате этого стойкое отвращение к любым улучшениям.

«Мы пробовали – это не работает». «Это всё не для нашей отрасли, у нас своя специфика».

Причина всех таких провалов проста – отсутствие понимания, что такое организационная культура, на какие ценности опирается тот или иной её тип и как разные бизнес-инструменты связаны с тем или иным уровнем или типом культуры.

Знаменитое высказывание «культура есть стратегию на завтрак» подразумевает, что внедрение методологии без учёта культурных особенностей организации будет безуспешным.

Очень часто организационная культура ошибочно трактуется, как качество людей.

«Это же работяги, им всё это сложно. Им нужен просто чёткий приказ копать отсюда и до вечера и зарплата в конце месяца. И, конечно, контроль, контроль, контроль».

Знаменитый психолог и специалист по организационному развитию Джон Седдон сказал: «Попытки изменить организационную культуру наивны и всегда обречены на провал. Поведение людей (культура) всегда является продуктом системы. Изменение системы влечёт за собой изменение поведения людей».

Факт в том, что одни и те же люди будут себя по-разному вести, попадая в организации с разными культурами. Человек – социальное существо, одной из главных способностей которого является способность подстраиваться под существующую среду или систему.

И, несмотря на то, что, конечно, для разных людей такая адаптация потребует разных усилий и времени, фактом остаётся то, что, система всегда будет определять культуру. Кроме, может быть, тех уникальных случаев, когда некоторое количество людей определенных взглядов собрались в организацию и проектируют систему исходя из своих культурных особенностей.

Как же правильно формировать желаемую культуру через системные изменения? И что значит внедрять инструмент с учётом тех культурных особенностей, которые он представляет?

Очень часто, когда я рассказываю про Agile, Scrum и их церемонии клиентам в первый раз, я слышу: «Да у нас и так всё это есть. Чем это отличается от наших производственных совещаний? Мы так же обсуждаем рабочие проблемы в команде и как их нам улучшить?»

Ок. Давайте посмотрим. Ведь формально между Agile-ретроспективой и совещанием по разбору результатов рабочей недели нет. Команда собирается в одном кабинете и обсуждает рабочие вопросы. Однако, на практике, напряженная, психологически подавляющая («как бы чего-нибудь не ляпнуть») атмосфера обычного совещания иерархической организации с дежурными ответами «всё в рабочем порядке» оказывается в разы менее эффективней, чем правильно проведенная расслабленная демократичная Agile-ретроспектива, где люди могут сидеть или стоять, как и где хотят. Где любая «ляпнутая» глупость, не только не наказывается, а поощряется. Где нет «запретных» вопросов, и где, в целом, участникам интересно и «безопасно».

Ни разу из моего опыта, я не смог по-настоящему объяснить разницу между этими двумя такими схожими по формату и такими разными по духу событиями на словах. Разницу между одним и тем же инструментом с разным культурным и ценностным наполнением: Лояльность, Порядок, Субординация – в первом случае, и Прозрачность, Гибкость, Психологическая безопасность – во втором.

«Мы серьёзные люди», — говорили мне. – «У нас серьёзная организация и мы здесь решаем серьёзные вопросы. Нам некогда в игрушки играть».

И каждый раз, когда эти же люди в качестве эксперимента проводили обычное совещание в Agile (или, наверно, точнее сказать в “Agilean”) формате, было радостно смотреть потом, как широко открывались их глаза и менялось мнение.

«Это действительно работает, чёрт побери!»

Да, это действительно работает, чёрт побери, и начинает это работать, как только вы перестаёте смотреть на инструменты сквозь призму инструкций и формальных признаков, и начинаете видеть их сквозь призму ценностей.

Проще говоря, вы перестанете «внедрять Бережливое производство» или «внедрять Agile», а научитесь интерпретировать ваши частные бизнес-вызовы как проявление системных или в случае бизнеса, культурных проблем.

5. Agilean вместо Lean или Agile

Чем отличается этот новый подход Agilean, от существующих Lean и Agile или зачем плодить сущности? Там, где нужен Lean – применяй инструменты Lean, там, где нужен Agile, применяй Agile! Логично? Не совсем.

Сочетание компонентов иногда может быть больше, чем его сумма или 1+1 = 3

В нашем случае из сочетания Lean и Agile получается Agilean – философия, трансформационная модель и набор инструментов, основывающиеся на следующих ценностях:

— СВОБОДНАЯ КОММУНИКАЦИЯ

— ПСИХОЛОГИЧЕСКАЯ БЕЗОПАСНОСТЬ

— НЕПРЕРЫВНОЕ РАЗВИТИЕ

— ГИБКОСТЬ

СВОБОДНАЯ КОММУНИКАЦИЯ — это абсолютная прозрачность процессов и решений, общая доступность информации, возможность кому угодно обсудить что угодно с кем угодно внутри компании, если речь идет об улучшении и развитии компании. Без церемоний, бюрократии и иерархических поклонов.

ПСИХОЛОГИЧЕСКАЯ БЕЗОПАСНОСТЬ – это культура демократичности, культура отсутствия «глупых вопросов». Данная ценность пересекается с предыдущей и дополняет её, потому что только в культуре психологической безопасности могут рождаться, свободно обсуждаться и внедряться идеи по улучшению.

НЕПРЕРЫВНОЕ РАЗВИТИЕ – это не только непрерывное улучшение процессов и инструментов компании, это саморазвитие, развитие коллег вокруг вас, постоянный поиск и устранение потерь, повышение личной и командной эффективности, а также уровня счастья всех участников!

ГИБКОСТЬ – незыблемых догм и правил на все случаи жизни для реализации ценностей выше не существует, поэтому обязательным условием разработки правильных стандартов и их постоянной адаптации к непрерывно меняющемуся миру является гибкость. Постоянные эксперименты, поиск решения при помощи метода проб и ошибок, прототипирование и дизайн-мышление – это гибкость. Постоянная работа в команде, умение прислушиваться и уважать чужое мнение – это гибкость.

Учитывая, что, применяя подход Agilean каждый может строить и разрабатывать свои уникальные инструменты в зависимости от своих задач, контекста и культурных особенностей, можно назвать Agilean — сверхгибкими технологиями или универсальным подходом построения культуры стартапа, где все подчинено одному — целям всех сотрудников компании.

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

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

Agile система управления проектами. Бесплатная онлайн версия

Компания S.A.Ricci PM осуществляет комплексное управление работами
по проектированию, строительству, внутренней отделке и
обустройству объектов коммерческой недвижимости.

Abiroy – тренинговая компания, специализирующаяся на
проведении комплексных проектов по подготовке и управлению
персоналом в сферах технического обучения, управленческого
развития, информационных технологий и охраны труда.
Реализация проектов "под ключ" для решения актуальных бизнес
задач клиентов.

Национальный исследовательский ядерный университет «МИФИ»
— один из первых двух национальных исследовательских
университетов России, образован 8 апреля 2009 года на базе
Московского инженерно-физического института. Историю ведёт
от основанного в 1942 году Московского механического
института боеприпасов.

Евразийский банк — казахстанский розничный банк. Головной
офис находится в Алма-Ате. По состоянию на 31 марта 2018 года
имеет 16 региональных филиалов и 119 расчетно-кассовых отделений.

Концертное агентство «Артисты и Звезды» — команда
профессионалов, установившая стандарты качества организации
концертов на самом высоком уровне.
Работают с 2010 года и сейчас проводят от 200 концертов в год,
более 100 артистов и коллективов работают с ними постоянно.
География деятельности насчитывает 65 городов.

10 лет на рынке строительных материалов. Деятельность компании
— розничная и оптовая продажа качественных строительных
материалов отечественного и европейского производства,
соответствующих передовым требованиям и современным технологиям
в строительстве.
Система полного цикла, от анализа рынка и закупки товара на
заводе производителя до доставки его конечному потребителю.

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

ООО «СИГМА» – российский разработчик и поставщик ИТ-решений
для автоматизации деятельности компаний энергетического
сектора и ЖКХ.
Компания обладает многоуровневой экспертизой в области разработки,
внедрения, сопровождения и развития аналитических, биллинговых
и расчётных систем, обеспечивающих высокий уровень автоматизации
предприятий.
В сферу компетенций компании входят также услуги
администрирования и технической поддержки различного аппаратного
и программного обеспечения сторонних производителей, интеграция
и адаптация ПО.
Компания была образована в 2005 году в Санкт-Петербурге.

Компания «ИНТЭК» осуществляет монтаж внутренних инженерных сетей,
монтаж воздушных и кабельных линий 0,4 кВ «под ключ»,
монтаж воздушных и кабельных линий 6, 10 кВ «под ключ»,
монтаж приборов учета «под ключ», проектирование инженерных сетей,
сопровождение документации.

ООО «Инвестиционная Компания «Фридом Финанс»
— российская инвестиционная компания, входит в состав холдинга
Freedom Holding Corp. Ведёт брокерскую, дилерскую
и депозитарную деятельность, основное направление деятельности
— американский фондовый рынок, также работает на рынках России
и Казахстана.

АО «Научно-производственный комплекс «ВИП» основано в 1994 году.
Предприятие специализируется на разработке и серийном производстве
сенсоров и датчиков физических величин, систем электропитания
и элементов систем управления.
Коллектив компании насчитывает более 200 высококвалифицированных
специалистов в области производства и разработки промышленной
электроники и средств измерения физических величин.

особенности внедрения гибкой разработки / Блог компании Mail.ru Group / Хабр

Продолжаем про нюансы гибкой разработки (Agile), которые случаются на практике. Как понять, правильно ли внедрен Agile, какая практика годится для какой задачи и отрасли, кто в компании должен переводить работу на «Agile-рельсы»? Своим опытом с редакцией блога Mail.Ru Cloud Solutions продолжает делиться Agile-коуч ScrumTrek Василий Савунов.

В прошлый раз Василий рассказал, что такое Agile, какие он включает методологии и какие вокруг него сформировались стереотипы. Теперь поговорим о его внедрении.


О компаниях, использующих Agile

— Есть ли «отраслевые предпочтения» в гибких методологиях?

Как показывает исследование Agile Russia, которое мы проводим второй год подряд, в сфере разработки ПО преимущественно используется Scrum, в финансовых организациях — Канбан, а в телеком-индустрии — и то, и другое.

Как человек, который непосредственно анализировал собранные данные, и работавший со многими из респондентов, я считаю, что такое положение вещей обусловлено двумя причинами:

  • Скорость изменений в IT значительно выше, чем в финансах. Поэтому там предпочтителен Scrum как подход, позволяющий за счёт быстрых экспериментов гибко управлять приоритетами и менять направление в зависимости от изменений внешней среды и условий «на входе». Финансы более консервативны.
  • Стоимость ошибки в финансах гораздо выше, чем в IT-разработке. Поэтому в них больше ценится Канбан, основанный на математике, а не на экспериментах, и позволяющий посредством небольших, но постоянных изменений улучшать рабочий процесс в целом.

Телекому Канбан тоже подходит. Хотя бы потому, что вектор развития отрасли — цифровизация. Однако пока мало кто понимает, как конкретно она должна выглядеть. Кроме того, в телекоме «быстрая» часть работы (разработка ПО) соседствует с «медленной» (поддержка и развитие аппаратной инфраструктуры). Поэтому наряду с экспериментами, которые проводятся по Scrum, имеет смысл эволюционно ускорять текущие процессы с применением Канбана.


Методики гибкой разработки, принятые в разных отраслях. Суммы не равны 100 %, потому что можно было выбирать более одного пункта. Изображение/ScrumTrek

— А как дела у мобильных разработчиков? Есть ли у Agile специфика в мобильной разработке?

С моей точки зрения, основная трудность при разработке мобильных приложений — выявление требований к приложению, потому что бывает сложно идентифицировать заинтересованных лиц. Эти трудности преодолимы, если использовать customer development для исследования потребностей клиента и Scrum для быстрой проверки продуктовых гипотез.

Customer developmentCustomer development, custdev, кастдев, развитие клиента (интересно, а так вообще кто-то говорит?) — это подход к созданию продукта через постоянное тестирование на реальном рынке и улучшение по результатам этих экспериментов. Это сближает кастдев с научным методом, делает создание продукта «научно обоснованным».

CustDev — один из элементов методологии Lean Startup, которая, в свою очередь, является одним из Agile-подходов при создании продуктов.

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

Кроме Scrum здесь можно использовать и ориентированные непосредственно на мобильную разработку подходы. Например, Mobile-D базируется на XP, Crystal и RUP — подходах достаточно древних и хорошо отработанных. Главное отличие Mobile-D от Scrum: наличие четких фаз и главенствующий акцент на инженерной стороне развития продукта. Если Scrum уделяет больше внимания управлению и поставке продукта, то Mobile-D сосредоточен на процессе производства и включает практики XP, существенно улучшающие качество конечного продукта. В то же время сказывается влияние RUP, поэтому процесс довольно формализованный.

Другой, наиболее современный подход к мобильной разработке — SLeSS, совмещающий Scrum и Lean Six Sigma. Сперва он реализует постановку рабочего процесса по Scrum, а затем применяет подходы Lean Six Sigma для статистического управления качеством. Мне кажется, SLeSS сочетает в себе необходимую гибкость с механизмами обоснованного принятия решений на основе статистики.

В то же время, Scrum Guide изначально не запрещает включать в рабочий процесс Scrum какие-то другие подходы и инструменты, которые могут быть полезными для разработки продукта. Поэтому всё вышесказанное можно реализовать и в рамках «классического» Scrum.

— Насколько гибкие методологии поддаются модификации под частные условия?

Здесь надо рассматривать по отдельности Scrum и Канбан.

Scrum — это фреймворк, то есть каркас, все элементы которого обязательны: и мероприятия, и роли, и артефакты. Ни один нельзя выбросить. Зато нету жестких требований к тому, как именно эти элементы претворять в жизнь — делайте, как вам удобно. И Scrum не запрещает добавлять новые элементы: встречи, артефакты, роли, которые вам нужны для работы и помогают ускорять процесс.

Канбан — набор инструментов и метрик. Он не даёт жёстких установок про то, какие именно инструменты и в какой комбинации применять, поскольку рассчитан на долгое эволюционное изменение существующей системы. Но в то же время успех Канбана определяется сбором данных о рабочем процессе и их регулярным анализом. Если этого не делать, со временем всё заглохнет и дальнейших улучшений не будет. Но ничего страшного: как говорил Эдвард Деминг, вы не обязаны меняться, выживание — дело добровольное.

— Какие типичные ошибки при адаптации Scrum совершает бизнес?

Главная ошибка при реализации гибких методологий — применение инструментов без понимания того, зачем конкретно их нужно использовать.

Например, в больших организациях при внедрении Scrum зачастую просто переименовывают проектного менеджера во владельца продукта, а проектную команду — в Scrum-команду и начинают требовать выдать готовый результат за две недели. Но это не работает, и по очень простой причине: не выполнены условия, при которых Scrum может работать.

  • Проектного менеджера хоть и окрестили Владельцем Продукта, однако он не получил необходимых полномочий и поэтому не вправе формировать видение продукта или менять приоритеты реализации. Как и раньше, он вынужден согласовывать каждый свой шаг с руководством и зажат в рамки требований по срокам и объёму работ. А значит, скорость принятия решений осталась прежней. Никакого ускорения или адаптации под меняющиеся условия.
  • Проектную команду хоть и назвали Scrum-командой, но люди, включённые в неё, по-прежнему могут числиться каждый в своём отделе и подчиняются непосредственно своим линейным руководителям. Соответственно, каждый из участников команды прежде всего делает то, что ему поручит его линейный руководитель, а не Владелец Продукта. Как следствие, задачи по продукту будут всегда ниже по приоритету, а значит, скорость реализации продукта, под который «собрали» Scrum-команду, никак не повысится.
  • Скорее всего, как и прежде, участники команды будут заняты и в других проектах. В то время как Scrum прямо оговаривает: участники команды должны быть выделены в Scrum-команду на 100 % своего рабочего времени, и заниматься только тем продуктом, которые ведет их Владелец Продукта. Если люди «поделены на проценты» между проектами/продуктами, то они будут переключаться между ними, что резко снизит как вовлеченность, так и эффективность работы над каждым конкретным проектом/продуктом.

Негативных последствий у такого неумелого «внедрения» множество, а начинаются они с попытки воспроизвести механику, но не суть Scrum. Основные ошибки в реализации Scrum я подробно описал в своём докладе «Стоп-сигналы для Agile» на конференции CodeFest 2017.

— Как оценить, насколько грамотно гибкие методологии внедрены в компании?

Существует тест Scrum Open, однако он служит скорее для проверки теоретических знаний. Что происходит на практике, он понять не даёт. С учётом того, что основа Scrum — это командная работа, а его приоритетом является скорость поставки продукта и ценность для потребителя, правильнее всего проводить опросы 360. Так надёжнее устанавливать степень зрелости команды и удовлетворенность заказчика.

Мы используем собственную методику, которую воплотили в сервисе ScrumTrek Diagnostic Tool. Работает она так. Команде и заинтересованным лицам вне её задаётся ряд вопросов о том, как они оценивают уровень командного взаимодействия, планирование своей работы, ценность поставляемого заказчику результата, взаимодействие с другими командами и так далее. По каждому параметру высчитывается медиана мнений и строится комплексная круговая диаграмма — Радар, который отображает взгляд как изнутри команды, так и снаружи.


Радар ScrumTrek. Смотрим на разброс оценок


Радар ScrumTrek. Смотрим на медианы

Схема содержит много полезной информации.

  • Атомарные оценки отдельных людей и их средние интересны сами по себе, тут пояснения не нужны.
  • Разброс оценок в команде — интересная вещь. Когда он очень большой, есть повод договориться о том, что мы как команда подразумеваем под тем или иным аспектом нашей работы. Что мы имеем в виду под «ценностью для клиента», например? А «скорость поставки»? Большой разброс свидетельствует о том, что в команде не сформирована единая позиция по ряду вопросов.

Маленький разброс говорит о консенсусе и хорошем взаимодействии внутри команды.

  • Оценки разбиты по категориям. Можно заметить, что с культурой всё хорошо, а вот производительность кое-где проседает. Понятно, куда «копать».
  • Отличие между оценкой внутри и вне команды — это один из самых важных показателей, он показывает расхождения между ожиданиями заказчиков и других заинтересованных лиц от команды и тем, как команда сама себя воспринимает. Agile — про тесное взаимодействие бизнеса и тех, кто реализует продукт, поэтому эти расхождения — отличный повод «сверить часы» между этими двумя областями и договориться о том, как перестроить работу команды.

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

О командах, внедряющих Scrum

— От кого в компании должна исходить инициатива внедрения методологий гибкой разработки?

Внедрение Scrum всегда идёт от бизнес-цели. Поэтому первым об ускорении должен задуматься заказчик — либо внутренний, либо внешний. Потом нужно проработать концепцию продукта, чтобы его можно было делать итеративно. И только затем формировать команду. Scrum ради Scrum не работает. Более того, он может оказаться слишком дорогим для решения конкретных задач.

Кто будет «проводником Agile» в компании, вопрос без единственно верного ответа. Я видел, как «зачинщиком» изменений становился технический директор. Были случаи, когда инициатива исходила от бизнеса, и даже видел, как такая инициатива зарождалась «снизу». Всё зависит от энергии и мотивированности человека, от того, сумеет ли он встроить своё видение разработки с использованием гибких подходов в бизнес-контекст продукта или подразделения.

Идеально, когда инициатива исходит от топ-менеджмента. Подвижки в эту сторону на российском рынке заметны.

— Какие новые роли и функции возникают в организации или команде с внедрением гибких методологий? Какие из них обязательны, какие опциональны?

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

У Scrum-мастера и владельца продукта могут быть помощники, берущие на себя часть их обязанностей, притом что ответственность за результат остаётся за Scrum-мастером или владельцем продукта.

Владелец продукта — зачастую человек от бизнеса. Но не обязательно: скажем, если мы создаём какое-то инженерное решение для производства, эту роль может исполнять главный инженер. В конечном счёте это человек, который лучше всех понимает, для какого потребителя мы делаем продукт, какие проблемы тот решает в первую очередь, как должны выстраиваться приоритеты при его создании. Очень важно, чтобы владелец продукта имел полномочия самостоятельно определять состав продукта на основании данных с рынка и от потребителя. У него должно быть право говорить «нет» заинтересованным лицам, с которыми он взаимодействует. Это нужно, чтобы приоритеты были согласованны, а решения принимались оперативно.

Scrum-мастер — человек, чья задача — создание сильной, сплочённой, ответственной, а в идеале самоорганизованной команды. Что важно, это не тимлид, то есть — не руководитель. Scrum-мастер не имеет права давать руководящие указания или напрямую вмешиваться в разработку продукта. Он — организатор, фасилитатор, коуч и Agile-практик. По моему опыту, лучшие Scrum-мастера получаются из проектных менеджеров — при условии, что они прошли обучение и сумели перейти от директивного формата общения к коучинговому.

Коучинговый стиль общенияКоучинговый стиль общения — это когда мы общаемся с людьми на равных. Не воспринимаем априори взрослых самостоятельных людей как подопечных, которыми надо руководить, а пытаемся подвигнуть их на самостоятельный поиск решения задачи. И только если они заходят в тупик — тогда уже вмешиваемся и помогаем своей экспертизой. Другими словами, в коучинговом стиле общения директивный подход заменяется на делегирующий.

Пример. Приходит подчиненный к руководителю, и говорит: «Я не могу выбрать из двух вариантов реализации какой-то наилучший. Реши ты!»

Если использовать коучинговый подход, то руководитель начнет задавать вопросы: почему именно эти два варианта ты выбрал? А из чего ты исходил? В чем для тебя трудность в выборе между ними? Кто тебе может помочь еще? И так далее. Через вопросы руководитель-коуч помогает человеку исследовать возможные варианты. В итоге человек уже сам понимает, как ему лучше поступить, и руководителю останется только договориться о сроках, когда подчиненный придет и расскажет, что у него получилось.

Следующий шаг за делегированием — визирование. В визирующем подходе сотрудник или команда выходят на такой уровень зрелости и ответственности, что руководитель дает только верхнеуровневую постановку задачи с точки зрения бизнеса. Сотрудник или команда самостоятельно рассматривает варианты решений, оценивает сроки, выявляет риски. Руководитель просто визирует всё это, возможно — добавляет что-то с точки зрения своей экспертизы и вносит какие-то коррективы. Затем договариваются о временных вехах, когда нужно будет показать результаты. Дальше сотрудник или команда несет всю ответственность за реализацию и демонстрацию результатов. В визирующем подходе руководитель выступает только как куратор и помощник для сотрудника или команды в рамках реализации ими бизнес-задачи.

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

Переходный период всегда сопряжён с дискомфортом. Agile-коуч призван помочь команде пройти этот период с минимальными трениями и выработать новые — удобные и эффективные — приёмы работы.

При масштабировании могут вводиться дополнительные роли, как описано, например, во фреймворке SAFe, но в их основе всё равно лежит круг полномочий и принципы работы Scrum-мастера или владельца продукта: просто появляются уровни иерархии относительно продукта.

SAFeSAFe, или Scaled Agile Framework — фреймворк для применения Agile в крупных командах по разработке ПО. В самой простой реализации подход предполагает два уровня: командный и программный (Team и Program соответственно), по мере усложнения оргструктуры и продукта к ним добавляются Portfolio и Large Solution. Работа по SAFe опирается на такую сущность, как ART (Agile Release Train) — «поезд релиза». Она, как правило, объединяет несколько команд и заинтересованных лиц в структуру, на протяжении длительного времени сообща создающую продукт или часть продукта, которая представляет ценность для заказчика.

— Как разграничиваются функции владельца продукта и Scrum-мастера «в идеальном мире»?

На одной чаше весов — интересы бизнеса, которые представляет владелец продукта, на другой — жизнеспособность и эффективность команды, за которую отвечает Scrum-мастер. Чтобы команда быстро достигала результатов, система должна пребывать в балансе. Если «пережмёт» владелец продукта, команда будет работать ночами и в выходные, и вскоре он окажется перед кучкой демотивированных, невовлечённых людей вместо слаженной команды. Если одеяло перетянет на себя Scrum-мастер, разработка будет вестись ни шатко, ни валко, с постоянными спорами и гораздо дольше нужного.

ПримерЧтобы это не было абстрактным, вот выдуманный микродиалог внутри команды. Посмотрите, что говорит каждый из своей роли:

Владелец продукта: Так! Нам надо будет сделать воооот такую фичу! Вы в прошлый спринт отлично поработали, так что, я думаю, вы всё успеете!

Scrum-мастер: Но в прошлый спринт фичу подобной сложности команда сделала на пределе сил, пришлось выходить в выходные, и кое-кто работал по ночам. Еще один такой спринт — и люди начнут заболевать, выгорать и, может быть, начнется исход. Давай не будем до этого доводить?

Владелец продукта: Неужели всё так серьезно? Если да — давай с командой обсудим, что можно сделать за спринт, не выжигая людей. В этой фиче есть часть, которую надо будет сделать обязательно, она не выглядит сильно сложной.

Scrum-мастер: Давай обсудим с командой. Ты знаешь, что только она может сказать, «сложная» это задача или нет.

Владелец продукта: Давай.

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

По части бизнес-компетенций всё «по классике», как с обычным менеджментом, за исключением необходимости определять приоритеты по этапам и теснее взаимодействовать с командой.

Владельцу продукта стоит освоить Lean Startup, customer development и другие современные подходы к созданию продуктов.

Для Scrum-мастера набор компетенций шире: фасилитация, конфликтология, групповая динамика, коучинг и, конечно, практика Agile. Это, скорее, навыки из области психологии, поэтому чувствуется их недостаток при обучении менеджеров.

— Действительно ли коллективное владение кодом снижает зависимость компании от «звёздных» разработчиков? Не падает ли их мотивация?

Коллективное владение кодом осуществимо и без гибких методологий. Достаточно договорённостей о code review и других формальных правил, а разработчики могут действовать атомарно.

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

Это дилемма: или краткосрочный, или долгосрочный успех. Кажется, что наём «звезды» — благо для бизнеса. Но что будет через три года, через пять, через семь лет после того, как такой профи присоединился к компании? Он станет незаменимым. И как минимум с тремя негативными последствиями.

Во-первых, у такого человека почти нет свободного времени, и компании, по большому счёту, это безразлично. Её логика: «Мы тебе платим огромную зарплату не для того, чтобы ты отдыхал». Попадая в подобную ситуацию, люди быстро выгорают, впадают в цинизм и стараются извлечь максимум выгод из своего положения.

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

В-третьих, достижения такого человека невозможно «масштабировать». Если вы задумали расширять команду разработки, будьте готовы к большой текучке: новичков будут отторгать, махровым цветом расцветёт «дедовщина», так как «старичкам» окажется невыгодно делиться опытом и знаниями. Ускорить разработку тоже едва ли удастся: всё упрётся в производительность отдельно взятого и незаменимого Васи Пупкина, которого всё устраивает, и который не собирается ничего менять.

— Что предпринять, чтобы всё-таки перейти к командному подходу?

  • Принять риск того, что мы неизбежно потеряем часть текущей команды «звёзд»: не все согласятся с новым подходом. Это неизбежно.
  • Изменить структуру поощрений. Например, ввести бонусы за написание документации или за обучение новых сотрудников, чтобы постепенно это стало обыденной практикой.
  • Среди «звёзд» найти тех, кто хочет расти, и помочь им освоить навыки менеджмента, фасилитации, коучинга. Открыть им новые горизонты. Не все на это согласятся. Зато те, кто согласится, будут лучшими приверженцами новых принципов работы.
  • Размывать культуру «дедовщины». В том числе вырывать «звёзд» из их привычной среды, например формируя новые команды по принципу «четыре-пять новичков на одного старичка». Плюс в такой команде нужно назначать умного и умелого Scrum-мастера, который даст понять «старичку», что ему ничто не угрожает, и в то же время настроит «новичков» на то, чтобы они с уважением относились к тем, кто знает больше них. И хорошо, если такая команда будет сидеть не в том месте, где раньше работал «старичок».

Помните, мы имеем дело с трансформацией корпоративной культуры, а это задача архисложная. Как сказал Питер Друкер, «культура ест стратегию на завтрак». Сколь бы совершенную формализованную стратегию вы ни предложили, её не удастся воплотить в жизнь, если у людей «не принято» соответствующее поведение. Чтобы лучше разобраться в вопросе, советую прочесть книгу Даниэль Браун и Итске Крамер «Корпоративное племя. Чему антрополог может научить топ-менеджера».

Материал подготовила команда Mail.Ru Cloud Solutions.

Лучшие приемы и практики Agile для технических и нетехнических команд

Работая продолжительное время по Agile, можно легко выделить основные ценности, принципы и практики, благодаря которым выбор в пользу методологии сегодня делают огромное количество компаний. Некоторые практики в методологии удостаиваются высокой оценки почти у всех, какие-то являются спорными. Однако Agile не стал бы Agile, если бы лучшие ценности и приемы методологии не завоевывали расположения миллионов менеджеров и разработчиков по всему миру.




Знаменитая методология была создана для разработки ПО. Поэтому практически все практики Agile применяются именно там. Однако это не мешает применять Agile и многим нетехническим командам.

Компании, которые не связаны с IT быстро обнаружили преимущества использования гибкого мышления и некоторых Agile-практик, которые могут помочь бизнесу достичь большего, принести клиентам максимум пользы и удовольствия, а также сплотить команду внутри.

С 2001 года Agile-принципы оформили в знаменитый манифест Agile, а сама методология стала стандартным процессом разработки ПО.

Каковы ключевые практики Agile сделали методологию столь известной и востребованной?

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

Список лучших практик Agile

Очередь задач

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

Обычно в бэклог продукта входят следующие элементы: продуктовые фичи, возможные баги, приоритетные знания по продукту, некоторые технические работы, и др.

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

В управлении бэклогом определяющую роль играет собрание backlog grooming, во время которого представители Agile команды обсуждают детали бэклога продукта и готовят очередное планирование спринта.

Итерации

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

Клиентоориентированность

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

User stories


В Agile описывается функциональность по общению с клиентами, а затем с позиции продукта определенным образом (помните формулу “Я как , хочу , потому что ”?). История пользователей в Agile project management означает единицу работы, которая должна быть завершена в одном спринте.

User stories включают описание, критерии приемки и оценку времени. Когда они слишком сложны, менеджеры продуктов разделяют их на более мелкие.

Agile-роли

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

  • Team Lead, Project Lead и Скрам мастера
  • Членов команды
  • Собственника продукта для Scrum и On-site customer для XP
  • Заинтересованные стороны (stakeholders)

Команды Agile могут также состоять из дополнительно привлекаемых технических специалистов.

Value stream analysis

Анализ потока ценностей — это метод управления для анализа текущего состояния и разработки будущего состояния продукта. Цель анализа в том, чтобы идентифицировать и удалять «отходы» в потоках создания ценности, тем самым повышая эффективность потока данных.

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

Timeboxing

Timeboxing используется в качестве метода планирования проекта. Расписание делится на несколько отдельных периодов времени (таймбоксы), каждый из которых имеет свои конечные результаты, срок и бюджет.

Спринты продолжаются в соответствии с указанными таймфреймами. Обычно от двух недель до одного месяца. Scrum-митинги обычно продолжаются около 15 минут.

Ежедневные собрания

Например, Scrum meeting — это ежедневное мероприятие, короткая утренняя или дневная встреча, обычно организованная менеджером продукта или владельцем продукта. Длится 10-15 минут и требует присутствия Скрам-мастера и всей команды. Такая встреча организуется, чтобы:

  • вспомнить, что было сделано вчера
  • определить, что будет сделано сегодня
  • выявить любые препятствия, если такие есть

Sprint demo meeting

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

Retrospective meeting

Речь идет о ретроспективе по окончательному итеративному развитию. Retrospective meeting рекомендуется посещать всем членам команды. Клиенты также могут участвовать.
Здесь обсуждаются возможности улучшения процессов, качества работы, используемых инструментов и т. д.

Тестирование

Очень важно своевременно получить информацию о фичах, которые не работают так, как планировалось. Тесты запускаются автоматически перед началом работы. Это гарантирует, что все изменения кода приемлемы.

Burndown chart

Этот график демонстрирует, действительно ли все идет в соответствии с календарем программирования и общим планом. Он отражает сроки и расписания. В диаграммах Burndown также отображается количество пользовательских историй за единицу времени.

Приоритизация требований

Приоритезация требований используется в Agile для определения того, какие конкретные требования к продукту должны быть включены в определенный релиз.

Менеджеры продуктов также приоритезирует требования для минимизации рисков во время разработки — сначала выполняются наиболее важные. В этом случае опытные менеджеры по продуктам и проектам используют хорошо известные методы и техники приоритизации.

Планирование релиза

Релиз продукта представляет собой набор новых функций или финальный запуск продукта. Грамотное планирование релиза помогает командам выпускать качественные продукты.

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

Все заинтересованные стороны должны знать, когда они могут ожидать новых функциональных возможностей. Календарь релизов всегда должен быть четко распланирован.

Этот список можно продолжать и дополнять другими интересными практиками. Однако какие же практики могут быть использованы нетехникеской командой?

Яркий пример — использование бэклога и приоритизация задач командой авиатранспортной компании Air Methods, которая специализируется на оказании скорой помощи.

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

Так команда пришла к Agile-практике использования и управления бэклогом и определению приоритетов. За визуализацию стали отвечать инструменты Trello.

На доске собираются запросы заинтересованных сторон, команда присваивают каждому зеленый или красный лейбл. “Зеленые” проекты можно выполнять сейчас, “красные” попадают в очередь.

Ежемесячно команда и заинтересованные собираются для определения новых приоритетов, голосуют и дискуссируют.

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

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

Сегодня успешно применять главные ценности Agile помогают доступные сервисы и инструменты для управления проектами, истории мировых компаний, распространненных в сети, множество современных курсов и актуальной литературы по методологии. Благодаря этому, приемы и практики Agile ежедневно обеспечивают успех многим компаниям и привлекают все больше технических и нетехнических команд.

крупнейшая идеологическая проблема в IT / Блог компании Издательский дом «Питер» / Хабр

В 2001 году группа технологов и программистов, разделявших небанальные теории о том, как следует управлять разработкой ПО, встретились на горнолыжном курорте Сноубёрд, чтобы письменно изложить некоторые из этих концепций. Так родился «манифест Agile» — обманчиво простой документ, призванный пересмотреть догмы разработки ПО. Разработка ПО в стиле Agile превратилась в новый стандарт организации труда программистов в организации. Такие компании как Facebook, Amazon, Apple, Google и Netflix выстроили свои внутренние процессы разработки в соответствии с базовыми положениями этого манифеста. Учитывая абсолютные масштабы Agile и его общественный резонанс среди сторонников, легко убедиться, что Agile — самая влиятельная из всех когда-либо формализованных трактовок разработки ПО. Однако, Agile — это идеология. Нормативная система ценностей и убеждений, практически до основания впитавшихся в дело разработки ПО. Таким образом, софтверная индустрия сегодня дает интересную возможность оценить, как номинальные цели некоторой идеологии согласуются с ее воплощением на практике.



В сущности, Agile была бунтом против корпоративного засилья в разработке ПО. Впервые было признано, что разработка ПО – сложный и зачастую таинственный процесс, который обязательно нужно уберечь от корпоративной забюрократизированности. Изменения, переизобретение, гибкость, динамизм – вот красные нити, проходящие через манифест Agile. Они показали себя бесконечно привлекательными: согласно одному глобальному исследованию, около 97% всех организаций в той или иной форме практикуют принципы Agile. Благодаря такому повсеместному распространению, Agile достигла в теории управления разработкой ПО тотальной номинализации: сегодня термином «аджайл» именуют идеологию, методы работы и даже системы, используемые для разработки ПО в современной организации. Agile даже распространяется за пределы программерских команд и все чаще практикуется в других командах, отвечающих, например, за финансы или управление человеческими ресурсами. Agile, трактуемая как универсальная теория менеджмента, оказалась исключительно доступной и популярной – несмотря на скудость эмпирических подтверждений ее эффективности и полезности.

Интересно, что в манифесте Agile не делается попыток артикулировать какие-либо конкретные методы работы, правила, процессы, системы или структуры, которые помогали бы разрабатывать ПО в стиле Agile. Это и неудивительно: ведь манифест Agile никогда и не претендовал на подробное описание того, как достичь целей этого манифеста. Такая явная размытость ничуть не убавила популярности Agile: фактически, стремительный рост спроса на конкретные методы и инструменты Agile привел к возникновению метаиндустрии на основе ресурсов Agile. Этот интерес стимулировал внедрение Agile, проникновение в новые отрасли самой идеологии Agile и ее производных. Наиболее отчетливо проявили себя тщательно определенные методологии Agile (например, Scrum и Kanban—т.e., детализированные описания процессов, которых нужно придерживаться для воплощения принципов манифеста Agile) и специализированные софтверные платформы, специально разработанные для поддержки Agile-разработки. Австралийская технологическая компания Atlassian продает целый ряд таких продуктов, предназначенных для поддержки процессов разработки ПО в стиле Agile; особого упоминания заслуживают Confluence и Jira, уже де-факто ставшие стандартами в индустрии. Для тех, кто не варится в технологическом сообществе, такие продукты кажутся весьма таинственными. Появился целый ряд поясняющих статей, прежде чем Atlassian попала в списки NASDAQ и непосредственно после этого. Статьи были призваны объяснить, что же именно продает Atlassian, и почему компания добилась такой высокой рыночной капитализации.

Подобно программным продуктам Atlassian, лексикон, описывающий процессы Agile и повседневные рабочие приемы, также стал все более непроницаемым для непосвященных. Практикующие Agile говорят о спринтах, досках Kanban, диаграммах сгорания задач, скоростях, пользовательских историях, эпиках и ретроспективах — значение всех этих слов зачастую меняется в зависимости от контекста, а сами эти термины могут быть аффилированы с одной или несколькими явно определенными методологиями Agile. Стоит ли удивляться, что, по мере усложнения методологии Agile, множится и когорта специалистов-консультантов, помогающих все это осмыслить. В Bain & Company к услугам клиентов – около 1000 практиков Agile. Пожалуй, это самый надежный индикатор, демонстрирующий, какой прибыльной стала индустрия Agile-консалтинга. Однако, если манифест Agile столь прост, каким кажется на первый взгляд, то зачем же столько консультантов? Насколько ощутимо услуги любого из них отражаются на качестве и эффективности работы в типичной технологической компании?

Несмотря на лексикон, специализированные инструменты и колоссальный корпус ресурсов, доступных для каждого, кто желает практиковать в своей компании разработку ПО в стиле Agile, зачастую сложно отследить, насколько точно Agile реализуется на практике – то есть, соответствует духу и букве, зафиксированными авторами в манифесте Agile. Манифест Agile намеренно и неизбежно сделан абстрактным. Вероятно, это и привело к постепенному извращению методологии Agile и, как следствие, всей культуры менеджмента в софтверной индустрии как таковой. На, казалось бы, простых основах было выстроено нечто колоссальное – механизм, крайне разочаровавший тех, кто заложил основу для его первой итерации. Более того, по причине долгой популярности Agile специалисты, не имеющие формальной Agile-квалификации, стали проигрывать конкуренцию коллегам, которые в Agile якобы профессионально разбираются. Множество карьерных бонусов ждет тех, кто заявляет, что понимает устройство Agilr и умеет его применять. Такая реальность стимулирует конформизм и топит любые попытки усомниться в доминировании Agile или поставить ребром вопрос о ее эффективности.

Энди Хант, один из авторов-основателей манифеста Agile, жалуется, что из-за абстрактной формулировки оригинального Манифеста появились и распространились бесконечные правила, используемые вне контекста и якобы образующие основу разработки в стиле Agile. Со временем такие правила кодифицируются в виде специализированных методологий, которым требуется бездумно следовать, забывая при этом об исходных руководящих принципах Манифеста. Иными словами, идеология Agile оказалась исключительно сложна для изучения, усвоения и практики. Поэтому некоторые персонажи опираются на жестко определенные правила или эвристику, которые выдают за Agile, а потом продолжают подменять этими правилами (часто вырванными из контекста) практику Agile, соответствующую целям Манифеста. В большинстве организаций никакого постепенного оттачивания процесса разработки не происходит; вместо этого менеджеры впадают в заблуждение, считая, что процесс не допускает изменений, отказываются от пошагового улучшения продукта, а стремятся содрать с разработчиков по три шкуры, оперируя при этом в основном взятыми с потолка и жестко зафиксированными канонами. Организациям, которым не удается извлечь никакой реальной пользы из Agile (а таких много) закономерно тяготеют к отслеживанию реализации некого Agile-процесса, игнорируя при этом более размытые, но при этом и более важные результаты процесса – то есть, поставку работоспособного ПО.

Расцвет Scrum и Kanban – это, в лучшем случае, попытка формализовать и распространить идеологию Agile. В худшем же случае все эти методологии – не более чем дополнительная бюрократия, порождающая все новые необоснованные правила и метрики, которым должны следовать разработчики. Все это навязывается по причинам, зачастую совершенно не подкрепленным эмпирически. Посредственные менеджеры, консультанты, разработчики и даже целые организации в таких условиях благоденствуют: становится проще зацикливаться на номинальных правилах идеологии, и постепенно это оказывается приоритетнее достижения реальных целей. В принципе, в индустрии разработки ПО наблюдается мания с измерением «вклада» и «отдачи» от Agile на уровне отдельных сотрудников. Такая мания привела к пренебрежению исходной этикой Agile, смещению приоритетов к сбору статистики по каждому отдельному сотруднику, тогда как на самом деле нужно постепенно улучшать процессы на уровне всей организации.

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

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..

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *