|
Украинскую версию статьи можно прочесть тут.
Scrum framework - легкий процессный фреймворк, который помогает людям, командам и организациям создавать ценность с помощью адаптивных решений комплексных проблем. Согласно ежегодному отчёту от State of Agile™ Survey - это самый популярный способ делать Agile. Руководство по Скраму (Scrum Guide) находиться в свободном доступе и его можно почитать/скачать тут.
Kanban Method - метод эволюционных изменений. Был задуман авторами, как альтернативный путь к гибкости - как способ повышения отзывчивости и адаптируемости без какой-либо существенной революции или реорганизации в вашем текущем подходе к работе или политической структуре вашего бизнеса. Официальное руководство по Kanban Method от Kanban University доступно тут.
Последние 11 лет я активно работаю с командами, суммарно за это время примерил на себя 20+ разных ролей в трёх больших компаниях. Практический опыт получилось насобирать от классического менеджера в организационной культуре Контроля до загадочной, до сих пор, для многих в IT, роли Scrum-мастера на несколько команд, в культуре Сотрудничества и Agile.
Сейчас я работаю в роли Scrum-мастера в компании Creatio (Terrasoft) и параллельно уже больше года в роли Agile Coach в компании Scrum Ukraine - провожу обучение и консалтинг по использованию Scrum и Kanban в крупных компаниях.
Работая в разных контекстах с разными людьми, командами, руководителями, стейкхолдерами я немного разобрался с тем, что такое команды, на самом деле. И чем успешные команды отличаются от тех, у которых не очень получается работать вместе, или тех, которые не являются командами вовсе. Работая по Scrum и применяя Kanban-метод, могу с уверенностью сказать, что эти подходы облегчают работу “команд”, фокусируют на важном и при правильном применений обеспечивают высокую эффективность и мотивацию участников. Scrum и Kanban отлично могут уживаться вместе и это не внезапная новость. Есть даже книги описывающие эти комбинации и им не один год, например:
- Corey Ladas - Scrumban: Essays on Kanban Systems for Lean Software Development (2008)
- Ajay Reddy - Scrumban [R]Evolution, The: Getting the Most Out of Agile, Scrum, and Lean Kanban (Agile Software Development Series) (2015)
А организация Scrum.org недавно выпустила Канбан-гайд для скрам команд (Kanban Guide for Scrum Teams), его можно скачать тут.
У меня нет цели пересказывать приведенные выше источники, я поделюсь некоторыми своими кейсами и примерами использования разных подходов. Интересный случай в моей практике был, когда еще в 2015-2016 годах, в течение десятков ретроспектив большой Agile-командой разработки (15-17 человек), мы формализовали отдельные элементы Scrum под себя. Параллельно каждый спринт я собирал десятки разных метрик описывающих происходящее в команде с позиции цифр. Было практично и многообразно.
Как оказалось позже, спустя 2-3 года на сертификации по Kanban (KSD+KMP), все эти инициативы и способы до которых мы догадывались экспериментируя, системно описывает Kanban-метод. Другими словами, то что мы годами называли в команде Scrum’ом оказалось одной из интерпретаций Kanban’а. У меня был приятный шок, мне кажется, я что-то понял в тот момент про суть Канбан-метода. Особенно круто было проверить на своих цифрах подход #NoEstimates, суть которого в отказе от оценок вовсе, как лишней потери времени и усилий оценщиков. Концептуально, за счёт чего можно отказаться от оценок задач, я описал в своей прошлогодней статье.
Осознанный и зрелый Scrum я увидел не так давно, в 2017 году. Тогда, всё сошлось, я прошёл две сертификации (CSPO+CSM) и сразу после этого начал работать в большой продуктовой компании Creatio (Terrasoft) full-time Scrum-мастером сразу в трёх командах. До этого этапа мне встречались лишь отдельные элементы, ивенты, эксперименты, подходы в Scrum-духе и Agile окружении. Тут же я увидел масштабный Scrum, много команд одновременно синхронно и асинхронно работающих над одним продуктом, как часы. У меня появилась возможность быть частью этого сонаправленного движения.
Последние 3.5 года я активно экспериментировал работая в Scrum, в том числе используя Kanban, когда у тебя три команды и каждых две недели происходит три спринта, есть где разгуляться в этом плане. Без моих волшебных Scrum-команд, я бы конечно не справился в одиночку, спасибо им за терпение и поддержку, а моему руководителю и стейкхолдерам за создание возможности этим инициативам случаться :)
Мы перепробовали действительно многое: сотни форматов ретро, передизайн внутренних процессов, упрощения и исключения потерь на разных этапах, точечные экспресс-обучения и комплексные тренинги/воркшопы по разным темам, попытки научиться смотреть на систему целиком (System Thinking), ежегодные Futurespective, сессии открытых фидбеков внутри команды, пост-оценивание задач, всевозможные вариации визуализаций, физические и виртуальные доски, определение критериев Advanced Agile команды и т.д.
Когда я пришел работать в Terrasoft (Creatio) в 2017 году, Agile-трансформация уже три года как произошла, Scrum-революция случилась. Все, в большинстве, уже знали что и как делать, зачем нужен тот или другой артефакт, как проводить ивенты, вести роадмап или бэклог, запускать спринты. В первую очередь из-за поддержки, вовлечённости и осознанности в Agile/Scrum руководства на мега-высоком уровне. Помню, кто-то сказал мне тогда из коллег: “Мы не играемся со Scrum’ом - мы так работаем. Это наши правила взаимодействия внутри и между командами.”
Вызов для меня состоял не в революции, а в выстраивании самоорганизованных и зрелых кроссфункциональных фиче-команд для работы в долгую: мы были и есть в фазе Continuous Improvement (Непрерывное совершенствование). Нам нужно было искать способы и подходы для эволюционных изменений. Я начал изучать разные варианты, среди которых были XP, Teal, Kaizen, Kanban, в итоге остановился на последнем, как самом подходящем в моём случае.
Kanban-метод - для меня открылся в первую очередь, как набор из десятков разнообразных идей, принципов, инструментов, потокоориентированости, WiP-лимитов, метрик, графиков, классификаций, которые помогают не останавливаться в развитии процессов и организации в целом. Канбан не требует революций - пользу можно получать сразу, путём маленьких, но регулярных улучшений. Канбан разделяет сервисную парадигму - а это значит что любую Scrum-команду или группу команд, которые делают общий продукт, можно рассматривать как некий сервис, который имеет границы, у которого есть заказчики и есть получатели ценности, которую сервис производит. У такого сервиса есть точка принятия обязательств и точка поставки, а Канбан-метод в свою очередь применяется как способ улучшения качества обслуживания этого сервиса. Это главная идея - всё остальное манёвры.
По сути, Kanban не внедряют, а применяют к процессу, который уже есть. Существует даже правило в сообществе Канбан-практиков, суть которого звучит приблизительно так: “Первое правило настоящего Канбаниста не произносить слово Канбан”. Почему это правило может пригодиться? Дело в том, что у людей с которыми вы работаете, может отличаться восприятие термина “канбан” и вы сможете столкнуться с сопротивлением или пониманием по-своему, еще до начала каких либо действий. Можно использовать отдельные техники и метрики и они будут приносить пользу команде.
Работая с любым уже существующим процессом вы можете применять Канбан-метод, даже если этот процесс организован по Scrum. В самом Scrum фреймворке уже заложены идеи из Kanban-метода, и наоборот. Просто эти идеи описаны или существуют не для всех в явном виде. Приведу примеры: один продукт для одной команды - чем не WiP limit = 1 для кол-ва продуктов над которыми работает команда в один момент времени? Или как формируется Sprint Backlog из Product Backlog - чем не вытягивающий принцип Kanban, который используют в Scrum? Definition of Done - чем не формализация для однозначного понимания пересечения точки поставки? Непрерывный процесс Product Backlog Refinement (PBR) - микс UpStream и DownStream только явно не прописанный в Scrum Guide? И т.д. и т.п.
Про практики и примеры такого осознанного применения Kanban-метода в рамках Scrum’а я рассказывал на нашем вебинаре.
В марте Scrum Ukraine проводит тренинг Kanban Management Professional I. Мы узнали у тренера Paul Klipp, зачем нужен этот курс и что он даст.
23 февраля Scrum Ukraine провели первый тренинг Kanban Basics. Он прошел в приятной дружеской атмосфере и, по отзывам участников, был интересным и продуктивным. Провели тренинг наши коучи, Миша Глущенко и Павел Камышов.
Миша Глущенко получил звание Accredited Kanban Trainer, что позволяет ему вести аккредитованные тренинги-сертификации.
