Почему мы внедряем Agile или Религиозный Agile-фанатизм

TL;DR При внедрении Agile цель — повышение адаптивности продуктовой разработки. Это многое объясняет и одновременно противоречит много чему.

В Agile-коучинге, как и во многих других дисциплинах, существуют священные коровы, которые принимаются на веру, но редко проверяются критическому осмыслению.

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

— Почему мы должны собирать всю команду на планирование?

— Потому что мы ценим людей и их взаимодействие больше процессов и инструментов.

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

Я вчера на тренинге, который сам и вел, словил яркий инсайт.

Манифест гибкой разработки ПО не отвечает на вопрос “Почему”. Манифест описывает набор стратегий принятия решения (aka “Ценности”) и принципов построения рабочих процессов в условиях неопределенности. Его имеет смысл читать так:

Поскольку мы хотим поставлять максимальную ценность своим пользователям в условиях неопределенности, мы используем такие стратегии (ценности) и принципы (12 принципов) построения работы, которые реализуются множеством разных способов (Скрам и вот это все).

Почему это важно

Во-первых это помогает отвечать на некоторое количество стрёмных вопросов:

— Что мне делать, если у меня команда во время спринта не загружена на 100%.

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

— Как ваш Agile поможет мне успевать в срок?

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

— Мы планируем проекты на год вперед и не можем выкинуть оттуда ничего. Почему Agile нам не помогает?

— Самая полезная с точки зрения пользователя функциональность может поменяться с течением времени и не зависит от ваших планов.

— Почему мы должны собирать всю команду на планирование?

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

Во-вторых, это объясняет почему правила Скрама, Канбан-метода, Экстремального программирования нельзя менять.

— Можно мы не будем делать ретроспективу?

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