7 токсинов доверия в команде

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

Что же является причиной снижения уровня доверия в команде. Ниже мой список основных токсинов.

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

Что такое продукт?

Что такое продукт? 

Перевод оригинальной статьи Ellen Gottesdiener “What is your product?”

«Что такое продукт?» Это ключевой вопрос, который я недавно опубликовала в своем докладе в преддверии конференции Agile Cincinnati.

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

Каждый в продуктовой разработке должен иметь общий для всех, последовательный и четкий ответ на вопрос: «Что такое продукт?»

Image copyright by EBG Consulting

У компании должен быть общий для всех сотрудников, последовательный и четкий ответ на вопрос: «Что такое продукт?»
Изображение от EBG Consulting

Пять принципов

Существует пять принципов, которые помогают определить продукт:

Читать далее «Что такое продукт?»

Традиционное и системное мышление

Перевод статьи Сезарио Рамоса Systems and traditional thinkers

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

Системный мыслитель признает, что большинство проблем в разработке программного обеспечения возникает в системе, в которой работают люди. Проблемы по своей сути системны!

«95 % проблем в бизнесе возникают на уровне систем и только 5 % на уровне людей».

Э. У. Деминг

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

Но что представляет собой система? Р. Л. Акофф предложил лучшее, на мой взгляд, определение:

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

Читать далее «Традиционное и системное мышление»

Эффективный PBR часть I

В этой статье я опишу что, с моей точки зрения, может обеспечить эффективность PBR в Скрам.

Почему PBR важен

PBR не является официальным событием в Скраме, но он снижает вариативность элементов Бэклога Продукта (PBI) перед тем как они попадут в Спринт. Когда верхние элементы Бэклога Продукта приходят в состояние “ready”, то в Спринте у команды возникает меньше “сюрпризов”, а вероятность достижения Цели Спринта возрастает.

Разработчики общаются с клиентами напрямую

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

  • промежуточные артефакты (BRD, спецификации и т.д.);
  • многочисленные передачи, как результат, искажение и потеря информации;
  • низкая скорость принятия решений;
  • отсутствие эмпатии у разработчиков по отношению к клиентам/пользователям продукта;
  • непонимание разработчиками бизнес-домена.

Стейкхолдеры (внутренние, клиенты, пользователи) в хорошем Скраме общаются с Командой Разработки напрямую. Интервью с пользователями, уточнение требований напрямую со стейкхолдерами является нормальной активностью Команды Разработки. 

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

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

Читать далее «Эффективный PBR часть I»

Trust Toolbox: палитра командных инструментов

Возвращаясь к теме командного доверия, сегодня хочется поделиться набором полезных инструментов. Для удобства составили список инструментов и категоризовали их с точки зрения фокуса и места использования (Персональный — Командный, Удаленная — Локальная).

Что же у нас получилось.

Читать далее «Trust Toolbox: палитра командных инструментов»

Правильное ведение хозяйства

или ежедневный чистый продукт

https://sites.google.com/a/scrumplop.org/published-patterns/_/rsrc/1555448727626/value-stream/good-housekeeping/GoodHousekeeping_Head.jpg?height=317&width=320

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

Команда разработки двигается к Цели Спринта.

✥ ✥ ✥

Если вокруг беспорядок, вы тратите время и силы на поиск того, с чего нужно начать.

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

Слишком большой объем информации на Доске информации путает сотрудников и мешает отделить главное от второстепенного. Это отнимает время.

Если команда откладывает наведение порядка на конец Спринта, это тормозит прогресс. Команда может вообще не навести порядок в рабочей среде, так как к концу Спринта появляется много «срочной работы». Беспорядок в ходе Спринта существенно снижает производительность (см. Заметки о производительности) и качество продукта.

Пустая трата времени возникает из-за работы в условиях неясного прогресса.

Поэтому:

Каждый день продукт (код) и рабочее пространство должны быть абсолютно чистыми.

Читать далее «Правильное ведение хозяйства»

Illegitimus Non Interruptus (без стука не входить)

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

✥ ✥ ✥

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

