Agile — це спосіб мислення, який допомагає будувати високоефективні команди та з їх допомогою давати максимум цінності бізнесу. Олександр Буратинський, Senior Agile Coach в Innovecs, розповів про те, що таке agile підхід, як він зародився та чому сучасному бізнесу не впоратися без нього.
Що таке agile підхід і для чого він бізнесу?
Без підходів, фреймворків, методологій agile бізнесу у наш час не вижити. Agile — це культура, mindset, який допомагає організаціям бути адаптивними, приймати своєчасні рішення та в принципі залишатися на плаву в сучасному світі. А наш сучасний світ, за моделлю “Cynefin” («Кеневін»), яка визначає складність оточення, визначається як комплексний, заплутаний (complex). Це пов’язане з тим, що наше оточення зараз повне невизначеності, нестабільності, як от, наприклад, ситуація з коронавірусом.
Agile як філософія становить собою постійний цикл навчання, який бере початок з певних івентів на ринку, на що організація реагує, перемелює через м’ясорубку і, якщо існують швидкі цикли зворотного зв’язку, які закладені у scrum методології, то бізнес може адаптуватися дуже швидко. Якщо це не закладено, якщо не проповідується agile, взагалі не зрозумілі цикли зворотного зв’язку та не зрозуміло, що таке адаптивність з точки зору фреймворків, як вони реалізуються у бізнесі, то організація може дуже швидко вигоріти, вилетіти з ринку та перестати зовсім існувати.
Коли настав той переломний для бізнесу момент, коли вони почали формувати філософію agile?
Мова про адаптивність, переналаштування циклів зворотного зв’язку зайшла достатньо давно. Scrum методології виповнилося 25 років минулого року. Поворотним моментом в сьогоденні послужив коронавірус, оскільки компаніям терміново довелося адаптуватися до нових умов, яких вони зовсім не очікували. Тобто чітко про agile заговорили на початку 2020 року, хоча scrum вже був, існував та набирав сили.
Scrum майстера, agile коучі періодично нагадували бізнесу, наголошували про важливість agile. Перший “State of Agile Report” з’явився у 2007 році. Коли бізнес зрозумів, що вже існують протестовані фреймворки, які масштабуються, наприклад SAFe, LeSS, то з більшою охотою почали запрошувати коучів і scrum майстерів до себе в компанії.
До того ж, раніше існувала така помилкова думка, що scrum — тільки для IT компаній. Дуже класно, що минулого року, коли вийшло оновлення scrum гайду, основного документа по scrum, звідти прибрали слова, що це IT фреймворк. Таким чином вони підкреслили, що фреймворк — взагалі для життя, для бізнесу та для розвитку.
Agile це поступовий процес чи він може вирішити кризу без підготовки?
Будь-яке рішення залежить від здатності кожної конкретної людини переадаптуватися. Той же mindset, та ж психіка — тобто наскільки один інженер може адаптуватися. І тут важливо розуміти, що agile коуч самостійно не може нічого вирішувати, бо потрібне рішення від власників бізнесу, що «так, ми адаптуємося».
До них також будуть питання, як вони ведуть свій бізнес, як вони приймають рішення, чи не замикають рішення на собі, не шукають винних. Тобто як себе ведуть власники бізнесу, топ менеджмент. Треба подивитися, які є ролі, які задачі ставляться перед цими ролями, який у них фокус. Тож вирішити проблему бізнесу в один клік неможливо. Більш того, неможливо навіть визначити проблему, потрібно з бізнесом побути якісь час.
Чим займається agile коуч?
Agile коуч, він — активний слухач, тренер, ментор, фасилітатор, консультант, він включається, направляє, ставить «дурні запитання», що дуже важливо. Якщо у компанії є стратегія, він також допомагає її транслювати, якщо немає — створити. Дуже часто хороші коучі приходять до власників і виясняють, яка ціль трансформації, що конкретно під цим мається на увазі. Що конкретно для них значить agile? Просто впровадити якісь цикли, чи змусити розробників розробляти більше, не розуміючи їх конкретної продуктивності. Тобто розробляється певна оптимізаційна ціль.
От на моєму проєкті, щоквартально у нас виробляються OKR (Framework Objective Key Results), певні цілі на квартал. У трансформації також можуть бути квартальні цілі. Наприклад, якісь конкретні команди потрібно провести через фази, сформувати та провести через шторм, нормалізувати, щоб вони почали перформити. Хтось в команді не бере участь в дискусіях про архітектуру, таких людей треба підрозкрити. Банально по-людські спілкуватися, проводити one-to-one, можна створити чаптер (chapter), де люди спілкуються між собою за експертизою.
Часто поки немає ні scrum майстра, ні agile коуча, люди не вірять, що їх чують, що можна щось змінити. Точечні включення на тему зустрічей, взаємодій, каналів комунікацій, оптимізаційні цілі за ролями, включенням певних ролей, створення кросфункціональних команд — це все робить agile коуч.
Як ти прийшов до своєї професійної ролі?
В IT я потрапив як тестувальник у стартап. Стартап займався Big Data, коли це ще не було мейнстримом. Мені все було цікаво, як, що, де можна робити. Коли я почав шукати баги в софті, то зрозумів, що ці баги утворюються, частіше за все, через непорозуміння. Наприклад, тестувальник та розробник отримують технічні завдання, десь «хромає» комунікація й як результат, виникають баги. В той момент я вже був тестувальником / Scrum майстром.
Тоді з’явилася можливість, коли ніхто не хотів бути Scrum майстром. Тож я став першим кого для цієї ролі обрали, при чому обрали сторожили, які вирішили що молодий розбереться. Я так розібрався, що виявилося, що від agile нікому нікуди не дітися. Я почав розбиратися між комунікаціями між розробниками, тестувальниками та тими хто висуває вимоги. Там мені здавалося, що баг був між конкретними людьми через відсутність комунікацій.
Потім я змінив компанію і був вже як QA менеджер та Scrum майстер, почав будувати тест-чаптери, формувати команди. Тут я зрозумів, що баги виникають між командами. Зрештою, я зрозумів що недоліки комунікації та поведінки виникають через керівництво і в принципі організацію варто розглядати як один цілий організм. Кожна команда це гвинтик, все на все впливає одночасно.
Мені дуже цікаво було розглядати ці системи, як міняти організацію, якими точковими діями (комунікаціями, зустрічами, додатковою роллю, документаціями) можна цілком оптимізувати компанію, щоб вона працювала краще. От в принципі такими пошуками вейстів, багами, оптимізуючи роботу компанії, зараз я прийшов до ролі Agile coach.
Ти працював певний час у Польщі. Чи є критичні відмінності між стилем роботи у Польщі та в Україні?
Українці однозначно працюють більше. Коли я повернувся додому, то Україна по mindset для мене ближче була все ж таки до США — така собі гойдалка: сильно вверх, сильно вниз. Кризи сильно вдаряють по нашим країнам, проте це дає багато шансів для розвитку.
Європа вона дуже усереднена, там все стабільно. А Польща вже у 2018 році змінила свій статус з економіки, що росте, у більш стабільну економіку. В них зараз багато аутсорсингових компаній, які працюють з 9:00 до 17:00, деякі приїжджають на роботу в 6-7 ранку та о 15:00 вже вільні, їх більше нічого не цікавить. Український стиль мені ближче: мені подобається працювати на проекті та будувати продукт, бачити як він росте та впливати на його еволюцію.