LeSS в МТС Кассе 2-я часть (основы Скрама и пилотная команда)

Начало обучения — подготовка к внедрению LeSS

Почему для внедрения LeSS нужно изменить оргструктуру

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

  • доставка наивысшей ценности для клиента;
  • адаптивность компании (способность резко поменять курс ради доставки бизнес-ценности);
  • обучение.

Изучение основ Скрама

Мы пригласили топ-менеджеров, разработчиков и руководителей всех функциональных подразделений (отделы маркетинга, продаж, нормативно-правового соответствия и пр.) принять участие в двухдневном тренинге по основам Скрама — Professional Scrum Foundations (PSF). Тренинг помог им понять ценности и принципы, лежащие в основе работы Скрам-команды. Существуют руководства по внедрению фреймворка LeSS в организации (руководство «Начало работы»). Первым же шагом в руководстве говорится о необходимости обучить всех. Теперь я осознаю, что с самого начала не обучил всех сотрудников должным образом и поэтому не строго следовал рекомендациям. Из-за этого очень быстро возникли проблемы с добровольцами и поддержкой внедрения фреймворка. Читать далее «LeSS в МТС Кассе 2-я часть (основы Скрама и пилотная команда)»

LeSS в МТС Кассе 1-я часть (аудит)

Учимся учиться в МТС Кассе

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

До обучения

Поглощение LiteBox компанией МТС

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

Став частью огромной корпорации МТС, насчитывающей около 70 000 сотрудников, команда LiteBox сохранила практически полную независимость. К моменту внедрения LeSS она действовала как отдельное бизнес-подразделение, штат которого превышал 200 человек.

Бизнес-возможности и понимание срочности изменений

Ко мне за помощью обратилось руководство МТС. Первые переговоры мы провели в конце 2017 года. С 1 июля 2018 года, как ожидали руководители LiteBox, должен был начаться огромный приток клиентов. Согласно их прогнозам, планировалось увеличение базы пользователей примерно в сто раз. В декабре 2017 года число клиентов LiteBox превысило 6 000, и ожидалось, что к осени 2018 года их численность перевалит за 100 000. Руководство LiteBox стремилось изменить процесс разработки продуктов, сделать его адаптируемым и легко масштабируемым. После нескольких непосредственных встреч с топ-менеджерами мы все согласились с тем, что необходимо начать с серии телефонных интервью, а затем провести тщательный аудит компании. Читать далее «LeSS в МТС Кассе 1-я часть (аудит)»

Как найти пользователей на Обзор Спринта

Проблема с поиском пользователей на Обзор Спринта

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

Амбициозная цель

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

Где мы искали гостей

Я разместила приглашение на Обзор Спринта в группе Scrum Russia на FB. Несколько ребят подтвердили свое участие. Команде удалось найти четырех пользователей среди тех, кто обращался в техническую поддержку. А отдел продаж привлек ключевого b2b-клиента. Ура!

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

Читать далее «Как найти пользователей на Обзор Спринта»

Как убить очереди и ускорить команду при помощи моббинга

Команда организовывает свою работу

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

По результатам Планирования Спринта Скрам-команда решает: каким будет Инкремент в конце Спринта; как организовать работу, чтобы получить готовый Инкремент Продукта (Скрам Гайд, 2017).

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

Разработка в стиле “моббинг” или “моб-программирование”

Википедия определяет моббинг как “форму психологического насилия в виде травли сотрудника”, а вот определение “моб-программирования” от автора подхода Вуди Зила:

замечательные люди, работающие вместе над одной задачей в один момент времени в одном месте за одним компьютером.”

По сути, моббинг — стиль работы, когда команда постоянно работает вместе и вместе “набрасывается” на любые задачи.
Читать далее «Как убить очереди и ускорить команду при помощи моббинга»

Как фокус на занятости может повлиять на качество и гибкость в командах

О чем статья

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

Системные диаграммы

В статье некоторые концепции объясняются при помощи системных диаграмм (Causal Loop Diagrams).

Фокус на индивидуальной занятости снижает скорость

