История эволюции одной Scrum команды
Всем привет!
Сентябрь этого года выдался насыщенным на события и поездки. После небольшого отпуска я отправился выступать на Krasnodar Dev Day #3. По мотивам моего выступления и написана эта статья. После этого я посетил пожалуй лучшую agile конференцию за последние пару лет — Agile Rock Conference 2018 в Киеве, Украина.
Помимо этого, я наконец-то собрался с силами и получил звание PSM II. Почитать мои советы и рекомендации по подготовке и прохождению данного теста Вы можете здесь.
Спасибо что продолжаете следить за моим блогом и приятного чтения!
Сегодня я хотел бы поделиться с Вами историей эволюции одной команды, работающей на основе Scrum фреймворка. Эта история произошла во время моей работы в N26 —самом быстрорастущем мобильном банке в Европе. Достижение и поддержание такого статуса требует высочайшего уровня гибкости, что уже давно стало одним из ключевых движущих факторов современного бизнеса.
Специалисты в области разработки программного обеспечения были в числе первопроходцев в этом направлении. Это дало почву для появления различных фреймворков и практик, позже объединившихся вокруг ценностей и принципов Agile Manifesto. Scrum является одним из них. Он занимает лидирующую позицию по использованию командами разработки во всем мире.
Предыстория
Команда, о которой я Вам сегодня расскажу, применяет Scrum c первого дня своего существования. Она была сформирована в апреле 2018 года и включала в себя двух немцев, австрийца, бразильца, итальянца, девушку из Беларуси и меня. Большую часть команды составляли специалисты, присоединившиеся к компании буквально 2–3 месяца назад.
Изначально мы применяли лишь инструменты и техники описанные в Scrum Guide. По мере того как команда становилась более зрелой мы начали вводить в обиход дополнительные практики. Занимая позицию Agile Coach в N26, в данной команде я выполнял роль Scrum Master.
Закладывая основы Scrum
Если Вы когда-либо читали Scrum Guide, Вам знакомы эти строки:
Scrum — это фреймворк, который помогает решать изменяющиеся в процессе работы задачи, чтобы продуктивно и творчески поставлять клиентам продукты с максимально возможной ценностью. Scrum является компактным, простым для понимания, но трудным для совершенного овладения.
И действительно, сама по себе структура Scrum является легковесной, однако ранее я не раз сталкивался с ситуациями, когда даже освоение азов фреймворка вызывало у людей проблемы. Так как большинство членов команды были новичками не только в компании, но и в мире Scrum, я подошел к процессу эволюционно, внедряя изменения шаг за шагом дабы снизить уровень стресса и избежать резкого отрицания.
Например, мы не стали приглашать стейкхолдеров продукта к участию в первом Обзоре Спринта (Sprint Review). Это позволило команде провести своего рода “репетицию” активности не покидая безопасную среду (safe environment). По своей сути, эта встреча действительно была репетицией — команда смогла ознакомиться с целью активности, определить комфортную для себя очередность шагов и роли, а также формат взаимодействия со стейкхолдерами для получения обратной связи. Последнее является важным условием для того, чтобы Ваш Обзор Спринта не превращался в простую демонстрацию проделанной работы (Demo).
По ходу второго Спринта Владелец Продукта (Product Owner) разослал приглашения к участию в Обзоре Спринта стейкхолдерам. Естественно, их список не получился оптимальным с первой попытки — это также требует инспекции и адаптации. По итогам Обзора и Владелец Продукта и Команда разработки были воодушевлены полученным фидбэком и общей оценкой проделанного труда со стороны посетителей.
После пятого Спринта мы отправились в другой офис компании для проведения Обзора Спринта уже с непосредственными пользователями продукта. В нашем случае ими являлись специалисты центра поддержки клиентов. По итогам проведенного с ними дня мы получили еще больше полезных инсайтов и знаний, что положительно сказалось в том числе и на нашем Бэклоге Продукта (Product Backlog).
В идеале, я рекомендую привлекать реальных пользователей продукта к регулярному участию в Обзорах Спринта. Это позволит Вам:
- обеспечить прозрачность в отношении Ваших планов и ускорить получение обратной связи от “рынка”;
- развить эмпатию к пользователям продукта у членов Команды разработки, что положительно скажется на их мотивации;
- подвергнуть Ваш Бэклог Продукта регулярной инспекции и адаптации, что позволит сделать его более релевантным реальным потребностям Ваших пользователей.
Другие инструменты и практики
Помимо применения Scrum, мы стали регулярно внедрять инженерные практики и инструменты оптимизации потока из Kanban, XP (Экстремальное Программирование) и Lean. Большинство из них команда использует и сейчас. Другие же утратили смысл и в этом нет ничего страшного — это часть естественного процесса эволюции команды.
Важно отметить что большинство из них предлагались и внедрялись самими членами Команды разработки, а не Скрам Мастером. Обычно для этого было достаточно “зеркалить” поведение команды, задавая наводящие вопросы, вместо того чтобы прямо указывать на имеющиеся проблемы или анти-паттерны. Главное преимущество — практики предложенные и внедренные самими участниками команды приживаются быстрее и чаще, так как люди изначально понимают их ценность и пользу.
Де-факто все Команды разработки в Scrum должны стремиться к достижению технического совершенства (technical excellence) по умолчанию. Применение практик из XP может стать существенным подспорьем. Регулярные сессии Парного (Pair Programming) и Моб программирования (Mob Programming) позволили всем членам команды достичь высокого уровня понимания технической составляющей проекта и сформировали платформу для обмена знаниями и опытом. Также эти и другие практики позволили нам поддерживать высокий уровень качества, ответственность за которое несёт вся Команда разработки, а не тестировщик или кто-либо другой.
Применение WIP-лимитов (WIP Limits) и Критериев “готовности” (Definition of “Done”) помогло выявить и устранить “узкие места” (bottlenecks). Помноженные на выдающийся уровень командной работы, эти факторы сделали наш поток (flow) более плавным и предсказуемым. Мы также пробовали применять Definition of “Ready”, но вскоре осознали что более плотная коллаборация с Владельцем Продукта и проведение сессий Уточнения Бэклога Продукта (Product Backlog Refinement) работают для нас лучше.
Проведенные в ходе запуска работы над новым продуктом offsite Kick-off и сессия Моделирования угроз (Threat Modelling) позволили заложить фундамент на будущее, приведя всех членов команды к единому пониманию Продукта, его Миссии, Пользователей и их проблем, а также обеспечить его защищенность от базовых уязвимостей.
Динамика внутри команды
Естественно, когда речь заходит о любом человеческом коллективе, в истории команды нашлось место конфликтным ситуациям и недопониманиям. Так, на одной из Ретроспектив команды в середине июля случилось “столкновение“ ”Скрам Мастера и Владельца Продукта. На какое-то время это поколебало атмосферу безопасности и единства команды, однако уже к конце следующего Спринта ситуация разрешилась и мы вынесли из нее несколько полезных уроков.
К сожалению, уже через месяц данный Владелец Продукта покинул компанию и мы были вынуждены заменить его другим. В том же месяце к нашей Команде разработки присоединился еще один специалист. Стоит отметить что команда с достоинством прошла это испытание и практически избежала отката к фазе “шторма” (storming), что обычно сопровождает любые изменения состава команд.
Промежуточные результаты
Выше Вы можете видеть несколько метрик, которые команда использует для самостоятельной оценки эффективности процессов. Это позволяет добавить data-driven подход в процесс инспекции и адаптации. Как Вы можете видеть, показатели Велосити (Velocity; измеряется в Стори Поинтах) и Пропускной способности (Throughput; в количестве задач) со временем стабилизировались и не демонстрируют существенных отклонений при условии их совместного рассмотрения. Команда также смогла выйти на регулярное достижение Цели Спринта (Sprint Goal) и поддержание высокого уровня качества, даже несмотря на отсутствие выделенной роли тестировщика или QA Engineer.
Важно понимать что оценка эффективности любой Скрам Команды только лишь на основе вышеперечисленных метрик не имеет смысла — ключевой метрикой всегда должна являться успешность разрабатываемого продукта. Также ни в коем случае не стоит применять их для сравнения нескольких команд между собой. Эти цифры и графики имеют смысл при рассмотрении только лишь в контексте конкретной команды. В добавок к этому, на жизни команды также сказываются такие факторы как отпуска, больничные, деловые поездки и прочее, что не отображено на графиках.
Помимо данных метрик, мы также использовали технику Проверки Здоровья Команды от Spotify (Spotify’s Squad Health Check) для само-диагностики перформанса команды каждые два месяца. Узнать больше о применении этого инструмента Вы можете из соответствующей статьи в моем блоге.
Основываясь на совокупности факторов (динамика в команде, производительность, поставляемая ценность и другие) я считаю что команда выиграла от применения эволюционного подхода внедрения изменений. Мы не только смогли избежать существенной просадки в производительности, но также сформировали среду, в которой все члены Скрам команды понимают и разделяют Ценности Скрама (Scrum values): Смелость, Фокус, Обязательство, Уважение и Открытость.
По своему возвращении из поездок я был рад увидеть что команда действительно взяла на себя ответственность за процессы и не “откатилась” к прежнему образу работы, который все еще местами наблюдается в компании. Этот факт является лучшим доказательством того, что люди в команде действительно поняли Scrum и выиграли от применения его и других инструментов, которые мы внедрили за эти 5 месяцев.
Спасибо за чтение. Надеюсь эта статья была Вам полезна! Отблагодарить меня за материал Вы можете “похлопав” и/или оставив свой комментарий ниже.
