Scrum: пять изменений организации команды, принесшие успех agile

Как я писал в завершении предыдущей статьи «Agile – ответ IT на вызовы цифрового мира», в этой, девятой статье серии «Менеджмент цифрового мира», мы начинаем рассматривать Scrum – метод, которому agile обязан своим успехом. И начну я это со списка пяти принципиальных изменений организации команды, которые он принес, а затем буду рассматривать их подробно.

Итак, первое изменение – кроссфункциональная проектная команда вместо функциональных отделов специалистов. Отметим, что проектные команды были достаточно распространены в IT. Но не менее было распространено и деление специалистов на функциональные отделы с передачей задач от отдела к отделу. И делали это в полном соответствии с учебниками менеджмента, чтобы обеспечить равномерную загрузку специалистов. Проблема лишь в том, что такое преобразование эффективно лишь в условиях, когда технология работы обеспечивает гарантированный результат, и возвраты по фазам работ – редки. В IT это не так, проект развивается в условиях неопределенности, а возвраты возникают часто. В этих условиях команда, обладающая всеми компетенциями, чтобы решить задачу – наиболее эффективный способ организации. Даже если в результате не все члены команды будут загружены полностью.

Отмечу, что это – совершенно общий принцип: в стабильных условиях выигрывает специализация и технологии, и выгодно строить длинные цепочки создания ценности с разделением на операции. А в условиях неопределенности результата и отсутствия технологий, дающих гарантию, эффективны короткие цепочки, в пределе – одна команда, которая доводит задачу до результата. Команда также может компенсировать недостаток компетеции отдельных специалистов за счет коллективного поиска решений. Отмечу, что вызовы цифрового мира – возрастание неопределенности VUCA-мира и цифровизация регулярных процессов, сохраняющая на людях только работу в особых случаях существенно повышают неопределенность в задачах и в других отраслях. И потому отказ от функциональных отделов в пользу команд, обеспечивающих решение задач с сокращением цепочек создания ценности – часть естественной перестройки организаций. Но об этом я еще буду говорить подробнее в будущих статьях.

И надо отдельно остановиться на том, что такое «кроссфункциональная команда», каких специалистов в нее надо включать? Общий ответ звучит так: всех, чьи действия существенных для комплексного решения задач, возлагаемых на команду. Команда может зависеть от внешних специалистов только в тех работах, которые нормированы и предсказуемы, и службы выполнения которых представляют инфраструктуру, то есть не являются ограничением для потока задач команды. В IT хорошим примером являются специалисты баз данных. Обычно разработчики имеют ограниченные компетенции по работе с базами данных и в команде специалист высокого уровня не нужен. Однако, когда идет разработка высоконагруженного приложения, для которой технические решения по работе с базой данных существенно влияют на его работоспособность, такой специалист в команде необходим. Аналогично и вне IT. Например, если решение задач включает заключение договоров, при этом договора – типовые, а юристы и бухгалтерия имеют налаженный документооборот, обеспечивающие прохождение договора в удовлетворительном темпе, то они могут быть за пределами команды. А вот если команда занимается уникальными сделками, требующими привлечения юристов и бухгалтеров для грамотного оформления, включая, возможно, переговоры с клиентом, то они должны быть в команде.

Возвращаясь к истории IT, надо сказать, что функциональная ориентация сотрудников проявлялась не только в организации отделов, но и в том, что даже будучи включенным в проектную команду каждый специалист ориентировался на решение только своих задач. Эта привычка, подлежащая искоренению. Да, мы ценим те компетенции, которые необходимы для проекта, и которые привели к включению вкоманде, но при этом полагаем, что конечная цель по решению задачи, которая стоит перед командой – важна и ожидаем сотрудничества и вклада даже в том случае, если профессиональные компетенции в моменте не востребованы. В IT вопрос стоял остро, и в ранних работах по Agile были жесткие формулировки: любой член команды может и готов решить любую из задач. А, чтобы вывести людей из функциональных границ, рекомендовалось, как возможная практика на начальном этапе внедрения, просто распределять задачи по жесткой очереди или даже по жребию, чтобы все быстро получили нужные компетенции.

Позднее от этого отказались, и сейчас определение кроссфункциональной команды именно такое, как я написал выше. При этом приветствуется умение решать задачи из смежных областей, а не узкая специализация, чтобы команда могла справляться с неоднородным потоком задач. И, более того, узкие специализации бизнес-аналитиков и системных аналитиков объединились в просто аналитика, который заодно может являться в команде тестировщиком, аналогичные процессы можно проследить среди специализаций разработчиков. А в целом это соответствует общему современному тренду перехода от I-людей с одной специализацией к T-людям, умеющим работать и в смежных областях, и даже к m-людям, имеющим несколько глубоких специализаций. Просто в IT это началось лет на 10-15 раньше, чем в остальных отраслях и не называлось таким образом.

Второе изменение организации – разделение ответственности менеджера, на мой взгляд, является ключевым. Его часто не акцентируют, а просто сообщают, что согласно Scrum Guide, команда включает в себя Владельца продукта (Product Owner), членов команды разработки (Development Team) и Скрам-мастера (Scrum Master). Product Owner отвечает за продукт, то есть за содержание той ценности, которую команда создает, команда разработки создает эту ценность, а фокус Скрам-мастера – помощь команде в ее самоорганизации для того, чтобы поставлять эту ценность быстро и качественно. Такое разделение решило старый спор о том, кто лучший руководитель в инженерных проектах – специалист в предметной области, или универсальный менеджер, который в предметной области не разбирается, зато обладает нужными soft skill, которые отсутствуют у предметника.

