Домінуючі члени команди команди Scrum

Що б ви зробили в ситуації, коли член команди намагається взяти на себе відповідальність, спочатку не покладено на нього, а на Майстра Scrum?

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

Що ви можете зробити:

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

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

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

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

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

Все це важко, але для цього потрібні менеджери та Scrum Masters.

Є ще один можливий спосіб зробити це. Зробіть це командною проблемою. Подзвоніть їм разом і скажіть, що вони недосяжні, і ось чому. Попросіть їх придумати рішення. Ви можете бути здивовані.

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

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

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

Схоже, він намагається бути майстром Scrum.

Уточнити свої позиції та діяти відповідно.

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

Коротка примітка: Ваш домінуючий розробник не є більш проблематичним, ніж ваш пасивний розробник.

в даний час планування спринту - це роль, яка обертається по всій команді

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

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

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

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

Плануйте цілий ретроспективний сеанс навколо цього. Запропонуйте їм взяти на себе певні цінності та продовжити наступну ретроспективу. Не вказуйте пальцями, використовуйте нейтральні методи.

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

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

Можливо, «домінуючий» дев був винагороджений своєю індивідуальною працею, а не командними досягненнями?

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

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

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

Запропонуйте йому стати майстром Scrum для наступного спринту.

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

Команди з ротаційною роллю головного scrum - це не рідкість.

Єдине завдання майстра Scrum - переконатися, що всі грають за правилами книги Scrum. Якщо майстри, які не працюють на scrum, зробили б це самостійно без втручання майстра Scrum, це просто показало б, що ви в чудовій (Scrum-) формі! Чим менше майстер Scrum повинен робити, тим злісніше і більш схильна ваша команда з точки зору Scrum. Врешті-решт роль майстра Scrum могла / повинна бути усунена, він є для того, щоб почати та навчити вас Scrum.

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

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

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

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