Applying Professional Scrum (APS)

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

Applying Professional Scrum Logo

Этот год начался с обновления линейки тренингов в соответствии с новой редакцией Руководства. Про одно из таких изменений хочется рассказать поподробнее. Тренинг Professional Scrum Foundations (PSF) теперь называется Applying Professional Scrum (APS). 

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

Остался и приятный бонус —  после тренинга есть возможность проверить свои знания при помощи тестирования — всем участникам предоставляется попытка сдать экзамен и получить международный сертификат PSM I (Professional Scrum Master I).

Если вы хотите укрепить свои знания и попрактиковаться в Скраме у вас есть возможность это сделать. 22-23 марта мы проведем этот тренинг в online-формате. Более подробное описание и программа тренинга доступна по ссылке.

Cross-Functional Team**

Команда в целом должна содержать все компетенции, необходимые для поставки продукта.

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

✥      ✥      ✥

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

Комплексный продукт может потребовать от команды освоения многочисленных навыков для разработки Done функциональности (см. Definition of Done). Когда работа требует дополнительного человека для каждого необходимого навыка, команда становится слишком большой, чтобы быть эффективной. У вас может возникнуть соблазн не расширять набор навыков в команде, а вместо этого ввести внешние зависимости. С другой стороны, вы можете поручить работу команде, чтобы они могли развить и изучить требуемые навыки. Но обучение требует времени.

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

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

Поэтому:

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

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

✥      ✥      ✥

Вместо того, чтобы менять состав команды по мере появления потребности в новых навыках, растите людей внутри компании и стремитесь к созданию небольших и стабильных команд. Со временем проводите кросс-обучение для участников команды, чтобы они развивали свои навыки, чтобы осваивать все большее количество областей знаний (см.Moderate Truck Number). Это повысит способность команды работать как автономная команда. С кросс-функциональными командами становится проще равномерно распределять работу.

Тогда все участники команды имеют все возможности для изучения вторичных навыков.
Они могут свормиться (см. Swarming: One-Piece Continuous Flow) работая над  Элементами Бэклога Продукта (PBIs), который увеличивает возможности для обучения и оптимизирует поток, чтобы помочь быстро получить Done функциональность. Развитие вторичных навыков делает команду более гибкой, так что любой член может заменить другого, который стал недоступен. Команда всегда прогрессирует и автономна.

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

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

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

Эти команды естественно действуют как “фиче-команды” (см. Conway’s Law) потому что большинство PBIs — фичи: ориентированные на рынок приносящие прибыль элементы. Если кросс-функциональные команды разрабатывают продукт, передачи естественным образом исчезают из Потока Создания Ценности: команда самостоятельно может разработать любую функциональность без помощи извне или вмешательства. Вовлечение нескольких команд приводит к задержкам циклов обратной связи, увеличивает потери (muda) из-за переделки и создает несогласованность (mura) между этапами разработки в Потоке Создания Ценности.

