Bogdan Onyshchenko

Hi everyone! The new podcast episode is out, this time featuring Steve Porter as a guest. We are talking about tough but fair exams, origins of the Nexus framework, complexity behind scaling Scrum and much more. Hope you'll enjoy listening to it and find it useful. Feel free to check previous episodes as well.

Декілька років тому, ще перед пандемією, я мав нагоду відвідати конференцію, присвячену гнучким підходам до створення продуктів. Наприкінці події відбулася панельна дискусія зі спікерами, серед яких було немало відомих людей з європейської аджайл-спільноти. Серед багатьох запитань до учасників дискусії було одне, що не на жарт мене зацікавило: «Які аргументи Ви можете навести проти використання Скраму?». Проте цей епізод я так добре запам’ятав не через запитання, а через відповідь на нього: «Немає сенсу використовувати те, що з одного боку „продають“ як гнучкий підхід, а з іншого — оновлюють лише раз на три роки». Чесно кажучи, на той час така відповідь мене дещо збентежила, оскільки я ніколи раніше не замислювався про Скрам з цієї точки зору. А й справді, чому зміни до Посібника зі Скраму вносять настільки рідко? Єдине, з чим я міг їх порівняти — це оновлення SAFe-у. Останній, до слова, оновлювався частіше, ніж Тейлор Свіфт чи Ед Ширан випускали новий альбом. Тож на той час у мене цілком логічно склалося враження, що теоретична частина в основі Скраму недостатньо часто вдосконалюється та переосмислюється. Оскільки питання було цікавим, проте нетерміновим, то я залишив його десь у потилиці чекати більш сприятливих обставин. Відтоді минуло трохи часу і я мав нагоду суттєво краще довідатися про Скрам: дедалі більше використовував його, обіймаючи різні посади; читав актуальні галузеві книги та статті, розширюючи горизонти; відвідував тренінги та конференції вже як доповідач; навіть подкаст започаткував (у лютому плануються 2 нових епізоди). Все це дозволило заповнити чимало прогалин, змінити ставлення до певних аспектів використання фреймворку та намацати речі, про існування яких я раніше навіть не здогадувався. Відповідь на запитання з попереднього абзацу теж почала вимальовуватися, радше її обриси. Впевненості у правильності ходу думок на 100% ще не було. Проте щонайменше дві речі стали очевидними на цьому етапі. По-перше, тисячі компаній і мільйони людей по всьому світу використовують Скрам. Зміни у Посібнику зі Скраму, що є єдиним теоретичним підґрунтям для цілого фреймворку, вплинуть на них усіх, тому слід бути гранично обережним, запроваджуючи нові правила гри. По-друге, Скрам насправді набагато складніший, ніж я собі думав спочатку. Хоча й існує відносно небагато типових шаблонів імплементації, кількість пермутацій різних проблем і труднощів, які виникають у команд і компаній при спробі застосувати Скрам, тяжіє до нескінченності. Ці пермутації також мають тенденцію видозмінюватися в міру розвитку бізнес-стратегій і технологій. Як не дивно, відповідь спала мені на думку під час чергового занурення у світ відеоігор. Мушу визнати, я — палкий шанувальник стратегій, зокрема стратегій у реальному часі. Одного вечора, стомившись програвати опонентам, що використовували нову для мене стратегію, вирішив пошукати порад на форумах та ютубах. Не минуло і 15 хвилин, як мене затягнула порожнеча ютубу, і будучи не в змозі протистояти алгоритму, почав переглядати усі відео поспіль. Дещо згодом (від 30 хвилин до 6 годин потому) я натрапив на відео, яке описувало одну з найбільш знакових подій в історії Starcraft Brood War. Відео розповідало про матч 2007 року між двома професійними гравцями з Південної Кореї: Bisu і Savior. І перш ніж продовжити історію, мені потрібно додати кілька важливих і не дуже деталей, аби все це хоч якось трималось купи в очах читачів, що не є поціновувачами відеоігор. Зображення взяте у TL.net Першою і, певно, найменш важливою деталлю, є величезна значимість відеоігор у Південній Кореї. Для них це не віртуальний чи дитячий спорт, а майже релігія. Фінал чемпіонату з популярного кіберспорту — це не менша подія для пересічного південнокорейця, ніж фінал Ліги чемпіонів УЄФА для пересічного європейця. Як доказ наведу лише один приклад: якось під час чемпіонату світу з футболу до роздягальні південнокорейської чоловічої збірної завітали найкращі професійні гравці у Starcraft, аби підняти моральний дух команди та налаштувати на перемогу. Футболісти шанували їх як своїх національних героїв. По-друге, щодо власне гри, то в ній доступні усього три можливі раси, з-поміж яких гравець може обирати: Террани, Зерги та Протосси. Кожна з них має унікальний набір інструментів, тактик, стратегій та сильних/слабких сторін. З моменту виходу в 1998 аж до 2007 року у грі налічувалось лише три великих оновлення, що мали вагомий вплив на ігровий баланс. Три основні суб’єкти та лише 3 оновлення протягом майже десятиліття — нічого вам не нагадує? Зображення взяте у Blizzard Entertainment У 2007 році поєдинок Протоссів проти Зергів, відомий ще як PvZ, вважався заздалегідь програшним для перших. Статистичні дані свідчили, що гравці за Зергів вигравали близько 53% усіх ігор, з іще вищими показниками на професійному рівні, де помилки та відхилення від оптимальних стратегій були рідкістю. Природно, Bisu, котрий грав за Протоссів, перед матчем вважали аутсайдером. Однак він використав несподівану та інноваційну стратегію, над якою працював довгий час, і виграв матч з рахунком 3:0. Цей поєдинок став настільки знаковим, що за одну ніч змінив хід PvZ протистояння назавжди, зробивши Протоссів фаворитами. Тож як Bisu зміг цього досягти? Майстерність і, головне, час! Задоволення приходить від уміння, а точніше — від результативного навчання. Ми найчастіше тішимось тоді, коли навчились робити те, чого раніше не вміли, нерідко вкладаючи у це чималі зусилля. Незалежно від того, чи запитаєте Ви Дена Пінка, шахіста, що є міжнародним гросмейстером, чи підлітка, котрий грає у Mortal Kombat, оволодіння своїм «ремеслом» — це найкращий спосіб втілити в життя такі «ого-го» моменти (як це зробив Bisu, змінивши гру назавжди), про які ви ще довго будете згадувати і розповідати. Хоча цей момент і триває недовго, але час, вкладений в нього, зазвичай вимірюється місяцями або роками. Сотні і тисячі годин наполегливої, невтомної роботи, невдач і повторних спроб залишаються за лаштунками. Тож тепер для мене стало очевидно, що навіть у середовищі, здавалося б, зрозумілому та статичному (як то комп’ютерна гра категорії AAA із трьома великими оновленнями протягом 10 років), дивовижні та інноваційні речі не лише можуть відбуватися, а й відбуваються. Тут вже настав час повернутися до розмови про Скрам. Якщо абстрагуватися від розробки ПЗ, спринтів, артефактів та решти, то можна перестати думати про Скрам як про фреймворк і почати сприймати його як продукт, яким доволі успішно користуються понад 10 мільйонів людей. Це — чимала аудиторія, яку не хочеться розчаровувати. Безумовно, не варто поспішати вносити у такий продукт зміни без достатньо зваженого попереднього аналізу. Бо тим самим ви ризикуєте не бути в стані передбачити, який вплив ці зміни матимуть, і врешті-решт ще й розчарувати мільйони людей, які використовують ваш продукт (грають у вашу гру). Тож співавторам Посібника зі Скраму доводиться ухвалювати зважені та обґрунтовані рішення щодо деталей кожного нового оновлення. Але скільки часу знадобиться, щоб упоратися із цією непростою задачею? Можемо спробувати оцінити. Розглянемо як приклад останнє оновлення Посібника зі Скраму від 2020 року. Командам, що вже використовують Скрам, знадобиться чимало спринтів, аби опанувати нові речі, як-от ціль продукту, Зобов’язання (Commitments) щодо Артефактів, перенесення відповідальності за Визначення Готового (Definition of Done) та створення придатного до використання Інкременту на плечі усієї Скрам-команди. Від себе можу додати, що минуло вже більше року, а нашій команді вдалося реалізувати ці речі лише на базовому рівні. Ми й далі активно оптимізуємо процес розробки, аби досягти кращих результатів. Тож в середньому знадобиться від декількох місяців до року, щоб Скрам-команда набила достатньо гуль і була в змозі оцінити вплив останніх змін, мати можливість поділитися набутим досвідом з іншими, надати зворотній зв’язок співавторам Скраму. То були команди, що вже досить довго варяться у Скрамі та їхнє сприйняття змін. Свіжа точка зору від людей ззовні може мати не меншу цінність. Проте скільки часу знадобилося б команді, що лише почала використовувати Скрам, аби досягти принаймні базового (механічного) рівня процесу? А скільки часу мине, перш ніж все працюватиме настільки злагоджено, що команда матиме шанс дістатися до «ого-го» моменту, яким варто буде поділитися зі спільнотою? Ймовірно, роки. Не забуваймо, що після всього вищесказаного відгуки від таких команд мають бути зведені докупи, перетравлені та проаналізовані, аби дозволити співавторам отримати якісно кращу, нову версію. Таку, що з більшою ймовірністю матиме позитивний вплив на Скрам-спільноту. Наостанок зауважу, що версія Посібника зі Скраму від 2020 року була переглянута не менше 15 разів, перш ніж побачила світ. Майже всі хороші речі потребують часу. Отже, маємо те, що маємо. Якщо тепер хтось запитає мене, чому Посібник зі Скраму оновлюють так рідко, то я відповім, що це через те, що у 2007 році Протосси почали перемагати Зергів у Starcraft. Чесно кажучи, мене ця відповідь влаштовує. А вас? Буду радий побачити ваші думки та відгуки у коментарях.

