Лечение «механического» Scrum. Часть 2. Команда30.06.2018 23:32

В первой части мы рассмотрели тревожные симптомы и возможные способы «лечения» Product Owner в «механическом» scrum. Продолжим разбор ролей и следующая на очереди — команда.

Все же знают мантру, что команда должна быть самоорганизованной и кросс-функциональной, это выглядит как самая простая часть scrum: берем людей с нужными компетенциями, говорим им: «вы команда», и полетели! Но на деле все несколько сложнее.


image

Самоорганизация

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

Чем плохо:

Любые границы — ограничивают @КЭП

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

Как лечим: Для людей в команде отменяются все должностные инструкции и иерархии, структура стремится к плоской. Все, кто в команде — это разработчики продукта (других ролей scrum guide не допускает). Есть только ситуационное лидерство, и люди сами решают, как им комфортно работать, чтобы быть эффективными. Конечно же, есть общие правила игры в компании, команда никоим образом их не нарушает (хотя может влиять на изменение на уровне компании), но за все внутренние вещи отвечает сама. Если есть серьезные препятствия на пути отмены ограничений для разработчиков, то стоит эскалировать вопрос до тех, кто принял решение о внедрении scrum и agile трансформации. Можно попробовать запустить плоскую структуру, как эксперимент на несколько спринтов, а затем провести обширную ретроспективу, где всеми заинтересованными лицами обсудить результаты эксперимента.

Симптом: Люди, помимо работы в команде, должны выполнять другие функциональные обязанности в компании. Например: 50% времени выполняет задачи команды, 50% — задачи отдела (разработка, тестирование и т.п.).

Чем плохо: Одна из ценностей в scrum — это сфокусированность. Команда фокусируется на цели спринта и движется к ней. Если помимо работы в команде человеку приходится заниматься еще чем-то, то фокус теряется. Как следствие, результат работы будет хуже. Сложно поддерживать командный дух в таких условиях.

Как лечим: Нужно добиваться, чтобы люди, входящие в команду, работали ТОЛЬКО в этой команде. Для этого стоит понять природу работы, свалившейся на разработчиков команды извне, и найти способы делать её не ломая scrum. Наверняка эта работа необходима компании, поэтому в зависимости от специфики работы можно:

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


Кросс-функциональность

Симптом: Люди внутри команды выполняют только определенную работу, есть четкая специализация. Хуже когда это еще покрыто должностными обязанностями, регламентами и прочей бюрократией. Отсутствие (отпуск, больничный и т.п.) одного члена команды, уменьшает функциональность команды. Привет, bus factor.

Чем плохо: Если команда зависит от компетенций одного из её членов, это неустойчивая к изменениям команда. Выстраивать с ней коммуникации сложно, т.к. нужно понимать текущую её функциональность и помнить о рисках, связанных с таким уровнем отказоустойчивости. Узкая специализация разработчиков сильно усложняет организационную работу для команды: при планировании нужно много думать о том, кто и чем будет заниматься; не каждая задача нуждается в заданных пропорциях компетенций команды, следовательно собрать сбалансированный спринт сложно; в такой схеме обязательно возникает «узкое горлышко», снижающая общую скорость команды.

Что делать: Нужно пропагандировать и поддерживать t-shaped навыки. Чтобы команда оставалась гибкой, важно чтобы конкретная функция или знание не были сосредоточены в одном человеке. Нужно стимулировать и поощрять постоянное развитие. Важно следить, чтобы команда совершенствовалась, искала способы улучшить процессы. Как варианты развития t-shaped: проведение внутренних семинаров, где члены команды делятся друг с другом знаниями; принять правило выполнения непрофильной задачи каждый спринт каждым членом команды; парная работа над задачами и т.д. Можно искусственно стимулировать команду, «выключая» её членов на некоторое время: отпуска, семинары, тренинги, командировки и т.п.

Симптом: В цепочке создания ценности команда отвечает (оказывает влияние) лишь за небольшую её часть, и как следствие, команда не может выпускать инкременты самостоятельно.

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

Проиллюстрируем это примером из web. Где упрощенно создание новой фичи включает в себя следующие этапы:

  • разработка UI / UX прототипа
  • разработка дизайна
  • создание RESTful API
  • создание SPA
  • написание интеграционных автотестов
  • сборка и выливка на боевое окружение


Для этих работ необходимы различные компетенции. Пример неудачного разделения на команды: выделить команду А из UI/UX, дизайнеров и frontend разработки, они готовят свой инкремент в виде SPA;, но они зависят от того, когда backend подготовить API для работы нового функционала; ждут когда QA проверит все интеграционно и напишет тесты;, а потом еще ожидают DevOps, чтобы те раскатали все на бой. Такой команде А трудно отвечать за релиз и доставку ценности, она просто пилит «заготовку» — SPA.

