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

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

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

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

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

Нам стоит больше работать с Аджайл-лидерами!

Весной 2019 мы провели первый двухдневный тренинг для Аджайл-лидеров Professional Agile Leadership (PAL), который был очень хорошо принят участниками. Ключевая аудитория — менеджеры среднего/высшего звена, которые работают с Аджайл-командами.

Это руководители бизнес-юнитов и продуктовых групп, например, трайб-лидеры. В Аджайл-сообществе распространены тренинги для Владельцев Продуктов и Скрам-мастеров, а что мы предлагаем лидерам и менеджерам? Ведь их роль и влияние ОГРОМНЫ. В их руках находятся ключи к организационному дизайну компаний, а значит, и гибкости (Business Agility). Кажется, что стоит больше работать с менеджментом, поддерживать его и обучать.

Поэтому мы проведем в середине ноября уникальный трехдневный тренинг Advanced Professional Agile Leadership (PAL-E). Добавили в программу темы ответственности и системного мышления. И теперь это взрывная смесь!

Непрерывная интеграция

Перевод неустаревающей статьи Мартина Фаулера про Непрерывную Интеграцию. Несмотря на то, что статья написана в 2006 году и упоминаемые в ней инструменты уже устарели, описание самой практики остаётся актуальной и по сей день.


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

1 мая 2006 г

Мартин Фаулер

Содержание

Читать далее «Непрерывная интеграция»

Скрам-паттерны для предсказуемости команд

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

Разработчики непрофессионалы или…?

Когда я работал программистом, то был фрустрирован тем, что постоянно не попадал в оценки. Не покидало ощущение, что я ненадежный работник и на меня нельзя положиться. С такими же проблемами сталкивались мои коллеги. 

“Злые” проблемы

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

Хорст Риттель и Мелвин Уэббер определили «злую» проблему как проблему, которая может быть четко определена только путем ее решения или решения ее части. Этот парадокс подразумевает, по сути, что вы должны «решить» проблему один раз, чтобы четко определить ее, а затем решить ее снова, чтобы создать работающее решение. (Стив Макконнелл)

Читать далее «Скрам-паттерны для предсказуемости команд»

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

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

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

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

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

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

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

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

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

Фасилитация Overall Retro

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

Читать далее «Фасилитация Overall Retro»

Plus que jamais или первый диалог с создателем освобождающих структур.

— Plus que jamais?
— Pardon?..
— Do you know what does it mean? I’m Henry, I’m French.
— Hi, Henry! (Понимаю, что речь про надпись на моей футболке). It means more than ever, it’s very about Liberating structures… Wait a minute… Henry?! Henry Lipmanowicz?


Хочу рассказать про Генри Липмановича (Henry Lipmanowicz). Он и Кейт МакКэнделс (Keith McCandless) создали освобождающие структуры — готовые шаблоны для фасилитации. Я люблю пробовать новые инструменты, технологии, подходы. И мне особенно интересно узнать о людях, которые их создают и развивают. Зачем им это? Это прибыльная бизнес-модель или этап личного развития? А вы когда-нибудь задумывались, зачем Кен Швабер и Джефф Сазерленд создали Скрам.

Читать далее «Plus que jamais или первый диалог с создателем освобождающих структур.»

Меняйте систему, а не людей

Система определяет результаты

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

  • Работа организована вокруг компонентных команд: аналитика, бэкенд, Android, Windows и т.д. 
  • Команды из-за многочисленных зависимостей передают из Спринта в Спринт проделанную работу. 
  • Цепочку замыкает “релиз менеджер”, который большой пачкой выводит новую функциональность на продакшн конечным пользователям. 
  • Легко заметить, что время цикла lead time или time-2-market равно нескольким Спринтам (2-3 месяца).

Мы называем это Copy Paste Scrum — использование Скрама в текущей организационной структуре без ее изменения. Какие факторы влияют на производительность всей системы? Обычно я задаю этот вопрос студентам, а затем даю несколько минут на генерацию факторов. Прошу разместить их в две колонки: система и люди. Типичный результат который получается в итоге:

Я проводил этот эксперимент с топ-менеджерами, разработчиками, менеджерами среднего звена, сотрудниками отдела продаж, маркетологами, но результат предсказуемый. Большинство стикеров оказываются в колонке “система”. Почему?

95% производительности зависит от системы (Эдвард Деминг 1982). 

Читать далее «Меняйте систему, а не людей»

Технические навыки

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

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

Вот, кстати, несколько полезных статей на эту тему:

Читать далее «Технические навыки»