Непростая жизнь Скрам-мастера. Что бы сделали вы?

[Alexey Krivitsky]

Вы - скрам-мастер проекта. 

Сегодня понедельник, и планирования спринта назначено на 10:00. Вы надеетесь, что оно пройдет более слажено, чем в прошлые разы. Команда начала брать на себя ответственность за процесс. Пятничная ретроспектива завершилась многообещающим планом улучшений. 

Вы распечатали карточки историй, сдвинули столы, создали на wiki чистую страницу для нового спринта, проверили проектор... 

За пять минут до начала раздается Skype-звонок. Это ваш Product Owner - Пит. 

Он извиняется и говорит, что ему нужно срочно уехать к клиентам в пригороде Лондона. Пит просит вас провести планирование без него. 

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

Что вам делать?

Alexey Krivitsky

Certified Scrum Trainer

SCRUMguides: Agile coach, Scrum Trainer & Executive

Agile Eastern Europe : Executive and Main Producer
AgileUkraine: Founder and Coordinator
LinkedIn | Twitter | CV | Blog | Skype: alexeykrv | +38.050.358.9212

Author of lego4scrum and outsourcing30.com

[Alexander Rivkind]

Я так понимаю, что:

- PO не может подключиться к митингу даже по телефону и не сможет это сделать до среды?

- Нет возможности коротко переговорить с РО и взять у него по телефону инструкции, какие из историй более приоритетные?

- Список высокоприоритетных историй, из которых формируется спринт - пустой, есть только беклог?

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

Если есть возможность, выбрать самим истории (например по приоритетам, до этого ж проводили какие-то PBR, наверное), желательно самые короткие :) и выслать посьмом PO на утверждение.

Какой "правильный ответ"? :)

2012/9/30 Alexey Krivitsky <alexeyk...@gmail.com>

--
Agile Software Development Group, Ukraine, http://www.agileukraine.org/
 
To visit the group online see: http://groups.google.com/group/agile-ukraine/
To post to this group send email to agile-...@googlegroups.com
To unsubscribe send email to agile-ukrain...@googlegroups.com

--
Best Regards, Alik.

[Borys Lebeda]

Привет,

Я правильно понимаю, что у команды нет Product Backlog, который
по контенту покрывает если не итерацию, то хотя бы время до среды?

2012/9/30 Alexey Krivitsky <alexeyk...@gmail.com>:

> --
> Agile Software Development Group, Ukraine, http://www.agileukraine.org/
>
> To visit the group online see: http://groups.google.com/group/agile-ukraine/
> To post to this group send email to agile-...@googlegroups.com
> To unsubscribe send email to agile-ukrain...@googlegroups.com

--
Borys L.

[Serhiy Yevtushenko]

И проводился Product Backlog Refinement за неделю до планирования?

Сергей

1 октября 2012 г., 15:34 пользователь Borys Lebeda
<borys....@gmail.com> написал:

[Alexander Burdun]

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

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

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

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

Как вариант можно именно в таком случае как в кейсе(ПО не будет полспринта, и порешать вопросы с ним не получится) отвлечься командой на сервисные задачи. Тоже иногда полезно. Как раз за спринт навести порядок в проекте, рефактор, а может были какие-то баги висячие, но не срочные.

1 октября 2012 г., 15:38 пользователь Serhiy Yevtushenko <syevtu...@gmail.com> написал:

--
Александр Бурдун

tel: +38 097 137 0443
skype:    a.burdun
AIM/ICQ: 307064073
http://burdun.com

[Alexey Krivitsky]

Всем спасибо за активность.

У кого еще какие мысли?

Леша

2012/10/1 Alexander Burdun <a.bu...@gmail.com>

[Alexander Burdun]

И ПО надо воспитывать. А то что за внесение дезорганизации в ряды.
Идеальный вариант это он говорит: так, чуваки, меня не будет, вопросы есть?
И тут уже выплывает. Ладно демо не проведется, но спринт заранее спланировать можно.

1 октября 2012 г., 16:20 пользователь Alexander Burdun <a.bu...@gmail.com> написал:

[Alexander Rivkind]

Так а правильный ответ будет?

И призы! :)

2012/10/1 Alexey Krivitsky <alexeyk...@gmail.com>

--
Best Regards, Alik.

[sergiy movchan]

книжку, чтоли, пишешь? :) когда ждать?

2012/9/30 Alexey Krivitsky <alexeyk...@gmail.com>

--
Agile Software Development Group, Ukraine, http://www.agileukraine.org/
 
