People's Scrum - выявлять препятствия, делая меньше (про вред оценки задач в часах) | Agile тренинги, обучение и сертификации Scrum, Kanban, DevOps в Scrum Украина
 
Стаття відображається оригінальною мовою.

People's Scrum - выявлять препятствия, делая меньше (про вред оценки задач в часах)

Глава из издаваемой нами книги "People's Scrum" Тобайаса Мэйера на русском и украинском в соавторстве с Алексеем Кривицким

27 черв. 2021

Издание книги

Мы, Scrum Ukraine, издаём книгу Тобайаса Мэйера "People's Scrum" на русском и украинском в соавторстве с Алексеем Кривицким.

Вы можете подписаться на уведомления о выходе книги уже сегодня и быть первым, кто получит к ней доступ!

Выявлять препятствия, делая меньше

Зачастую новым командам тяжело артикулировать препятствия, а скрам-мастера с трудом определяют виды вопросов, которые нужно задать участникам команды для идентификации препятствий.

Я не думаю, что фокус на постановке вопросов поможет с этим. Считаю, что более эффективно сосредоточиться на создании атмосферы очевидности и честности. Доски рабочих процессов помогают нам в этом, но сами по себе этого не достигнут. Иногда бывает нужна оплеуха.

Самым большим затруднением для идентификации препятствий, которое мне удалось выявить, служит практика измерения задач часами рабочего времени и обновления этих часов на каждой встрече. Фундаменталисты из числа практиков скрама посмотрят на меня косо, когда я скажу, что это всё не имеет смысла.

Несколько лет назад в роли скрам-мастера я принял одну команду, которая практиковала скрам «по книге» (по их словам). Все они ненавидели стендап-митинги, и в особенности, это обновление часов. Они чувствовали, что их измеряют на микроуровне, что нужно просто доверить им выполнение своей работы, что это оскорбительно, а заниматься этим означает тратить время впустую. Что ж, поскольку я склонен доверять скорее интуиции, нежели метрикам, я был рад удовлетворить эту просьбу. В наши дни изменения самого скраму не одобряются [благодаря изобретению уничижительного термина «скрамно» (scrumbut), означающего «мы практикуем скрам, но не выполняем X»], но в первые дни у нас было больше культуры экспериментирования в духе «инспектировать и адаптировать». Я подумал, что мне все еще позволено называть тот процесс скрамом, и это было важно для той конкретной корпоративной культуре.

Мы договорились, что задачи не будут оцениваться часами при том условии, что все задачи будут достаточно небольшими, чтобы их можно было выполнить за один день. Это последнее условие очень важно. Благодаря такому изменению процесса мы обнаружили, что когда задачи не выполнялись за один день, это указывало на препятствие, о котором никто не подумал упомянуть или даже не смог признать препятствием. Сейчас некоторые из этих «препятствий» очень крошечные, например, «мы думали, что задача была проще», поэтому решение состоит в том, чтобы разбить задачу на более мелкие части и дать обязательство выполнить меньшую задачу на следующий день. Однако другие препятствия, которые таким образом оказываются на поверхности, могут указывать на более серьезную проблему.

Например, команды отставали, а у одного разработчика была задача, в течение трех дней стоявшая в колонке незавершенной работы (WIP) на доске. Спустя один день он сказал, что все почти готово и даже чуть больше, чем он ожидал. Мы отметили ее красной точкой (эта отметка красной точкой дает немедленную визуальную индикацию заблокированных задач). Спустя два дня он сказал, что у него не было времени завершить работу. Это вызвало некоторое недоумение. Почему не было времени? Выяснилось, что этого конкретного разработчика часто отзывали для исправления ошибок в другой части кода. Это не имело ничего общего с проектом, над которым он работал, и ранее не обсуждалось на совещании по планированию. Никто из участников команды не считал это препятствием, поскольку «просто так мы тут все делаем». Очевидно, что-то должно было измениться.

Эта проблема не всплыла бы так быстро, не будь у нас правила «однодневной задачи». Процесс измерения объектов на микроуровне с намерением создания наглядности фактически служит сокрытию важной информации.

Припоминаю еще одну команду, с которой я работал (там применялся электронный инструмент для отслеживания задач), где разработчики сокращали часы работы над всеми задачами, которыми занимались, даже если знали, что сделали там не слишком много работы. Все они были заинтересованы в том, чтобы диаграмма сгорания задач действительно сгорала и не чувствовали себя в безопасности, говоря, что размер задачи остался таким же или даже вырос. К концу спринта почти на каждую из задач оставалось около часа, довольно мало из них были полностью закрыто, и не было сделано ни одной истории полностью. Это убедило меня в необходимости бинарного измерения. Задача либо выполнена, либо нет. Задача, на которую остался один час, не выполнена.

Прекратив измерять частично выполненную работу и измеряя только завершенные вещи (задачи и истории), сотрудники команды смогли лучше понять, на что они реалистически могут решиться и одновременно создало атмосферу честности и доверия. Кроме того, стало намного проще идентифицировать препятствия, мешавшие им выполнить задачи (обычно на протяжении 24 часов или менее).

Начиная с 2005 года я отговорил все команды, с которыми работал, измерять и отслеживать выполненную работу в часах. Применение правила «однодневного задания» очень быстро выявит препятствия и дисфункцию. Кроме того, оно позволит вашим разработчикам сосредоточиться на работе, а не на цифрах. Конечная цель — полностью отвлечься от этих задач и сосредоточиться на реальном запросе. Сами по себе задачи имеют нулевую ценность: они всего лишь шаги в этом путешествии. История или запрос — это тот артефакт, который действительно интересует клиента.

