Artem Bykovets

Робота Agile Coach чи Scrum Master вимагає вміння працювати в дуже різних «режимах» / «стійках» (в англ. - Stances).

Нажаль, доволі часто ми бачимо початківців у цій ролі, що зусереджені виключно на фасилітації (при чому довольно лінійній та директивній), що призводить до розчарування девелоперів у сервісі, що вони отримують від свого Scrum Master. Давайте коротко розберемо основні сервіси (згідно Scrum Guide) та «Стійки» (згідно ставшої вже майже мануалом статті від The Liberators) професійного Скрам Майстра.

Також іноді можна почути, щось типу: «…ці Скрам Майстри ні за що не відповідають…». Згідно дизайну фреймворку Scrum, то є 2 ключові відповідальності (The Scrum Master is accountable for…):
1. …establishing Scrum as defined in the Scrum Guide;
2. …the Scrum Team’s effectiveness.

Сервіси поділяються на 3 напрямки:
1. Скрам Команді:
+ коучінг самокерованності та кросфункціональності
+ допомогає фокусуватись на створенні інкрименту продукту найвищої цінності, що відповідає критерії готовності (DoD)
+ сприяє усуненню перешкод та блокерів прогресу (котрі реально блокують створення інкрименту)
+ сприяє ефективності Скрам Івентів

2. Продукт Оунеру допомагає:
+ .. техніками роботи з ціллю Продукту та роботи з Беклогом Продукту;
+ .. розуміти важливість чітких та лаконічних елементів беклогу;
+ .. впровадити емпіричний підхід продуктового планування;
+ .. фасилітацією співпраці з стейкхолдерами за потреби.

3. Організації:
+ Лідить, навчає та коучить організацію у впровадженні Скрам;
+ Планує і консультує щодо впровадження Scrum на рівні організації;
+ допомагає працівникам та стейкхолдерам зрозуміти та використовувати емпіричний підхід до комплексної роботи (складної)
+ прибирає барʼєри (у спілкуванні) стейкхолдерів та Скрам Команд.

Це було би нереально робити лише фасилітуючи дискусії, чи не так? 🤪

Отже ключові Stances of the Scrum Master:
1. «Вчитель / Тренер» (Teacher)
2. «Усувач перешкод» (Impediment remover)
3. «Коуч» (Coach)
4. «Наставник» (Mentor)
5. «Фасилітатор»
6. «Агент Змін» (Change Agent)

Про що вам було би цікаво дізнатись більше? 😎

5 Тема: "Місце стратегії та ідеї в розвитку бізнесу" та "Ключові уроки українських Продуктових Agile команд у воєнні часи"
Спікер: Artem Bykovets

"Місце Стратегії в розвитку бізнесу":
📌Що таке Стратегічна Ідея та де звʼязок зі Стратегією?
📌Стратегування vs Стратегія
📌Чому Стратегія це не список KPI / OKR
📌Типи контекстів
📌і ще трохи цікавого...
"Ключові уроки українських Продуктових Agile команд у воєнні часи":
📌передумови дослідження
📌ключові виклики
📌що допомагало долати хаотичність та невизначеність
📌чому навчились та живі приклади впровадження...
І, звісно, з радістю будуть відповіді на питання та жива дискусія із залом.

Який елемент з вашого досвіду найбільш недооцінено чи найчастіше трактують невірно?

Про що для вас Agile, якщо спробувати вмістити всю суть у одне (можна складне) речення?

(навіяно обговоренням під одним постом в LinkedIn)

Всім продуктивного тижня 😉

Щойно завершив свій виступ на UA Online PMDay 2023 Autumn!

Цього разу темою взяв: «Якщо Agile це “не про проекти”, то як їх тоді робити? Проектні vs Продуктові vs Сервісні структури команд.»

Часто доводиться чути баталії між Аджайлістами, що кажуть: “Agile це про розробку Продуктів, а не проектів, не плутайте!” та іншими менеджерами і консультантами, що розповідають історії про успішне Agile PMO 🤪, впровадження Agile Delivery Management 💪 та гнучке управління портфелем проектів✈️. Хто ж правий? Де криються підводні камені та ризики невірного трактування концепції крос функціональних команд та ітеративних фреймворків розробки…

