Чотири колеса Scrum

Чимало скрам-команд стоять на місці, не підозрюючи, що “їдуть” на одному з чотирьох коліс, у той час як просування вперед вимагає синергічну дію усіх чотирьох. Що то за “колеса”? Що робити, коли одне вийшло з ладу? Хто і як має ремонтувати “автомобіль” під назвою Scrum?

Чотири колеса Scrum

Існують чотири невід’ємні складники скрам-підходу, які умовно назвемо “колесами”. Усунути бодай одне означає знівелювати Scrum. Ось вони:

1. Теорія
2. Практика
3. Правила
4. Цінності

Розгляньмо кожне “колесо” і з’ясуймо, що робити, коли воно не крутиться.

Колесо теорії

Взагалі Scrum передбачає зміну підходу до розробки продукту. Адже впровадження цифрових технологій у бізнес, створення нових технологічних рішень для компаній як в ІТ, так і в інших галузях, свідчить про складну інтелектуальну діяльність, яку професійним жаргоном називають “комплексним доменом”.

Комплексний (від англ. complex — складний, багатогранний) домен передбачає високий рівень невизначеності під час розробки цифрового продукту.

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

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

Це також означає, що компанії, які цього не розуміють — з одного боку, хочуть запровадити новітній скрам-підхід, а з іншого — крутити стару шарманку (або катеринку — від французької назви першої пісні “Шармонт Катрін” — чарівна Катрін [Charmante Catherine], що виконувалися на катеринці — шарманці). Щоправда, замість прекрасної Катрін, їхня пісня називається “Командно-адміністративний стиль”.

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

Нескладно передбачити: в найближчому майбутньому ІТ-компанії, що досі грають на катеринці, поступляться гнучким (agile) командам і підуть геть із ринку (або залишать складний домен, перекваліфікувавшись на щось простіше — продаж помідорів, збут електротоварів, виробництво цегли абощо).

Два протилежні підходи

Отже, існує старий підхід із командно-адміністративним стилем керування — “за протоколом”, “згідно з інструкціями”, “за погодженням”, “відповідно до плану”, який у складному домені або не працює взагалі, або працює жахливо, або не витримує конкуренції з боку гнучких команд. Цей підхід також називають предиктивним (від англ. predictable — прогнозований), а в сукупності з вертикальною моделлю керування та контролем можемо назвати його директивно-предиктивним.

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

З якоїсь причини прихильники директовно-предиктивного підходу схильні приписувати емпіричному скрам-підходу хаос.

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

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

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

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

Завдання лідера в такому разі — забезпечити їх усіма необхідними інструментами для успішної реалізації завдань. “Мій успіх залежить від успіху всієї команди” — ось гасло лідера в парадигмі Scrum (на противагу старому підходу “Без генія моєї персони команда не зможе реалізувати проект”).

Таким чином, емпіричний підхід має чітко окреслені межі й сформульовані правила, проте він водночас гнучкий. Це означає, що:

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

Як бачимо, емпіричний підхід у Скрамі має теоретичне підґрунтя, що витікає з наукового методу, ітераційно-інкрементального підходу й концепції самоорганізованих команд (учасники самі вирішують, що, коли і як робити — див. докладніше у статті “П’ять рівнів самоорганізованих команд“, а також “Самоорганізовані та кросфункціональні команди у Scrum: початок дискурсу”).

Проблема колеса теорії

Найбільша проблема у цьому контексті — небажання лідерів організацій змінювати звичні підходи до керування. Назвемо це “колесом теорії”. Що це означає?

• Запроваджуючи скрам, керівники не збираються нічого змінювати у своїй практиці керування проектами (у Scrum розробку інтелектуального продукту проблематично називати “проектом”, адже класичний проект зазвичай прописаний від “А” до “Я” і не передбачає змін та адаптацій, у той час як Scrum наголошує на постійній адаптації продукту з урахуванням свіжих емпіричних даних, отриманих у кожній ітерації).
• Багато керівників навіть не здогадуються про необхідність змінювати власну практику керування й підходи до розробки.
• Чимало керівників не до кінця розуміють переваги й недоліки підходів, за якими звикли працювати.

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

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

