Semenov online

Якщо провести аналогію з роллями Scrum framework та персонажами «Острів Скарбів» Роберта Луїса Стівенсона то хто був ким? Хто по суті був Scrum Master? Може Капітан Смоллетт, Джим Гокінс, а може Сильвер🏴‍☠️? Нещодавно перечитав «Острів Скарбів» та поцікавився цим у AI. А ось і результат: ▪️Product Owner — Лівері (Сквайр Трелоні) - Визначає мету (скарб) і фінансує експедицію. - Приймає ключові рішення (наприклад, наймає команду, орендує корабель). - Має візію (знайти скарб Флінта), але не втручається в оперативне управління. ▪️Scrum Master — Доктор Лівсі - Координує команду, виступає голосом розуму (наприклад, під час конфліктів). - Допомагає долати перешкоди (наприклад, коли Джим потрапляє в складні ситуації). - Не є лідером, але фасилітує процес (слідкує за тим, щоб команда діяла ефективно). ▪️Команда (Developers) — Решта персонажів ▫️Капітан Смоллетт — відповідає за виконання задач (безпека, навігація). ▫️Джим Гокінс — «розв’язник проблем», бере на себе ініціативу. ▫️Пірати (Сильвер, його команда🏴‍☠️) — «стейкхолдери з інтересами», які вносять хаос (як непередбачені ризики). ☠️Чому не Сильвер? Він більше схожий на «зацікавленого стейкхолдера» (хоче скарб для себе), а не на PO чи SM, бо саботує процес. Висновок: ▪️PO = Сквайр Трелоні (візія, ресурси). ▪️SM = Доктор Лівсі (фасилітація, допомога команді). ▪️Developers = Капітан, Джим, моряки (виконання).

Часто питають “а що робити з незгодними в команді, які не хочуть вашого agile/scrum?”. Звісно кейси різні є, але інколи «незгодні» насправді згодні. Є форма, а є суть. І ваша задача (як агентів змін, провідників) - це докопатися до суті, бо «вордінг» може бути різним як на відео 😅 https://youtu.be/yA2HwBNtpzI?si=dMDxWWlKipPUbAY9

Орг.дизайн, скейлінг, дейскелінг, оргтипологія така, оргтипологія сяка ..це ніби здається складним і треба бути супер скіловим А-коучем, консультантом щоб впоратись з викликами. Але знаєте що є складним? Підказка у першому слові першої цінності Agile Manifesto. Це робота з людьми, які вхопились в свою унікальну експертизу та незамінність і тримають її в руках як той застарілий TV. Робота з майндсетом, страхами, мотивами.. у пʼятницю я колезі написав щось на кшталт «ти знаєш, те чим я займаюсь це не про Agile і не про коучинг, це якась вже психологія по роботі зі складними людьми щоб вони переусвідомили і змінили своє ставлення». За кожною поведінкою стоїть певний мотив, чомусь людина так себе поводить, і от докопатися до суті це вже є складним, а не фреймворки :)

Все це чудово виглядає зі сторони і звучить логічно, людяно і здраво. Але :) токсик вказує на системні проблеми в команді, в організації такою своєю саркастичною чи грубою реакцією. «Придушення» токсичності веде до штучної гармонії та болота, де всі будуть нетоксично квакати замість того щоб змінювати стан речей. Токсик - це «градусник» для Агента Змін, ПМа, СМа, який вказує на проблематику. Будьте токсиками :) а точніше цінуйте токсиків, вони вам допомагають челенджити статус кво і покращувати стан речей.

☢️ Не будь токсіком! ☢️ Зараз дуже часто можна почути "Ой він такий токсік", або "Більш токсичної людини я ще не зустрічала". Часто ми навіть не замислюємось, що ж дійсно змушує нас називати інших Токсіками. А інколи ми не помічаємо, як самі можемо ставати токсичними у спілкуванні – на роботі, в особистому житті, навіть у соцмережах. 🗿 Що ж таке токсична комунікація і як її уникнути? Тут чудово лягає концепція ненасильницької комунікації, і я намагатимусь максимально просто про це розповісти. 🔅 Токсична комунікація може проявлятися у вигляді критики, звинувачень чи сарказму. "Ти ніколи нічого не робиш правильно!" ➡️ "Коли завдання виконане неправильно, я відчуваю стрес, бо важливо, щоб ми дотримувались дедлайнів." "Це твоя проблема, не моя!" ➡️ "Я бачу, що ти стикаєшся з труднощами. Давай спробуємо знайти рішення разом." 🔅 Спостерігай без оцінок Замість того, щоб критикувати, фокусуйся на фактах, не додаючи власних оцінок. "Ти запізнився, як завжди!" ➡️ "Ми почали зустріч о 10:00, а ти прийшов о 10:15." 🔅 Висловлюй свої почуття Не приховуй емоції, але говори про них у першій особі. Це допоможе уникнути звинувачень. "Ти мене дратуєш" ➡️ "Я відчуваю роздратування, коли не отримую вчасно відповіді на важливі запитання." 🔅 Визначай свої потреби Пояснюй, чому для тебе важлива певна дія або поведінка. Це допоможе іншим краще зрозуміти твої мотиви. "Мені важливо, щоб ми зберігали організованість, тому що це допомагає уникати стресу в команді." 🔅 Пропонуй конкретні рішення Ненасильницька комунікація включає прохання, а не вимоги. "Ти повинен закінчити це до кінця дня" ➡️ "Чи можеш ти завершити це до кінця дня, щоб ми встигли все інше?" Так, це доволі складно - зберігати баланс у комунікації, коли є купа чинників, які виводять нас із рівноваги, але використовуючи хоча б одне з наведених правил, ти вже зможеш помітити позитивні зміни у спілкуванні з оточуючими.

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