Як працювати у крос функціональних Agile командах, якщо:
1) вони всі роблять один продукт (в широкому сенсі дефініції продукту) і нам вистачає людей, щоб створити збалансовані команди. (концепція LeSS-like структури з єдиним РО та Беклогом)
2) кількість “продуктів” та контекстів над якими слід працювати ЗНАЧНО перевищує кількість людей з котрих можна зібрати ці команди… а “основні задачі” (операційні) - ніхто не відміняв. (Авторська концепція “20% розчин Scrum) (от цю частину нажаль не вистачило часу, щоб покрити…)
3) у команди є багато (3-5++) різних “замовників” (внутрішніх чи зовнішніх) чи команда по своїй природі Сервісна, а не створює конкретний продукт. (концепція управління потоками створення сервісу)

Трохи поговорили та помалювали разом з учасниками конференції (малюнки додаю).

p.s.: пішов робити фінальні підготування до завтрашньої конференції Simplicity Day: Agility & Resilience (в Києві вживу та онлайн у вигляді відео стрімінгу з чатом)

#конференції

Всіх причетних вітаю зі святом😜 Тестуйте невпинно та у співпраці🤪

«Питання в зал - яке ваше відношення до Pre-Filled Retro. Тобто коли є борда по лінку, під час спринту туди по факту накидуються тікети, і потім на ретро проговорюються.»

я би почав із зʼясування:
- Яку проблему це має вирішувати?
- Яка мета цього експерименту?
- Які можуть бути наслідки?

З мого досвіду, таке найчастіше пропонують коли:
1) «.. на ретро важко згадати що там було під час спринту…»

Значить, що не таке і критичне й важливе воно було, раз швидко забули! І це абсолютно ок, що якісь речі в моменті тригерять, але швидко вирішуються і не потребують додаткових кроків чи обговорень через декілька днів. Не треба заради кількості висмоктувати з пальця «що би мені написати на стікері на ретроспективі…». Чи заради "унікальності стікера", щоб додати щось, чого в інших не було.

2) «у нас є максимум 30хв і якщо не готувати заздалегідь цю дошку, то ми просто нічого не встигаємо»

Це вже певний сигнал, що треба допомогти команді та організації зрозуміти цінність від Ретроспективи, щоб час на неї виділявся достатній для результату. До того ж, заповнення під час спринту дошки - це теж час, котрого потім не вистачає… +цей префіл, якщо це не 1-2 слова на стікері, створює розфокус в середині спринту.

Цінність ретроспективи, що ми вже маємо фідбек стейкхолдерів із Рев'ю Спринту і можемо обговорювати дійсно важливі речі!

Отже:
1) Я нормально ставлюсь до якоїсь "коробки" / «паркінгу тем» для майбутнього обговорення. Чисто, щоб "не забути до".

2) Я негативно ставлюсь до prefilled retro. (З досвіду, то або заповнює потім 1-2 людини, а іншим пофіг і на старті динаміка рвана.) +це часто призводить до "ну у нас вже все на дошці, то давайте швиденько"🤪

І звісно, якщо прям тут і зараз відбувається єресь, що ставить під загрозу якість, DoD, ціль Спринта чи здоровʼя / стосунки команди - не треба чекати до кінця Спринту ;) Слідуйте принципу «Jidoka». Зупиніть конвеєр, виправте проблему і потім продовжуйте розробку. А причини проблеми, та як їх не повторювати знову і знову - обговорите вже на Ретроспективі ;)

Сходив у гості до Product Market Fat на подкаст. Говорили про:
✅ Чому Артем пішов в аджайл, і як він став Agile Coachем? Історія про вхід та зростання в ІТ від Артема.
✅ Про Scrumbutt та інші аджайльні збочення. Чому Scrum наче й легко зрозуміти але важко слідувати принципам?
✅ Які риси повинен мати скрам майстер, та які в нього responsibilities?
✅ Чи продакт овнер та продакт менеджер це одна людина? Чи може у нас бути багато овнерів для одного продукту?
✅ Чому SAFe це лайно, і чому воно таке популярне? Чому це не є scaled agile здорової людини?
✅ Що насправді означає “User Story” і чому девелоперам важливо говорити зі стейкхолдерами та користувачами?
✅ Як правильно скейлити Scrum та масштабувати гнучкість та адаптивність в організації?

Подивитись випуск на YouTube можна тут:
https://www.youtube.com/watch?v=b1hG9aEZzg8