To visit the group online see: http://groups.google.com/group/agile-ukraine/
To post to this group send email to agile-...@googlegroups.com
To unsubscribe send email to agile-ukrain...@googlegroups.com

--
...dali bude...

[Vlad Savitsky]

Привет.

В книге читал - рекомендуют идти серфить на досках и ждать, когда ПО придет с вопросами.

Смелый шаг. Это наверняка спровоцирует конфликт и, если не знать как его разрешить, то результат может быть неожиданным.

Мы делали иначе - устраивали технический спринт (технический долг и тикеты, нужные команде, а не ПО).

Либо сами планировали на своё усмотрение. В этом случае я был вместо ПО и старался использовать видение проекта.

В вообще, я согласен - ПО нужно воспитывать и процесс этот не быстрый.

Влад.

2012/10/2 sergiy movchan <sergiy....@gmail.com>

--
 Vlad Savitsky
(Team Lead, Shvets Group)

+380965302712
Skype: vlad_savitsky
vlad.s...@shvetsgroup.com

http://www.linkedin.com/in/vladsavitsky

[Artem Mygaiev]

+1 за работы над техническим долгом или просто задачами которые интересны/нравятся команде, при отсутствии заранее оговоренных (в проекте) правил на такой случай.

Артём

[Borys Lebeda]

-1 работать над техническим долгом, в книжке правильно написали :)

Чаще всего через два спринта заказчик вообще считает нормальным не выходить на связь с командой. Разве что ваш заказчик владелец компании, self made man и вообще большой молодец, и в свободное время любит бороться с техническим долгом. А вот средне-статистический ПО это обычный менеджер среднего звена, которому проще строчить отчёты руководству раз в неделю о том что всё зашибись и команда настолько agile, что сама знает что нужно. ... А самому сёрфить на доске.

Кроме того, борясь с техническим долгом и команда привыкает работать без ПО - возвращаться потом в штатный режим работы бывает не легко.

Так то!

[Artem Mygaiev]

Простите, а вам шашечки или ехать?

Если у вас ПО некомпетентен - вы его так не воспитаете, а только развалите команду через 2 таких спринта. А ПО с вероятностью 99% чудесным образом все свалит на СМ, особенно если это происходит в самом начале проекта.

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

А вообще, конечно, 100% рецепта успеха нет... Иногда и итальянские забастовки могут помочь, да.

Артём

[Eugene Shifrin]

Иногда итальянские забастовки могут помочь

 

А иногда пройти сперва незамеченными, и потихоньку стать постоянным состоянием проекта J))

 

 

Eugene Shifrin

CEO

MWDN Ltd - the people who get things done

----------------------------------------------------------------

US: 202-657-4450

Ukraine: +380675742485

Israel: +97237226086

mailto:eug...@mwdn.com

skype: eugene.shifrin

http://www.mwdn.com

[Borys Lebeda]

Господа,

Если вы работаете на хлебокомбинате, на который вовремя не
привезли муку, то вы скорее всего работать не будете.
Такое положение дел не корректно называть итальянской забастовкой
(даже если хлебокомбинат находится в Италии :)), это технологический
простой и для директора, инвестора или стейхолдера, оно должно
выглядеть именно как технологический простой.
Если начальник цеха Артём при этом предлагает пекарям протереть
огнетушители или научить печь хлеб из вторсырья, то он рискует
нарваться на неприятности как со стороны команды, так и со стороны
руководства ...

Ладно я пошутил :)

Конечно, нужно работать над технологическим долгом (особенно если
это происходит в самом начале проекта)
ведь если отпустить команду в отпуск или на соседний проект, или
оставить заниматься самоподготовкой, то она непременно развалится
через пару спринтов.
И, конечно, надо ПО дать понять, что даже если работы нет, то мы
всё равно её себе придумаем, а иначе он с вероятностью 99% чудесным
образом все свалит на вас.
А то, что в книгах пишут - чепуха, их одни ботаники пишут,
которые реально никогда проектом не управляли.

Вы меня убедили (+1)

P.S. Мне шашечки и ехать.

2012/10/3 Artem Mygaiev <jocu...@gmail.com>:

--
Borys L.

[Artem Mygaiev]

Спасибо, про комбинат улыбнуло. Хорошо, когда в топике есть люди с чуством юмора, веселые, задорные.

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

По сабжу - мне кажется, что тут есть немного непонимания. Я точно так же +1 за, цитирую:

отпустить команду в отпуск или на соседний проект, или оставить заниматься самоподготовкой 

только я работу над tech debt рассматриваю в том же контексте.