Це вже визнання чи ще нє? 😼

3/3 І вже після того як у інженерів (ваша група на воркшопі) прийшло розуміння що Agile не проти них, а що саму концепцію визначили їх "попередники", то повертаємось до принципів і розглядаємо ще декілька з них, наприклад Our highest priority is to satisfy the customer through early and continuous delivery of valuable software Коли наш customer буде satisfied? Що має відбуватись? Ага, є хтось хто "знімає" з нього запит, потреби, спілкується з ним, і всі ці валідовані побажання потрапляють в беклог до команди і не через рік, а одразу і його не тільки почули, а і через 2-3 тижні (не по Арістовічу) надали солюшин який вирішує його головний біль, і так далі, далі ви і сами знаєте краще за мене. "Повертаємось до 4х цінностей https://agilemanifesto.org. Все це потрібно і processes and tools і documentation і contract і following a plan, але коли у нас підвищена невизначеність, раптово і пріоритети і вимоги змінюються, і конкуренти і нові можливості на ринку .. ми більше цінуємо Customer collaboration, Responding to change (в цьому і полягає адаптивність) і Working solutions (не software, може якось іншим разом поясню) і Individuals and interactions." "А тепер розглянемо (це я їм кажу, не вам 😁) Скрам фреймворк, яким чином механіка реалізує всі ці принципи by design". І тепер їм вже цікаво аналізувати та метчити принципи та механіку, але це вже інша історія 😉.

2/3 Далі, проговорюю що є ще 11 принципів, але до них ми повернемось згодом. Одразу переходжу на головну сторінку https://agilemanifesto.org. Ні, про цінності ще говорити зарано, вони їх не зрозуміють, а якщо зрозуміють - то не вірно 😉. Тому це вже під кінець. "Давайте подивимось на тих хто визначив ці принципи та цінності". Кого з них ви знаєте? Ну, наприклад, Martin Fowler. Чим він займався і яке відношення мав до цього Agile? Переходимо на https://www.martinfowler.com/, о архітектура, це напевно те що вас цікавить, переходимо на https://www.martinfowler.com/architecture/ і скролимо сторінку, розглядаючи що там і яку книгу він написав, далі переходимо на рефакторінг https://refactoring.com/ і так само скролимо, розглядаємо яку книгу він написав по цій темі і які там матеріали. А ось і про тестування для інженерів https://martinfowler.com/tags/test%20categories.html. Все це ми відносно повільно скролимо і спілкуємось. Потім повертаємось до сторінки маніфесто. Всі ці люди - вони практики, інженери в минулому, консультанти зараз і маючи досвід в різних проектах прийшли до спільного знаменника, що в умовах підвищеної невизначеності (і вимоги змінюються і технології змінюються і нові ідеї та знання приходять лише в процесі розробки) в продуктовій розробці має бути кастомер центричний фокус з швидким фідбеком від ринку і тп.

