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), чтобы оптимизировать количество качественных самолетов произведенных в одноминутный Спринт.

From MeSS to LeSS | Игра с карточками паттернов внедрения LeSS

Оригинальная статья доступна по ссылке.

Это описание воркшопа, который я провел на конференции LeSS в Амстердаме.

Можете использовать этот воркшоп для всестороннего обсуждения своей новой группы LeSS или для внесения изменений в процесс внедрения LeSS. Во время стандартного воркшопа можете использовать начальную ситуацию, о которой я писал в своих статьях о копипаст-мастшабировании здесь и здесь. Теперь я называю такую ситуацию MeSS (от англ. mess — «беспорядок»), поэтому ваша задача — перейти от беспорядка к LeSS (From MeSS to LeSS). В контексте своей организации начните с оценки текущей ситуации.

Читать далее «From MeSS to LeSS | Игра с карточками паттернов внедрения LeSS»

Conway’s Law**

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

Читать далее «Conway’s Law**»

Области Ценностей

Trinity Cathedral/Charlie Comella Community Garden uses different garden beds to divide their work. Each bed grows one or more types of plant that are combined to produce the meals for the community.

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

✥      ✥      ✥

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

Читать далее «Области Ценностей»

Pop the Happy Bubble

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

✥      ✥      ✥

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

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

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

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

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

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

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

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

Поэтому:

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

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

Scrumming the Scrum

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

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

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

✥      ✥      ✥

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

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

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

Поэтому:

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

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

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

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

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

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

✥ ✥ ✥ 

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

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

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

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

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

Поэтому:

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

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

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

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

✥ ✥ ✥

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

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

Поэтому:

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

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

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

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

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

✥ ✥ ✥ 

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

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

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

Поэтому:

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

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

Паттерны Скрама — применяя Скрам на практике

Перевод оригинальной статьи Сезарио Рамоса Scrum Patterns — putting Scrum into practice.

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

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

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

Табличный подход Аджайл-внедрения

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

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

Шаг 2. Создаются модель для измерения соответствия стандартному процессу или подходу.

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

Шаг 4. Аджайл-коучи обучают команды, группы и подразделения работе согласно стандартному процессу.

Этот подход хорошо согласуется с идеями Фредерика Уинслоу Тейлора об эффективности производства: существует «наилучший способ» и нам необходимо отделить голову от рук».

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

Читать далее «Паттерны Скрама — применяя Скрам на практике»