Як у такому разі витягти палицю з колеса теорії?

Якщо для читачів роль скрам-майстра викликає більше запитань, ніж відповідей, то ось і перша відповідь. Усунення перешкод у роботі скрам-команди — це прерогатива скрам-майстра. “Палиці” в колесі теорії — приклад таких перешкод. (Докладніше про ролі в скрам-підході див. у статті “Рольова модель Scrum”).

Колесо практики скраму

Одна з помилок новачків — це нерозуміння різниці між елементами скрам-підходу та його практиками.

Практика скраму — явище не статичне, а змінне. Ретроспектива, наприклад, — обов’язковий елемент Scrum, але способів їх проводити безліч. Останній, що я використовував, — “Піца-ретроспектива”. Завдяки творчому підходу й розмаїттю способів використання елементів Скраму, учасникам значно цікавіше працювати й зберігати увагу на меті.

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

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

Іншою “палицею” може бути нав’язування улюблених практик однієї персони. Наприклад, метод оцінювання завдань (скажімо, story points). Фахівець відвідав тренінг або прочитав книгу про методи оцінювання в Agile, після чого нав’язує його іншим учасникам команди як єдиний правильний. Те саме може стосуватися колег, які звикли оцінювати завдання в людиногодинах або людиноднях.

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

Стовпи, постулати, принципи, цінності Scrum — поняття фундаментальні, у той час як практики (способи реалізації, механізми, методи) — гнучкі.

Див. наприклад, приклади візуалізації різних способів організації ретроспективи в Scrum:

Колесо правил

У скрамі вони якраз чітко прописані. Порушення цих правил завжди має негативні наслідки.

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

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

Неповага до цього правила може проявлятися у:

• втручанні у роботу команди з боку керівництва компанії;
• позбавленні стратегічних функцій (права на розробку стратегії, установлення пріоритетів тощо);
• скасуванні, відміна або заміна рішень власника продукту.

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

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

Колесо цінностей скраму

Іноді автомобіль не їде, бо повністю здулося четверте колесо — цінностей.

Нагадаю про п’ять цінностей Scrum:

1. Повага.
2. Відданість справі й дотримання слова (commitment).
3. Концентрація уваги на продукті та його розробці (focus).
4. Відкритість (openness).
5. Відвага (courage — сміливість озвучувати правду).

Ідеться про певну поведінкову модель усіх учасників розробки за скрам-підходом.

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

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

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

Цінності прямо стосуються системи мотивації. Наприклад, метод батога й пряника у Scrum не працює.

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

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

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

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

Що робити

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

1. Дотримуватися системи ролей у Scrum. Це означає, що в команді обов’язково має бути професійний скрам-майстер або принаймні фахівець, який виконує цю роль (у такому разі варто підвищити його компетентність на професійному тренінгу з відповідною сертифікацією).
2. Розвивати скрам-команду. Сама собою команда розробників не стане професійною скрам-командою, їй потрібен тренер (скрам-майстер), а також постійне зростання у внутрішній комунікації, формуванні скрам-культури, крос-функціональності, самоорганізації та автономності.
3. Осмислити й добре знати “чотири колеса” Scrum — теорію, практику, правила й цінності, удосконалюючи компетентність кожного учасника команди у кожній із цих сфер.
4. Усвідомити різницю між “Прекрасною Катрін” та емпіричним підходом.
5. З’ясувати сутність гнучкого підходу та його переваги в епоху стрімкого розвитку цифрових технологій.

ДОЛУЧИТИСЯ ДО AGILE.LIVE

• Найближчі сертифікаційні тренінги Agile.Live: Professional Scrum Master (PSM), Advanced Scrum Master with PSM II Certification, Professional Agile Leadership Essentials (PAL-E)
• Підписатися на сторінку у LinkedIn
• Підписатися на Telegram-канал Agile.Live
• Підписатися на You-канал Agile.Live