Радикальная откровенность для Скрам-мастера

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

Овчарки и болонки

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

  • рисуют красивые флипчарты;
  • клеят стикеры;
  • передают микрофон на “демо”;
  • поддерживают Скрам-доску в актуальном состоянии;
  • заводят “тикеты” в Jira;
  • решают административные задачи, которые им “слили” менеджмент и команда;
  • координируют зависимости.

Когда Скрам-мастера болонки, а не овчарки, они не выполняют основную функцию:

Скрам-мастер отвечает за продвижение и поддержку Скрама, как это определено в Руководстве по Скраму (Руководство по Скраму)

Когда Скрам-мастер не бросает открытый вызов командам, менеджменту и организации, он становится бесполезным. Скрам-мастер это не просто командный коуч и фасилитатор. Многие эффективные Скрам-мастера, которых я знаю, как раз не самые выдающиеся фасилитаторы и коучи. Но они обладают другим — сердцем льва и желанием сражаться с организационными дисфункциями, отстаивая принципы и ценности Скрама. Хороших Скрам-мастеров часто не любят в организациях. Они “путаются” под ногами и не соглашаются с менеджментом, задают неудобные вопросы и не позволяют переходить границы Скрама. 

Мой опыт подсказывает, что хорошие Скрам-мастера получаются из зрелых людей с четкой жизненной позицией и крепким внутренним стержнем. 

А еще они практикуют радикальную откровенность.

Читать далее «Радикальная откровенность для Скрам-мастера»

Пример цепочки освобождающих структур для знакомства участников

Знакомьтесь, это Барри (справа), один из команды The Liberators. Барри (Barry Overeem) и Кристиан  (Christiaan Verwijs) — пионеры немецкого сообщества освобождающих структур. Ребята не просто развивают освобождающие структуры, но и делают это в организациях и командах, которые работают по Скраму.

Читать далее «Пример цепочки освобождающих структур для знакомства участников»

Из первых уст. Инсайты с конференции Liberating Structures European Gathering, Hamburg, August, 2019

Привет! Маленькая мечта сбылась: познакомилась с создателями освобождающих структур на конференции Liberating Structures European Gathering!

Конференция,  больше похожая на митап, проходила 8-9 августа 2019 в Гамбурге. Я ехала подготовленная — у меня было много вопросов к создателям освобождающих структур Генри Липмановичу (Henry Lipmanowicz) и Кейту МакКэнделсу (Keith McCandless).

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

Читать далее «Из первых уст. Инсайты с конференции Liberating Structures European Gathering, Hamburg, August, 2019»

Скрам-мастер: умелый фасилитатор

Перевод оригинальной статьи Рафаэля Саббаха «Scrum Master: The Skilled Facilitator«

В книге «Умелый фасилитатор» (2002 г.) Роджер Шварц определяет групповую фасилитацию как

«процесс, в котором человек, чья кандидатура принята всеми участниками группы, занимающий нейтральную позицию, не влияющий на процесс принятия решений, выступает диагностом и помогает группе улучшить работу над проблемами, процессом принятия решений, способствуя повышению эффективности взаимодействия»

На основе этого определения Шварц создал модель «умелого фасилитатора».

Мы можем использовать ее, чтобы описать некоторые качества, которые ожидаем от Скрам-мастера при его работе с Командой Разработки и Владельцем Продукта — все они вместе образуют Скрам-команду. В частности, я применяю подход, когда фасилитатор обучает команду улучшать рабочие процессы и все менее зависеть от него. Это то, что Шварц называет развивающей фасилитацией.

Читать далее «Скрам-мастер: умелый фасилитатор»

Swarming: one-piece flow

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

Личные предпочтения сотрудника и препятствия в рабочей среде часто ведут к разрозненности усилий. Если команда одновременно работает над несколькими элементами, это ведет к чрезмерному количеству незавершенной работы, низкой эффективности и соответствующим задержкам.

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

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

Предположим, команда пытается увеличить выработку путем параллельной работы, когда каждый сотрудник работает над одним элементом Бэклога Продукта (PBI). Работая в одиночку, члены Команды разработки с большей вероятностью сосредоточатся на разработке элемента, а не на его тестировании, в частности, потому что специалистов, обладающих компетенциями и желанием проводить тестирование, намного меньше, чем специалистов для творческих задач проектирования и разработки. Если в ходе Спринта возникает задержка нескольких элементов, возрастает риск того, что к концу Спринта PBI не придут к статусу «Готово». Что еще хуже, некоторые разработчики из Кремниевой долины и Европы, работающие над сложным программным обеспечением, обнаружили, что если не выявить и не исправить ошибку в ходе Спринта, один час тестирования кода может превратиться в 24 часа тестирования три недели спустя. Если команда откладывает тестирование, а не применяет Сворминг, то элемент, который можно было бы поставить через месяц, будет поставлен через два года. Читать далее «Swarming: one-piece flow»

Скрам: зачем нужна самоорганизация

Перевод оригинальной статьи  Виллема-Ян Агелинга “Scrum — Self-organization isn’t a fluffy thing”

Разговоры про самоорганизацию происходят не из-за того, что мы хотим  просто видеть сияющих от счастья людей.

Да, счастье — это бонус, побочный эффект. Но для чего на САМОМ ДЕЛЕ нужна самоорганизация?

Интересно, что в Руководстве по Скраму не говорится, ПОЧЕМУ самоорганизация — это хорошо. Словно создатели Скрама не видят необходимости объяснять нам ее важность. Предполагается, что все и так это знают. Но я считаю, что это не способствует осознанию ее важности.

К счастью, хорошее обоснование приводится в статье от 1986 года, с которой начался Скрам — «The New New Product Development Game» авторов Хиротака Такеучи и Икуджиро Нонака. Они описывают несколько ярких примеров, когда самоорганизация эффективна и ведет к более быстрой и качественной разработке продукта:

  • команда IBM, перед которой в начале 80-х гг. стояла задача разработать персональный компьютер;
  • команда Honda, получившая задание разработать «машину, которую захочет водить молодежный сегмент», и в результате создавшая Honda City/Jazz.

Первый документ по Скраму от 1995 года не упоминает самоорганизацию. Похоже, что данный термин отсутствовал в Скраме начала 90-х годов. Однако при этом в рамках экстремального программирования (Extreme Programming, XP) оно считалось ключевым фактором успеха:

«Блестящие программисты, конкурирующие между собой в эгоцентричном окружении, не смогут создать продукт, который создадут обычные программисты, работающие коллаборативно как самоорганизующаяся команда. Чтобы полностью раскрыть потенциал, нужен рабочий процесс, в котором преобладают командный дух и сотрудничество». — www.extremeprogramming.org

В те дни между XP и Скрамом было сильное взаимовлияние, один подход вдохновлял другой. Более того, в 2001 году люди, создавшие и популяризовавшие Скрам и XP, встретились с другими светлыми умами и разработали Аджайл-манифест. Самоорганизация упоминается как один из 12 принципов Аджайл-манифеста:

«Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд», — Аджайл-манифест (2001).

В 2001 году стало очевидно, что самоорганизация стала частью Скрама, это отмечают Кен Швабер и Майкл Бидл в книге «Agile Software Development with SCRUM» (2001):

«Команда часто проходит через короткий период, когда она не понимает, что у нее есть все полномочия. […] Но это удивление быстро проходит и сменяется продуктивностью, возникающей из-за самоорганизации», — «Agile Software Development with Scrum», 2001.

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

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

Самоорганизация — необходимое условие для создания продуктивных и креативных команд.