Як ми впровадили Scrum: граблі і точки зростання

Привіт! Мене звати Олександр, я Scrum-майстер в Trionika. Хочу поділитися своїми особистими спостереженнями про те, як змінилася ефективність роботи розробників і продуктолога під час і після впровадження Scrum компанії. Відразу уточню: компанія спеціалізується на видобутку та монетизації трафіку. Крім цього, розробляє свою платформу зразок Upwork для роботи з клієнтами та підрядниками по всьому світу.

За 9 років на ринку ця команда напрацювала величезну базу коду, тому за доопрацюванням дрібних фіч стало складно бачити прогрес в роботі (думаю, багато хто зрозуміє, про що я). Починало все більше здаватися, що нинішній потужний IT-відділ компанії перетворюється в неповороткого монстра, який намагається встигнути скрізь, а фактично топчеться на місці. В якості рішення для зрушення з мертвої точки народилася ідея спробувати Scrum: зібрати пілотну Scrum-команду з 8 чоловік в IT-відділі, яка з виділеним Product Owner повністю відповідала б єдиним планом.

На цьому етапі я і приєднався до команди. Що з цього вийшло, читайте далі.

Наша Scrum-команада

Перші кроки

Коли я прийшов в компанію, вже були зроблені перші кроки: було сформовано Scrum-команда і проведено кілька спринтів. Перед тим як я остаточно вступив на посаду, мені пощастило бути присутнім на кількох зустрічах в якості консультанта. Роль PO виконував один з ключових замовників, який попередньо пройшов сертифікаційний тренінг на Scrum Product Owner, а роль Scrum-майстра — CTO, познайомився з методологією по книзі «Революційний метод управління проектами» Джеффа Сазерленда.

Команду розробки вибирав CTO, не залучаючи самих людей у прийняття рішень. Їм було дано короткий екскурс в Scrum у вигляді 20-сторінкової методички. У незвичних для себе ролях і вже з великим досвідом роботи на керівних посадах PO і Scrum Master користувалися напрацьованими за роки і зарекомендували себе стратегіями: намагалися вирішувати за всіх. Команда розробки також слідувала напрацьованої стратегії: в основному відповідати, коли запитують, і по більшій частині ствердно кивати.

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

Як пройшла перша зустріч з планування спринту

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

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

Як ставилося питання про згоду? По суті, у команди розробки не було ясної картини того, на що вона підписується. Був озвучений обсяг завдань. І питання звучало так: «чи Згодні?» По-перше, така постановка питання передбачає відповідь «Так», оскільки складно йти всупереч думці керівника. По-друге, було неясно, що саме належить зробити. Просто цифри з оцінками ні про що не говорять, важливо саме побачити самі завдання, представити їх виконання і реалістичність задуму. Ми ще неодноразово поверталися до способу оцінки. А почали з візуалізації взятих завдань. Малювали на дошці завдання з оцінками, і вже потім команда говорила, реалістично це.
Додані 10% завдань були позамежними. Як з'ясувалося пізніше, на минулому спринті команда намагалася показати найкраще, на що була здатна (оскільки її тільки сформували), і працювала на межі можливостей. Це годиться для одного ривка, але не для постійної роботи. У результаті навіть минулий спринт команда закрила з працею, а бачачи, що в новому завдань ще більше, команда була демотивована і не впоралася. Трохи пізніше ми прийшли до більш розумного підрахунку закладаються в спринт завдань — до середнього арифметичного від останніх чотирьох спринтів. Це згладило різкі скачки в обсязі завдань.
Оцінка завдань прив'язувалася до днів розробки. Від кількості днів у спринті віднімалися годинник на зустрічі, і на дні, що залишилися набиралися завдання. Такий спосіб ускладнював визначення місткості спринту, а також позбавляв маневру у заповненні спринту завданнями. І правда, на якій підставі при 10-денному спринті можна брати менше завдань, ніж оцінених на 9 днів (один залишався на зустрічі)? Будь-яка оцінка дає лише припущення про завершення, але не фактичне час. Надалі ми ввели в ужиток Story Points. Умовно один SP так і залишився дорівнює одному дню, але саме при формуванні спринту ми почали брати задачі, виходячи з минулого velocity команди, не прив'язуючись до днів. У перших спринтах «лихоманило» від 20 до 45 SP на команду з 5 чоловік на двотижневий спринт, зараз же більш рівно — приблизно 35 SP на спринт, і показник потроху зростає.

За підсумками першої ретроспективи ми виробили звід правил, за якими побудували подальше спілкування. Проблема була в тому, що при переході на Scrum ми виділили один загальний чат, який почала валитися вся поспіль інформація. Згідно очікуванням, у команди розробки відразу повинна була з'явитися колективна відповідальність та самоорганізація щодо прийнятих рішень. У цьому потоці було неможливо зрозуміти ні той, хто здійснює дію, наскільки це важливо. У результаті повідомлення пропускалися: Product Owner не розумів, як може впливати на команду, а команда не розуміла, що їй робити з повідомленнями.

Нові правила

Оскільки повністю ізолювати процес розробки від процесу підтримки систем не вдалося (завжди були оперативні завдання, що вимагають швидкого рішення), в зводі правил ми виділили такі моменти:

Як відрізняти важливі повідомлення від прохідних? @mention людини вирішувало половину проблем, а загальне згоду на читання нетаргетированных повідомлень з низьким пріоритетом — другу.
Як зорієнтувати повідомлення конкретним людям або команди в цілому?
Як реагувати на повідомлення? Ми збудували своєрідну «естафету», за підсумками якої відправник міг розраховувати на відповідь, не смикаючи по черзі всіх учасників команди в надії отримати його. Перший відреагував (іноді сам відправник) допомагав вирішити проблему або знайти того, хто може це зробити.
Як реагувати на зміни у завданнях? Це той необхідний мінімум, який треба зафіксувати у задачах/відписати за підсумками прийнятих рішень.
Як реагувати на запити, написані наприкінці робочого дня після його закінчення? Як показала практика, майже всі ці запити не вимагають миттєвої реакції і було досить просто написати, що «прийнято до уваги, на наступний день перевіримо».