Скрам требует серьезного сдвига в мышлении и поведении. Освободившись от мысли, что почасовые измерения так или иначе необходимы или полезны, вы сделаете большой скачок к вашему Agile-прорыву.

Комментарии Алексея Кривицкого

Как лаконично Тобайас смог описать то, с чем я борюсь уже хороших 10 лет. Я называю это заболевание "иллюзией контроля" - практики, которые как бы помогают лучше вести проекты и точнее управлять работой, но при небольшом их анализе сразу же становится очевидно, что никакого положительного влияния ни на выполнение работы, ни на ответственное поведение людей они не оказывают.

Оценки задач в часах, отслеживание выполнения работы и зависимостей на диаграммах Ганта, требования "комитмента" от команды выполнить кровь из носу весь план спринта, отслеживание загрузки каждого участника команды, личные цели, индивидуальные планы, и т.д. Всё это - популярные практики менеджмента, которые устарели ещё до моего рождения (а я 1980 года выпуска), и вообще никогда не были применимы к людям, работающим над креативной работой.

Задача современного менеджера, и скрам-мастер относится к этой категории экспертов, - строить социальные системы, которые силой простых социальных правил, формируют ожидаемое положительное поведение людей по отдельности и группы в целом.

Поясню. К примеру, когда каждый член команды подотчётен одному микроменеджеру, который ставит задачи и проверяет их выполнение - это не цельная социальная система, это просто N отношений "работник-микроменеджер", которые очевидно полностью зависят от компетентности этого самого микроменеджера. Такая система не масштабируется, не развивается и упирается в когнитивные способности одного человека. Тут никакого волшебства спонтанного прорыва и синергии никогда не произойдёт. Они либо сделают проект, либо нет - с вероятностью 50 на 50.

Социальная система, способная на решение челленджей и время от времени удивляющая окружающих магическими прорывами - это такая группа людей, которые подотчётны друг другу, сплочены некоторыми невидимыми силами и где возможна спонтанная дискуссия между её равными участниками в роде такой: "Петя, что там с твоей задачей? Ты обещал час назад закончить? Нам уже пора двигаться дальше с этим. Чем я могу помочь? Иду к тебе, посидим вместе."

Так работает Скрам-команда с большой буквы, где вещи происходят, потому что людям не всё равно, и их отношение к работе при этом катализируется социальными силами: общие обещания, peer pressure, безопасность сказать "мне нужна помощь", коллективные договорённости, понятные сроки, реалистичные планы, участие в создании этих самых планов и сроков и т.д.

Чтобы сделать прорыв своих менеджерские практик и стать макроменеджерами, подумайте вот о чём - какие поведения вы хотели бы видеть у людей внутри ваших команд и в организации в целом?

И после того, как вы поймёте для себя, какую социальную систему вы хотите построить, начните наблюдать и экспериментировать с окружением для команд и процессами - что создаёт эти поведения, а что нет. И вы очень быстро увидите, что многое, что кажется общепринятой практикой управления, вообще не даёт никакого положительного отклика.

Рекомендовані заходи

тренінг
Дмитро Незабитовський  

Дводенний курс з основ Agile і фреймворками Scrum і Kanban. Курс сертифікаційний, по його закінченню учасники отримують іменні сертифікати ICAgile Certified Professional - Agile Fundamentals (ICP).

тренінг
Євген Лабунський  

Дводенний поглиблений клас присвячений фасилітації. Курс сертифікаційний, по його закінченню учасники отримують іменні сертифікати ICAgile Agile Team Facilitation (ICP-ATF Certified professional).

тренінг
Олександра Баптизманська, Євгенія Чумачкова  

Дводенний поглиблений клас присвячений фасилітації. Курс сертифікаційний, по його закінченню учасники отримують іменні сертифікати ICAgile Certified Professional.

Рекомендовані статті

Зачем нужна сертификация специалистам, которые работают в Agile?

На связи Дмитрий Незабытовский. Я аккредитированный и действующий ICAgile Instructor и Advanced Certified ScrumMaster® (A-CSM) от Scrum Alliance. Практикующий ScrumMaster в продуктовой компании Terrasoft (Creatio).
В этой статье хочу поделиться с вами треками развития Agile специалистов начиная …

Что происходит в мире Agile в 2021 году?

Intro

Буквально пару недель назад (12 июля 2021 года) был опубликован очередной State of Agile Report под номером “15” от компании Digital.ai Agility (прежде VersionOne). Это уже 15-ый отчёт по счёту с 2007 года. В мире практикующих аджайлистов, последние годы, уже стало хорошей традицией …

Как осознанно и системно развивать процесс Scrum команды?

В любой Scrum команде существуют области для улучшений в процессе, которые часто можно подправить применив Kanban-метод. Другими словами, посмотреть на Scrum процесс через Kanban-линзу, переложить особенности процесса создания ценности на формальные правила, цифры, метрики, и графики. Таким …

Ми активні в соціальних мережах і хочемо спілкуватися. Додавайтеся на нашу сторінку в facebook та приєднуйтесь до наших спільнот.

Із питань корпоративних програм:

+380 93 4974661
hello@scrum.ua

З приводу тренінгів, реєстрацій, рахунків:

+380 95 7402380
hello@scrum.ua

За всіма номерами телефонів - голос і telegram.

©2017 - 2021 Scrum Ukraine. Всі права захищені.

Політика конфіденційності