Pop the Happy Bubble

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

✥      ✥      ✥

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

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

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

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

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

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

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

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

Поэтому:

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

Это паттерн для исправления. Лучшая ситуация – не попадать в «Пузырь Счастья». Когда кто-то (например, Скрам-мастер) поднимает проблему, которую все игнорируют, бросьте вызов команде и спросите их, как они планируют ее решить. Главное, в первую очередь, заставить команду признать, что у нее есть проблема.

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

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

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

Внешний человек, который “лопает пузырь”, уступает по важности кому-то из Скрам-команды, но может быть необходим, если вся команда не знает о «Пузыре Счастья». Любой, кто находится в лидерской позиции, может инициировать вовлечение этого внешнего “лопателя пузыря”. Крайне важно, чтобы были достоверные данные для подтверждения заявлений о производительности команды и о существовании «Пузыря Счастья». Тот факт, что команда находится в пузыре, означает, что они могут скептически относиться к наличию проблемы. Предоставьте членам команды данные, чтобы они не могли их оспорить. Лучшая роль для этого вне команды — это, вероятно, Скрам-мастер из другой команды, особенно если Скрам-мастер также не замечает этой дисфункции. Эта роль уникальна тем, что она объективна и нейтральна и может видеть всю картину. Команда видит свое отражение и поэтому может понимать последствия своего постоянного поведения. Скрам-мастер играет вопрошающую  роль. Если Скрам-мастер слишком настойчив и пытается продвинуть определенное решение, такое поведение может быть разрушительно для командной самоорганизации. Где это возможно, используйте вопросный метод Сократа.

✥      ✥      ✥

Ожидаемый результат –  команда осознает свои недостатки, вновь привержена улучшениям и предпринимает для них шаги. Основным результатом является осознание, и это может быть самым важным. “Лопание Пузыря Счастья” повышает осведомленность о проблемах, которые команда может решить с помощью Scrumming the Scrum. И наоборот, модели Scrumming the Scrum, Ретроспективы и Norms of Conduct помогают в первую очередь предотвратить появление “Пузырей Счастья”.

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

Наиболее вероятным положительным долгосрочным следствием многократного появления “Пузыря Счастья” является то, что команда получает признание за способность рефлексировать и совершенствоваться. Это полноправный источник Team Pride (см. Team Pride).

Рекомендуемые тренинги

Продвинутый курс Professional Scrum Master II (PSMII) + Scrum Patterns для Скрам-мастеров с опытом больше года. Решаем кейсы, изучаем интересные техники фасилитации, применяем системное мышление, Скрам-паттерны и готовим вас к сертификации Professional Scrum Master (PSMII).

Уникальный тренинг Scrum Patterns для Аджайл-коучей и Скрам-мастеров. Освойте десятки Скрам-паттернов и закройте большинство проблем, с которыми сталкиваются ваши Скрам-команды. Научитесь используйте комбинацию Скрам-паттернов и системного мышления.

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. Аджайл-коучи обучают команды, группы и подразделения работе согласно стандартному процессу.

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

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

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

Скрам-мастер паттерн**

Перевод паттерна Scrum Master**

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

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

✥ ✥ ✥

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

Читать далее «Скрам-мастер паттерн**»

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

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

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

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

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

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

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

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

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

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

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 (без стука не входить)»