Scrum Щоденна зустріч: пунктуальність над повною присутністю команди?

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

Мені подобаються щоденні зустрічі Scrum, які проходять так.

У моєму останньому проекті щоденні Scrums більше схожі на зустріч з оновленням статусу. Хоча позиція така, що ми тримаємо Scrums і практикуємо належний Agile.

Ми є розподіленою командою в двох різних країнах, і люди, які перебувають в одній країні, не в одному офісі. Як наслідок у нас віртуальні Scrums.

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

Наприклад, востаннє, коли ми телефонували, і особа, яка координувала зустріч, перевіряла, чи всі були, і ми сказали, що один з членів нашої команди ще не був, але він дзвонив. І мені сказали почати ділитися, не чекаючи члена моєї команди.

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

Це нормально для команд, що практикують щоденні вигуки? Це вперше трапляється зі мною.

Я не можу знайти жодної бібліографії безпосередньо про це. Хоча присутність усіх членів команди підкреслюється, але наголошується також, що зустрічі завжди повинні розпочинатися в один і той же час. Але я думаю, що може бути невелика толерантність до затримки.

Я навіть читав у своєму блозі хтось із припущень, що майстер Scrum може застосувати штрафні санкції, якщо хтось приїжджає із запізненням на 5 секунд. Я думав, що Scrums повинні були бути доброзичливими, і таке покарання здається протилежним результатом.

Який рекомендований підхід у такій ситуації?

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

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

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

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

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

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

Так працює Scrum?

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

Якщо ви вирішите проводити щоденні теги, вони повинні тривати не довше 15-20 хвилин, і так, всі повинні бути вчасно або вони не беруть участі. Збільшення тегів - на користь членів команди, а не майстра scrum; штрафні санкції за пропущені щоденні зустрічі повинні поводитися так само, як і будь-які інші запізнення.

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

Люди над процесом . Це один із основних орендарів компанії Agile, якщо процес не працює для вашої команди, обміньте його чи модифікуйте. Нехай команда модифікує це відповідно до своїх потреб.

Подумайте про це так, у чому сенс щоденного вставання?

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

З командою з 4 -8 розробників, вони повинні бути швидкими та спритними - 30 секунд більшу частину часу. Якби я виконував роль майстра скраму, я був би стурбований запізненням початку зустрічей, оскільки це збільшить вартість зустрічей. Так само, мінливі часи зустрічей створюють відволікання для всіх - чи ми збираємось ... Я також був би дуже обізнаний про те, щоб збалансувати це з потребами, щоб команда могла підтримувати один одного, тому може затримати зустріч, якщо потрібно, тому що хтось хто, ймовірно, був перешкоджений, знаходився по телефону / туалету.

Там, де команди розподіляються географічно так, як ви описуєте, я б позначив це як перешкоду команді ВСІМ ретроспективі. Очевидно, що перешкоди для роботи Scrums і спілкування вони не всі сидять разом і вміють вільно та легко спілкуватися.

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