Скрам: зачем нужна самоорганизация

Перевод оригинальной статьи  Виллема-Ян Агелинга “Scrum — Self-organization isn’t a fluffy thing”

Разговоры про самоорганизацию происходят не из-за того, что мы хотим  просто видеть сияющих от счастья людей.

Да, счастье — это бонус, побочный эффект. Но для чего на САМОМ ДЕЛЕ нужна самоорганизация?

Интересно, что в Руководстве по Скраму не говорится, ПОЧЕМУ самоорганизация — это хорошо. Словно создатели Скрама не видят необходимости объяснять нам ее важность. Предполагается, что все и так это знают. Но я считаю, что это не способствует осознанию ее важности.

К счастью, хорошее обоснование приводится в статье от 1986 года, с которой начался Скрам — «The New New Product Development Game» авторов Хиротака Такеучи и Икуджиро Нонака. Они описывают несколько ярких примеров, когда самоорганизация эффективна и ведет к более быстрой и качественной разработке продукта:

  • команда IBM, перед которой в начале 80-х гг. стояла задача разработать персональный компьютер;
  • команда Honda, получившая задание разработать «машину, которую захочет водить молодежный сегмент», и в результате создавшая Honda City/Jazz.

Первый документ по Скраму от 1995 года не упоминает самоорганизацию. Похоже, что данный термин отсутствовал в Скраме начала 90-х годов. Однако при этом в рамках экстремального программирования (Extreme Programming, XP) оно считалось ключевым фактором успеха:

«Блестящие программисты, конкурирующие между собой в эгоцентричном окружении, не смогут создать продукт, который создадут обычные программисты, работающие коллаборативно как самоорганизующаяся команда. Чтобы полностью раскрыть потенциал, нужен рабочий процесс, в котором преобладают командный дух и сотрудничество». — www.extremeprogramming.org

В те дни между XP и Скрамом было сильное взаимовлияние, один подход вдохновлял другой. Более того, в 2001 году люди, создавшие и популяризовавшие Скрам и XP, встретились с другими светлыми умами и разработали Аджайл-манифест. Самоорганизация упоминается как один из 12 принципов Аджайл-манифеста:

«Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд», — Аджайл-манифест (2001).

В 2001 году стало очевидно, что самоорганизация стала частью Скрама, это отмечают Кен Швабер и Майкл Бидл в книге «Agile Software Development with SCRUM» (2001):

«Команда часто проходит через короткий период, когда она не понимает, что у нее есть все полномочия. […] Но это удивление быстро проходит и сменяется продуктивностью, возникающей из-за самоорганизации», — «Agile Software Development with Scrum», 2001.

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

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

Самоорганизация — необходимое условие для создания продуктивных и креативных команд.

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

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

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

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

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

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

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

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

Не давайте ответ, не услышав вопрос

Перевод оригинальной статьи Ceзарио Рамоса Do not provide the answer before knowing the question

Я общался с компанией, которая внедряла модель Spotify и попросила меня помочь. Они хотели понять, в чем разница между моделью Spotify и LeSS. Сначала мы обсудили, что такое LeSS. Я объяснил, что LeSS — это организационный дизайн, оптимизационные цели которого скорость, адаптивность и обучение. LeSS для организации то же самое, что Скрам для одной команды.

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

HR

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

Непрерывное улучшение

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

Но ещё хуже то, что копирование модели не даёт ощущения, что эта модель — ваша. Почувствовать, что у вас есть собственная модель, получается только тогда, когда вы создаете что-то самостоятельно. И если члены вашей команды чувствуют, что обладают чем-то, то выше вероятность, что они сами будут стремиться это улучшать. А это главное условие непрерывного совершенствования. Сложно почувствовать это, просто копируя чужие действия. Это скорее, как взять в долг — совсем не то же самое, как создать самостоятельно. Я отношусь к машинам из проката совсем не так, как к своим собственным.

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

Компания понимает этот момент, они очень серьёзно относятся к непрерывному улучшению.

Становление модели

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