Скрам-команда — общий ресурс, который закрывает потребности многих стейкхолдеров. Трагедия общин — это дилемма, возникающая, когда множество людей, действуя независимо и рационально, руководствуясь своими личными интересами, в конечном итоге истощают общий ресурс, даже если очевидно, что такой результат не отвечает чьим-либо долгосрочным интересам. Впервые описал эту дилемму американский эколог и философ Гаррет Хардин в знаменитой статье «Трагедия общин» («The Tragedy of the Commons»), опубликованной в журнале Science в 1968 году.

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

Желательно, чтобы Скрам-команда отвечала за результаты своей работы (“eat your own dog food”). Если выявляется дефект, команде нужно его исправить как можно быстрее. Если создается специальная команда для исправления дефектов, Скрам-команда не будет обращать внимание на скрытые дефекты.

Это, а также другие причины постоянно мешают работе Скрам-команды.





 Читать далее «Illegitimus Non Interruptus (без стука не входить)»	

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

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

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

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

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

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

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

Аварийная процедура (Emergency Procedure)

Эд Аттербери, коллега Джеффа Сазерленда, сбит зенитной ракетой над Ханоем. На изображении видно, как он прыгает с парашютом!

…компании, команды и отдельные сотрудники часто обнаруживают, что не могут поставить продукт вовремя, и Sprint Burndown Chart свидетельствует о неизбежном провале. Для работы в Аджайл-стиле необходимы быстрое определение проблем и оперативная реакция.

✥ ✥ ✥

В середине Спринта проблемы возникают из-за срочных требований или непредвиденных изменений. К середине Спринта становится очевидно, что Команда разработки не в состоянии успешно завершить Бэклог Спринта. Команда находится наверху Sprint Burndown Chart и видит, что при текущем выполнении работ она не может достичь Цели Спринта.

Есть много причин для срывов Спринта, в данном паттерне рассматриваются три основные из этих типичных проблем:

Для гибкости необходимо быстрое реагирование на изменения, а для этого проблемы должны выявляться как можно раньше. К сожалению, часто новые команды и среднестатистические команды не хотят, чтобы проблемы становились заметными. В частности, они не хотят останавливать работу, устранять проблемы и подвергаться критике. На первом заводе NUMMI (New United Motor Manufacturing, Inc) компании Тойота в Америке руководители из Японии посетили фабрику через шесть месяцев после открытия и увидели, что сотрудники боялись дергать шнур-андон — если дернуть этот шнур, срабатывает сигнальная лампа и начинается обратный отсчет, после которого конвейер останавливается. Рабочие не останавливали конвейер достаточно часто, чтобы разрешать свои проблемы. Руководство дернуло за шнур несколько раз, чтобы остановить конвейер и продемонстрировать рабочим, что самым главным препятствием было их нежелание останавливать конвейер. Остановка конвейера позволяет заметить проблемы и правильно их разрешить. «Отсутствие проблем — это проблема», как гласит мантра японских руководителей. Читать далее «Аварийная процедура (Emergency Procedure)»

Освобождающие структуры для Скрам-мастера

Присоединяйтесь к нашему сообществу Liberating Structures Russia, где каждый сможет попробовать освобождающие структуры. Давайте строить сообщества, которые вызывают изменения!

Перевод оригинальной статью Барри Оверима “The Value of Liberating Structures for Scrum Masters”

В августе 2018 года Scrum.org запустил тренинг Professional Scrum Master II. Его цель — предложить Скрам-сообществу продвинутый класс, предназначенный для поддержки Скрам-мастеров в их профессиональном развитии. Особенность PSM II — его формат, состоящий  из освобождающих структур.

Поэтому возникает вопрос:

«В чем ценность Освобождающих Структур для Скрам-мастеров?»

Что такое освобождающие структуры?

Освобождающие структуры — это набор из 30+ моделей взаимодействия, которые уравнивают, обогащают и углубляют взаимодействия в группах. Кит МакКэндлесс и Анри Липманович выяснили, что корни Освобождающих структур лежат глубоко в науке комплексных систем. Они реализуют пять элементов дизайна и десять принципов. Это означает, что они не являются жестким, статичным набором активностей. Новые структуры постоянно разрабатываются, а существующие модифицируются, корректируются или удаляются. С освобождающими структурами можно начать трансформировать целые организации, изменяя способы взаимодействия групп и отдельных людей. Читать далее «Освобождающие структуры для Скрам-мастера»