Скептик в команді Scrum

Моя компанія нещодавно перейшла на спритний спосіб роботи, і в рамках неї ми почали використовувати SCRUM. Хоча мені це дуже комфортно і я вважаю, що цей спосіб перевершує традиційний, деякі мої товариші по команді не поділяють такої ж думки. Насправді вони дуже скептично ставляться до "всіх спритних речей", і не сприймають це серйозно. Наприклад, один із товаришів по команді завжди спізнюється на зустрічі, і це не дуже хвилює це. Керівництво ІМО намагається цього не помічати (можливо, тому, що це нове, і люди потребують часу, щоб звикнути до цього).

Моє запитання: як вирішити це питання, не викликаючи конфлікту всередині команди?

Зіткнувшись із надзвичайним скептицизмом, я спробую кілька речей:

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

2.) Я не підміняюсь негайно заміною на повністю роздуту SCRUM (або іншу) методологію. Завжди найкраще вводити невеликі аспекти Agile одночасно.

3.) Я згоден зі скептиками (до певної точки). Agile - це не срібна куля, а SCRUM, Kanban, Lean тощо - теж не срібна куля. Натомість я працюю з ними, щоб побачити, які аспекти могли б їм негайно принести користь (сервер CI зазвичай не є мозком), і тоді я пробую решту "Дозвольте на тиждень пройти тиждень, а потім переглянути його".

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

Тож переходимо безпосередньо до вашого питання. Підняти його разом з командою:

"Я також трохи скептично ставлюсь до процесу протистояння, але я вважаю, що як команда, ми повинні дати йому належну поїздку протягом 1 тижня (без виправдань!), А потім переглянути його, щоб перевірити, чи працює він на нас. Що люди думаєте? "

Типовий випадок неправильно реалізованого Scrum .

Scrum був накладений на команду. Команда не була (ціла).

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

Опір змінам - ваш ворог тут.

Я настійно пропоную вам почати спочатку і представити Scrum команді та дозволити їм задавати питання.

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

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

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

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

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

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

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

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

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

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

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

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

Команди Scrum повинні бути самоорганізуються. Scrum також працює, впроваджуючи надзвичайну прозорість у всьому.

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

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

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

Уникнення "конфлікту в команді" навіть не повинно бути фактором.

Звільніть товариша по команді, тоді він не буде викликати суперечок всередині команди.

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

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

Хто прийняв рішення про перехід і чому? Де ці скептики взагалі приймали рішення чи рішення було просто упущене на них?

Ви занадто жорсткі та / або швидкі у впровадженні своїх нових методів? Ви викладали хороші (не обов’язково ідеальні) продукти, використовуючи свої старі методи? Чи продемонстрували ви скептикам, як це їм принесе користь? Ви можете це продемонструвати? Чи показали ті, хто «побачив світло» скептикам, як це приносить користь їм, колективу та компанії?

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

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

Звичайно, що тоді робити, якщо переможуть скептики?

Проведіть зустріч команди, щоб обговорити і з’ясувати, чому ваша компанія перейшла на SCRUM і змусити всіх визначити, що вони думають про SCRUM, додасть значення поточному режиму роботи. Іноді компанії роблять перемикачі з головою (я бував на зборах у scrum, де ніхто насправді не слухає, і всі просто відштовхуються від того, що робили вчора, і залишають. Ці команди зазвичай досягають рівноваги на кшталт - "Я не допитую вас, і ви не заплутаєтесь" зі мною "і валяйся там. Це просто марна трата часу), Тож візьми те, що найкраще для тебе.

Зазвичай ветерани чинять опір чимось, що може змінити їхній сучасний стиль роботи, тож ви повинні переконатися, що для них достатньо моркви, щоб вийти з інерції. У такому випадку я б або мав 1: 1 з цією людиною, або змусив би його стати майстром по scrum :). Після того, як ви покладете на них відповідальність, вони знайдуть мир з цим або повністю усунуть його, оскільки це не додає цінності. Обидва - виграш.