Повний список платформ, де є випуск - тут :)
https://wtf-is-pmf.top/

PMF s3 e5 - Артем Биковець про аджайл, скрам, та ефективність команд і процесів П’ятий (5) випуск третього сезону подкасту Product Market Fat. В гостях Артем Биковець - керуючий партнер та засновник SimpleSense (навчання аджайлу та скрам...

Since it become quite popular to use at work and also create frameworks and slides using acronyms, I've decided to join the race as well :)

Here is my description of highly efficient, productive, and motivated development ! Meet - ARTEM :)

A - Adaptability: The team demonstrates adaptability by quickly adjusting to changing project requirements and market dynamics, utilizing their professional expertise and skills.

R - Responsibility: The team members take ownership of their tasks and demonstrate a strong sense of responsibility towards meeting project deadlines, delivering high-quality results, and ensuring customer satisfaction.

T - Technical Proficiency: The team possesses a high level of technical proficiency and expertise, leveraging their skills and experience to develop innovative solutions and overcome technical challenges.

E - Empowered: The team members are empowered to make decisions and contribute their unique perspectives based on their skills and experience, fostering a collaborative and inclusive environment.

M - Motivated: The team is highly motivated and driven by their passion for excellence, continually seeking to improve their skills, expand their knowledge, and deliver exceptional products.

They showcase adaptability, professionalism, responsibility, technical proficiency, and a strong drive for continuous improvement. Their collective skills, experience, and dedication contribute to their success in delivering high-quality products while maintaining customer satisfaction.

Сьогдні ділюсь із вами (якщо ви раптом досі не бачили) випуском книжкового клубу на DOU зі мною та Назаром, Тетяною та Богданом про книгу “Розверніть корабель. Уроки менеджменту від капітана підводного човна” авторства Девіда Марке, письменника, експерта з питань лідерства та капітана Військово-морських сил США у відставці 🤩

https://youtu.be/ji7IgvFyhtc

p.s.: коментуйте тут і там! Діліться з колегами та знайомими) «Замовляйте» наступні книги для зйомок рубрики, про які хочеться дивитись Книжковий Клуб (чи навіть прийти і стати ведучим у студії)

p.p.s.: ну і з 200тис 200тих ювілеєм вас 😉 Yellow submarine весь день в голові звучить (if you know what I mean🤪)

Поганий менеджер дає команди, хороший — повноваження | Розверніть корабель 📚 Книжковий клуб #9 📘 У цьому випуску книжкового клубу обговорюємо книгу “Розверніть корабель. Уроки менеджменту від капітана підводного човна” авторства Девіда Марке, письменн...

дуже наглядний відос, про вплив WiP лімітів на Cycle Time і Пропускну здатність системи:

WIP: why limiting work in progress makes sense (Kanban) One of Kanban's main principles is to limit the work in progress (WIP). This video uses a drive-thru to illustrate what WIP is and why limiting WIP is a good...

- це сила!
- могила🤪
[ ]

Завчасний анонс для тих, хто запитував: "А де тебе можна послухати у форматі Stand Up Comedy?" і хто в Києві (чи приїде).

25 квітня 2023 року, початок о 18:00, Peppers Club (Київ)

Буде і про варан менеджерів і про корпоративних "котів" і про інші цікавинки з життя "працівників та їх лідерів" 🤪

З 6м релізом 🤪

«У нашої команди дуже великий відсоток правок, або уточнень прилітає після релізів, бо РО не вміє писати Acceptance Criteria, а девелопери не дуже сильні в аналізі задач, то ми вирішили найняти їм Бізнес Аналітика, щоб вирішити цю проблему…» Знайомо?🤪

А як щодо: «щось у нас багато дефектів в продукті та мале покриття автотестами… мабуть це тому, що у нас немає ролі QA Lead, а всі тестувальники володіють тільки навичками мануального тестування! Треба найняти людину, котра буде за це відповідальна і от тоді….» 💪

Чи може ваш сценарій це: «…задачі інтеграції та деплоймента викликає безліч питаннь та труднощів, то ми плануємо створити DevOps команду і передати їм відповідальність ….» 🤓