Often enough one can stumble upon the article titled "X principles of doing something". It feels that the learning there is often incomplete as the opposite side of the spectrum is simply not there. For instance, reading an article titled "5 steps to help you quit smoking" is half as effective as reading both that article and "5 mistakes a smoker makes when trying to quit" all together. The latter not only touches some areas that the former doesn’t, but most importantly, offers a different perspective. The idea behind this blog post is to accumulate the experience of ‘how not to do things’ when it comes to exercising business agility. Hope that it helps other folks out there. Naturally, there are more than 10 ways to screw things up, but we all know that less is more (and frankly 10 commandments sounds way cooler than 17 or 26). So, if you really-really want to fail before you even start, obey these commandments: 1. You are the Consultant. Your goal as an agilist is to come in as a consultant. You are not in the team, you work with the team. The overall success of the whole ‘agile endeavor’ is their responsibility, you’re there to support them along the way. 2. You shall keep things under control. Control is the ultimate form of trust. Since you’re not on the team, you should install as many metrics for the team as possible. This will not only provide a more comprehensive picture of how things are really going, but will also help you to accurately report to management. 3. You shall not stay. Starting from day 1 you must make people understand that you’ll be gone soon. It’s a good thing both for your career and for them. Consider yourself Mary Poppins of the agile world: you show up in dire times, make change and then leave. If you never leave, people will never learn to be agile autonomously. 4. You shall abide by your job description. You are hired by a company that has clear expectations of what your duties should be. Company pays you money to do what's expected of you, not what you think would be best. 5. You shall be realistic. It’s an extremely rare thing to implement an agile framework exactly as it’s described in the guide or some official document. Tweaking a few things here and there is completely fine, as reality often demands it. This is very much like the laws of physics, that only work in the ‘ideal conditions’. 6. You shall not touch that which works. The mantra about relentless improvements and continuous pursuit of perfection has nothing to do with how things work in reality. Once a configuration of things that works is there - hold on to it with all your might and prevent all attempts to disrupt the status quo. 7. You shall know best. Once you start working in a new environment, you will get bombarded with opinions, suggestions and ideas. It’s best to ignore most of those, as they might derail you from the path you’ve chosen. Remember, the very people coming up with those ideas have made the mess you were called in to clean up. 8. You shall not give in to the temptation of the new. Unlike new technologies that tend to pop up everyday, forcing poor engineers to constantly learn, agile methodologies and frameworks tend to stay way more stable. These ‘updates’ have a little to no value and are mostly dictated by the need to stay relevant in the market. Exercising agility is like riding a bike - you learn it once and just keep riding. 9. You shall be like Bruce Lee. He said: “I fear not the man who has practiced 10 000 kicks once, but I fear the man who has practiced one kick 10 000 times”. And this is the way to go for you as well: pick a framework and use it, regardless of the environment or circumstances, over and over again until you master it perfectly. 10. You shall keep going. No matter what’s going on, admitting mistakes or changing your strategy halfway through will be perceived as a weakness. So, stand your ground at all costs and persist until you break through. I hope you have enjoyed the list. What would be your advice on wreaking havoc when applying agility? Please leave your comments below.

A few years ago, before the pandemic, I visited an Agile conference in Kyiv, Ukraine. At the very end of it there was a panel discussion with some of the big names in the European Agile world.

Hi everyone! The new podcast episode is out, this time featuring Gunther Verheyen as a guest. We are talking about his 2 new latest books, neverending passion for Scrum, overcomming an illusion of agility, becoming better Scrum practitioner and humanizing the workplace. Hope you'll enjoy listening to it and find it useful. Feel free to check previous episodes with fellow PSTs as well.