Насколько я понял, в этой компании они делают именно так. И весьма успешно.

Cезарио Рамос

Сезарио занимается широкомасштабными Аджайл-трансформациями по всему миру. Автор книг «Emergent» и «Scrum Patterns». Он также является сертифицированным тренером LeSS, профессиональным тренером по Скраму (Professional Scrum Trainer™) и сертифицированным коучем.

Создаем прозрачность и ответственность в команде

О чем эта статья

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

Когда команды избегают продуктивного конфликта

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

Команды ТОП-менеджеров тоже не являются исключением. Они часто дополнительно обременены политическими конфликтами, подковерными играми и борьбой за организационные “колодцы”. Читать далее «Создаем прозрачность и ответственность в команде»

8 привычек адаптивных организаций 21 столетия!

8 привычек высокоэффективных организаций или
управленческие тренды 21 столетия! Какие они? И насколько Scrum и LeSS «успевают» за этими трендами 🙂
Когда читал этот список, составленный компанией Corporate Rebels, то улыбался, потому что все 8 пункты уже «встроены» в фреймворк Scrum и его масштабируемый вариант LeSS. Оригинальная статья доступна по ссылке, а здесь я кратко опишу пункты на русском.
 
Итак, список из восьми пунктов «адаптивных» или «прогрессивных» организаций, как их называют в статье Corporate Rebels.
 
1. Фокус на ценностях и большой миссии, а не на деньгах только. Подобный подход дает людям энергию, страсть и мотивацию. Люди хотят быть частью чего то большего, а не просто зарабатывать деньги.
 
2. Организационная структура, основанная на нетворке команд, уход иерархической структуры. Иерархия медленна, лишена гибкости, задерживает быструю доставку ценности на рынок.
 
3. Поддерживающее лидерство, уход от директивного командно-контрольного стиля управления. Задача современного управленца — создание условий и окружения для максимального раскрытия потенциала сотрудников, создание культуры непрерывного улучшения. Управленцы являются носителями миссии и ценностей, они пример для других.
 
4. Переход к эмпирическому контролю процессов, гибким планам, уход от планирования, основанном на предсказаниях. Адаптивные организации предпочитают подход «fail fast».
 
5. Свобода и доверие важнее правил и контроля. Работники это взрослые люди, которые сами могут контролировать себя и брать на себя ответственность. Задача управленцев — создать необходимые условия для этого.
 
6. Переход от централизованной модели управления к децентрализованной. Адаптивные организации передают принятие решений на периферию тем, кто каждый день общается с клиентами и лучше знает их боли и потребности.
 
7. Переход к радикальной прозрачности. Абсолютный доступ к финансовым данным, любой информации в реальном времени. Это ускоряет принятие решение и делает их более эффективными.
 
8. Уход от формальных должностных инструкций и фокус на обучении сотрудников и раскрытию их потенциала. Границы между ролями становятся более размытыми.
 
#Agile #Scrum #LeSS #ScaledScrumIsStillScrum

Не надо аплодисментов (Кен Швабер)

Не надо аплодисментов

Кен Швабер

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

Что в этой ситуации не так?

Во-первых, Обзор Спринта — это не презентация. Это не время продавать Скрам. И тем более не время высшему руководству демонстрировать свою поддержку. Все это, конечно, нужные активности, но сейчас они отвлекают от истинной цели Обзора Спринта. Обзор Спринта предназначен для того, чтобы Владелец Продукта проверил и адаптировал Продукт для увеличения возврата инвестиций. С этой целью Владелец Продукта проверяет и корректирует созданный Инкремент. Затем он консультируется с командой и другими стейкхолдерами и реорганизует Бэклог Продукта для следующего Спринта. Цель Обзора Спринта — организовать взаимодействие между Владельцем Продукта, людьми, которых он представляет, и командой. Тут должны иметь место сотрудничество, обмен важной информацией и мозговой штурм, чтобы решения были максимально обоснованы. Читать далее «Не надо аплодисментов (Кен Швабер)»

8 причин хронического незавершения работы в Спринте

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