Опубликованное в Harvard Business Review исследование двух корпораций, одна из которых функциональная, а другая продуктовая, говорит о том, что кросс-функциональные группы предоставляет лучшие возможности обоих организационных структур (см. «Организационный выбор: продукт против функции» в (см. “Organizational Choice: Product vs. Functionˮ).

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

Изменения будут происходить быстро (и нужно позволить, чтобы они пошли быстро). Изменения будут скорее нормой, чем исключением. Для этого требуются небольшие организации, в которых все знают, что происходит: организации, способные принимать изменения, работать в разных специализациях, регулярно приносить пользу и, если не считать другого термина, гибкими.

Игра

Соберите несколько небольших команд, которые будут соревноваться в игре за создание бумажных самолетиков и управление ими. Каждый член команды может делать только одну складку за раз, а затем должен переключиться на работу в другой плоскости. Никакой самолет не может иметь более 15 складок. Он должен быть не менее 15 сантиметров в длину и 8 сантиметров в ширину. У него должен быть тупой кончик шириной не менее 2 сантиметров. Чтобы квалифицироваться как качественный продукт, самолет должен пролететь 3 метра по горизонтали, когда испытатель его проверяет. Тестер может проверить каждый самолет только один раз.

Попробуйте игру, и примените Скрам-паттерны (Swarming), чтобы оптимизировать количество качественных самолетов произведенных в одноминутный Спринт.

Обновление Руководства по Скраму 2020: Product Goal

Перевод оригинальной статьи Дэйва Уэста Scrum Guide 2020 Update: Introducing the Product Goal

Что такое Product Goal?

В обновленном Руководстве по Скраму (2020) к артефактам добавлено три пункта приверженности. Их задача — улучшить качество артефактов для повышения прозрачности. В случае с Product Backlog приверженность относится к Product Goal. 

По сути, Product Goal наделяет Бэклог Продукта контекстом. Определить ее, можно ответив на вопрос: «почему мы выполняем всю эту работу?». Можно использовать ее в качестве краткой презентации на тему: «Над чем сейчас работает Скрам-команда?». Слово «Цель» выбрано не случайно, оно описывает:

  • то, к чему мы стремимся, и
  • то, что можно измерить по достижении.

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

Читать далее «Обновление Руководства по Скраму 2020: Product Goal»

Руководство по Scrum 2020

В этой короткой статье я перечисляю основные изменения в новой версии Руководство по Скраму 2020. Если у вас нет времени, чтобы тщательно изучить руководство, эта статья для вас. Руководство доступно с 18 ноября в английской и русской версиях. 

Цель изменений

Авторы Скрама утверждают, что главный мотив изменений — сделать Скрам менее предписывающим, более бережливым (lean) и более гармонично вписывающимся в разные контексты, особенно за пределами разработки программного обеспечения (ПО). И, знаете, Руководство значительно похудело. Теперь оно насчитывает лишь 13 страниц.

Перечень основных изменений

  • Одна Скрам-команда, сфокусированная на одном продукте. Концепция отдельной команды внутри команды (Development Team), которая привела к поведению взаимоотношений «прокси» и «мы/они» между Product Owner и командой разработчиков, устранена. Теперь есть только Скрам-команда, сфокусированная на общей цели, с тремя разными зонами ответственности: Product Owner, Scrum Master и Developers. То-есть, теперь мы говорим не о ролях, а зонах ответственности (accountabilities) внутри одной системы. Как следствие, Скрам-команда коллаборативно отвечает за достижение Цели Спринта, за соблюдение определения готовности (Definition of Done) и т.д.
  • Добавление Product Goal. Добавлена концепция Product Goal, которая фокусирует Скрам-команду на достижение более широкой цели. Каждый Спринт должен приближать продукт к итоговой Product Goal. Чем может быть эта Product Goal? В зависимости от контекста, это может быть миссия, видение продукта или же тактическая квартальная цель. Руководство специально использует нейтральный термин, чтобы дать вам возможность наилучшим образом определиться в вашем контексте.
  • Место для Sprint Goal, определения готовности (DoD) и Product Goal. Предыдущие Руководства по Скраму описывали Sprint Goal и определение готовности (DoD), но они не были официальными артефактами и относились к правилам Скрама. Теперь каждый из трех артефактов содержит «приверженность». Для Product Backlog есть Product Goal, для Sprint Backlog есть Sprint Goal, для Increment есть определение готовности (DoD) (теперь без кавычек). Они существуют, чтобы обеспечить прозрачность и сфокусировать на прогрессе по каждому артефакту. 
  • Самоуправление вместо самоорганизации. В предыдущей версии команды назывались самоорганизующимися. Команда сама решала, кто и как будет выполнять работу. Версия 2020 года фокусируется на Скрам-команде, и подчеркивает важность самоуправления. Благодаря тому, что представитель бизнеса (Владелец Продукта) является частью системы, Скрам-команда может определять не только кто и как организовывает работу, но и направление движения.
  • Три вопроса события Sprint Planning. В версии 2017 были описаны два вопроса Sprint Planning: «Что» и «Как». В Руководстве по Scrum 2020 года особое внимание уделяется третьему вопросу — «Почему» — относящемуся к Sprint Goal. 
  • Исчезли вопросы из Ежедневного Скрама. Описание Ежедневного Скрама значительно сократилось. Ушли рекомендуемые вопросы: кто, что делал и т.д. Теперь разработчики сами решают как наилучшим образом инспектировать прогресс к Цели Спринта.
  • Один Владелец Продукта/Бэклог Продукта в независимости от количества команд. Если раньше и могли бы различные трактовки того, как правильно масштабироваться и сколько может быть Владельцев Продуктов и Бэклогов Продуктов, то теперь спор завершен. Руководство 2020 года явным образом говорит о том, что в случае, когда много Скрам-команда разрабатывают один продукт, то у них один и тот же Владелец Продукта/Бэклог Продукта.
  • Скрам основан на lean. В предыдущих руководствах утверждалось, что Скрам основан на принципах эмпиризма. Теперь к ним добавлены принципы бережливого мышления (lean). Лично я очень рад этому, потому что всегда утверждал, что Скрам основан на идеях Toyota Production System (TPS).
  • Отсутствуют обязательные атрибуты у элементов Бэклога Продукта (PBI). Версия 2017 требовала от нас четыре атрибута у каждого PBI: description, order, estimation, value. Теперь они могут отличаться в зависимости от уникального контекста, в котором разрабатывается продукт.
  • Исчезло ограничение в 10% на Product Backlog Refinement (PBR). Уточнение Бэклога продукта остается ongoing activity и упоминается несколько раз в тексте, но ограничение по времени отсутствует, потому что может отличаться в различных контекстах.
  • Исчезли кавычки с “Ready”. Элементы Бэклога Продукта (PBI) называются готовыми к выбору в Спринт, если они могут выполнены за Спринт. При этом слово ready осталось, но кавычки растворились.

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

Scrum ON!

Хватит обвинять фреймворки, улучшайте внедрения

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

Существует множество других Аджайл-подходов: Extreme Programming (XP), Scrum, Nexus, Kanban, LeSS, Crystal Clear, Lean Startup, Management 3.0. В своей коучинговой практике я отдаю предпочтение фреймворкам Скрам и LeSS, но больше всего ценю ценности и принципы, стоящие за ними. Со-создатель Скрама Кен Швабер считает о том, что Скрам может быть заменен лучшим подходом, если тот будет основан на четырех принципах: самоорганизации, эмпиризме, коллективном интеллекте и прозрачности. 

Пора сделать важное заявление:

Перестаньте обвинять фреймворки, начните улучшать внедрения.

Наблюдаю, что организации переполнены поверхностными Agile / Lean инициативами. Наверняка и вы сами сталкивались со ScrumButs, FlaccidScrum, Copy Paste Scrum, фейковым Канбаном. Люди склонны обвинять инструменты и фреймворки / методы, но, по моим наблюдениям, это проблема реализации. Есть исследование, подтверждающие это мнение.

Неспособность большинства организаций в полной мере воспользоваться преимуществами инноваций имеет мало общего с конкретным инструментом совершенствования, который они выбирают. Вместо этого проблема заключается в том, как внедрение новой программы совершенствования взаимодействует с физическими, экономическими, социальными и психологическими структурами, в которых происходит ее реализация. Другими словами, это не просто инструментальная проблема, это системная проблема, которая создается взаимодействием инструментов, оборудования, сотрудников и менеджеров. (Nobody Ever Gets Credit for Fixing Problems that Never Happened, Nelson P. Repenning, John D. Sterman)

Читать далее «Хватит обвинять фреймворки, улучшайте внедрения»

Pop the Happy Bubble

Скрам-команда преодолела некоторые препятствия и работает более эффективно, чем раньше.

✥      ✥      ✥

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

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

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

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

Некоторые команды могут не видеть пути улучшения, потому что все препятствия, которые у них есть, находятся «вне команды». Когда команда не достигает Цели Спринта, она всегда приписывает это разовым, исключительным событиям.  И всегда есть какое-то одноразовое событие. Они чувствуют, что если бы только некоторые «они» могли что-то с этим сделать, команда бы улучшилась.

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

Команда может жить в “Пузыре Счастья”. Одна из самых больших проблем состоит в том, что пузыри прозрачны – команде очень трудно его увидеть. Почти всегда требуется взгляд со стороны, чтобы осознать такое поведение. Команде нужно получить обратную связь от нейтральных наблюдателей. Это то, что команды, возможно, не хотят замечать. Наблюдатели должны иметь смелость быть честными с участниками команды и чтобы справиться с неприятием результатов их обратной связи.

С другой стороны, все команды могут улучшаться. Они просто не видят этого.

Поэтому:

Привлеките команду к осознанию своей ситуации (Лопните Пузырь Счастья): вынудите команду противостоять своему удовлетворению, подсветив им важные недостатки. Затем вместе с командой планируйте действия по улучшению. Создайте в команде культуру постоянного самоанализа и совершенствования.

Читать далее «Pop the Happy Bubble»

Почему Аджайл-трансформация буксует

Знаете ли вы компании, которые используют Аджайл-практики и внедрили Скрам, но так и не получили ощутимых результатов после нескольких лет трансформации? Чаще всего дело в том, что цели оптимизации адаптивность и скорость противоречат организационному дизайну компании, который поддерживает другие цели. В этой статье мы научимся находить несоответствия между целями оптимизации и текущей структурой. 

POSIWID (“Purpose Of The System Is What It Does”)

Специалист по системам и управлению Стаффорд Беер разработал важную и популярную эвристику системного мышления, известную под аббревиатурой POSIWID: «Purpose Of the System Is What It Does». Другими словами, цель оптимизации определяет результаты системы. Беер считал POSIWID лучшей отправной точкой для понимания любой системы. Мы должны сосредоточиться на фактических результатах, а не на желаемых. Почему? Системы показывают в точности те результаты, которые определены ее целью оптимизации и поддерживающей цель структурой. 

Когда люди понимают, как цель системы и ее структура определяют результаты, они могут взять на себя ответственность за изменению структуры.

Давайте приведем примеры, где ЗАЯВЛЯЕМАЯ и ФАКТИЧЕСКИЕ цели систем не совпадают.

СистемаНаблюдаемая проблемаЗаявляемая цельЦель, сформированная с помощью POSIWID
ШколаМного не вовлеченных детейВоспитание полноценных и самостоятельных людейШкола хорошо достигает цели в том, чтобы сделать обучение для детей как можно более скучным
Программное обеспечение XYZБольшой отток клиентовПомощь малому бизнесуПродукт прекрасно достигает цели в том, чтобы заинтересовывать клиента, а затем сделать все возможное, чтобы он ушел.
ПарламентКоррупция, слияние власти с крупным бизнесомПредставлять интересы граждан и защищать их интересыПарламент замечательно выполняет цель, которая заключается в обогащении и лоббировании интересов крупного бизнеса.

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

Каждая система идеально разработана для достижения результатов, которые она получает. (Дон Бервик)

Хороший пример, когда поставленная цель не работает — Copy-Paste масштабирование. Это самый распространенный способ использования Скрама в больших организациях по всему миру. 

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

Такая структура порождает зависимости и длинные релизные циклы. Кроме того, команды работают не над самой важной функциональностью из-за наличия многочисленных Бэклогов Продукта. Copy-Paste масштабирование имеет мало общего с заявленными оптимизационными целями. Чаще всего фактические цели оптимизации: сохранение статуса-кво и структур власти, индивидуальная эффективность, создание видимости изменений для того, чтобы отрапортовать руководству о том, что “трансформация завершена”. Поэтому фактическая цель, определенная с помощью POSIWID, может звучать так: 

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

Итак, можно до посинения доказывать, что целью системы является [XYZ], но если это не подтверждается результатами и поведением системы, то это ЗАЯВЛЕННАЯ цель, а не ФАКТИЧЕСКАЯ. Давайте дальше разбираться в том, как привести к соответствию цели оптимизации и организационный дизайн.

Читать далее «Почему Аджайл-трансформация буксует»

Scrumming the Scrum

…вы используете Скрам, как движок для улучшения. Скрам-команда должна проводить эффективные Ретроспективы Спринта и быть готовой Лопнуть Пузырь Счастья. Базовые механики Скрама на месте и вы хотите использовать Скрам для реализации своего видения кайзен (смотрите также Kaizen and Kaikaku):

Кайзен или kai-zen (カイゼン)  японская бизнес-философия постоянного совершенствования методов работы, личной эффективности и т. д. В переводе с японского ‘улучшение’.

Посмотрите также Toyota Kata.

✥      ✥      ✥

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

Их работа не Done (смотри Definition of Done), их Бэклог не Ready (see Definition of Ready), команда не самоорганизуется для повышения производительности.

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

Поэтому:

Определите самое важное препятствие на Ретроспективе Спринта и устраните его до конца следующего СпринтаЧтобы устранить самое важное по приоритету препятствие, поместите его в Бэклог Спринта как задачу с приемочными тестами (смотри Testable Improvements) которые будут определять, когда задача Готова. Затем оцените статус задачи, как и любой другой, на Обзоре Спринта.

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

Читать далее «Scrumming the Scrum»

Скрам начинается с готового к релизу инкремента

Фейковые Спринты

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

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

Сердцем Скрама является Спринт, период времени не более одного месяца, в течение которого создается потенциально готовый к релизу инкремент продукта (Руководство по Скраму, 2017).

Читать далее «Скрам начинается с готового к релизу инкремента»

Работаем с ценностями в Скраме (часть 3)

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

Движок обратной связи

Известна латинская сентенция: Turbato melius capiuntur flumine pisces, что буквально означает «в мутной воде рыба ловится лучше». В одной из басен древнегреческого поэта Эзопа говорится о рыбаке, который мутил воду вокруг сетей, загоняя туда ослеплённую рыбу. Для поддержания ценностей нужна прозрачность и частые циклы обратной связи, чтобы команда понимала куда плывет. Поэтому Скрам-команды инспектируют и адаптируют ценности и взаимоотношения на Ретроспективе Спринта. 

Подход, который мы часто используем с командами, требует навыков использования ненасильственной коммуникации (NVC). Сессия обратной связи состоит из нескольких шагов:

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

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

Читать далее «Работаем с ценностями в Скраме (часть 3)»