Незаметный Скрам-Мастер*

…у вас есть Скрам-Мастер, который служит Команде Разработки. Команда Разработки должна использовать Ежедневный Скрам, чтобы поделится информацией о прогрессе, скорректировать Бэклог Спринта и скоординировать оставшуюся до завершения Спринта работу.

✥ ✥ ✥

Во время Ежедневного Скрама участники Команды Разработки не обсуждают текущие вопросы друг с другом, а обращаются непосредственно к Скрам-Мастеру. Команда постоянно ожидает указаний или одобрения, прежде чем начать работу. То есть они не берут на себя ответственность за событие и не действуют как команда.

Участники Команды Разработки в Скраме находятся в выгодном положении, так как они больше чем кто-либо погружены в детали плана. Но зачастую разработчики выбирают безопасную позицию и на встречах рассказывают Скрам-Мастеру о текущем статусе работы, вместо того чтобы принять решение о перепланировке Спринта. Такое поведение может быть привычкой, выработанной во время работы с предыдущим Менеджером Проекта или отражать непонимание командой роли Скрам-Мастера. Если я участвую в Ежедневном Скраме как разработчик и должен о чем-то рассказать, скорее всего я обращусь к одному человеку, который, на мой взгляд, будет меня слушать (к тому, кто настаивал на проведении этой встрече). Таким образом, участники незрелой команды будут обращаться к Скрам-Мастеру. Ситуация может усугубиться, если команда будет и дальше ждать указаний от Скрам-Мастера.

Поэтому:

Выполняя роль владельца Скрам-процесса, Скрам-Мастер должен убедиться, что команда берет на себя ответственность за Ежедневный Скрам.

✥ ✥ ✥

Один из способов решения данной проблемы для Скрам-Мастера: стать «невидимым». Например, Скрам-Мастер может встать позади человека, который рассказывает о статусе работы, или просто незаметно выйти из помещения. Можно воспользоваться другим вариантом и объяснить Команде Разработки почему так важно брать на себя ответственность.

Ежедневный Скрам проводят для инспекции прогресса текущего Спринта и адаптации плана работ для достижения Цели Спринта. Команда Разработки ответственна за проведение Ежедневного Скрама. Скрам-Мастер может присутствовать на встрече, но не вмешивается в планирование Команды Разработки, пока команда не попросит его. Тем не менее, даже в этом случае он не должен направлять команду или критиковать их решения об организации работы. (Скрам-Мастер может вмешиваться в обсуждение процессов, например временных ограничений, но все же лучше, чтобы участники Команды Разработки решали такие вопросы самостоятельно).

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

Формирование внутренней мотивации брать на себя ответственность за планирование работы требует от  команды уверенности в себе и вовлеченности каждого участника в результат. Оба этих условия – предпосылки к тому, чтобы Скрам-Мастер снизил степень своего влияния. Кроме того, с ростом данной уверенности и вовлеченности участников, растет самооценка команды (см. Самооценка команды) и команда становится более автономной (см. Автономная команда).

Скрам-Мастеру не нужно присутствовать на Ежедневном Скраме. Он объясняет участникам команды преимущества Ежедневного Скрама, чтобы они сами взяли на себя ответственность за результат.

Скрам-мастер — «менеджерская» роль

Перевод оригинальной статьи Гюнтера Верхейена.

В традиционной модели «менеджер» — это тот, кто занимает более высокое положение в иерархии.

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

У авторитарной модели есть серьезные ограничения. Традиционный менеджер кажется отважным и смелым, но часто неэффективен. Традиционная модель отбивает желание работать, снижает энтузиазм, игнорирует внутреннюю мотивацию и использует внешнюю, сводит на нет удовольствие от работы, служит благодатной почвой для политиканства и взяточничества. В организации, где трудятся люди, а не роботы, такая система менеджмента ведет к катастрофе. Она неуважительная и негуманная.

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

Рассмотрим идею о том, что Скрам-мастер — это «менеджерская» роль.

В отличие от традиционного «менеждера», у Скрам-мастера нет формальной власти над Командой Разработки или работой. Скрам-мастер ведет управление через Скрам-процесс. В организации он отвечает за эффективность использования Скрама командами, отделами и организацией. Скрам-мастер отвечает за понимание и реализацию Скрама. Это настоящая менеджерская задача: с подотчетностью, сферой деятельности и ответственностью, но часто саму роль Скрам-мастера упускают из виду и игнорируют.

