Мій перший фейл у запровадженні аджайл-культури

Ми продовжуємо серію бесід про самоорганізовані та крос-функціональні команди із В’ячеславом Москаленко, першим сертифікованим тренером Scrum в Україні, співзасновником Agile.Live. (Про початок дискурсу можете прочитати у попередній статті “Самоорганізовані та кросфункціональні команди у Scrum”, де В’ячеслав розповів про специфіку скрам-команд і головні труднощі, що виникають при спробі запровадити аджайл). Цього разу В’ячеслав поділиться цінним досвідом.

[В’ячеслав Москаленко]: “Думав — ось воно, щастя. Ба ні, знову досвід”. Хочу розповісти про невдачу, яка спіткала мене на початку кар’єри в Scrum. Чому це важливо:

1. Існує певна ідеалізація експертів. Замість мотивувати, це часто демотивовує. Людина міркує “Я ніколи не досягну такого рівня” й опускає руки, замість того, щоб з ентузіазмом втілювати зміни, рухаючись у напрямку “Так, тому” (про різні способи казати “Так” див. нашу статтю “Таки-так: Дихотомія Ґюнтера”).
2. Компаніям необхідно чути не тільки “правильні відповіді”, а й учитися на помилках. Краще, коли це помилки інших.
3. Історія про фейл — насправді цінний інсайт, що допомагає краще зрозуміти аджайл-культуру й перенести ідеї з книжок і тренінгів у реальні життєві ситуації.

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

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

Ми діяли за “старою” моделлю (беру в лапки, бо маю на увазі класичну модель керування проектами, що актуальна досі для багатьох сфер професійної діяльності, наприклад, будівництва), відому як каскадна або водоспадна (waterfall) — докладно розробляємо проект відповідно до специфікацій, розбиваємо на етапи, в кінці маємо результат, який відповідає “технічному завданню” та вимогам замовника.

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

Таке формулювання старого доброго менеджменту, вочевидь, не академічне, проте дохідливе.

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

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

Коли хтось не міг виконати завдання, робив це неякісно або не вкладався у відведений час, я сварив того “хтося”. Або соромив. Парадоксально, але від практики соромити й сварити я отримував брутальне задоволення!

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

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

Скрам був чимось новим для більшості компаній. Бракувало досвідчених фахівців і знань на цю тему; ми не були винятком.

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

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

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

адто багато публічних фігур заявляло про те, що робитимуть щось “по-новому”. До того ж, в народі кажуть, не все нове — чудесне, і не все чудесне — нове. Тож учасники команди за звичкою чекали на нові розпорядження від мене як технічного лідера.

Ми запустили практику щоденних п’ятнадцятихвилинок (Daily Scrum), під час якої я продовжував бути “босом”, а учасники розробки — безініціативним та пасивним “колективом” підлеглих.

Я ставив питання, дотримуючись вимог фреймворку, проте відповіді були формальними. Всі й так знали: все буде так, як вирішить Слава Москаленко.

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

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

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

Таким чином, ззовні, формально ми впроваджували скрам, проте всередині команди все залишилося старим. Ми проводили зустрічі для “статусності” й “прозорості” (щоб усі бачили, хто чим займається). Де-юре існувала новостворена скрам-команда, де-факто — пасивний колектив на чолі з керівником проекту і технічним лідером.
Абсурдність ситуації досягла свого апогею, коли я раптом помітив, що сам вказую “підлеглим” на те, що їм говорити на “дейлі скрамі”, а що — ні!

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

Спочатку я впирався, знаходив море причин зберігати статус кво (“Ми не можемо бути самоорганізованими, оскільки….”, “Ми хочемо змін, але команда ще незріла” тощо), та врешті-решт я сказав: “Так!” без всяких “але” (див. “Таки-так: Дихотомія Ґюнтера”).

Що мені довелося змінити в собі

Найважче мені далися такі зміни:

1. Прийняти факт необхідності ділитися владою.
2. Відпустити віжки контролю.
3. Створити сприятливі умови для команди, щоб вона могла самостійно розв’язувати проблеми.
4. Не втручатися, коли виникають перепони, довіряти команді.
5. Сформувати новий набір навичок для формування самоорганізованої та самокерованої команди, що пов’язані зі сферою емоційного інтелекту, емпатією, умінню адаптуватися до нових обставин.

Підсумки

Ми розглянули приклад невдалого початку запровадження скрам й дійшли таких висновків:

1. Запроваджувати скрам у парадигмі “керівник — підлеглі” — груба помилка.
2. Перед запровадженням Scrum варто чітко розуміти різницю між каскадною моделлю (waterfall) та ітеративно-інкрементальним підходом у Scrum.
3. Не потрібно утримувати командира (ініціатора, царя, боса, шефа, “лідера”, “начальника”), який не бажає ділитися владою і зменшувати вагу власної персони у розробці продукту. Такі фігури блокуватимуть ініціативу команди й створюватимуть залежність від особи, замість взаємозалежності між членам кросфункціональної команди.
4. Лідеру команди не обов’язково втручатися, коли виникає проблема чи перепона. Краще дозволити команді самостійно знайти рішення.
5. Усі помиляються. Це нормально.
6. Не потрібно вірити в “ідеальну команду”. Ідеальні скрам-команди зазвичай існують у книжках. Надмірна ідеалізація часто демотивовує, замість того, щоб мотивувати.
7. Ми хочемо Scrum чи його ілюзію?
8. Початківцям важливо мати наставника, щоб пришвидшити перехід на скрам.
9. Завдання лідера в парадигмі 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