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

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

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

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

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

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

Ошибка же строить процесс следующим образом: в первом спринте аналитика, во втором разработка, а в третьем тестирование. Фейковые спринты.

В чем же отличие тогда от классического вотерфолла, с последовательными этапами, кроме нового названия? На практике ни в чем!

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

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

Четвертая важная основа фреймворка - доверие.

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

Пятый важный пункт - это ценности Scrum. На них построен фреймворк. Без них команда будет механически выполнять ритуалы.

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

  Это также смелость признавать свои ошибки и открыто о них говорить. Смелость брать на себя обязательство и ответственность.

• 2 ценность - это уважение. Уважение к членам команды, к продукту, к заказчику и конечному пользователю. Без уважения все остальные ценности могут быть подставлены под сомнения. 

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

• 4 ценность - обязательность. Команда в начале спринта, берет на себя обязательство достичь цели спринта. Эта ценность о том, чтобы команда делала все возможное и была замотивирована в достижении цели.

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

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

Начинает возникать вопрос, почему? Скрам что ли не работает?

Да нет. На самом деле все дело в том, что Скрам создаёт условия, в которых все ранее спрятанные и сглаженные проблемы вылазят наружу.

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

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

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

• Зарегистрироваться на бесплатный урок