Хочу підкреслити 2 важливі думки:
1) Створити нову Роль в системі - доволі просте і швидке рішення, що приходить одразу. Але дайте відповідь на декілька питаннь:
+ як поява цієї специфічної Ролі відповідальної за конкретні функції та завдання вплине на (без)відповідальність існуючих в системі Ролей?
+ як поява нової ролі (на рівні патернів управлінських рішень) впливає на мотивацію вивчати нове у існуючих членів команди?
+ на скільки легко з системи Роль прибрати? (особливо, якщо самі нещодавно її туди додали)🤪
+ як збільшення кількості специфічних Ролей та Відповідальностей (Roles & Accountabilities) впливає на загальну складність (Complexity) системи? (про це більше в 2 пункті)

2) Локальна оптимізація зазвичай призводить до глобальної субоптимізації (Local optimisation usually leads to global sub-optimisation)

Спроба вирішення «локальної проблеми» тут і зараз «простим» способом без врахування впливу на інші «елементи системи» призведе до певних негативних наслідків на системному рівні, які вірогідно буде значно складніше виправляти, ніж початкову «локальну проблему»! 🤓

Отже перед тим, як додавати нову Роль в систему, я раджу відповісти на ці питання:
1) Яку проблему ми вирішуємо?😜
2) Які є способи вирішення без створення нової Ролі і без ускладнення існуючої системи?🤪
3) Це тимчасова / сезонна проблема, чи постійна? Як вона розвивається історично в динаміці? 😔
4) Які з існуючих ролей системи могли би взяти на себе відповідальність? Чого їм не вистачає? Яким чином їм це дати? Як це вплине на якість? На мотивацію? На продуктивність? 📞
в разі якщо без нових Ролей / Людей не обійтись ну ніяк…
5) Як не зробити з неї новий бас фактор / bottle neck? 🤨
6) Що ми будемо робити з новою Роллю (чи новими співробітниками), якщо проблему буде вирішено і ця «нова Роль» в оригінальному дизайні (вигляді) перестане бути критично необхідною? 😎

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

З початком весни вас 📆

Ділюсь варіантами метрик, які можна використовувати:

📉 Backlog Health: міра загального здоров’я та ефективності використання backlog, включаючи фактори по типу розмір беклогу (backlog size), старіння елементів (aging items), і прогрес до завершення майлстоунів (якщо ви користуєтесь епіками чи версіями наприклад).

📈 Flow Efficiency: відсоток часу, протягом якого команда фактично працює над поставкою цінності, по відношенню до очікування ресурсів або узгодженнь. (Working time / (Working + Waiting) time * 100%)

📊 Work In Progress (WIP): обсяг роботи, яка зараз виконується в системі. Цей показник може допомогти командам виявити вузькі місця та зменшити мультизадачність.

💢 Work in Progress (WIP) Limit: максимальна кількість завдань, над якими може працювати команда в будь-який момент часу.

♻️ Cycle Time: час, потрібний команді для виконання завдання від старту робіт над нею до повного завершення.

🕖 Lead Time: час, який проходить від моменту, коли клієнт «замовив» роботу, до моменту поставки готового результату.

🏆 Throughput: точна кількість робочих елементів, виконаних за одиницю часу.

🕝 Time to Value: час, потрібний команді, щоб доставити відчутну (tangible) цінність клієнтам.

🕧 Time to Market: час, потрібний команді, щоб вивести продукт або функціонал в ринок.

💥 Defect Density: кількість дефектів на одиницю роботи.

🔨 Mean Time To Repair (MTTR): середній час, потрібний для ремонту дефекту.

👏 Customer Satisfaction: показник того, наскільки клієнти задоволені роботою команди.

📌 Escaped Defects: кількість дефектів, які потрапляють у кінцевий продукт, незважаючи на зусилля команди запобігти їм.

❓ Rework Percentage: відсоток роботи, яку було перероблено через дефекти чи інші проблеми.

🗣 Retrospective Feedback: відгуки членів команди про ефективність ретроспектив або процес постійного вдосконалення команди.

💪 Team Morale: загальний показник рівня залученості та мотивації команди, визначений за допомогою опитувань чи інших форм зворотного зв’язку.

Пропонуйте корисні метрики, яких немає в списку, а також ваші думки в коментарі! Що використовуєте у своїх командах?

Працюючи в комплексному оточенні (Complex Domain), ми часто зіштовхуємось з труднощами, перешкодами і робимо помилки чи «під тиском обставин» робимо щось «не так»😔

