Скрам как движок организационных изменений

Когда люди обсуждают Скрам, то чаще всего возникает картинка выше: фреймворк и его роли, артефакты, события. Правила Скрама довольно просты, и они детально описаны в Руководстве по Скраму (Scrum Guide). Очевидно, что людей привлекают потенциальные преимущества Скрама (скорость, бизнес ценность и т.д.). Ко мне на открытые тренинги частенько приходят руководители компаний (в том числе и вне IT), которые, прочитав нашумевшую книгу Джеффа Сазерленда “The Art of Doing Twice The Work In Half The Time”, с нетерпением хотят как можно быстрее внедрить Скрам, чтобы получить обещанные бонусы. И кажется, что стоит лишь определить роли, пройти сертификационный тренинг — и дело в шляпе! К сожалению, это не совсем так, а точнее… совсем не так. И вот почему.

Другая сторона Скрама (“темная сторона луны”).

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

Свобода.

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

Скрам Команда — самоорганизованная и самоуправляемая единица, которая в идеале должна самостоятельно принимать решения по максимально широкому кругу вопросов. Назову лишь несколько:

  • Как выполнять свою работу (дизайн, архитектура, моделирование, планирование, какими инструментам пользоваться и т.д.)
  • Состав команды (кого нанимать и увольнять решает Команда Разработки совместно с Владельцем Продукта, последний подкрепляет принятые решения бюджетом).
  • Координация — кросс-функциональные команды сами принимают решения о форматах внутреннего и внешнего взаимодействий. Отпадает необходимость в роли менеджера, потому что координация кросс-функциональных команд тривиальна и может выполняться Разработчиками.
  • В парадигме Скрама Владелец Продукта = mini-CEO = “Стив Джобс” и отвечает за ROI/P&L, самостоятелен в своих решения, определяет видение продукта, дает определение бизнес ценности и отвечает за ее оптимизацию.

Командная работа.

Командная работа в Скраме предполагает:

  • Общий успех или неуспех (подумайте, как сюда вписываются индивидуальные KPI в организации).
  • Отсутствие формальной иерархии внутри команды ( “в Команде Разработки не может быть иных титулов кроме как Разработчик. Этому правилу нет исключений”).
  • Активная помощь друг другу и выход из парадигмы “я Java разработчик, моя работа — писать код на Java”. Главная задача каждого члена Команды Разработки — максимальная помощь команде в том, чтобы передвинуть “мяч” как можно дальше (отсюда и термин Scrum).
  • Командная ответственность за результат (подумайте, насколько организационная структура и система бонусов и performance appraisal обеспечивает этот пункт).

Кросс-функциональные и кросс-платформенные команды.

Большинство организаций построено вертикально или по “функциям” — департаменты и подразделения объединяют людей одной специализации (Marketing, Sales, IT/R&D, Compliance). Внутри каждого “функционального колодца” выделяется линейный менеджер. R&D или IT обычно имеют еще и свои внутренние колодцы (Development, Testing, Analysis, Component 1.. Component N). Подобная структура оптимизирована под максимальную утилизацию ресурсов (“efficiency”), но имеет мало общего с бизнес гибкостью и адаптивностью организации (“effectiveness”), так как для создания ценности для внешнего клиента необходимо кросс-функциональное и кросс-платформенное взаимодействие нескольких подразделений. Часто это влечет за собой расформирование функциональных подразделений и переход к Feature командам.

Инкрементально-итеративная разработка.

Инкрементально-итеративный подход предполагает, что финальный продукт рождается в результате многочисленных экспериментов и получения обратной связи от конечных пользователей и заинтересованных лиц. Итеративность предполагает изменения того, что было сделано на предыдущих шагах. Это автоматически значит изменение правил игры и уход от Fixed Scope-Price-Time контрактов и переход к прямому взаимодействию бизнеса с разработкой (Customer Collaboration over Contract Negotiation). Влечет ли это за собой потенциальные организационные изменения? Скорее всего.

Эмпирический контроль процессов.

В конце каждого Спринта команда создает “готовый” Potentially Shippable Product Increment (PSPI). Таким образом Владелец Продукта получает бизнес гибкость и может в любой момент принять решение о выводе продукта на рынок. А еще появляется прозрачность — заинтересованным лицам понятно текущее состояние продукта и прогресс в разработке. Часто прогресс неудовлетворительный и это ОК — можно досрочно прервать разработку продукта и направить оставшийся бюджет на другие инициативы (“однозначный успех!”).

Самое важное — не обвинять Скрам в том, что он просто подсветил существующую вариативность в разработке, и уйти от желания скатиться в уже знакомую игру под названием “выигравший-проигравший” или Fix-Price Contract с атрибутами вроде “Commitment” и отсутствием прозрачности.

Пример изменения организационной структуры при внедрении Скрама.

Хочу поделиться примером успешного внедрения Скрама в небольшой продуктовой организации до 200 человек. До внедрения Скрама организационная структура была довольно типичной и состояла из большого количества функциональных подразделений (см. на картинку ниже) с типичными “болячками” подобной структуры:

  • Слабое взаимодействие между функциональными подразделениями.
  • Отсутствие ответственности (“моя работа — бла бла бла…”).
  • Излишнее количество менеджмента + эффект испорченного телефона (“hand-offs”).
  • Отсутствие гибкости, низкая скорость разработки.
  • Отсутствие прозрачности, где мы находимся сейчас?

Теперь внимание — организационная структура компании после внедрения Скрама (см. на картинку ниже):

Изменения в организационной структуре:

  • Несколько функциональных подразделений были объединены в одну продуктовую группу.
  • Количество менеджеров сократилось.
  • Команды перешли от компонентной к кросс-функциональной структуре.
  • Бизнес и разработка оказались в одной продуктовой группе и между ними возникло прямое взаимодействие.

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

Так что же такое Скрам?

Скрам — двигатель организационных изменений, который помогает компаниям становится более гибкими и адаптивными. Правильное внедрение Скрама в организации влечет за собой НЕИЗБЕЖНОЕ изменение организационной структуры, ее упрощение (“уплощение” 🙂 или “блинизация” ) или de-scaling.

Если ваша организационная диаграмма не изменилась после внедрения Скрама, то возможны 2 варианта:

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

Scrum ON!

Share this nice post:

2 комментария on “Скрам как движок организационных изменений”

  1. Станислава:

    Хотим новую тему статей! Как сделать клевый скрам там, где уже делают хороший скрам? Очень нужно!!! =)


Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *