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

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

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

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

Итак, разделение ответственности руководителя группы, при котором ее значительная часть передается всей команде, потребовало средств синхронизации представления о текущем состоянии работ для всех членов команды. Прорыв Scrum стал возможен благодаря тому, что в него включены простые и наглядные способы визуализации продвижения внутри спринта: доска и burndown chart, а также встречи, на которых эти представления обсуждаются и синхронизируются у всей команды. С момента появления техника работы с досками развивалась, довольно много в нее внес Kanban, который используется не только для организации работы небольшой команды, но и для больших подразделениях. И сейчас накоплено множество техник, позволяющих наглядно представить на доске ситуацию в проекте. Опыт внедрения Agile-методов показывает, что сама по себе визуализация работ на доске позволяет существенно повысить эффективность работы даже без перестройки других механизмов управления, просто за счет прозрачности ситуации для всего коллектива.