Скрам-мастер — это действительно менеджер, но не в традиционном смысле. Очевидно, что Скрам-мастер не управляет бюджетом, людьми, работой и задачами. За возврат инвестиций отвечают Владельцы Продуктов. Командами управляют сами собой. Однако для возникновения самоорганизации в Скраме нужны цели и границы. Скрам-мастер управляет границами, самоорганизации: использует таймбоксы для управления рисками и фокусом, кросс-функциональную коллаборацию, “готовые” к релизу результаты, валидированное обучение.

Скрам-процесс обеспечивает командам каркас для творчества и коллективного создания ценности. Он задает ритм и закладывает основу для открытий. Скрам-мастер управляет Скрам-процессом, задействуя различные сервисы. И в них, как в зеркале, отражается состояние Скрама в организации. Выгоды, получаемые от Скрама, зависят от качества сервисов, которые оказывает Скрам-мастер. Или это не так?

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

Скрам-мастер паттерн**

Перевод паттерна Scrum Master**

В 1953 году участники британской экспедиции Эдмунд Хиллари и Шерпа Тенцинг Норгей, во главе с Джоном Хантом, впервые в истории взошли на Эверест. Признание получают те, кто достигает цели при поддержке фасилитаторов, играющих не такую заметную, но ключевую роль в миссии. Часто Скрам-Мастер работает незаметно.

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

✥ ✥ ✥

Без полного понимания Скрама и применения его принципов и ценностей Команды Разработки, Владельцы Продуктов и организации не смогут воспользоваться преимуществами, которые он дает.

Читать далее «Скрам-мастер паттерн**»

Как подготовить и провести Обзор Спринта с помощью освобождающих структур

Мы любим использовать освобождающие структуры для проведения событий Скрама. Сегодня расскажем о цепочке освобождающих структур для Обзора Спринта. Другие цепочки выложены на доске Trello. В статье мы больше фокусируемся на идеях, которые заложены в основу освобождающих структур. Детальную, пошаговую инструкцию и временные рамки вы найдете в Trello.

Цель Обзора Спринта

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

Читать далее «Как подготовить и провести Обзор Спринта с помощью освобождающих структур»

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

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

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

Ретроспектива: отдых, работа или наказание?

Несколько лет назад я была начинающим Скрам-мастером. Я готовила и фасилитировала командные Ретроспективы. И очень быстро заметила, что участники по-разному вовлечены в процесс и каждый преследует свои цели. Кто-то энергично исследует проблемы и ищет решения, а кто-то мучительно ждёт завершения. Я была в ужасе от своей некомпетентности! Пока мой ментор не сказал мне,  что это окей, это и есть моя Скрам-мастерская работа. Спасибо ему за это 🙂

А еще он мне рассказал про простую метафорическую модель, которой теперь делюсь с вами. 

Кто приходит на ретроспективу?

Согласно модели, условно бывает 4 типа участников ретроспективы:
— Исследователь
— Отпускник
— Покупатель
— Заключённый

Читать далее «Ретроспектива: отдых, работа или наказание?»

Из первых уст. Инсайты с конференции 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 г.) Роджер Шварц определяет групповую фасилитацию как

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

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

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

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

Скрам-мастер: спокойный, бескорыстный и отзывчивый

Недавно Далай Лама опубликовал статью “Почему лидеры должны быть внимательными, бескорыстными и отзывчивыми” в Harvard Business Review. Мне кажется, что эта модель отлично ложится на Скрам-мастера. Предлагаю вам небольшие выдержки. Оцените сами.

Быть спокойным и осознанным

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

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

Почему фокус на Velocity убивает Agility

В этой статье я расскажу об опасной динамике, которая возникает в случае, когда Владелец Продукта, Скрам-мастер и/или менеджмент организации фокусируют Команду Разработки на Velocity.

О чем говорит Velocity.

Концепция Velocity означает:

Скорость, с которой Команда Разработки конвертирует элементы Бэклога Продукта в ГОТОВЫЙ К РЕЛИЗУ инкремент продукта.

Обратите особое внимание на выделенные слова. Velocity применима тогда, когда Команда Разработки может доставлять каждый Спринт готовый к релизу инкремент. В этом случае Done = DoD = releasable.

Но даже в этом случае Velocity не показывает:

  • Была ли решена проблема клиента.
  • Занимаемся ли мы самыми приоритетными проблемами клиента.
  • Объем поставленной ценности.
  • Степень удовлетворенности клиента.

Velocity лишь показывает, что команда была чем-то занята.

Является ли это достоверной оценкой успешности ваших продуктов и сервисов? Оценивают ли клиенты ваши продукта по тому, насколько были заняты сотрудники компании?

Если хотите, Velocity отражает объем “выработки” Команды Разработки. К сожалению, этого недостаточно для создания успешных продуктов и сервисов. Читать далее «Почему фокус на Velocity убивает Agility»