Важливо, щоб в цій рутині, ми не застрягли в позиції жертви і не прийняли цей Status Quo, як «нову нормальність», та шукали способів, як це змінити і покращити, а не виправданнь та винних тій ситуації, що маємо.

Часом, першим кроком до вирішення проблеми, є її усвідомлення. Неодноразово використовував інструмент «Драбина відповідальності», як по відношенню до себе, так і щоб допомогти своїм колегам та командам, краще зрозуміти «на якому рівні прийняття відповідальності я зараз?»

Наприклад: «…ми працюємо без Цілей Продукту та Спринтів, адже вони тут не потрібні, а скоуп постійно по 3-4 рази за Спринт змінюється, бо так в компанії Стейкхолдери трактують Agile…»

або наприклад: «..у нас немає Скрам Майстра, бо менеджмент не бачить поки в ньому потреби. Якщо одного дня, вони зрозуміють і наймуть нам його - то буде звичайно круто, але поки працюємо, як вже працюємо…»

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

А на якому рівні останнім чином дієте ви відносно системних дисфункцій у ваших організаціях? А ваші РО, девелопери?

Хочете працювати в кращих організаціях і процесах? Візьміть і зробіть їх 🙂

Поважайте швидкість з котрою відбуваються зміни в організації (respect the pace of change)

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

Ставтесь до організації, як до живої істоти, а до своєї ролі, як для терапевта, тренера… Ваша задача - допомагати і поважати нинішній стан та ресурс клієнта. У кожного організму є свої особливості, обмеження, «розтяжка» та якісь наслідки «минулих травм». Неможливо з нуля підготувати до Iron Man за декілька тижнів… Будуть зриви з дієти та пропуски тренувань, а потім знову невеликі перемоги на шляху до цілі…

Respect the pace of change - це мантра, котру повторюю собі, щоб «тюнингувати» свій рівень очікуваннь і бути в ресурсі для клієнтів, мати емпатію та віру, в те, що вони круті і в них все вийде 😉

А як у вас з мультітаскінгом та особистим плануванням? Які інструменти використовуєте і що допомагає?

Мій особистий рецепт це мікс наступних підходів:
1) Personal Kanban (зазвичай фізична дошка зі стікерами прямо на стіні поруч з робочим місцем).

Починав колись з банальних 4х колонок: Backlog | To Do | Doing | Done… З часом помітив, що в Беклог якась нескінченна черга, купа всього зависає в Doing (бо чекає на фідбек чи якусь іншу задачу), після кожної зустрічі / дзвінка, додається одразу одна чи декілька карток в To Do (саме сюди, повз Backlog)… та і Done треба якось чистити періодично… а що ж буває, що є некст степи після Done…

Тут прийшов час переробити трохи дошку!

1.1.) Зʼявились топ 3 цілі (aka дуже спрощений варіант персональних OKR), щоб краще фокусувати та пріоритезувати.
1.2) Колонки проапдейтились до нового флоу (також додались WiP ліміти на колонки):
IDEAS | Month [8] | Next Priority [5] | To Do [3] | Doing [2] | Waiting Feedback [4] | Done (розділена на секції: просто Done, та Lessons Learned)
1.3) У деяких карток зʼявились чеклісти (аля сабтаски), щоб не плодити стікери і берегти природу 🤪 (типу: підготувати Мурал, вислати інвойс, додати в календар, вислати інвайт в Зум, підготувати фідбек форму, відправити фоллоуап мейл) (це в свою чергу спровокувало появу великої кількості заготовлених тімплейтів та автоматизацій)
1.4) Почав використовувати стару добру Матрицю Ейзенхауера, щоб не пхати всі «нові виникаючі запити» одразу в To Do чи Next (а також, щоб періодично вичищати свої не початі задачі з Беклогу та Next😉)

2) вже згадана та закріплена до посту Матриця Ейзенхауера (допомагає при особистому ревʼю, рефайнменті та додаванні нових задач)

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

4) останній рік до гугл Calendar додав ще використання Calendly, де є різні заготовленні посилання на бронювання слотів в мій календар
- на 90 хв дзвінки: зазвичай менторські та коучінг сесії, чи якісь невеликі воркшопи/активності для команд клієнтів
- на 45 хв дзвінки: щоб познайомитись, обговорити запит потенційного клієнта, швидко задемати результат та отримати фідбек
- на 4 годинні слоти для бронювання тренінгів в моєму розкладі
Під кожний варіант налаштовано певні правила (скільки хвилин до та після зустрічі має залишитись вільними / в які дні тижня та часові проміжки доступно бронювання). Calendly автоматом розлилає запрошення і додає лінк на Zoom event захищенний паролем