Системы, паттерны и структуры.

Команда Разработки является системой с общей целью и взаимозависимыми между собой элементами (разработчики). Если события в системе повторяются, то они становятся паттерном. За каждым паттерном скрывается подкрепляющая структура. В данном случае паттерн системы — хроническое незавершение задач в Спринте.

Поиск структуры.

Задача Скрам-мастера — в партнерстве с командой найти структуру, которая вызывает паттерн и изменить ее. Для этого Скрам-мастер может предложить команде использовать на Ретроспективе инструменты системного мышления:

  • Пять почему
  • Fishbone
  • Causal-Loop Diagrams(CLD)
  • Дерево реальности
  • Метод А3

Фундаментальные причины, к которым приходят команды, могут сильно различаться. Приведу те, с которыми встречался в своей практике.
Читать далее «8 причин хронического незавершения работы в Спринте»

Перестройте цепочку убеждений с помощью упрощенного Lean Canvas

Перевод оригинальной статьи Эша Маурья «Reorder Chain of Beliefs with a leaner Lean Canvas»

В своей последней статье я рассказал, почему описание идеи по шаблону Lean Canvas похоже на составление цепочки убеждений. Звенья, появляющиеся в цепочке позднее, зависят от предыдущих звеньев, и недоработки в предыдущих звеньях вызывают цепную реакцию. Поэтому очень важно изучить вашу цепочку убеждений и сосредоточиться в первую очередь на особо слабом звене — самых рискованных предположениях.

Настоящая сложность заключается не в генерировании идей, а в их валидации.

Чтобы идея была успешной, в ней должны постоянно уравновешиваться риски трех типов: риски клиентов, риски рынка, технические риски. Я описал оптимальный вариант, когда идея находится на пересечении привлекательности, рентабельности и выполнимости.

Читать далее «Перестройте цепочку убеждений с помощью упрощенного Lean Canvas»

Извлеченные уроки и результирующие эксперименты (кейс МТС Касса 12-я часть)

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

Избегайте участия скептиков

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

«Не дайте им встать на вашем пути, какими бы ни были ваши взаимоотношения, так как если вы позволите им остаться, они нанесут столько вреда, что ваши изменения потерпят крах». Читать далее «Извлеченные уроки и результирующие эксперименты (кейс МТС Касса 12-я часть)»

Учимся работать с семью командами (МТС Касса 11-я часть)

Я очень удивился, когда узнал, что компании «МТС» и «LiteBox» еще в 2017 договорились году увеличить количество команд до семи. Таким образом, сразу после изменения структуры к продуктовой группе стали присоединяться новые команды.

Команда RITG со стороны аутсорсинговой компании-партнера. Владелец Продукта был полон энтузиазма по поводу присоединения новых команд и заключил партнерство с одной из аутсорсинговых компаний в своем городе. Через несколько недель новая команда под названием RITG присоединилась к продуктовой группе. В течение нескольких Спринтов мы пытались интегрировать людей в наш процесс. Мы постоянно испытывали проблемы коммуникации во время Уточнений Бэклога Продукта (PBR). Кроме того, они не показывались на Обзоре Спринта. Тогда я порекомендовал переместить их в офис физически. Осуществить это было нелегко, однако, несмотря на все, Владелец Продукта добился успеха. С того момента у нас было пять команд в одном офисе.

Команда ROST в офисе. Тем временем, внутренний отдел по управлению персоналом помог нам создать еще одну фиче-команду под названием ROST. Два члена бывшей пилотной фиче-команды подключились к ней на несколько Спринтов, чтобы присоединение прошло максимально гладко.

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

К сожалению, новые посредники. Ранее я говорил, что одним из основных препятствий при внедрении было привлечение людей, которые не поддерживали изменения и вели себя как посредники между командами и клиентами. Количество команд росло, и группа бизнес-анализа также росла. Был нанят новый бизнес-аналитик, который фокусировался на внешних активностях. Вот как выглядела структура в тот момент:

Читать далее «Учимся работать с семью командами (МТС Касса 11-я часть)»