Как лечим: Определяем, каких компетенций не хватает команде, чтобы доставлять инкремент. Наделяем команду этими компетенциями благодаря обучению существующих членов команды, или добавлением новых игроков в команду. Т.к. найти / научить людей — задача не самая простая и быстрая, то можно налаживать коммуникации с соседними командами / отделами, объясняя им ценности scrum и договариваясь с ними об специальных регламентах / правилах взаимодействия, при которых они не будут ломать scrum вашей команде. Стоит подсветить процесс расширения функциональности команды: после первой ретроспективы и определения недостающих компетенций, можно их распечатать и разместить перед командой. Когда команда справляется с отсутствием компетенции (научились; новый член команды; настроили эффективную коммуникацию с другой командой и т.д.), то поверх ранее недостающей компетенции вешаем решение. Со временем команда должна стремиться расширять свою функциональность, чтобы полностью покрывать цепочку создания ценности.

Команда и продукт

Симптом: Команда есть, а продукта нет. Нет PO, нет backlog. Просто люди делают задачи, приходящие с разных сторон.

Чем плохо: Это не scum. Когда за командой не закреплен продукт, то команда вряд ли будет «гореть» работой. Когда есть глобальная цель (видение / стратегия / roadmap развития продукта), то хочется идти к ней. Ты делаешь работу, получаешь обратную связь, рефлексируешь и делаешь следующий шаг. Без чувства причастности ты рискуешь оказаться в рутине: обратная связь тебе особо не нужна, команда становится просто инструментом переработки ТЗ в функционал.

Как лечим: У команды должны быть свой продукт с backlog и PO, который сможет зажечь команду продуктом и увлечь её за собой — в этом суть. Нужно понять, зачем вам scrum? Понять, откуда у команды берутся задачи? Понять, есть ли среди этого потока «продукт»? Выбрать среди «заказчиков» команды одного и сделать его владельцем продукта, наделив его единоличным правом отвечать за backlog. Возможно, придется разделить команду на scrum команду работающую с одним PO (это может быть «пилотная» scrum команда) и вторую команду, ПОКА работающую по-старому с остальными «заказчиками». Обеспечивая максимальную прозрачность процессов и результатов, происходящих в новой scrum команде, можно заложить базис для дальнейшего распространения scrum и agile в организации.

Симптом: Команда не имеет влияния на продуктовую составляющую: она не решает, «как делать?», команде просто говорят «что делать?», т.е. на вход приходит ТЗ, а команда рассматривается как функциональная единица.

Чем плохо: Это очень опасный вариант, если в компании действительно провозглашаются ценности agile и scrum. Обычно это подразумевает, что все сотрудники — классные профессионалы, способные решать любые задачи, которые не боятся принимать решения и брать ответственность. Но если не дают принимать продуктовые решения, то вся свобода творчества у команды обычно с продукта перекидывается на технологии. Раз команде не дают решать, как сделать жизнь пользователя легче, мир лучше, а продукт полезнее; то команда начинает развивать кодовую базу, пробовать новые технологии / инструменты / фреймворки и т.д. Возникает конфликт интересов между PO и командой, команда начинает продавать «рефакторинги», «оптимизации», «серебряные пули» в виде нового стека и т.д. А страдают от этого в первую очередь пользователь и продукт. В процессе перехода от директивных моделей управления к agile есть опасность застрять в понимании команды как функциональной единицы (команда до этого не принимала решения). Это чревато тем, что либо убьем инициативу команды, либо придем к ситуации, когда команде интереснее технологии, чем продукт.

Как лечим: нужно выявить причину недоверия к команде или её нерешительности: почему команда не ищет решения, а работает только с детальным тех.заданием? Найдя причину, можно постепенно устранять её. Например:

  • У команды не хватает компетенций или опыта.: Кто-то же прорабатывает решения и пишет ТЗ, можно либо добавить этого человека в команду, либо позволять ему работать над некоторыми задачами совместно с командой, тем самым передавая часть своих навыков и опыта команде. Так постепенно команда научится и привыкнет решать продуктовые задачи.
  • У руководства есть страх, что команда ошибется.: Это краеугольный страх при переходе к agile, но, не преодолев его, не получится приобрести всю силу scrum команды. Команда обязательно ошибется, потому что ошибаются все. Но ошибка — это источник опыта и мастерства. Полезнее, когда команда ошибется, потому что она так решила, а не из-за неправильного внешнего ТЗ. Scrum — это ритм: быстро сделали решение для проверки гипотезы; получили обратную связь; осознали, что пошли не туда; выкинули решение. Стоимость ошибки резко сокращается (потратили спринт, а не квартал / год / ваш релизный срок), что позволяет переступить через страх ошибки.

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

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

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


Заключение

В следующей части продолжим рассматривать роли scrum, и доберемся, наконец, до scrum master-а. Кратко напомню, что вам делать с симптомами:

  1. Отбираете симптомы, применимые к вашей ситуации.
  2. Из них выбираете наиболее острые.
  3. Осознаете эту боль.
  4. Придумываете с командой решение (за отправную точку можно брать кейсы из статьи).
  5. Реализуете ваше решение.
  6. Переходите к пункту 1.


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

Спасибо Sai Kin за илюстрации.

© Habrahabr.ru