Як мені боротися з контрпродуктивною командою scrum?

Попередня історія:
Я працював у складі цієї команди останні три роки, і за цей час у нас було три різних майстра Scrum, які все керували різними справами.

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

Зараз члени моєї команди дратуються і нудьгують, коли ми робимо події Scrum, і одна людина, зокрема, є дуже словесною.

Сьогодні:
Два місяці тому компанія призначила мене Scrum Master у своїй команді через мою відданість працьовитості та її принципам.

Я сильно страждаю під атмосферним тиском небажання членів моєї команди робити Scrum.

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

Для них планування - це лише марна трата часу, тому що ми просто переходимо в новий спринт і не завершуємо роботу все одно, чому б це турбувати.

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

Щоденний Scrum - це знову лише марна трата часу, тому що ніхто з них не заважає говорити і планувати день. Вони просто заявляють: "Я працював над завданням X вчора, і над цим знову працюватиму сьогодні". І більшість часу вони просто жартують навколо, поки я не стану більш суворим.

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

Сьогодні людина, яка завжди проти мене, сказала мені, щоб перестати говорити "Вони сказали, що це те, що вони зобов'язані для цього спринту", тому що, за його словами, "ми ніколи не завершуємо спринт. Ми просто рухаємося в завданнях і беремо нові в наступний спринт для заповнення квоти. Ми робимо KanBan насправді. Тож перестаньте це говорити ".

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

Вони звикли прокляти, але за останні два роки їх готовність знизилася до більш-менш скельного дна.

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

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

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

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

Підводячи підсумок, перестаньте зосереджуватися на Scrum і замість цього поверніться до основ спритності. Ви можете почати з самого початку, з маніфесту спритності : Цінність людей та взаємодії над процесами та інструментами.

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

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

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

Ретроспективний процес - це те, чому, якщо ви відвідуєте всі команди в компанії, яка добре рухається, вони роблять це дещо інакше. У нас є кілька команд, які роблять Kanban, деякі, які роблять XP, деякі, які займаються лише складанням понеділка в середу, п'ятниця.

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

Гаразд, почнемо грубо - велика частина проблеми з вами - Ви чуєте, але ви не слухаєте. Ваша команда чітко розповідає, в чому проблеми. Ви повинні звернутися до них, а не звинувачувати свою команду.

Планування

Для них планування - це лише марна трата часу, тому що ми просто переходимо в новий спринт і не завершуємо роботу все одно, чому б це турбувати.

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

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

Рішення : виправте свої оцінки за допомогою комбінації:

• Історія (як поєднання часу та ризику).
• Не допускайте виконання завдань у спринті, який становить> 55 SP
• Порівняльні оцінки
• Планування на основі доказів

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

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

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

Якщо ви раніше не використовували SP, то моя порада - почати з 1 години справжньої чесної роботи бога = 5SP як орієнтиру. Майте на увазі, що у звичайних умовах розробки ви отримаєте, можливо, 6 таких на день, тож 30SP / день макс . Ніколи не допускайте виконання завдання, яке займає більше 2 днів, щоб потрапити на дошку. В ідеалі, на мій досвід, ви повинні мати 2 завдання на день.

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

Ретроспектива

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

Нагадує про Daily beatings will continue until morale improves!та дві минулі роботи. Якщо ви не усунете перешкоди, то вони вірно вважають, що це марна трата часу.

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

Тому:

• Розгляньте шість капелюшних методів для поліпшення спілкування.
• Скоротіть час, витрачений на ретроспективу, максимум на 30 хвилин.
• Переконайтеся, що скарги, подані під час Ретроспективи, розглядаються до наступної.

Щоденні СКРУМИ

Щоденний Scrum - це знову лише марна трата часу, тому що ніхто з них не заважає говорити і планувати день. Вони просто заявляють: "Я працював над завданням X вчора, і над цим знову працюватиму сьогодні". І більшість часу вони просто жартують навколо, поки я не стану більш суворим.

Здається, що у вас тут є дві проблеми: засідання SCRUM занадто довгі, а ваше планування та створення завдань відстійне.

І те, і інше може звучати, як зустріч з сутичками, це марна трата часу.

Для довжини SCRUM:

• Спробуйте максимум 15 хвилин.
• Спробуйте всі встати.
• Фіксована формула:
  • Що ви робили вчора.
  • Що ви плануєте сьогодні.
  • Що члени вашої команди (а не ви!) Повинні знати про завдання, як воно вплине на них.
• Не турбуйтеся з перешкодами, якщо ви не збираєтеся їх вирішувати.

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

