У цій та наступних статтях ми публікуємо серію бесід із В’ячеславом Москаленком у відповідь на одну з найболючіших проблем у впровадженні аджайл-культури — самоорганізовані й кросфункціональні команди.
Актуальність питання
Фахівці, команди і компанії, чия діяльність пов’язана із розробкою продукту, часто скаржаться на проблеми з командами, що виникають у процесі запровадження Scrum або повсякденній роботі. У книжках одне, а на практиці інше.
Я мав честь запроваджувати Scrum у великих компаніях у США, Сінґапурі, Великій Британії та інших країнах, завдяки чому здобув цінний досвід і успіхів, і поразок, яким хочу поділитися з однодумцями на сторінках Agile.Live.
Річ у тім, що всі потуги запровадити Scrum відповідно до постулатів Agile може перекреслити одна підступна “дрібниця” — застаріла практика командної роботи.
З іншого боку, для формування нової аджайл-культури в командах знадобиться поетапна стратегія, про яку також розповім у наступних статтях.
Саме з командами тісно пов’язана сутність Scrum. Адже завдання скрам-майстра полягає в тому, щоб створити середовище, в якому під час кожного спринту команда зможе створити інкремент із узгодженого (не з “начальством”, а між учасниками процесу розробки) завдань, а також перевірити результати й внести відповідні корективи у наступний спринт.
Терміни
Тож для початку з’ясуймо значення термінів.
В Україні побутують такі поняття, як “самоорганізовані команди”, а також “самокеровані команди”. У західній діловій культурі також використовують обидва терміни, self managing та self organizing (teams). Деякі навіть сперечаються про те, який із них правильний. Не будемо гаяти на це час. Я говоритиму про команди, як їх визначає Scrum.
У посібнику “Скрам” використовують поняття self-managing teams, self-management та cross-functional, cross-functionality. У них і закладено сутність скрам-команди у Scrum-підході. (Подробиці див. у оригіналі посібника англійською “The 2020 Scrum Guide” на офіційному сайті Scrum.org).
Говорячи про самоорганізовані чи самокеровані команди, я маю на увазі невеликі команди з 6-10 осіб, які не організував “хтось”; вони самі себе організували.
При цьому, самоорганізація скрам-команд не абстрактно-філософська чи популістсько-піарна (“Ми — єдина команда!”, “Ми однодумці!”, “Разом ми сила!” тощо), а передбачає відповідальність за чітко окреслений спектр питань, які вирішуватиме у процесі розробки.
Ідеться про питання, що лежать у трьох площинах:
- Що.
- Коли.
- Як.
ТРИ ПЛОЩИНИ САМОКЕРОВАНИХ СКРАМ-КОМАНД
Навряд чи існує щось простіше з точки зору теорії. Та навряд чи існує щось складніше, аніж “Що, коли і як” з точки зору практики — професійного функціонування команд у парадигмі Scrum.
Труднощі у запровадженні підходу Scrum
Незалежно від географічного розташування (США, Східна Європа, Австралія, країни Близького чи Далекого Сходу), рівня економіки країни чи галузі (ІТ, банківська сфера, виробництво товарів чи надання послуг), — більшості команд не вдається одразу відповідати “букві й духу” Scrum.
Чому? Що заважає швидко запровадити зміни й функціонувати професійно як скрам-команда?
Навіть за умови проходження тренінгу, попереднього досвіду розробки продукту й належної теоретичної підготовки тім-ліда чи скрам-майстра, залишається вразлива зона — людський фактор.
Уявімо на хвилинку фахівця, який має повноваження агента змін. Йому потрібно відмовитися від ряду повноважень, делегувати їх команді, а далі “не сунути носа до чужого проса”.
Що коли команда припускається помилки? Що коли обрала хибний шлях? Що коли він має власне бачення на розв’язання проблеми?
Ось тут і виникає спокуса припуститися найпершої помилки — продовжувати контролювати процеси (що, коли, як), вважаючи, що без мудрості старшого брата (керівника) група фахівців не зможе виконати завдання.
Керівник, що продовжує функціонувати у старій парадигмі “начальника” (йдеться не обов’язково про особу пенсійного віку; представниками “старої парадигми” можуть бути навіть студенти), якому не подобається рішення команди, власноруч його перекреслює і однак вирішує діяти по-своєму.
Такі лідери створюють ілюзію скраму. Адже всі ролі є, команда є, сертифікат є, фреймворк є. От тільки команда може бути пасивною, чекати на повеління боса чи навпаки — керівник, що нав’язує свою волю команді.
Я сам припустився колись цієї помилки під впливом людського фактору, коли вперше запроваджував скрам у компанії Ciklum. На щастя, у мене був наставник, який допоміг вчасно виявити недоліки, а сам продукт вийшов успішним. Тоді я засвоїв один із найважливіших принципів, про який докладніше розповім у статті “Мій перший фейл у запровадженні аджайл-культури”. Окрім фейлу, я також розповім успішні кейси та правильний підхід — стратегію поетапного формування та розвитку успішної скрам-команди.
Особливості скрам-команд
Отже, командний підхід до розробки лежить в самій основі Scrum. Він виключає складні ієрархічні системи чи багаторівневість з точки зору класичного організаційного менеджменту. Це, скоріше, група фахівців, що фокусує увагу не на “виконанні вимог на структурному рівні організації”, а на досягненні мети — створенні продукту, цінного для замовника й користувачів.
До кожної скрам-команди входять:
- Скрам-майстер.
- Власник продукту.
- Розробники.
Скрам-команди і самокеровані (самі вирішують, що, коли та як саме робити), і водночас багатофункціональні (кросфункціональні) — володіють усім набором навичок, необхідних для успішної розробки продукту, а тому можуть самостійно вирішувати, хто чим і як буде займатися.
До того ж, учасники багатофункціональної команди здатні замінювати одне одного, допомагати, взагалі піклуватися одне про одного (емпатія як одна з принципових рис команди звучить як щось із розряду фантастики, особливо для вихідців із колишніх країн СРСР).
Кількісно це невеликі команди (6-10 осіб). Цей ліміт є результатом емпіричних спостережень. Адже саме невеличкі групи професіоналів здатні ефективніше використовувати час, швидше доходити згоди, досягати високої продуктивності. “Роздування” команди є небажаним для Scrum. Імовірно, великі групи буде розформовано на кілька невеличких команд, зосереджених на відповідному продукті.
Хочу також наголосити, що самоорганізованість та кросфункціональність передбачає відповідальність кожного учасника команди, що суттєво впливає на продуктивність розробки та якість продукту.
“Самоорганізованість та кросфункціональність передбачає відповідальність кожного учасника команди, що суттєво впливає на продуктивність розробки та якість продукту”.
В’ячеслав Москаленко — перший сертифікований тренер Scrum в Україні, співзасновник Agile.Live
Принципова відмінність Scrum-команди від інших підходів полягає не стільки у створенні цінності для кінцевого продукту (цим займається класичний проджект-менеджмент), скільки у створенні цінності на кожному проміжковому етапі його розробки (спринту), що допомагає досягти значно вищого рівня цінності продукту у його кінцевому вигляді, на противагу від старих підходів, коли замовник може бачити результат тільки в кінці проекту, не маючи можливості вносити корективи на проміжкових етапах розробки.
ДОЛУЧИТИСЯ ДО AGILE.LIVE
Найближчі сертифікаційні тренінги Agile.Live: Professional Scrum Master (PSM), Professional Agile Leadership Essentials (PAL-E), Professional Scrum Product Owner (PSPO)
Підписатися на сторінку у LinkedIn
Підписатися на Telegram-канал Agile.Live
Підписатися на You-канал Agile.Live