Чи може статися вигорання при безперервному спринті Scrum? [зачинено]

У мене досить маленький стартап, і ми почали використовувати форму циклу розробки Scrum / Agile.

Багато в чому мені подобається Scrum. У нас відносно короткі спринти (2 тижні), і мені подобається Burn Down Chart, щоб відстежувати прогрес команди. Мені також подобається Дошка функцій, тому я завжди знаю, що мені робити далі. Це добре, коли знімаєш карточку об’єкта з дошки, заповнюєш її, а потім кладеш у спалену купу.

Однак зараз ми вступаємо у наш 18-й цикл випуску Sprint, і я починаю відчувати себе трохи згорілим. Справа не в тому, що я не люблю роботу чи своїх колег, просто ці спринти - це ... ну, спринти . Від початку до кінця я буквально відчуваю, що мчуся проти годинника, щоб підтримувати швидкість нашого розвитку. Коли ми закінчимо спринт, ми витрачаємо один день на планування набору функцій та оцінок наступного спринту, а потім знову йдемо.

Це нормально для людей, які працюють у зрілому процесі розробки Agile / Scrum? Або нам чогось не вистачає? Чи зазвичай є час у середовищі Scrum, який не призначений / відстежений, щоб виконати якісь дрібні справи та очистити голову?

Це відносно нормально і іноді може бути скаргою членів нашої команди, якщо проекти тривають протягом тривалого періоду часу.

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

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

Генрік Книберг має сказати:

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

http://www.crisp.se/henrik.kniberg/ScrumAndXpFromTheTrenches.pdf

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

• Завершіть спринт у п’ятницю вранці. Зробіть огляд спринту та ретроспективу вранці, і дозвольте команді решту днів попрацювати над іншим, щоб очистити голову. Візьміть план планування Sprint у понеділок.
• Ми ввели поняття "лабораторні дні". Це цілі дні, коли команду відбирають від проекту, і вони проводять цілий день, працюючи над вдосконаленням власних технічних навичок шляхом дослідження між собою та співпраці з певних технічних тем. Здебільшого вони не мають абсолютно нічого спільного з конкретним проектом і дозволяють членам команди думати про більш легкі теми.

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

Вони також можуть мати зображення значка Scrum поруч із визначенням вигорання.

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

IMHO, короткі 2 тижні Scrum слід забороняти, крім малих доз, не більше 4-8 поспіль. Використовуйте його як інструмент для виняткових або критичних речей, а не постійно. Використовуйте здоровий глузд.

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

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

Це точно допомагає мені не перегоріти.

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

Спринт - це не тире на 100 ярдів; це одна (випадкова) миля в марафоні, тобто темп, який ви можете витримувати нескінченно довго.

Ваша команда проводить ретроспективи в кінці кожного спринту? Це можливість команди "перевірити та адаптувати" свій процес? Як ScrumMaster, я регулярно прошу команду оцінювати, як "почувається" команда та як вони отримують задоволення. Ми досліджуємо, чому чи чому, і експериментуємо з коригуваннями та альтернативами.

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

Що стосується "... часу в середовищі Scrum, яке не призначено / не відстежується, щоб виконати деякі дрібні справи і очистити свою голову", зберігаючи прихильність команди на рівні x% від доступної потужності (бажано балів, але можна використовувати години за потреби; в будь-якому випадку я виявив, що щось у межах 60-70%, здається, є нормою) є ключовим фактором стійкості всередині Спринту, а випадковий "безкоштовний день коду" добре працює для зовнішніх Спринтів.

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

Я знаю деяких людей, чиї робочі дні складалися лише з двох з половиною годин спринту, а решта дня була зосереджена на різноманітних інших заходах: підтримка, звільнення технічного боргу, дослідження тощо. Швидкість їх розвитку була встановлена ​​відповідно.

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

Ви у вашому 18-му спринті !?

Враховуючи 2 тижні на спринт, це означає 36 тижнів безперервної роботи над одним проектом. Ви також коментуєте, що працюють близько 6 годин на день. Це звучить як багато!

