Як Scrum Master бере участь у щоденних режимах очікування?

У нас є професійний консультант Scrum Master [*], який нещодавно приєднався до нашого проекту. На жаль, ми не знаємо її імені (вона ніколи не представилась нам, вона просто зайшов за один день і сказала "у нас є щоденний стенд"), і, схоже, вона не робить багато іншого, крім крісла щоденна зустріч, коли я напівжартома попросила її також щоденно давати відгуки на зустрічі, вона досить здивовано сказала, що це робота майстра Scrum - "полегшити, а не брати участь".

Це здається досить антигігіальним (працював над іншими спритними проектами, де команди керувались самостійно), що повинно бути егалітарним, але я не впевнений у тому, як це працює в методології Scrum. Я підозрюю, що вона не робить багато цілий день, і це є причиною її оборонності в цьому питанні.

Чи бере участь майстер Scrum у "вчорашньому, сьогоднішньому перешкодах" під час засідання, або їх роль просто головувати ("сприяти") зустрічі?

[*] Нам насправді не сказали, яка її робота, ми просто припускаємо, оскільки вона називає себе майстром Scrum

В ідеалі майстер scrum відповідає за сприяння проектній діяльності та усунення будь-яких перешкод, що виникають під час цього. Він / вона не бере участі у спілі "вчора, сьогодні, перешкоди" під час щоденного протистояння сам по собі, однак несе відповідальність перед членами команди за будь-який статус за перешкоди, про які вони повідомили під час попередніх процедур. .

Я працював з 5 командами scrum з відомою організацією, всі вони дотримувалися тієї ж практики.

Щоб отримати детальне уявлення про всі обов'язки майстра scrum, рекомендую ознайомитись з цим http://www.scrummasterchecklist.org/pdf/ScrumMaster_Checklist_12_unbranded.pdf

Я багато років був SM, відкладаю команду в цьому. Якщо вони хочуть, щоб я брав участь, я це роблю, а також сприяю.

Ідея полягає в тому, щоб бути одним із "слуг-лідера".

Команда повинна мати можливість "наймати / звільняти" СМ, не мати їх, а вимагати стати, не представляючи себе.

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

Якщо очікує, що СМ надасть статус її щоденній діяльності, то ІМХО має помилкові сподівання. Призначення статусу полягає в тому, щоб команда могла вирівняти свою діяльність, і я не знаю, чому член команди хотів би знати, що вона (SM) робила вчора, щоб планувати сьогодні. Принаймні одна книга навіть говорить про те, що від SM навіть не вимагається щоденних відвідувачів.

Майстер Scrum не обов'язково бере участь у щоденній зустрічі Scrum згідно з офіційними рамками Scrum.

Кілька цитат з Scrumguides.org :

• "Майстер Scrum виконує правило, що в щоденній Scrum беруть участь лише члени команди розробників."

• "Майстер Scrum гарантує, що Команда з питань розробки має зустріч, але Команда з питань розробки відповідає за проведення Щоденної Скрутки".

• "Під час зустрічі члени Групи розвитку пояснюють [...]"

• Завдання майстра Scrum - це "сприяння подіям Scrum за потребою чи потребою"

(Тим не менш, IMHO збільшує прозорість, якщо майстер Scrum приєднується до процедури "вчора, сьогодні, перешкоди". Також ІМХО, досконалий Власник продукту, необов'язково може також брати участь і відповідати на три пропозиції у щоденній Scrum. Але це проти офіційного Scrum.)

У мене 3 команди Scrum на посаді майстра Scrum, і ми використовуємо електронну дошку завдань у нашій спритній практиці. Усі мої команди, за винятком однієї, надають свій статус для всіх завдань, над якими вони працюють, переходячи від однієї людини до іншої, в типовому процесі резервного копіювання. Команда винятків вирішила, що вони хочуть робити їх окремо, і тепер попросила, щоб я керував цим тим, хто керував зустріччю.

Чи є якесь виправдання для Scrum Master взяти на себе цю роль під час стендапу? Я можу зрозуміти, чи має команда більше 7 ресурсів, але здається, що це роль няні, покликана змусити всіх звертати увагу замість того, щоб команда відповідала за дорослих, тому що вони не хочуть брати на себе проблеми, щоб самоорганізуватися.

Один з членів цієї команди також виконує роботу для однієї з інших команд і в ретро-спринті зазначає, наскільки швидше проходить зустріч, коли кожна людина піднімається і приймає на себе керівництво на дошці. Команді це не мало ніякого значення, і спеціаліст з питань розвідки підштовхнув команду вистояти на ґрунтовному методі.

Ваша компанія почала неправильно. Майстер скраму повинен бути частиною команди.

Наймаючи штатного майстра розробки, все, що ви зробили, - це додати ще один шар між командою та керівництвом / власниками пакетів. Зовсім не спритний.

Одна людина з команди, зазвичай менеджер, який також є частиною команди, бере роль майстра скраму. Але це насправді не «титул». це роль, яку кожен може виконати за потреби. В одній команді ми звикли обертати її щомісяця.

Тепер це відповідає на всі запитання. СМ є частиною команди, він бере участь у всіх командах. легко.

бути SM - це лише найголовніша робота - слідкувати за зовнішніми завданнями команди. Тому SM зазвичай займає трохи менше роботи, тому що він буде тим, хто весь час переривається зовнішнім зв’язком та надсиланням електронних листів на кшталт "будь-які оновлення на це запитання?". нічого більше.

Продавець зміїної олії, який побачив можливість продати себе в ролі майстрів scrum master, - це негідність землі і повністю йде проти Agile, як ви зазначили.

Scrum Master не оновлює свого статусу, але вони є там, щоб полегшити зустріч. Їх роль полягає в тому, щоб переконатися, що зустріч розпочаться вчасно, кожен учасник зустрічі оновлює свій статус у межах свого часового періоду, вживайте заходів, коли будь-який учасник команди має блокпости у виконанні своїх завдань.

FYI, ми використовуємо нашу щоденну зустріч в режимі реального часу за адресою http://www.standup.report, яка також дозволяє нашій офшорній команді брати участь та полегшувати процес зустрічей, додаючи / змінюючи подані завдання членами команди в Інтернеті.