У результаті знизився рівень стресу і стало зрозуміло, що і в яких випадках робити.

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

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

Рівні розвитку

Одна з найбільш цікавих завдань — це оцінка рівня розвитку команди. Хтось з учасників команди більш зрілий і готовий бути лідером. Інший же готовий виконувати тільки свої завдання і зараз освоює цінність вміння ділитися результатами роботи з іншими членами команди. Для Scrum-майстра, як і для будь-якого тренера/коуча, життєво необхідно виявити цей рівень, діяти у відповідності з ним і мотивувати всіх учасників рухатися до високої мети. Ну і звичайно ж, постійно рости самому. Це природний хід речей в житті людини, команди і компанії. Все послідовно проходять етапи, якщо не відбувається застрягання на якомусь із рівнів.

Базовий рівень

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

Для команди актуально те ж саме, але в більшому масштабі:

Можуть виникати конфлікти між PO і командою, керівником і командою.
Важливі чіткі усталені правила.
Зміни приймаються нелегко.

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

У таких ситуаціях поради до дії і навчання прості:

Терпляче і наполегливо нагадувати, промовляти, повторювати правила і прийняті рішення.
Виробляти зрозумілі способи комунікації, щоб важлива інформація не губилася, фіксувати прийняті рішення та підсумки зустрічей. Ми почали з того, що я збирав усі прийняті рішення і робив загальну розсилку, потім частина перенесли у внутрішню Wiki і з часом плануємо перебратися в Confluence.
Фокусуватися на навчанні комунікації. Зі своїми прямими обов'язками люди, зазвичай, справляються добре, проблеми в них легше всього виявити і усунути. Що стосується soft skills (в перспективі — найбільш затребуваного навички навіть у технічних фахівців), з цим часто виникають труднощі.
Вчитися чути інших учасників команди, розуміти, що вони роблять, чим живуть, які їхні потреби.
Думати не тільки про те, як вирішити своє завдання, але і те, як узгодити її із завданнями інших.
Переконатися, що отриманий результат — це те, що потрібно насправді, а не те, що написано в ТЗ (знову-таки привіт, sprint review!).

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

Як видно з нашого початку, команда перебувала на базовому рівні і успішно подолала його.

Наша Scrum-команада

Просунутий рівень

На просунутому рівні Scrum розкривається у всій красі. Він надає відмінний фреймворк для посилення взаємодії учасників всередині команди, а також взаємодії між командою і навколишнім світом:

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

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

Правила роботи вже непогано освоєні, також напрацьована певна готовність до змін. Однак увагу не поширюється далі власної команди. Наприклад, можуть мати місце тліючі конфлікти між відділами (часто вони майже не проявляються зовні). Щось в дусі «для своєї команди готовий на все, а решта — не моя відповідальність». Або просто незрозуміло, чим займаються інші, а значить, вони викликають неприязнь.

Що важливо зробити на цьому рівні:

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

Однією з перших завдань нашої команди було виробити визначення завершеною завдання. Що ми розуміємо під цим і до якої міри доводимо завдання при здачі? Хоча продумати і намалювати на дошці загальний підхід не склало жодних проблем, все ж на те, щоб реалізувати його і домовитися про деяких деталях, у нас пішло кілька спринтів. Наприклад, ми довго сперечалися, до якої міри треба доводити завдання перед першою демонстрацією замовнику. Я був за те, щоб показувати, коли всі ключове зроблено і практично завершено тестування. Але все ж у підсумку ми вирішили, що краще доробляти завдання до стану, коли ми готові викласти результат, і після цього демонструвати замовникові. Зараз критерії готовності завдання у нас наступні:

По завданню проведено code review (проводиться в кілька етапів на різних стадіях, йому була присвячена ще одна ретроспектива).
Завдання реалізована в коді.
Завдання відповідає ТЗ (або зафіксованим змін).
Завдання перевірена QA.
Баги, знайдені QA, виправлені.
Прописані To Do по завданню зроблені.
Завдання доступна замовнику.
Зроблена відписка в change log.
Завдання продемонстрована і прийнята замовником.

Відзначаємо готовність завдання за критеріями

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

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

Що ми зробили:

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

Зараз ми знаходимося на цьому рівні і придивляємося до наступного.

Зрілий рівень

По-справжньому усталеного рівня досягають небагато людей і команди:

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

Приклад зрілих команд — це самі розробники Scrum Джефф Сазерленд і Кен Швабер. Будучи програмістами, вони реалізували методику для досягнення найкращого результату у взаємодії з власниками продуктів, а потім почали ділитися методикою з світом.

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

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

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

Якщо ситуація має активну фазу (двоє лаються), перевести її в більш спокійне русло, переводячи увагу на загальні інтереси команди і компанії.
Коли ситуація ввійшла у спокійну фазу, виявити справжній запит/проблематику ситуації.
Вичленити необхідні першочергові дії та виконати їх.
Ще раз переглянути ситуацію, враховуючи спільні інтереси команди і компанії. Знайти усі взаємозв'язки і передумови, які призвели до ситуації, врахувати їх уникнути тих самих граблів в майбутньому.
Задати собі питання «Що ще я можу зробити в цій ситуації?» і виконати необхідну дію.

Роби раз, роби два

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

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

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

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

Висновки

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

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

Опубліковано: 10/09/19 @ 10:00
Розділ Різне

SEO Блог