В первой части статьи мы подробно обсуждали, почему узкие специалисты в команде, работающие над “своими” задачами в Спринте, снижают общую скорость (Cycle Time) команды. Все дело в том, что узкие специалисты создают островки очередей. Когда возникает новая работа, то она помещается в конец очереди.  А это влечет за собой увеличение общего времени выполнения задачи, ведь Cycle Time = Queue Time (время простоя в очереди) + Service Time (время работы над задачей).

Читать далее «Как фокус на занятости может повлиять на качество и гибкость в командах»

Как обучение в команде влияет организационную гибкость

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

Как связаны скорость и гибкость в Скраме

Чем быстрее Скрам-команда поставляет готовые элементы Бэклога Продукта (PBI) на рынок (Time 2 Market), тем быстрее получает обратную связь, и тем больше знаний о продукте, клиентах, рынке она приобретает. Опираясь на обратную связь, Владелец Продукта изменяет порядок элементов Бэклога Продукта, размещая самое ценное наверху. На системной диаграмме это выглядит так: Читать далее «Как обучение в команде влияет организационную гибкость»

До старта команды: как определить продукт и сформировать команду

В этой статье

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

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

Часто в создание продукта вовлечены сотни и тысячи людей

В статье “Как определение продукта влияет на организационную гибкость” мы обсудили, что полноценное определение продукта включает в себя архитектурные компоненты и системы, различные функциональные группы (люди, команды), внутренние бизнес-процессы компании и каналы.

Почему так? Продукт имеет следующие атрибуты:

  • Пользователей на рынке (за пределами организации).
  • Ключевой функционал, закрывающий потребности пользователей.
  • Независимый P&L (бизнес-модель).

Читать далее «До старта команды: как определить продукт и сформировать команду»

Как определение продукта в Скраме влияет на организационную гибкость

Мы говорим “продукт”, но что это значит? Давайте разберемся, что такое продукт и как влияет его определение на организационную гибкость.

На что влияет определение продукта в Скраме

Определение продукта влияет на организационные элементы: людей, компоненты, процессы и системы. Например, продукт определяет:

  • Владельца Продукта.
  • Наполнение и объем Бэклога Продукта.
  • Количество и состав команд.
  • Определение готовности (DoD).
  • Пользователей продукта.

Что такое настоящий продукт?

В своей практике я использую чек-лист для определения продукта:

  • Есть пользователи на рынке (за пределами организации).
  • Есть ключевые фичи, которые закрывают потребности пользователей.
  • Есть бизнес-модель (независимый P&L).
  • Продукт поддерживается системами людей, процессов и компонентов.

Коммерческие организации создают продукты и сервисы для пользователей на рынке. Часто мы забываем об этом и придумываем искусственные понятия “внутренних продуктов” или “внутренних сервисов”. Настоящие продукты и сервисы имеют бизнес-модель и создают бизнесценность:

Выгода для организации, выраженная в деньгах, возникшая в результате эксплуатации сервиса или продукта.

Читать далее «Как определение продукта в Скраме влияет на организационную гибкость»

Почему менять правила Скрама — не лучшая идея

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

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

Метафора “озеро и камни”

Авторы Скрама Кен Швабер и Джефф Сазерлэнд долгое время изучали бережливое производство (Lean Thinking) и многие его концепции были заложены в Скрам. В том числе, метафора “озеро и камни”, в которой камни обозначают существующие несовершенства в команде и организации.

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

Скрам проявляет несовершенства в управлении продуктом и методах работы, чтобы вы могли постоянно улучшать продукт, команду и рабочее окружение (Руководство по Скраму, 2017).

Читать далее «Почему менять правила Скрама — не лучшая идея»

Митап «Звездный ресторан». Послевкусие

У нас традиция. Каждый год, 31 октября мы с друзьями ходим в ресторан. И в этом году мы поддержали традицию, нас ждал “Звездный ресторан”. Необычный по формату для нашей митап-группы Russian Lean/Kanban Network. И об этой встрече небольшая рецензия.

Читать далее «Митап «Звездный ресторан». Послевкусие»