• Розбийте завдання на точки кулі.
• Переконайтеся, що завдання є невеликими, щоб зайняти менше доби. В ідеалі, ІМО, завдання повинно тривати ~ 3 год і еквівалентно приблизно 13 СП, тому ви можете робити 2 на день у більшості умов.

Справа з командою

Сьогодні людина, яка завжди проти мене, сказала мені, щоб перестати говорити "Вони сказали, що це те, що вони зобов'язані для цього спринту", тому що, за його словами, "ми ніколи не завершуємо спринт. Ми просто рухаємося в завданнях і беремо нові в наступний спринт для заповнення квоти. Ми робимо KanBan насправді. Тож перестаньте це говорити ".

Він правий. Ви неправі. Ви робите скандальний SCRUM та / або варіацію на Kanban. Зовсім не їхня вина.

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

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

Вони просто роблять роботу замість того, щоб мати справу з перешкодами.

І тут я подумав, що робота - це те, про що йдеться. Цікаво, хто мав справу з перешкодами .... о так. Майстер Scrum. Це ваша робота. Вони говорять вам, що не так. Ви це виправляєте. Не навпаки.

Це, мабуть, тому у вас стільки проблем у "Ретроспективі".

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

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

Помішайте на жарт - як у роботі зі своєю командою, а не проти. (Кого піклується про гроші компанії? Ти зараз акціонер?)

Узагальнити

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

Покращіть своє планування, і ви покращите потік та стан моралі.

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

Найголовніше: слухайте своїх людей. Вони вже сказали вам (і мені) в чому проблема.

Щасти!

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

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

Також ви порушуєте один із принципів у гнучкому маніфесті : "Індивіди та взаємодія над процесами та інструментами".

З іншого боку, якщо ваша команда вважає, що ітеративний розвиток поганий, то, можливо, ви робите це неправильно. Не має значення, якщо ви не закінчите все, що планували за одну ітерацію - завжди можете перемістити речі на наступну ітерацію. Ось чому ви позначаєте речі як "має містити", "приємно мати" і т. Д. Поки ви надаєте нові функціональні можливості, ви робите це добре.

Лише невелика зухвалість: у моїй попередній та нинішній компанії ми проводили і досі робимо стендап-зустрічі. З мого досвіду, це велика марнотрата часу, оскільки щоразу вони перетворюються на 30+ хвилин засідання звіту про стан, і мені надають мало інформації, що не має ніякої інформації. Люди говорять про свої проблеми, що, чесно кажучи, мені не байдуже.
У моїй попередній компанії вони були розумними, визнавали цю проблему з рейтингами, і зупинили їх незабаром після того, як люди почали скаржитися.

Якщо вам подобається подивитися дійсно гарне відео про скрам, дивіться " Роберт К. Мартін - Земля, яку забув Scrum ".

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

Далі, ров все, що не працює. Процес без значення - це лише злодій часу. Стандії можуть зайняти величезну кількість часу, якщо він не зосереджений і не надає цінності команді. Години, можливо, краще провести в іншому місці. Можливо, також варто подумати про розбиття команди, якщо вона занадто велика.

Спробуйте зрозуміти, що демотивує команду. Майте ретроспективи і, що ще важливіше, дійте на виході. Не менш важливо святкувати успіхи, а також дивитися на невдачі.

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

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

Команда повинна сприймати це, хоча розробникам бути дуже реалістично щодо оцінок може бути дуже важко - я працював над командою, яка не закривала спринт протягом року (постійно закриваючи менше 50% спринту) , завжди за оцінкою, і в кожному плануванні / ретроспективі я був самотнім голосом, який говорив їм, що ваші оцінки відсмоктуються, ви нерозумно перестарели, перестаньте виправдовуватися за те, що заважало вам зробити оцінку, і замість цього скоригуйте оцінку так, щоб вона відображала реальність ( можливо, більш дипломатично, ніж це, але це було основним настроєм) - Коли ви на цій посаді, я б цілком погодився з куркучем вашої команди, який каже, що процес є марною тратою часу, оскільки ви насправді займаєтеся KonBon, незалежно від як ви це називаєте. У певний момент його думка стає підтвердженою обставинами. Це '

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