5) Блокноти із записами + Mural дошки під кожного клієнта, щоб трекати історію нашої співпраці, інсайти із зустрічей, та постійно адаптувати роадмап. (переїзд із паперу в діджитал ще триває. Але в проектах де працюємо в парі чи втрьох з кимост - тільки так!)

6) ну і звісно якісний звук + шумоізолюючі навушники та софт для них (Krisp) - про це вже писав окремим постом раніше! Це дуже важливо для якості сервісу і співпраці.

Діліться своїми підходами в коментарях ;)

p.s.: ілюстрацію зробила Olina Glindevi

А прикольний вийшов міні-курс :)
Послухаємо сьогодні фідбек та запитання від учасниць :)

Допомагаймо один одному і йдемо до перемоги.

The third week of the Amarelo Azul training program has begun!💫
This time, we will ✔️analyze common mistakes of entrepreneurs, ✔️define leadership styles, ✔️test hypotheses and learn how to conduct interviews with users, ✔️learn what "sense making", "User Personas", "MVP", and "Lean UX Canvas" are, ✔️what are the basics of Agile and Scrum, and ✔️how to make the first sales even before creating a product. Finally, what can go wrong when building your business and what to do about it?🤯

So, who will guide this week's participants:
🧑‍🏫 Artem Bykovets, CEO, Organizational Consultant, and Agile Coach at Simplesense.
👩‍🏫 Anna Khlyntseva , entrepreneur, product and project manager with over 20 years of experience!

🗓And this Saturday, the participants will have another offline meeting in Lisbon.
We will talk about everything in sequence and, of course, share insights.

Stay tuned.🚀

🇺🇦
Третій тиждень навчальної програми Amarelo Azul розпочато!💫

Цього разу ми ✔️розберемо часті помилки підприємців, ✔️визначимо якими бувають стилі лідерства, ✔️будемо тестувати гіпотези та вчитись проводити інтерв'ю з користувачами, ✔️дізнаємось що таке sense making, User Personas, MVP та Lean UX Canvas,✔️ якими є основи Agile та Scrum і ✔️як зробити перші продажі ще до створення продукту.

І головне – що може піти не так при побудові вашого бізнесу і що із цим робити.🤯

Гідами, які приведуть наших учасниць до всіх важливих відповідей, цього разу будуть:
🧑‍🏫 Артем Биковець, СЕО, Організаційний консультант та Agile тренер в Simplesense
👩‍🏫Анна Хлинцева, підприємиця, продуктова та проєктна менеджерка із досвідом у понад 20 років!

🗓А в цю суботу на учасниць знов чекає офлайн-зустріч в Лісабоні.
Про все будемо розказувати послідовно і звісно ділитись інсайтами.

Не перемикайтесь..🚀

Друзі, а яка ваша думка про цих трьох працівників?
Хто працює добре, погано, "шлангує"?
Може когось треба підвищити або навпаки, звільнити?
Ваш варіант ;)
Дякую Artem Bykovets за чудовий слайд із виступу на Project Management Day

Don't Confuse Prioritization and Clarification

Не плутайте пріорітезацію та прояснення вимог 😜

У є два ключові інформаційні потоки, пов’язані з власником продукту:
(1) адаптивне визначення напрямку розвитку продукту та відображення цього рішення в пріоритетності беклогу продукту (Product Backlog)
і
(2) виявлення (discovery) та уточнення деталей потреб користувачів і елементів беклогу.

У першому потоці (напрям і пріоритезація) аналізується інформація, пов’язана з факторами прибутку, стратегічними клієнтами, бізнес-ризиками тощо.
У другому потоці (деталізація та роз’яснення) метою є виявлення деталізованої поведінки та досвіду користувачів (UX), якість елементів беклогу, тощо.

LeSS framework рекомендує наступне (--Guide: Prioritization over Clarification; Large-Scale Scrum: More with LeSS; p 178)