Отметим, что ответственность Product Owner за время развития Scrum претерпела эволюцию, связанную с изменением рамки проекта, о которых я говорил в своей статье «Краткая история IT-менеджмента». В те времена, когда Scrum зарождался, заказчики софта обычно заказывали конкретный функционал, который необходим им для поддержки бизнес-процессов, а Product Owner при переговорах со стейкхолдерами оценивал техническую возможность разработки в разумные сроки, и от него требовалось больше компетенций именно в технической стороне. В настоящее время гораздо больший акцент в заказе – возможность решения конкретных бизнес- задач, и потому Product Owner должен быть специалистом в бизнесе. Впрочем, такое разделение сильно зависит от характера проектов и взаимоотношений с заказчиком, эти границы подвижны. Просто надо учитывать, что в разных книгах эта граница проведена по-разному, в зависимости от опыта автора.

В целом ответственность за технические решения по реализации лежит на команде. Scrum не говорит, как именно она устроена, однако он явно выделяет мероприятия, на которых реализация должна быть прояснена достаточно для уверенной оценки ее трудоемкости. И детали отдает на самоорганизацию команды. При этом, если компания устроена так, что в командах много новичков с недостаточным опытом, то часто выделяется роль технического лидера (Tech Lead) или архитектора – опытного специалиста, отвечающего за технические решения. Но это должно быть обосновано, и не случайно это не проявлено в Scrum Guide: если команда включает опытных самостоятельных разработчиков, то выделение ответственного за технические решения наоборот. является вредным и демотивирует других членов команды, превращая их в исполнителей. Поэтому лучшая практика – когда технические решения готовит исполнитель, а по существенным вопросам предлагает их членам команды на review.

Отдельно надо подчеркнуть, что основная ответственность за организацию работ лежит на команде, а не на Scrum Master, который лишь помогает команде соорганизоваться. И это третье изменение – управление через самоорганизацию, блокировка микроменеджмента. Во всех учебниках по менеджменту говорят, что микроменеджмент не эффективен, что руководитель должен организовать работу так, чтобы не быть поглощенным операционкой, ежедневно раздачей задач. А в Scrum это просто сделали на уровне процесса – в нем нет места, где можно отдать указания. Вообще. И если у члена команды с решением задачи возникают трудности – то он тоже не идет к кому-либо за указаниями, а запрашивает помощь по своему выбору, не отдавая при этом ответственность. А чтобы он не забыл и не стеснялся это делать, в процедуру ежедневных встреч (Daily Scrum Meeting) включен вопрос – что мешает продвигаться к решению задач.

Примерно таким же образом делится ответственность, если мы говорим о внедрении Scrum за пределами IT, например, в продающих подразделениях. Руководители, которые отвечали за определенные сегменты рынков становятся владельцами продуктов и ставят задачи. И команды продавцов уже сами решают. каким образом эти задачи выполнять. на чем концентрировать свои усилия, где есть перспективы. А роль Скрам-мастеров начинают выполнять руководители групп, отвечающие за организацию работ менеджеров по продажам, если они были в компании, а если их не было – то опытные из числа продавцов, кто может обучать других.

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

Раз мы разделили ответственность, возникает задача синхронизации представлений всей команды о продвижении проекта. И успех Scrum обусловлен тем, что он предложил простые инструменты для этого – доску и burndown chat, а также необходимое количество встреч для синхронизации. Это – четвертое изменение. Отметим, что одному руководителю такие инструменты не нужны, он вполне может работать диаграммами Ганта или другими сложными средствами, а вот требования для инструментов, используемых всей командой – гораздо выше. Техника работы с досками далее развивалась, и сейчас может дать эффект даже без изменения процессов, внедрение Kanban, например, начинается именно с визуализации на доске потока работ. В следующей статье мы ее обсудим подробнее.

А последнее, пятое изменение – итеративная поставка ценности. Это та самая схема Scrum, которая очень популярна, и с которой обычно начинают рассказ. Но которую часто понимают упрощенно – мы просто квантуем поток. Впрочем, иногда это уместно, потому что Scrum могут использовать как эффективный инструмент перестройки культуры компании, благодаря тому, что в процесс встроены предохранители против старого менеджмента, и Agile-коуч может не просто заметить, а явно и обоснованно указать команде на возврат к старому.Ну а через некоторое время это начинают делать Скрам-мастера и другие члены команды. и их замечания невозможно отвергнуть – есть Scrum Guide, который надо выполнять. Да, можно не выполнять – но тогда надо честно признать, что Scrum у вас – лишь вывеска, а не содержание.

Схема Scrum – сложная, она включает в себя и функциональную схему процесса и реализацию его элементов. Более того, на рисунке приведена не полная схема, хотя представляют обычно именно такой вариант. Я ее тоже буду разбирать отдельно, уже после статьи про доски.

А в заключении этой статьи надо сказать, что Scrum-процесс – на уровне команды. И он ничего не говорит, как синхронизировать работу разных команд, организовать управление компанией в целом. Это можно делать с помощью Kanban для потока ценности компании в целом, или использовать другие фреймворки, или строить собственные конструкции. Об этом я тоже буду говорить в последующих статьях. Продолжение следует…