Pop the Happy Bubble

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

✥      ✥      ✥

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

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

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

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

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

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

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

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

Поэтому:

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

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

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

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

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

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

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

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

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

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

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

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

Алгоритм формулирования ценностей

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

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

Для формулировки ценностей я использую алгоритм, позаимствованный в книге Culture Engine:

  • Формулировка ценностей (1-2 слова)
  • Определение и калибровка ценностей (несколько предложений)
  • “Я” формулировки конкретного поведения (несколько примеров).

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

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

Стабильные команды**

http://scrumbook.org.datasenter.no/images/StableTeams.jpg

…команды уже некоторое время производят продукт. В постоянно меняющейся бизнес-среде возникают вопросы о штатной перестройке, развитии и оптимальном составе команды.

✥ ✥ ✥ 

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

В проектном менеджменте часто путают людей с человеческими ресурсами. Это приводит к «управлению ресурсами», и спрос увязывается с пропускной способностью (capacity) каждой команды (или иногда с пропускной способностью каждого члена команды), которая вносит свой вклад в результат.

В результате людей часто перебрасывают из команды в команду при старте новых проектов или при возникновении кризисов, связанных с поставками. Это ведет к нестабильности и дополнительным расходам из-за:

  • администрирования, чтобы отслеживать, над чем работают люди;
  • сниженной эффективности, так как командам нужно интегрировать нового участника (эффективно создавая новую команду), которому в свою очередь нужно узнавать о команде и продукте;
  • действия «закона Брукса» («Если проект не укладывается в сроки, то добавление рабочей силы задержит его еще больше»).

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

Поэтому:

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

Читать далее «Стабильные команды**»

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

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

Дух игры

Ценности впервые были описаны в книге Кен Швабера и Майкла Биддла “Agile Software Development With Scrum” (2001). На вопрос “зачем ценности в Скраме?” у меня есть несколько ответов. Во первых, ценности определяют дух игры: культуру, незримую составляющую, маяки, на которые можно опереться в случае отсутствия полной ясности. Это этический и моральный кодекс Скрама. 

Описание фреймворка умещается на семнадцати страницах. Но оно не описывают все ситуации, с которыми столкнутся команды. Ценности похожи на принципы фэйр-плей в спорте.

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

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

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

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

✥ ✥ ✥

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

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

Поэтому:

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

Читать далее «Незаметный Скрам-Мастер*»

Вчерашняя погода*

http://scrumbook.org.datasenter.no/images/custom_text_shelter_14054-2.png

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

✥ ✥ ✥ 

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

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

В некоторых организациях на команды давят, требуя доставлять больше, чем они могут. Используя концепции «stretch goal» или «BHAG (Big Hairy Audacious Goal)», объем работ кажется захватывающим и привлекательным. Но подобные цели разрушают автономность команд и идут вразрез с подходом кайдзен (см. Кайдзен и Кайкаку).

Поэтому:

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

Читать далее «Вчерашняя погода*»

Работа в офисе или удаленно?

Перевод статьи Мартина Фаулера «Remote versus Co-located Work«

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

СОДЕРЖАНИЕ

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

Читать далее «Работа в офисе или удаленно?»

Swarming: one-piece flow

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

Личные предпочтения сотрудника и препятствия в рабочей среде часто ведут к разрозненности усилий. Если команда одновременно работает над несколькими элементами, это ведет к чрезмерному количеству незавершенной работы, низкой эффективности и соответствующим задержкам.

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

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

Предположим, команда пытается увеличить выработку путем параллельной работы, когда каждый сотрудник работает над одним элементом Бэклога Продукта (PBI). Работая в одиночку, члены Команды разработки с большей вероятностью сосредоточатся на разработке элемента, а не на его тестировании, в частности, потому что специалистов, обладающих компетенциями и желанием проводить тестирование, намного меньше, чем специалистов для творческих задач проектирования и разработки. Если в ходе Спринта возникает задержка нескольких элементов, возрастает риск того, что к концу Спринта PBI не придут к статусу «Готово». Что еще хуже, некоторые разработчики из Кремниевой долины и Европы, работающие над сложным программным обеспечением, обнаружили, что если не выявить и не исправить ошибку в ходе Спринта, один час тестирования кода может превратиться в 24 часа тестирования три недели спустя. Если команда откладывает тестирование, а не применяет Сворминг, то элемент, который можно было бы поставить через месяц, будет поставлен через два года. Читать далее «Swarming: one-piece flow»

Инкрементальный дизайн и архитектура

Перевод оригинальной статьи Рона Джеффриза «Incremental Development»

Суть подхода Big Design (детальное проектирование до начала разработки, англ. Big Design Up Front, BUFD) заключается в том, что у нас есть тщательно отобранный набор идеальных требований, и при помощи нескольких достаточно формализованных практик мы создаем красивую архитектуру для воплощения этих требований. Этот дизайн подобно солнцу освещает мир программирования, позволяя программистам без каких-либо глубоких раздумий идеально воплощать идеальную архитектуру для выполнения этих идеальных требований.

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

В случае работающего продукта

За свою полувековую карьеру в разработке ПО я узнал многое — и самостоятельно, и работая с командами. Если бы я мог вернуться в прошлое и вынести только одну мысль, она была бы такой:

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

Читать далее «Инкрементальный дизайн и архитектура»