Единственное разногласие, вероятно, в приоритетах. Евангелитература рекомендует бездействием (по отношению к проекту) дать ПО понять что без его 100% участия работы не будет, и это тоже вариант - просто не стоит категорически отбрасывать остальные; можно сказать что "воспитательный" момент здесь приоритезируется. Я бы делал в такой ситуации то, что будет наиболее полезно для проекта и команды - в каких-то случаях действительно может иметь смысл воспитывать ПО, но ИМХО это далеко не всегда так. Как вы сами писали:

средне-статистический ПО это обычный менеджер среднего звена, которому проще строчить отчёты руководству раз в неделю о том что всё зашибись и команда настолько agile, что сама знает что нужно

возможно его и воспитывать-то бесполезно, а только локального по отношению к команде proxy делать. Или, не дожидаясь пока полностью зафакается проект в то время пока команда серфит на досках, потребовать замены ПО.

Возвращаясь к начальному топику Алексея - мне кажется, что предлагалась скорее тактическая задача, внезапное отсутствие вполне себе адекватного, хотя и неопытного ПО ("[планирование] пройдет более слажено, чем в прошлые разы") при не очень зрелой команде ("команда [только] начала брать на себя ответственность за процесс"). Очевидно, что ПО начинает заниматься sales ("это то, что нам нужно!") и скоро вообще пропадёт из виду - не потому что он подлец и лентяй, а потому что его перегружают другой работой. ИМХО долгосрочно тут нужен прокси или другой ПО. Краткосрочно - я бы сместил планирование на среду, 2 дня потратил на blackjack and hookers - то есть что команде угодно (учитывая незрелость команды - всё-таки на тренинг и работы по последней ретроспективе).

А вообще хорошо что вы заплюсовали, у меня даже карма как-то посветлела вроде.

Артём

[Vova Oros]

Я бы всё таки крайне не рекомендовал работать над тех. долгом. Такая игра в демократию и спрашивание работников, что они считают нужным делать, приводит к частой работе над рюшечками, которые людям нравятся. И никак не над беклогом, который так или иначе существует, и приоритеты расставлены. Такая фигня, конечно, может тянуться от нескольких недель до нескольких лет - но рано или поздно приходит кризис и либо менеджера поменяют либо проект закроют.

Конкретно по ситуации - команда же работала спринт до этого, значит и беклог и приоритеты есть! Если тех. долг на ретроспективе/пре-планнинге в _явном_ виде не был поставлен в высокий приоритет, лучше его не делать. А вообще - вполне нормальная и обычная ситуация. Однако Скрам Мастер _должен_ взять на себя обязанности Продакт Овнера. И делать работу вместо него. И со временем получить повышение. Ну, или, жаловаться и искать виноватых... выбор всегда есть.



Неділя, 30 вересня 2012 р. 16:25:40 UTC+3 користувач Alexey Krivitsky написав:

[Sergii Malyi]

Читаешь ответы и умиляешься :)
Сразу видно, кому ехать, а кому шашечки :)
Конечно же скрам-мастер должен взять на себя ответственность. Если он
представляет себе, какие задачи являются более приоритетными. Если он
вообще в контексте проекта. Если он не "фингерпойнтер". Если он
менеджер, а не разносчик кофе. Вот и все, о чем здесь стоило говорить.
А соответствует это рекомендациям или не соответствует - дело десятое.
Нам платят за своевременно и качественно выполненную работу, а не за
соблюдение рекомендаций.

--
Sincerely,
Sergii Malyi

2012/10/3 Vova Oros <pep...@gmail.com>:

[Vlad Savitsky]

Сергей, я так делал  - был и скрам-мастером и ПО...

Это вызывает волнения в команде, потому что начинаю требовать результаты и слежу за сроками как ПО, а не защищаю команду как СМ.

Кроме того роль ПО требует доп. времени, а я ещё и программирую по мере сил.

Пару спринтов мы так вытянули перед важной вехой проекта и всё сделали вовремя, но цена была очень большой.

Теперь у нас есть нормальный ПО и мы его действительно учим, но он и сам хочет учиться - так что нам повезло.

Так что могу подтвердить - да СМ брал на себя роль ПО (хотя и запрещено совмещать), но поручить другому быть скрам-мастером было нельзя в тот момент.

Устраивать забастовку в тот критичный для клиентов момент было равносильно увольнению всей командой.

Сейчас же ситуация более благоприятная и мы учим ПО и ждем от него приоритетов и видения проекта.

Влад.

2012/10/4 Sergii Malyi <serg...@gmail.com>