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

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

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

✥ ✥ ✥ 

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

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

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

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

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

Поэтому:

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

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

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

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

Дух игры

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

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

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

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

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

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

✥ ✥ ✥

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

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

Поэтому:

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

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

7 принципов упрощения организаций

Перевод оригинальной статьи Баса Водди и Крэйга Лармана.

Зачем компаниях Аджайл или LeSS? К сожалению, многие организации стремятся повысить эффективность отдельных людей и команд. Фокусируясь на отдельных активностях, “выхлопах” (outputs), скорости (velocity) и утилизации ресурсов, они не осознают, что это обычно приводит к снижению доставляемой ценности и адаптивности, удлинению циклов разработки фич для клиентов. LeSS нацелен не на локальные оптимизации (такие как рост персональной эффективности), а на оптимизацию организации для повышения ценности, доставляемой клиентам, и адаптивности —  скорости, с которой организация может менять направление разработки, опираясь на обучение.

Как же построить гибкую и адаптивную организацию? Упростив ее!

Читать далее «7 принципов упрощения организаций»

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

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

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

✥ ✥ ✥ 

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

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

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

Поэтому:

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

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

Повышайте Agility при помощи PBR

Уточнение Бэклога Продукта (PBR) в однокомандном Скраме не является официальным событием. В масштабированной разработке (LeSS, Nexus) комплексность продукта резко возрастает, и PBR становится обязательным каждый Спринт. В этой статье я объясню, как с помощью PBR повысить организационную гибкость (Agility) продуктовой группы.

Вопрос молодому Скрам-мастеру

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

Я спросил: «Какое событие Скрама ты бы хотела “отладить” в первую очередь: Планирование Спринта, Ежедневный Скрам или что-то еще?» Подумав, она ответила: «Планирование Спринта». Ответ логичный, ведь Планирование Спринта — первое событие в любом Спринте. Так ли очевиден ответ?

Читать далее «Повышайте Agility при помощи PBR»

Скрам-мастер — «менеджерская» роль

Перевод оригинальной статьи Гюнтера Верхейена.

В традиционной модели «менеджер» — это тот, кто занимает более высокое положение в иерархии.

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

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

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

Рассмотрим идею о том, что Скрам-мастер — это «менеджерская» роль.

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

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

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

Читать далее «Скрам-мастер — «менеджерская» роль»

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

Перевод статьи Кристиана Вервийса

Обзор Спринта

Как часто вы оказываетесь на Обзорах Спринта, полных презентаций PowerPoint? А когда на них нет ни пользователей, ни клиентов, ни стейкхолдеров? Или маетесь от скуки, потому что встречи превращаются в хор перебивающих друг друга голосов или сводятся к повторному обсуждению одних и тех же вопросов?

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

Читать далее «Проведите вовлекающий Обзора Спринта с помощью готовой цепочки освобождающих структур»

Радикальная откровенность для Скрам-мастера

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

Овчарки и болонки

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

  • рисуют красивые флипчарты;
  • клеят стикеры;
  • передают микрофон на “демо”;
  • поддерживают Скрам-доску в актуальном состоянии;
  • заводят “тикеты” в Jira;
  • решают административные задачи, которые им “слили” менеджмент и команда;
  • координируют зависимости.

Когда Скрам-мастера болонки, а не овчарки, они не выполняют основную функцию:

Скрам-мастер отвечает за продвижение и поддержку Скрама, как это определено в Руководстве по Скраму (Руководство по Скраму)

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

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

А еще они практикуют радикальную откровенность.

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

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

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

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

СОДЕРЖАНИЕ

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

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