Як власник продукту (Product Owner), ви зосереджуєтеся на ретельному обдумуванні напрямків і пріоритетів, але делегуєте командам якомога більше детальних дослідженнь та аналізу (discovery). Ви заохочуєте та допомагаєте командам вступати в безпосередню розмову з користувачами (чи їх прямими представниками), діючи як сполучна ланка, а не посередник між ними! Коротше кажучи, ви здебільшого зосереджені на визначенні пріоритетів, а не на детальному роз’ясненні, яке делеговано командам.

P.S.: А як це працює у вас? 🤪

Бути Agile так само важливо, як і Робити Agile 😜

Спринт. Вирішуйте складні завдання і тестуйте нові ідеї за 5 днів — Книжковий клуб #5 У новому випуску книжкового клубу обговорюємо книгу "Спринт. Вирішуйте складні завдання і тестуйте нові ідеї за 5 днів". Розібрали, що таке технологія спринту та як ....

Щасливого Різдва 😜

All of our social problems arise out of doing the wrong thing righter. The more efficient you are at doing the wrong thing, the wronger you become. It is much better to do the right thing wronger than the wrong thing righter! (Dr. Russell Ackoff)

🇺🇦
Всі наші соціальні проблеми виникаються через те, що ми робимо не вірні вчинки правильніше і краще. Чим ефективніше ми робимо «неправильні речі» - тим більше ви помиляєтесь / відхиляєтесь від цілі. Набагато краще робити правильну річ неправильно, ніж неправильну річ правильно! (Доктор Рассел Акофф)

Agile By Example was always in my shortlist of Top Agile Conferences to visit as a speaker and visitor as well. This year we were honored to speak there and delivering with Andrii Glushchenko our talk: "Why does Culture Matter? Recent Examples from Ukraine".

The video is available on Conference Youtube channel.

AgileByExample 2022: Andrii Gluschchenko & Artem Bykovets - Why Does Culture Matter?

Планував сьогодні написати якийсь гарний лонгрід чи описати мануал, але з відомих причин - на це не лишилось ресурсу та енергії. І тут на допомогу приходить широкий нетворкінг і круті професіонали з усього світу, контентом котрих також радий тут ділитись із вами 🙂

Цього разу ділюсь з вами свіжим (2 тижні від релізу) 15-хвилинним відео, котре просто, коротко, але повноцінно робить overview Scrum Framework з позиції Scrum команди від Peter Stevens (відомого в тому числі своїми виступами на українських конференціях).

Це чудовий контент як для початківців, так і для досвідчених Scrum-майстрів, Власників Продуктів і Девелоперів.

Inside The Scrum Team - Complete Inside the Scrum Team is basically a 1-day introduction to Scrum compressed into a 15-minute animated presentation. In Part 1, you’ll explore the reasons for...

Відповідаючи на питання учасника тренінгу, в черговий раз спробував сформулювати передумови для біль менш адекватного і не надто дисфункціонального використання Scrum Framework в аутсорсингових компаніях (з позиції ролі SM):

Pre-Conditions для Скрам в аутсорс:
1) Time & Material contract - is a MUST. (при fixed scope+time+budget - у вас практично відпадає сенс проводити Sprint Review та Sprint Planning зустрічі, адже скоуп відомо наперед і зафіксовано, а за його зміну в залежності від фідбеку чи нових зʼясованих елементів контексту - ніхто не похвалить, бо це створить багато «зайвих проблем». Також оптимізаційні цілі і KPI менеджменту в таких проектах конкурують із самою ідеєю використання емпіризму та ітеративно-інкрементальної продуктової розробки… без T&M формату - буде боляче😭)

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

3) Чітко розділяти коли ти працюєш, як SM продуктової розробки, а коли ти працюєш, як один з менеджерів аутсорсингової компанії. І відповідно функціонувати. (тут головне чітко розуміти цілі та задачі кожної з ролей, її стейкхолдерів та сервіси для кожного. Може допомогти візуалізувати в два списки функцій і проаналізувати де вони перетинаються, а де конфліктують. Ну а далі, головне вчасно переключатись, робити це зрозуміло та прозоро для колег і не спіймати шизофренію🤪)

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

Я працював в такому аутсорсингу і можу сміливо заявити, що це був один із найкращих та зрілих прикладів впровадження Agile (Scrum at Scale + XP практики), які доводилось бачити і розвивати. Все можливо, якщо знаєш куди ведеш людей та не боїшся пробувати ;)

п.с.: буду радий почитати ваші думки на тему в коментарях та про ваш досвід (як успішний, так і не дуже)📞