Как запустить Scrum в маленькой компании
— Алексей, привет! У меня тут вопрос есть по твоей теме, а как запустить Agile в небольшой команде для небольшого бизнеса?
— О! Это очень просто! Agile это про получение результата в соответствии с ожиданиями. Если не вдаваться в технические детали, то тебе подойдет процессный каркас - Scrum. Для начала тебе, как бизнесу, нужно поставить задачу команде: что ты хочешь на ближайшую неделю.
— Хорошо, это я умею.
— Но тут есть риск, что они могут понять тебя неправильно. поэтому лучше всего спросить: Расскажите мне, как вы планируете это делать?
— А зачем мне лезть в эти технические детали? У меня и так дел много.
— Тебе не нужно в них лезть, но если ты не спросишь, то ты рискуешь потратить деньги и не получить результат. А мы же про бизнес говорим, да? Самое важное, тебе нужно понять: а понимает ли команда разработки КАК сделать то, что ты просишь или нет.
— Ну хорошо, убедил. И это все?
— Еще нет. Может "внезапно" выясниться, что они не могут сделать то, что ты просишь за неделю, тогда просто спроси их: Сколько времени нужно? Что может помешать? Есть ли способы ускорить? - так ты выявишь риски.
— Что-то как-то сложно. Может я могу кому-то это делегировать?
— Ну.. делегировать, то, ты можешь, если ты готов понести финансовые издержки на эксперименты. Можно просто не спрашивать команду, а просто ставить задачу и спрашивать их оценку. Но я тебе рекомендую это делать только после того, как ты убедишься, что они тебя понимают и делают ровно то, что ты хочешь.
— Хорошо, дальше что что?
— Дальше, через неделю ты спрашиваешь результат, что получилось, что нет, сравниваешь с планом.
— План-фактный анализ? Да я помню такой!
— Почти! Но тут есть подводные камни: результат тебя может не обрадовать, или скорость работы не устроить.
— Да они регулярно мне рассказывают про сложности! Может уволить всех?
— Не спеши. Лучше спроси их: "Какие трудности были?" и "Что думаете с этим делать?"
— И что поможет?
— Пока задаешь вопрос не поможет, но ответы запиши, это уже публичные обещания, они потом пригодятся.
— Когда?
— Здесь нужна чуйка. Но лучше раз в месяц, не реже, или каждые 2 недели собрать команду на пиццу в офисе после обеда, и просто выложи им факты: "Ребята, я заметил что..." и перечисляешь факты, или обещания о которых договорились и не сделали. После этого просишь их обсудить пути решения и представить тебе план мероприятий по изменению.
— Это же просто!
— Просто, да не совсем. Так, как у тебя, как у бизнеса, есть пистолет на отстрел, тут важно не передавить. Поэтому, лучше договориться об ожидаемом результате обсуждений и оставить их наедине с проблемой.
— А если они просто посидят и ничего не решат? Я что зря потрачу время и деньги?
— А ты попробуй. Тебе нужен план изменений подхода к работе, но если ты будешь на команду давить, это будет твое навязанное решение, а тебе нужно сделать так чтобы это было их решение.
— А если не получится?
— Вижу много опасений. Это совещание по улучшению самое сложное в Agile и Scrum, как подходах со встроенным механизмом улучшения процесса. Если при планировании и контроле у тебя тоталитаризм "что делаем, а что не делаем" то тут уже нужно доверие. Также как при делегировании. Вот ты мне доверяешь?
— Тебе? Тебе доверяю.
— Вот! Ну не получится, позови меня. я тогда помогу провести это мероприятие. Наверное это единственное мероприятие где нужен незаинтересованный эксперт-посредник. Эта роль называется "фасилитатор"
— Ладно, ты снял опасения. Но что-то по твоему описанию весь этот твой Scrum весьма похож на стандартный управленческий цикл и цикл Деминга-Шухарта PDCA - Планируй-Делай-Проверяй-Корректируй.
— Конечно похож. Ничто не ново под луной. Но часто в компаниях даже этого цикла нет, есть просто "планируй-делай-планируй-делай" Scrum это просто хорошая коммерческая упаковка. Каждый консультант должен придумать свою матрицу 2x2 или канвас. Но крутые консультанты придумывают свою методологию. Так проще продавать.
— По Scrum понятно, а Agile это к чему?
— "Agile" правильней говорить Agile Software Development? то есть "Адаптивная разработка программного обеспечения" - это процесс разработки программ. Если хочешь его развертывать, то тут же более глубокое погружение нужно: на уровень архитектуры, поддержки, обеспечение внесения изменений управления знаниями. Давай в другой раз. Ты хотя бы Scrum запусти.
— Ну в другой раз, так в другой раз.
— Я ответил на твой вопрос?
— Даже больше чем! Я попробую!