Краткое руководство по масштабированию Scrum встреч до 50+ участников (без дополнительных затрат)

Скрам масштабируется

Рост - про увеличение в размере, масштабирование - про повышение интеллекта. Рост - о добавлении слоёв иерархии, новых ролей и процедур. Масштабирование - о преодолении сложности её минимизацией.

 

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

 

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

 

Не то, чтобы участники команд буквально уничтожали элементы беклога при планировании спринтов… но ход мысли и общая идея вам должны быть понятны.

 

Вам не нужно управлять молекулами воды, чтобы они выполняли свои функции. Нужно позволить им сделать свою работу. Именно так и Scrum помогает решать сложные и трудоёмкие задачи: спуская их на уровень команд и конкретных людей, позволяя им самостоятельно разбираться во всех необходимых деталях.

Скрам встречи масштабируются

По правде говоря, все Scrum встречи масштабируются настолько просто, что я довольно долго сомневался, писать ли об этом вообще.

 

Для масштабирования Scrum церемоний фасилитатору необходимо сделать следующее:

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

Давайте посмотрим на практическое воплощение этих идей.

Масштабирование работы над беклогом продукта

Преодоление сложности - не про разбивание больших вещей на мелкие элементы: очень надеюсь, что вы не разбиваете тарелки на мелкие кусочки, чтобы их помыть (я уже молчу о мойке машин и купании детей). Вместо этого вы просто подставляете тарелку под струю воды и позволяете молекулам выполнить свою работу на невидимом (неуправляемом вами) уровне.

 

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

 

Как раз наоборот - вы добьётесь обратного эффекта - так как кому-то теперь придётся заниматься склейкой всех этих компонентов. Хотя на первый взгляд это выглядит не очевидно, вы должны разок увидеть это своими глазами, тогда вы поймете, о чём я говорю...

Подготовка места проведения встречи

Когда мы пытаемся масштабировать разработку продуктов, мы часто обращаемся к совету из Large-Scale Scrum: фокусируйтесь на всём продукте. На этом этапе я обычно помогаю группе стейкхолдеров, визионеров и продуктоводов совместно создать общее понимание “большей картины”, чем те, что есть у каждого. Иногда они приносят свои мини-беклоги, и мы начинаем склеивать продукт по кусочкам. Это зачастую довольно длительный процесс.

 

В большинстве организаций это процесс создания “большой картины” может занять довольно много времени. Это связано в первую очередь с тем, что практики сегодняшнего продуктового менеджмента (так сказать его статус-кво) как раз поощряют разбиение больших продуктов на мелкие удобоваримые куски. Поэтому у меня всегда при себе, помимо маркеров и стикеров, есть баночка супер клея. Также с её помощью я могу выделывать всякие штуки, но это совсем другая история.

 

На фотографии ниже группа продакт менеджеров совместно создаёт общую “большую картину” продукта. На доске отображены: общие бизнес цели, цели релизов, “user journeys” и прочее - там также достаточно места для будущего беклога:

 

Как “большая картина” готова - приглашаем всех в комнату!

 

Приглашение участников и объяснение целей

После того, как мы всех собрали ("все" - это те, кто может помочь нам разобраться в деталях работы), один из менеджеров продукта объясняет всем собравшимся принципы организации доски: цели, приоритеты, проблемы и задачи, гипотезы и главные общие вопросы.

Пока детский лепет, не правда ли? А вот теперь будет весело!

Маленькие самоуправляющиеся группы

Один продукт, один беклог продукта, общая работа над беклогом продукта - наша мантра, которую мы используем каждый раз, при работе над продуктом, где задействовано несколько (много) Скрам-команд.

Чтобы упражнение получилось обучающим (и, кстати, встреча для общей работы над белковом продукта - это в первую очередь обучающая встреча), мы перемешиваем всех участников из существующих команд разработки, формируя новые временные группы специально для этой встречи. Мы хотим, чтобы в каждой группе были участники из всех команд.

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

 

Это то, что гибкость на продуктовом уровне на самом деле означает (помимо других вещей).

Краткие рекомендации для команд

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

  • Каждая группа берёт непроработанный элемент беклога продукта, приглашает в группу одного из продакт менеджеров и обсуждает эту тему не более 15 минут.
  • Главной целью обсуждения является выработка общего понимания: в чём заключается проблема, как выглядит “user journey”, … - минимальный, но достаточный объём информации, чтобы можно было сказать можно ли это сделать вообще, и если да - не слишком ли тут много работы. В противном случае - элемент бьётся на меньшие части.
  • По истечении 15 минут вся группа решает (с помощью быстрого голосования), насколько готов данный элемент и визуально это помечает на карточке (одна точка - недостаточно понимания; две точки - есть вопросы, но в целом понятно; три точки - alles klar!) и переходит к следующему непроработанному элементу.
  • И, кстати, друзья, наши элементы беклога продукта не хранятся в Jira. На самом деле мы не так давно отменили нашу лицензию Jira, когда перешли к использованию листов A3 для элементов беклога. Эмпирическим путём мы пришли к тому, что этого размера бумаги достаточно для хранения оптимального количество деталей. (И не спрашивайте, как апологеты экстремального программирования умудрялись втиснуть свои истории на пяти-дюймовых индекс-карточках. Получается, размер таки имеет значение).
  • По завершению оценки элемента беклога, участники группы складывают лист A3 и вешают его назад на стену. Таким образом, другим группам тоже будет видно, что этот элемент проработан, так как на нём есть точки.
  • Обычно за часовую встречу мы успеваем проработать около 12-15 элементов беклога, этого нам как раз хватает на две недели работы всех команд.

Не вмешиваться (напоминание менеджерам)

 Эта встреча выглядит довольно неорганизованной, даже хаотичной, и, если посторонний человек случайно войдёт в середине совещания, то ему, скорее всего, покажется, что совещание просто неуправляемое: некоторые рабочие группы иногда распадаются на ещё более меньшие, кто-то спонтанно подбегает к доске и начинает чертить диаграммы, другие внезапно решают пообщаться один-на-один посреди комнаты…

Но мы то знаем - всё идёт путём..

 

На самом же деле, хаос - это признак самоорганизации. Сравните, к примеру, солдат, марширующих на параде; и толпу хипстеров, стягивающихся к стадиону на концерт Red Hot Chilly Peppers. Кто из них кажется более организованным, а кто - хаотичным? Кем из них управляют, а кто самоорганизовался?

 

Так что, на самом деле ничего страшного, если процесс выглядит немного беспорядочным. Более того (и это мой личный вывод) - если Scrum-встреча недостаточно сумбурна - вы что-то явно недоглядели!


Write a comment

Comments: 0