Я не знаю так багато про гнучкі методології (хоча насправді ми використовуємо Scrum у нашому поточному проекті), але існує принцип щодо вашого робочого часу (я маю на увазі, скільки часу ви витрачаєте на виконання завдання) має становити 60% ~ 70%. Тепер, повторюючи цифри, якщо ваш робочий день триває 8 годин, а ви проводите 6 годин, ви дійсно витрачаєте близько 75% робочого часу. Це може бути невеликим відхиленням, яке нарешті призведе до того, що у вас виникне таке відчуття.

ОТОХ, я вважаю, що якщо ваш проект займе багато часу, спринти повинні бути більшими, не 2 тижні, але не місяць. Розгляньте криву донизу на діаграмі вигорання: Почніть спринт із звичайного прогорання завдань і зменшіть активність за останні 2 або 3 дні до закінчення спринту.

Agile - це не камінь із гравіруванням: «працюй швидше / сильніше / краще / важче», це більше схоже на блакитне небо з білими хмарами, на якому написано: «працювати приємно, красиво, продуктивніше». (трохи хаха на кінець люб'язно надано daft punk + radiohead).

Я цілком розумію, що ви говорите. Для тих з вас, хто каже "ваш темп занадто швидкий", я не впевнений, що згоден, що темп - це завжди проблема, коли люди згоряють в результаті цього процесу. Незважаючи на те, що відстеження всього вашого прогресу - це добре, це може бути і самим фактором стресу (і не відстеження може бути також), не тільки тому, що ваш начальник / прем'єр-міністр буде на вас, якщо вони побачать, що щось не відбувається за планом, але для себе. Просто наявність цієї зареєстрованої інформації - це те, що ЗМОЖИТЬ більшість людей працювати лише настільки важче, ніж ви зазвичай ВЕСЬ ЧАС, і я не впевнений, що більше часу на ваші оцінки часу це вирішить для всіх. Я не думаю, що мотиватор (як ваш графік вигорання) завжди позитивний.

Деякі люди не почуватимуться так, інші - так. Не існує ЄДИНОГО способу роботи, який ВІДПОВІДЕ всім. На мою думку, ніколи не буде.

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

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

Єдиний спосіб для вас стати більш ефективними (працювати і з тиском) і робити менше роботи - це змусити когось зробити цю роботу або автоматизуючи її.

На мою думку, завжди слід переглядати ті процеси і бачити, що можна автоматизувати, і витрачати час на автоматизацію ваших процесів. Автоматизація коштує за додаткову роботу замість того, щоб робити «справжню роботу», але незалежно від того, наскільки маленьким автоматизованим завданням ви завжди отримаєте прибуток у довгостроковій перспективі. ЗАВЖДИ! Якщо не один день, то через два. Не один місяць, два. Не один рік, а два роки. Ви зрозуміли ідею.

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

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

Сталий темп є ключовим принципом спритності. Виконуючи практики управління (SCRUM) разом з інженерними (XP), команда може проводити спринт за спринтом необмежений час. Однак, оскільки можна, не означає, що потрібно.

Здається, вам потрібна зміна на тлі нескінченної серії спринтів, яку ви бачите перед собою. Можна запропонувати ряд варіантів. Кожну X кількість спринтів член команди (або пара) може відхилити від команди. Під час вашої ротації ви можете підтримати команду бігу, взяти заняття, зосередитись на наборі шипів, взяти відпустку тощо.

Якщо у команді 5 пар, і ви повертаєте людину з лінії, людина може виконувати ротацію кожні 10-й спринт (якщо одиночна людина) або кожну 5-ю ітерацію (якщо пара). Питання бюджету та рентабельності інвестицій для вашої діяльності повинні бути вирішені вашим керівництвом та / або діловим партнером. Але очевидно, що деякий час, щоб "заточити пилку", принесе користь команді, таким чином, проекту. Підтримувати команду свіжою та зосередженою - це дуже добре. Але ми повинні пам’ятати, що нам платять, і нам потрібно принести користь за зароблені долари.

Я думаю, вам чогось не вистачає, але ви не єдиний. Як каже Джим Хайсміт: "Швидкість все частіше використовується як показник продуктивності (а не міри калібрування потужності, якою він передбачався), який зосереджує занадто багато уваги на обсязі переданих сюжетів".

Я гадаю, саме це відбувається з вашою командою. Я рекомендую прочитати цей основний допис Хайсміта IMHO: Швидкість - це вбивство спритності!