Kanban / Agile / Scrum / Lean — как выравнивать процессы, убирать посредников, максимизировать ценность фреймворка

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

Что делать? Почему так происходит?

Именно на стыке этих двух вопросов в 1995 году Кеном Швабером и Джеффом Сазерлендом было предложено поиграть в регби* вместо того, чтобы продолжать упорно следовать традиционным «негибким» методикам управления проектами.

*Термин Scrum берет свои корни из командной тактики регби-команд.

Таким образом, появился Scrum — методика управления проектами, основанная на взаимодействии команды как единого организма.

Следует отметить, что совокупность «гибких» методик управления проектами образует Agile подход.

В 2001 году Кен Швабер и Джефф Сазерленд приложили свои совместные усилия к созданию Манифеста Agile.

Agile включает в себя рассматриваемые в статье Scrum, Kanban и Lean.

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

Таким образом, работа над проектом состоит из спринтов, длительностью 2-4 недели, каждый из которых содержит перечень задач, именуемых «user stories».

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

Сам список задач называется «Product Backlog», — бэклог продукта, и представляет собой приоритезированный список требований к продукту.

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

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

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

Итак, мы приходим к ключевому отличию Scrum от других «гибких» методик управления проектами, — распределению ролей.

Прежде всего при работе по Scrum важно наличие двух ключевых персон: Scrum-master и Product Owner.

Scrum-master непосредственно внедряет методику в командную атмосферу, интегрирует систему управления в командные процессы.

Product Owner в свою очередь является связующим звеном между заказчиком, пользователями, ТОП-менеджментом и командой разработки в широком ее понимании, не ограничиваясь Dev-тимой.

Product Owner’а условно можно охарактеризовать как переводчика, полиглота в сфере бизнес-коммуникаций.

Так ли все идеально?

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

На этом моменте начинается самое интересное.

MVP действительно может быть футбольным полем, команда может регбистами, которые нападают на бэклог по Scrum, вот только бэклог не всегда оказывается ожидаемой «дыней»**, а значит и в регби поиграть может быть крайне проблематично.

**Дыня — устоявшийся сленговый термин, обозначающий мяч, использующийся при игре в регби.

Почему проблематично?

Работая со стартапами часто приходится сталкиваться с необходимостью искать среди «гибких» методик управления проектами способы сделать их более «гибкими».

В моей практике, на позиции Product Owner’a, передо мной стояла задача внедрить Scrum, построить по указанному фреймворку рабочие процессы в команде.

Задача была действительно интересная, учитывая, что 80% команды — удаленщики, а Scrum, если мы говорим о его каноническом виде, подразумевает ежедневные совещания.

На первый взгляд, каких-либо проблем или их предпосылок не возникает.

ZOOM, Skype в помощь, и Scrum успешно реализуется в удаленных командах.

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

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

Инсайт пришел от Dev-команды. Senior Team Lead на тот момент работал со своими подопечными по Kanban.

Что такое Kanban?

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

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

Теоретически, Kanban может применяться командой даже при отсутствии Product Owner’а / Product Manager’а.

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

Я предложил Тимлидам работать внутри своих узкоспециализированных команд (разработчики, дизайнеры, копирайтеры) по Kanban, а на внешнем уровне, с менеджментом, с бизнес командой (Scrum-master, Product Owner) — работать по Scrum.

Таким образом, мы переходим к ключевым инсайтам.

Истина где-то посередине, современный опыт применения «гибких» методик управления проектами показывает, что наиболее эффективного, релевантного в 100% случаев фреймворка не существует.

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

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

В процессе работы мне удалось сформировать правило: «Kanban подход уместен при работе с продуктом только в том случае, если с внешней стороны, на уровне проекта, реализуется управление по Scrum».

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

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

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

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

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

Agile — это история про изначально проактивную команду.

В заключении немного о Lean.

Lean также является одной из «гибких» методик управления проектами, однако в большинстве известных примеров данный подход используется применительно к производственным предприятиям.

Суть подхода заключается в максимальной минимизации потерь, снижения издержек производства.

Ввиду специфической области применения методика не является доминирующей среди современных стартапов, а IT-стартапы в большинстве своем ориентируются на Scrum.