— А зачем мне лезть в эти технические детали? У меня и так дел много.

— Тебе не нужно в них лезть, но если ты не спросишь, то ты рискуешь потратить деньги и не получить результат. А мы же про бизнес говорим, да?  Самое важное, тебе нужно понять: а понимает ли команда разработки КАК сделать то, что ты просишь или нет.

— Ну хорошо, убедил. И это все?

— Еще нет. Может "внезапно" выясниться, что они не могут сделать то, что ты просишь за неделю, тогда просто спроси их: Сколько времени нужно? Что может помешать? Есть ли способы ускорить? - так ты выявишь риски.

— Что-то как-то сложно. Может я могу кому-то это делегировать?

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

— Хорошо, дальше что что?

— Дальше, через неделю ты спрашиваешь результат, что получилось, что нет, сравниваешь с планом.

— План-фактный анализ? Да я помню такой!

— Почти! Но тут есть подводные камни: результат тебя может не обрадовать, или скорость работы не устроить.

— Да они регулярно мне рассказывают про сложности! Может уволить всех?

— Не спеши. Лучше спроси их: "Какие трудности были?" и "Что думаете с этим делать?"

— И что поможет?

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

— Когда?

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

— Это же просто!

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

— А если они просто посидят и ничего не решат? Я что зря потрачу время и деньги?

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

— А если не получится?

— Вижу много опасений. Это совещание по улучшению самое сложное в Agile и Scrum, как подходах со встроенным механизмом улучшения процесса. Если при планировании и контроле у тебя тоталитаризм "что делаем, а что не делаем" то тут уже нужно доверие. Также как при делегировании. Вот ты мне доверяешь?

— Тебе? Тебе доверяю.

— Вот! Ну не получится, позови меня. я тогда помогу провести это мероприятие. Наверное это единственное мероприятие где нужен незаинтересованный эксперт-посредник. Эта роль называется "фасилитатор"

— Ладно, ты снял опасения. Но что-то по твоему описанию весь этот твой Scrum весьма похож на стандартный управленческий цикл и цикл Деминга-Шухарта PDCA - Планируй-Делай-Проверяй-Корректируй.

— Конечно похож. Ничто не ново под луной. Но часто в компаниях даже этого цикла нет, есть просто "планируй-делай-планируй-делай" Scrum это просто хорошая коммерческая упаковка. Каждый консультант должен придумать свою матрицу 2x2 или канвас. Но крутые консультанты придумывают свою методологию. Так проще продавать.

— По Scrum понятно, а Agile это к чему?

— "Agile" правильней говорить Agile Software Development? то есть "Адаптивная разработка программного обеспечения" - это процесс разработки программ. Если хочешь его развертывать, то тут же более глубокое погружение нужно:  на уровень архитектуры, поддержки, обеспечение внесения изменений управления знаниями. Давай в другой раз. Ты хотя бы Scrum запусти.

— Ну в другой раз, так в другой раз.

— Я ответил на твой вопрос?

— Даже больше чем! Я попробую!