Организационный коучинг: целое не может быть разделено на части

О чем эта статья

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

Низкое качество, снижение продаж

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

Целое не может быть разделено на части

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

“Более 90% проблем, которые возникают в корпорациях, должны решаться не там, где они возникли” (R. Ackoff)

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

В традиционном организационном дизайне частой и повторяющейся темой является локальная оптимизация — “эффективность”, которая противоречит оптимизационной цели системы.

Производительность системы зависит от взаимодействия частей, а не от того, насколько эффективно они работают по отдельности. (R. Ackoff)

Читать далее «Организационный коучинг: целое не может быть разделено на части»

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

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

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

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

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

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

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


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

1 мая 2006 г

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

Содержание

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Владелец Продукта в больших организациях

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

Скачать брошюру

Владелец Продукта в небольшой компании

Руководство по Скраму описывает контекст небольшой компании или стартапа. В этом случае все просто: 7-9 человек обладают всеми необходимыми навыками и выполняют всю работу. Владелец Продукта определяет видение и порядок Бэклога Продукта, а Команда Разработка хорошо понимает бизнес и проблемы своих клиентов, уточняя требования напрямую с ними. Маленькая организация — это отсутствие бюрократии, передач и минимум потерь. Скрам изначально был создан и успешно зарекомендовал себя в работе с небольшими командами. 

Читать далее «Владелец Продукта в больших организациях»

Прокачайте PBR при помощи Example Mapping

В этой статье мы поделимся с вами техникой Example Mapping для командной работы над спецификациями. Мы применили эту технику на Актуализации Бэклога Продукта (PBR) с продуктовой группой LeSS. Попробуйте и вы!

Об Example Mapping мы узнали из блога Мэтта Вина — автора тестового фреймворка Cucumber. Хотим отметить очевидные плюсы техники:

  • добавляет структуру в обсуждение элементов Бэклога Продукта; 
  • помогает найти пробелы в знаниях;
  • позволяет создать первоначальную версию приёмочных тестов сразу на PBR.

Мы уже писали о важности эффективного проведения Акутуализации Бэклога Продукта (PBR) в статье Эффективный PBR часть I. Статья, которую вы сейчас читаете, детально раскрывает технику Example Mapping.

Example Mapping для PBR

“Организации, проектирующие системы, ограничены дизайном, который копирует структуру коммуникации в этой организации”
— Мэлвин Конвей 

Следуя закону Конвея, мы не хотим чтобы команды были ограничены выбором в принятии решений по дизайну разрабатываемых систем из-за неэффективной коммуникации. Поэтому одно и правил LeSS звучит как: 

  • Каждая команда – это самоуправляемая, кросс-функциональная, колоцированная, и долгоживущая структурная единица.

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

На встречу были приглашены 5 команд из продуктовой группы LeSS, стейкхолдеры из смежных подразделений, которые выступали главными заказчиками функциональности и, конечно же, Владелец Продукта. 

Наша цель заключалась в  том, чтобы детально проработать TOP-5 элементов Бэклога Продукта. 

Порядок действий был следующий:

1. Обозначили 5 хранителей знаний (экспертов) на каждому из выбранных элементов. Эти люди оставались на станциях все время.

2. Образовали смешанные группы из 5 команд, которые присоединились к экспертам.

3. Мы подготовили вымышленный пример фичи “Предотвращение нелегального использования топливной карты” и обучили группы технике Example Mapping

И объяснили цветовое обозначение для стикеров:

  • История — описание элемента Бэклога Продукта
  • Правило — это один из критериев по которому мы поймем что фича реализована как задумывалась, иначе говоря голубые стикеры — это критерии приёмки фичи
  • Пример — конкретный пример описывающий правило, Действие => Результат
  • Вопрос — если на текущий момент в группе возникает вопрос, на который группа не может в таком составе ответить, вопрос пишется на розовый стикер для дальнейшего прояснения

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

4. Запустили World Cafè — фасилитационный формат, где есть “хозяин” станции, в нашем случае им являлся эксперт, к которому присоединились группы участников. Группы работали на станциях: проясняли требования и наполняли флипчарт, используя Example Mapping.

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

5. После того как все группы побывали на всех станциях произошла презентация результатов работы.

Что у нас получилось:

  • Обратили внимание, что на одной из станции образуется большое количество вопросов. Оказалось, что много информации уже было написано в базе знаний, но прошло порядочно времени. Знания забылись. Мы нашли ноутбук, залезли в БЗ и выгрузили ключевые моменты на стикеры.
  • Большое количество голубых стикеров — сигнал к тому что эта фича большая. Хорошая новость! Ее можно разбить прямо по правилам!  
  • Все 5 команд продуктовой группы познакомились в равной степени с каждым элементом Бэклога Продукта (PBI), а значит каждая команда сможет взять любой из них на Планировании Спринта.
  • Правила, описанные на зелёных стикерах, уже в первый же день работы в Спринте могут использоваться для автоматизации приемочного тестирования. Более того, подход test-first теперь становится неизбежным 🙂

Попробуйте и Example Mapping! Будем рады услышать от вас идеи, ваши находки и улучшения 🙂

Напоминаем, что 14-16 октября у нас состоится первый тренинг Professional Scrum Developer (PSD) на русском языке — лучший тренинг для Скрам-команд, которые создают реальное программное обеспечение. На тренинге мы подробно разберём тему PBR, а также другие темы эффективной работы.

Читайте и другие наши посты про PBR в нашем блоге: Эффективный PBR часть I и Мультикомандное уточнение Бэклога Продукта

Из первых уст. Инсайты с конференции 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»