Чи потрібен Scrum Master у висококваліфікованій команді?

Моє розуміння обов'язків майстра scrum наступне:

• Закріплюйте процес
• Видалити перешкоди (що розробники не можуть усунути самі)
• Запобігайте перебоям ззовні
• Сприяйте зустрічам у стилі scrum (стояння, ретроспектива тощо)

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

Коли команда стає високоефективною, і організація розуміє межі спринту, здається, що потреби в майстрі scrum зменшуються. Чи можливо команді врешті-решт дістатись до того, коли вже не потрібен майстер скраму?

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

Однак якщо вам справді потрібна перевірка того, що ви все робите правильно - дивіться цю маленьку статтю одного з батьків-засновників руху Agile.

Одним із членів методології родини Crystal є Crystal Clear. Crystal Clear може бути описаний слухачем рівня 3 такими словами:

“Помістіть 4-6 людей у ​​кімнату з робочими станціями та дошками та доступом до користувачів. Дозвольте їм доставляти користувачеві перевірене програмне забезпечення користувачам кожні один-два місяці, а інакше залишайте їх у спокої »

Насправді я описав Crystal Clear цими словами до кмітливого спонсора проекту. Він дотримувався цих інструкцій і через п’ять місяців повідомив: "Ми зробили те, що ви сказали, і все спрацювало!"

Я взяв інтерв'ю у лідера команди через кілька місяців, і його звіт був приблизно таким же коротким, як і мої вказівки:

«Після вашої пропозиції, ми четверо взяли цей конференц-зал, який має мережеві зв’язки. Ми тримали його всі чотири місяці, малюючи на дошках там, доставляючи програмне забезпечення, коли ми їхали. Це спрацювало чудово ».

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

Ні! Майстер Scrum НЕ потрібен команді високої продуктивності.

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

Але, будь ласка, не плутайте це з відповіддю на питання "Чи потрібен майстер скраму для команди Scrum?"

Відповідь на це - абсолютно так. Будь-яка команда, яка не має майстра scrum, не займається скрутом незалежно від того, що вони думають. Це те, що Кен Шабер називає "Scrum but", і походить від фрази "Ми робимо Scrum, але ..."

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

Існує також найважливіша робота адміністратора, пов’язана з елементами scrum, керування відставанням приходить на думку - залежно від інструменту, який ви використовуєте, майстер scrum, ймовірно, візьме на себе відповідальність за це.

Не намагаюся бути цинічним, але я ніколи не бачив, щоб процес був так тонко налаштований, що ніколи не буває детриту, який хтось повинен прибирати :-)

Зрештою, навіть якщо насправді нічого робити, процес переконання, що нічого робити, несе відповідальність за когось. Чи це для підзвітності, чи ні, це внутрішнє рішення.

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

Ніщо не залишається таким же. Можливо, вам вдасться пройти через певний проект, але навіщо змушувати команду виконувати ці обов'язки? Управління компанією може спричинити слабку економіку і почати пред'являти додаткові вимоги. Нові найми можуть стати зривом.

Я просто не бачу перевертання, щоб не мати такого.

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