Чек-лист готовности к новой (гибкой) организации процессов

Команда и стейкхолдеры готовы принять принципы и правила Agile-подхода:

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

Существует ли в организации «право на ошибку»? Неважно, что ошибся, важно, что ошибку обнаружили, распознали и быстро исправили. Принцип «fail fast, fail safe» (ошибайся быстро, ошибайся безопасно).

Существует ли правило , что у аварии нет имени фамилии и отчества

Существует ли ограничение на то, что команда сделавшая неправильно , должна стать «расстрельной»

Есть ли Agile-команда.

Можно работать компактной командой: 7 сотрудников плюс-минус 2 человека.

Её еще называют «2 pizza team», команда, которую можно накормить двумя пиццами. То есть совсем небольшая. Техники масштабирования Agile на большие команды существуют, но они очень и очень нетривиальны. Начинать с них точно не стоит

Есть ли такие команды (или можно соединить в команды) , в которых присутствуют сотрудники, обладающие компетенциями, необходимыми для разработки продукта/услуги и представляющие все подразделения, которые необходимы для разработки продукта/услуги;

Может ли организация позволить себе, чтобы у сотрудников было бы достаточно времени для работы в команде. Крайне желательно, чтобы они все свое время посвящали работе над проектом, принцип «100 на 0» — 100% вовлечения;

Можно ли организовать так, чтобы команда вся целиком сидела вместе, в одном помещении;

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

Есть руководитель проекта или заказчик продукта (услуги), который:

уполномочен единолично определять все требования к продукту/услуге и приоритетность задач;

доступен для команды, может обсуждать и рассматривать вопросы по продукту в темпе работы команды.

То есть нет такой ситуации, когда команда отработала «спринт», например, за две недели, а потом месяц ждет возможности поговорить с руководителем /закачиком;

доверяет команде.

Заказчик («владелец продукта» ) продукта определяет, что делать, команда определяет, как делать. Заказчик/руководитель не вмешивается в процесс решения задач, не говорит: «Не так вы работу работаете, я сейчас разъясню. Давайте это отложим и лучше сделаем так».

Руководитель организации/совет/попечители (если это важно) подтвердили свою поддержку

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

Согласованы накладываемые на проект/продукт/услугу ограничения.

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

И самое важное: нельзя останавливаться.

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