Змусити людей скуповуватись на значно різний спринт (з точки зору кошторису, планування, зобов'язань) - це важко, в цій команді я, зрештою, досягнув цього через два фактори. Один тільки збирав дані від JIRA і казав: "немає виправдання для цього, номери відключаються, вони завжди відхиляються в одному напрямку. Нам потрібно це виправити, я не хочу виправдання в ретро, ​​я хочу цифри, які потрібно скласти ", - а інший був тиском з боку вищого керівництва, який я врешті-решт пояснив їм як ..." Сенс цього процесу полягає в тому, щоб зробити наш графік розвитку передбачуваним. Якщо ми виконаємо постійний обсяг роботи кожен спринт, що чудово, незалежно від цього, нашій раді потрібно точно відображати те, що ми робимо. Керівництво більше усвідомлює наш успіх відносно зобов’язань, ніж насправді насправді, заради себе, складіть прогнозний ряд у відповідність з результатом, щоб було схоже, що ви робите свою роботу, а не витрачаєте половину кожного спринту нічого не робити. Чим далі віддаляються люди з цього часу, тим більше вони просто бачать, що ти провалюєшся, оправдання, яке ти робиш у ретро, ​​- це навіть щось не в їхньому розумінні, вони просто бачать, що ти зазнаєш невдачі ".

Врешті-решт наша команда отримала тягу, і все почало проходити набагато плавніше і низько, і ось ми навіть почали мати більш високий результат, як тільки процес почав працювати. Тому tl; dr - робіть все необхідне, щоб почати закривати спринти з відносно високим ступенем успіху. Якщо ви цього не зробите, куркуляр у вашій команді продовжуватиме чинити опір Scrum за результатами, і в кінцевому підсумку буде правильно, що ваш процес насправді є лише шахрайством і марною тратою часу.

Як майстер Scrum, ви тренуєтесь та керуєте командою для підвищення продуктивності. Рамка Scrum - це потужний інструмент, щоб потрапити туди, але рамка Scrum абсолютно ніколи не повинна сама ставати ціллю - інакше ви робите Cargo Cult .

Здається, ти вже 3 роки займаєшся «Cargo Cult», і люди зрозуміли, що це жахлива методологія управління проектами. Хороша новина - у вас розумні люди , вони правильно зрозуміли. На жаль, деякі люди у вашій компанії називають це Scrum, але, знову ж таки, у вас розумні люди , вони навіть розповіли, що робить команда, не називається Scrum.

Планування - це лише марна трата часу, тому що ми просто переходимо в новий спринт і не завершуємо роботу все одно, чому б це турбувати.

Саме так. Навіщо турбуватися? Вам потрібно знайти відповідь, а точніше, вам потрібно змінити планування та сам спринт, щоб було сенс у плануванні. Або це, або перестаньте даремно витрачати час на безглузде спринтерське планування. Ви можете попросити компанію відправити вас на тренінг Scrum Master, адже проведення чудового спринтського планування не є банальним.

Під час ретроспективи [...] інші мовчать, і мені доводиться стикатися з цим щоразу.

Якщо ви маєте справу з однією і тією ж проблемою кожну ретроспективу, люди навіть не намагаються (більше?) Говорити під час Ретроспективи, це лише марна трата часу. Якщо ви чи команда не зможете якось вирішити питання, порушені в "Ретроспективі", зустріч - це лише деморалізація команди. Питання, порушені в ретроспективі, мають бути вирішені, а наступна ретроспектива має бути досягнута.

Щоденний Scrum - це знову лише марна трата часу, тому що ніхто з них не заважає говорити і планувати день. Вони просто заявляють: "Я працював над завданням X вчора, і над цим знову працюватиму сьогодні".

Справді, навіщо турбувати витрачати час на всіх, якщо вони просто працюють над одними і тими ж завданнями кілька днів? Вони абсолютно правильні, що Daily Standup дійсно безглуздий. Standup сприяє тісній співпраці з багатьма завданнями, кожне з яких може бути виконано за півдня або менше. Якщо ваші завдання не можуть бути розбиті таким чином (через зламане спринтерське планування або через те, що ваші завдання насправді не вписуються в Scrum), не існує великого сенсу проводити 5-хвилинну щоденну зустріч standup (це не довше 5 хвилин, правда?).

"Ми ніколи не завершуємо спринт. Ми просто рухаємося в завданнях і беремо нові в наступному спринті, щоб заповнити квоту. Ми робимо KanBan насправді. Тому перестань говорити це".

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

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

Що ви можете зробити з цього приводу?

1. Вислухайте їхні занепокоєння. Знову ж таки, ти благословен у тому, що у тебе розумні люди .

2. Допоможіть їм вирішити перешкоди.

І це все, насправді. Вам знадобиться поекспериментувати з тим, як змінити планування спринту, щоденну Scrum і ретроспективу, щоб зробити їх цінними для команди - навіть якщо ви хотіли скинути етикетку Scrum, у вас все одно є ці 3 зустрічі з однаковою частотою та подібною метою у всіх інших методологія управління проектами там. Що стосується того, як ви будете експериментувати (частота, вміст, хто проводить зустріч, час, тривалість тощо), це напрочуд просто: Запитайте команду. Не примушуйте своїх ідей до них, якщо що-небудь вам слід дозволити їм нав'язувати свої ідеї на вас (якщо вважати, що вони можуть погодитися на деякі).

Якщо ви боїтеся втратити контроль, заздалегідь встановіть деякі межі, наприклад:

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

Я думаю, що всі цитують один і той самий рядок з " Маніфесту Agile" . Я зроблю те саме: "Індивіди та взаємодія над процесами та інструментами".

Якщо ви як майстер SCRUM хочете потім використовувати SCRUM для виконання завдання, ви повинні підходити до них як до однієї особи, яка взаємодіє з іншою. Почніть мозковий штурм, як покращити процес. Можливо, ви можете переконати їх, що вони люблять SCRUM. Можливо, вони можуть переконати вас використовувати інший процес. Давай дізнаємось!

Здається, що команда вже визнає, що нинішня система не виконує завдання. Чи можете ви заохотити їх повірити, що це може зробити цю роботу? Ви згадуєте кілька прикладів. Якщо ви переповнюєте спринт, щоб він завжди протікав ... зупиніться. Це ваша команда SCRUM. Допоможіть їм припинити зайві дії. Натисніть на управління, щоб отримати кімнату для дихання. Використовуйте SCRUM для того, для чого це добре. Використовуйте його, щоб представити дані керівництву, що вони наполегливо наполягають, щоб вони втрачали цінність свого процесу. Якщо керівництво хоче SCRUM як процес, знайдіть їх, щоб допомогти створити простір та енергію, необхідну для його виправлення. Як майстер SCRUM, ваше завдання - вирішити проблеми, щоб команда могла бути продуктивною.

Ще одним корисним підходом може стати нерест нового процесу в межах старого. Продовжуйте працювати SCRUM таким же марним способом, але обмежте невелику частину розкладу і скажіть: "У цій частині нашого розкладу ми розберемося, як правильно використовувати інструменти". Не займіться там. Використовуйте свої показники. Зосередьтеся на всіх своїх зустрічах там. Тільки що залишилася частина вашого проекту "СКРУМ" як щит, щоб підтримувати управління щасливим, поки ви та ваша команда "[розкрийте] кращі способи розробки програмного забезпечення, роблячи це та допомагаючи іншим робити це". З часом вам захочеться ставити все більше і більше ваших ціннісних завдань у це відро, і старе відро буде повільно вмирати. Незабаром у вас з'явиться яскраве середовище розробки програмного забезпечення, і ніхто не мудріший.

Або змішайте і зрівняйте їх. Я працював над програмою, яка була анти-scrum. Клієнти хотіли мати можливість додавати нові завдання в будь-який момент процесу і змусити нас діяти над ними негайно. (Це насправді було розумним запитом: їхня робота була дуже мінливою, і їм часто потрібна швидка підтримка ... саме за це нам і заплатили). Звичайно, нам довелося розібратися, як боротися з їхніми питаннями "чому X не робиться, коли ти обіцяв це у спринті". Нашим рішенням було насправді побудувати двоступеневий процес. Довгострокові завдання були поставлені до SCRUM для належного визначення пріоритетності. Короткострокові завдання були поставлені в домашньому процесі, який зосереджувався на тісній взаємодії між клієнтом і розробником. Було зрозуміло, що клієнти можуть натиснути на нас за допомогою цього короткотермінового процесу, але вони зрозуміли, що так натискають на спринт " s, і їм заборонялося додавати запити, не одночасно чуючи та вирішуючи проблеми, які вони викликали. Результат? Це спрацювало. Більшість завдань було поставлено в процесі SCRUM, як і належить, і надзвичайні ситуації з ними безперебійно взаємодіяли. Таке ставлення було: "Якщо ви хочете бути замовником, будьте в черзі за історією SCRUM. Якщо ви хочете бути партнером, не соромтесь сходити і працювати з нами на щоденному рівні та змусити цей продукт працювати ! "

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

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

Через цю зміну Scrum Masters та їх спосіб вести шоу

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

Мені цікаво, звідки береться команда. Можливо, вони були більш-менш автономними, перш ніж Scrum (включаючи неминучого майстра Scrum) був скинутий на них? Чому Scrum був представлений в першу чергу? Що воно мало вирішити?

Scrum повинен забезпечувати керівництво, і ваша команда дає зрозуміти, що вони не вважають це корисним в жодному разі. Їм не байдуже керівництво, вони вважають це недоцільним марнуванням часу. Мабуть, принаймні один, хто приймає рішення, вважає, що їм потрібно керуватися. Хто? Чому? У них є крапка?

Ця проблема не обмежується програмним забезпеченням.

У будь-якому робочому середовищі знайдуться різні люди з різними особистостями та здібностями. Навіть якби Scrum був ідеальним методом, все одно були б люди проти цього через їх особистість та здібності.

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

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

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

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

Вони звикли прокляти, але за останні два роки їх готовність знизилася до більш-менш скельного дна.

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

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

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

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

У моєму випадку я особливо страждав під пунктом 5. В основному, scrum ставився до мене як до дитини та до невдахи. Зараз я є винахідливим співавтором, який допомагає своїм колегам ... не дивно, що б я віддав перевагу!

У мене зараз новий босс, який просто ходить і розмовляє з людьми, і я настільки вдячний за це! Частина, чому це працює, полягає в тому, що ми також маємо кімнату чату (ми використовуємо найважливіше) для спілкування між розробниками. Якщо хтось має порядок денний, ми приймаємо його там. Зустрічі призначені лише для спеціальних обговорень розробників, а не для встановлення штучних щоденних строків.

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

Змінити методологію важко

Це величезний виклик в робочій області, адже ви працюєте за інерцією "так ми робимо справи", і проти тиску термінів і бізнес-потреб.

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

Я настійно рекомендую Роя Ошерове на цю тему. У нього є короткий підсумок того, як планувати та впливати на зміни у вашій компанії , і він детально розглядає тему у цьому відео .

Основне зауваження Ошерово полягає в тому, що необхідно вирішити всі наступні виклики:

Особиста мотивація: Чому хтось повинен піклуватися про те, щоб поводитися конкретно?
Особисті здібності: чи можуть вони це буквально зробити?
Соціальна мотивація: чи існує така поведінка з боку тиску для такої поведінки?
Соціальна здатність: Чи підтримують мене оточуючі люди мою поведінку та допомагають мені, коли мені потрібна допомога?
Структурна мотивація: Чи є винагорода \ покарання за добру \ погану поведінку?
Структурна здатність: Чи підтримує фізичне середовище таку поведінку?

Вам потрібно навчитися ламати завдання вниз

Ваша команда вважає, що "я працювала над завданням X вчора і над цим знову працюватиму сьогодні", і вони здаються правильними, в тому сенсі, що завдання продовжують відштовхуватися тиждень.

Тут справді корисно - навчитися розбивати завдання на невеликі компоненти. Що ви шукаєте, це відповідь на запитання "Гаразд, ви працюєте над завданням X, але що конкретно у завданні X ви працюєте сьогодні ?"

Деякі відповіді можуть бути:

• Я вивчаю цей клас застарілого коду.
• Я виправляю помилку, симптоми якої є (СИМПТОМИ).
  • Якщо це якась помилка, яка триває певний час: "Сьогодні я спробую це ... (ПЛАН)"
• Мені потрібно змінити цей інтерфейс.
• Я пишу тести.
• Я інтегрую неперевірений код.

... і так далі, і так далі. Можливість спостерігати за тим, що ви насправді можете зробити за день або за тиждень, - одна з великих переваг Agile. Але це означає, що вам потрібно дивитися на вирішення окремих днів, а не на якусь монолітну задачу X, яка буде готова, коли вона буде готова.

Виконано проти доставлено

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

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

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

Отож, варто запитати себе: чи розробники встановлюють цілі спринту, відповідно до потреб та потреб, які вони насправді бачать? Або керівництво встановлює терміни, залишаючи розробникам намагатися скласти свої зобов’язання в спринт-графік?

Якщо розробникам не надається часу на планування речей або роботу за надійним планом, то не дивно, що вони не можуть зробити корисні оцінки. :)

Це може бути непопулярна думка, але ви, можливо, нічого не зробите з цим.

Я можу собі уявити, що за роки існування колективу та потоку лідерів виїхали люди, які були справді незадоволені колективом. У вас є залишки людей, які можуть скаржитися, але не зацікавлені в тому, щоб насправді докладати зусиль для покращення ситуації. Вони просто хочуть витратити свої 8 годин злому коду, нікого не перебиваючи і просто повернутися додому в кінці дня. Те, що ви маєте тут, здається серйозною проблемою мотивації. І вирішити цю проблему майстер scrum - не робота. Проблема того, хто платить цим людям.

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