1/3 На воркшопі з інженерами починаю з того, що "перед тим як перейдемо до різних практик, фреймворків ми трохи призупинимось і розглянемо деякі принципи, на яких вони побудовані". Відкриваю https://agilemanifesto.org/principles.html, показую екран і виділяю один принцип та зачитую Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Запитую як вони розуміють що таке sustainable development і чому це важливо. Підсвічую що це саме про продуктову розробку, де продукт розвивається, проходить певні фази Product Life Cycle і якщо не влучити в Product Market Fit, то продукт помре у зародку ☠️. Так от, саме в продуктовій розробці, ми маємо так організувати свої процеси та взаємодію щоб "грати в довгу". Далі, виділяю The sponsors, developers, and users. Запитую, а чого хочуть спонсори бізнесу? Гроші, масштабування, лідерська позиція на ринку і все таке. І що вони зазвичай для цього роблять, що від вас хочуть? Приходимо до того, що їх інтерес - це "ПОБІЛЬШЕ І ПО ШВИДШЕ". І якщо постійно гнати в режимі "побільше і по швидше" то що тоді? Що просідає, де розбалансировка? Приходимо до різного, але воно все навколо якості продукту, мотивації команди, ресурсного стану (батарейки) команди. А чого хочуть розробники? Ви, як розробники, чого хочете, в чому ваш інтерес? І тут вони вам як насиплять, все що в них наболіло - і про брак часу на нормальну архітектуру, і що техн. борг спонсори не розуміють і що вони стають заручниками ситуації де мають нехтувати якістю і говнокодити аби в дедлайни вписатися і на автотести часу немає.. коротче приходимо до того що інтерес "ПОМЕНШЕ і ПО ЯКІСНІШЕ". А чого хочуть користувачі? Ви всі є користувачами банківського додатку. Ви чого хочете як клієнти? Тут вже і про UX, і про доступність, стабільність і про якість. Так от, у The sponsors, developers, and users різні інтереси, і у них може бути (і зазвичай є) конфлікт інтересів. А як вирішується конфлікт інтересів? Правильно, переводом в процесне русло, при чому так щоб була можливість підтримувати постійний ритм як завгодно довго, тобто "грати в довгу".

Ого, чесно кажучи, не очікував що ця тема актуальна і у вас 🫣. Отже, ще раз закцентую що ЦА саме інженерні команди, бо для СМів, ПМів формат та контент інший - там розбираєм в ключі "Ось це стілець - на ньому сидять, ось це стіл - за ним їдять". Ось 4 цінності, 12 принципів. Розбираємо чому це важливо - в складних ситуаціях, де немає правильних відповідей (відсилка потім до complex domain) люди make a decision (саме створюють рішення, не приймають), відповідно до своїх цінностей (навіть якщо вони їх не усвідомлюють). Перефраз кожного принципу 3-ма словами, які передають його суть. А якщо формат ще і офлайн - то додаємо тактильності - стікери, фліпчарти. На декількох кейсах розглядаємо як ці цінності та принципи "вступають в гру". ВСЕ ЦЕ ЧУДОВО НЕ ПРАЦЮЄ якщо у вас інженерні команди, які вже скептично налаштовані. Тож далі вже про них.

Типовий кейс, за останні 7 років, з яким постійно маю справу - пояснити цінність Agile Manifesto для інженерних команд, які переходять на Agile-based framework. Пробував різні варіанти (розуміючи що вже є алергія на “Agile” як на слово так і на все що з ним повʼязано через «якісні» спроби впровадження) і прийшов до простого алгоритму так щоб воно навіть для скептичних інженерів екологічно лягало. Один з нещодавних фідбеків керівника «ти перша людина, яка пояснила моїм социопатам що таке Аджайл, так щоб вони зрозуміли та не зафукали ні сам Аджайл, ні тренера» Чому це важливо? Якщо на цьому кроці не засетапити прийняття та довіру до Agile концепції, то далі взагалі можна не рухатись. Чи цікаво вам отримати такий алгоритм? Дайте пару вогників 🔥або серденьок 🫶 і я приділю цьому час щоб розписати.

Це знову сталося. Чомусь мене продовжують залучати до складних кейсів, де незрозуміло як вчинити - от хай Сергій гляне і скаже що робити. На цей раз кейс був «звільняти не можна розвивати». Треба визначити де поставити кому 😎. Мова йшла про senior developer 15+ років досвіду. 1-1 з його тімлідом, 1-1 з самим розробником, пару коучингових технік і визначили де ставимо «кому». Так як більшість в курсі, хто мій ентерпрайз клієнт та в якій я трансформаційній ролі зараз - то більше деталей не дам 😎. Але пост не про це, періодично отримую відгуки що мене цінують за практичні інструменти та кейси. Так от ділюсь інструментом, який точно допоможе визначити де ж поставити «,». При прийнятті рішень ви аналізуєте дві складові - поточний, реальний перформанс людини та його потенціал зростання та розвитку. І потім матриця 3*3 допоможе зрозуміти яке рішення прийняти.

Channel photo updated

Завершається 3й тиждень і бачу як самоорганізація по визначеному фрейму без "гавканья" (як це називає моя дружина) працює 😉

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

English. Знайшов безкоштовний ресурс https://test-english.com/, там все по рівням, для кожного рівня вже готовий беклог уроків і в кожному уроці (граматика, читання, слухання, словник) є тест для самоперевірки, тож зручно одразу отримувати фідбек від системи чи ти засвоїв урок. Всі ці уроки як посилання я додав на ту ж Міро дошку, тепер клік по "айтему" і відкривається урок, все під рукою, нічого не забувається. Сам беклог я по swimlines розніс по певним темам.