7 прикладів, як менеджери в IT шкодять ефективній роботі команд

Письменник, редактор та засновник сервісу Serious Scrum Віллем-Ян Ейлінг розібрав кілька ситуацій, коли менеджери та керівники IT-компаній шкодять роботі команд, у блозі Medium.

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

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

Ейлінг зазначив, що Scrum-команди, як правило, чудово справляються із самоврядуванням. Але вони багато в чому обмежені організацією. Ось кілька прикладів.

1. Інформування команд про те, яку роботу вони мають виконувати і до якого терміну

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

Ось чому рішення про те, що робити, як це зробити і в які терміни має належати Scrum-команді. А власник продукту (як джерело роботи для команди) — це єдина людина, яка має визначати порядок беклогу продукту. Але це не заважає менеджерам, що не входять до Scrum-команди, обходити власника продукту і просити команду замість поставленого завдання робити щось інше. Це не має жодного сенсу, проте часто трапляється. На думку Ейлінга, таке керування ігнорує саму концепцію Scrum.

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

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

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

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

Члени Scrum-команди співпрацюють задля досягнення спільних цілей. Командна робота є ключовим чинником. Ціль продукту, мета спринту та показники якості продукту є зобов’язаннями команди. Було б логічно судити всіх членів команди, спираючись на те, як вони спільно виконують ці зобов’язання.

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

4. Похвала командам, які не встигають виконувати роботу

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

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

5. Очікування, що команди працюватимуть над кількома напрямками одночасно

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

6. Проміжний результат як показник успіху

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

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

7. Ігнорування організаційних перешкод

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

 

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

 

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

Порада: доопрацьовуйте ідеї менеджерів та лідерів компаній

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

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