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

Когда люди обсуждают Скрам, то чаще всего возникает картинка выше: фреймворк и его роли, артефакты, события. Правила Скрама довольно просты, и они детально описаны в Руководстве по Скраму (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 варианта:

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