Главная » Хабрахабр » Лечение «механического» Scrum. Часть 2. Команда

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

Продолжим разбор ролей и следующая на очереди – команда. В первой части мы рассмотрели тревожные симптомы и возможные способы «лечения» 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 развития продукта), то хочется идти к ней. Без чувства причастности ты рискуешь оказаться в рутине: обратная связь тебе особо не нужна, команда становится просто инструментом переработки ТЗ в функционал.

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


Оставить комментарий

Ваш email нигде не будет показан
Обязательные для заполнения поля помечены *

*

x

Ещё Hi-Tech Интересное!

Юнит тестирование скриптов баз данных

Принимая удобство в использовании юнит тестов на моем любимом С++, я попытался перенести свой опыт на TSQL, тем более что новый работодатель любит полезную инициативу на местах и раздает плюшки за оное. Просмотрел несколько известных фреймворкoв я пришел к выводу, ...

Теория счастья. Введение в мерфологию

Продолжаю знакомить читателей Хабра с главами из своей книжки «Теория счастья» с подзаголовком «Математические основы законов подлости». Это ещё не изданная научно-популярная книжка, очень неформально рассказывающая о том, как математика позволяет с новой степенью осознанности взглянуть на мир и жизнь ...