Насколько ваша команда соответствует принципам agile? Пять вопросов для проверки

Автор оригинала: Dan R Greening
  • Перевод


Такие гибкие методологии, как Lean Startup и Scrum, помогут вам понять, чего хотят клиенты, и как им поскорее это дать. Сильнейшие Agile-команды следуют пяти основным паттернам. Чтобы понять, соответствуют ли ваши рабочие процессы принципам Agile, проверьте, насколько вы следуете этим паттернам. Чтобы оставаться гибкими, следуйте этим паттернам постоянно.

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

Мы нехотя платим за быструю адаптацию и эволюцию – мы увеличиваем в 10 раз частоту релизов, сжав зубы, страдаем на собраниях и ругаем скрам-мастеров, автоматизируем то, что раньше делали вручную, пересматриваем даты по контрактам, обучаем персонал и так далее – все потому, что хаос никуда не уходит. И если мы справляемся с хаосом лучше, чем наши конкуренты, мы выигрываем.

Мы не можем точно ответить на вопрос: мы уже Agile-команда? Абсолютно «гибких» команд не бывает. Но мы можем ответить, насколько мы соответствуем принципам Agile. Мы можем быть более или менее «гибкими», чем мы были раньше; более или менее «гибкими», чем конкурент.

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

Итак, начинаем…

Основные Agile-паттерны




Организации/команды, следующие принципам Agile…

  • измеряют экономический прогресс (например: скорость, индекс потребительской лояльности, число переходов, динамику изменения метрик, соответствующих стратегии компании),
  • проводят эксперименты ради улучшений (т.е. проводят ретроспективы в Scrum, активно работают с фидбеком в Lean Startup),
  • ограничивают количество одновременно выполняемых задач (т.е. отслеживают каждый спринт, работают только над конкретными задачами).

Устойчивые организации/команды, следующие принципам Agile…

  • берут на себя коллективную ответственность (это может проявляться в рамках планирования спринта или формирования ответственности перед владельцем продукта в Scrum, коллективное владение кодом в XP).

Расширяющиеся организации/команды, следующие принципам Agile…

  • решают проблемы системно (например, используют метод пяти «почему», теорию ограничений).

Первые три модели позволяют создать нечто, что я называю «хрупкий Agile». Если вы измеряете экономический прогресс, постоянно экспериментируете и ограничиваете количество открытых задач в спринте, то это значит, что вы умеете реагировать на изменения, адаптироваться и быстро работать. Но вы долго так не протянете.

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

Принятие четвертого паттерна дает нам «устойчивый Agile». Коллективная ответственность (или просто личная ответственность для отдельного человека) мотивирует людей искать недостающие команде навыки, исследовать изменения рынка и учиться. Некритичные изменения просто мотивируют людей учиться больше.

Пятый паттерн – «решать проблемы системно» – расширяет нашу экспертизу и позволяет использовать подходы, выходящие за пределы нашей Agile-команды или компании. Между «гибкой» организацией и ее окружением нет жестких границ. Да, мы продолжаем брать на себя коллективную ответственность: исправлять проблемы в продукте – наша работа; но найденные нами решения могут оказаться полезны нашим поставщикам, боссам, другим отделам – для общей выгоды. Компании Toyota пришлось обучить не только своих поставщиков, но даже своего конкурента General Motors, чтобы те приняли производственную систему Toyota для облегчения процесса адаптации к постоянным изменениям.

Джефф Сазерленд (один из создателей Scrum) недавно бросил мне вызов: найти точное определение гибкости. Ничего не найдя, я придумал его сам. Достаточно ли этих пяти паттернов, чтобы дать определение устойчивым гибким методологиям? Да. Есть ли хоть один не-Agile подход, который бы соответствовал хотя бы одному из этих пяти основных паттернов? Нет. Идем дальше!

Измеряем «гибкость»




Теперь, когда мы дали определение гибкости, вы можете оценить собственную гибкость, отвечая на эти вопросы:

1. Насколько легко и часто мы измеряем наш экономический прогресс?

Рассчитываем ли мы свою юнит-экономику? Есть ли у нас сопутствующие стратегия и метрики? Какие метрики фиксируют наши основные индикаторы? Можем ли мы улучшить наши показатели для большего соответствия стратегии компании и экономике в целом?

2. Экспериментируем ли мы ради улучшений?

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

3. Ограничиваем ли мы открытые задачи?

Сколько мы уже сделали работ, не вошедших в релиз? Какой длины наши спринты? Как насчет нашего планирования? Много ли ресурсов мы тратим на планирование, оценку, проектирование? Получим ли мы тот же результат, если будем меньше времени тратить на разработку, планирование, оценку и проектирование?

4. Есть ли у нас коллективная ответственность?

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

В рамках проверки можно выявить очевидные признаки, что сотрудники и руководители не чувствуют коллективной ответственности: отрицаем ли мы существование проблемы? Часто ли мы виним в проблемах других? (Если из вашей компании внезапно и таинственно исчезают хорошие сотрудники, то у вас, вероятно, есть эта проблема). Обвиняем ли мы организационную политику и структуру компании в наших проблемах? Чувствуем ли мы вину (виним ли мы самих себя в чем-либо)? Тащимся на работу, как зомби, только потому, что нам надо оплачивать счета?

5. Решаем ли мы проблемы системно?

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

Отвечая на эти вопросы, вы оцениваете свою гибкость. Какова ваша организация: она хрупкая, устойчивая или расширяющаяся? Однако не останавливайтесь на этом, задайте те же вопросы своим коллегам. Что насчет ваших руководителей? Насколько они «гибки»? Какие простые, наименее политически опасные меры они могут предпринять, чтобы повысить гибкость организации?

Конечно, дело в том, что эти вопросы помогут не только оценить, насколько быстро вы выделяете основные препятствия и реагируете на внешние изменения; эти вопросы помогут вам усовершенствовать эти процессы. И это именно то, что вы хотите узнать, когда спрашиваете: «Насколько мы соответствуем принципам Agile», верно?



P.S. Дэн Грининг (автор оригинала) является одним из докладчиков тематической конференции Lean Kanban Russia, которая пройдет в Москве со 2 по 3 октября 2015 года. Регистрация уже открыта – приглашаем к активному участию!
ScrumTrek
Мы помогаем компаниям стать крутыми!
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама

Комментарии 5

    +6
    Один из главных недостатков гибких методологий — это неоправдано высокий упор на идеальную команду. Создается впечатление, что рынок труда переполнен гиперответственными сотрудниками, готовыми часами работать за идею, самообучаться, и приносить доход работадателю. И каждая подобная статья, как будто внушает, что достаточно сказать «встань и будь ответственным членом команды!», чтобы решить все проблемы мотивации\стимуляции.
    Мой опыт (и опыт управления персоналом, как научной дисциплины) показывает, однако, что люди приходят в организацию решать свои проблемы, строить свою карьеру. Инструменты, в которых ключевым является человеческий фактор (практически жертвенная вовлеченность всей команды) — создают огромный риск провала. Гораздо проще, эффективние, и интереснее выяснить, каким способом можно стимулировать команду к ответственности. Без этого, все agile-манифесты похожы на план:

    1. начать работать по agile
    2. прочесть пару мотивирующих статей
    3. ???
    4. ???
    5. PROFIT!!!
      0
      Вы все правильно говорите. Но это не противоречит, то му что написано, а скорее дополняет. Никто не говорит, о жертвенности. Конечно, над мотивацией команды надо работать, просто это вне рамок данной статьи.
        +3
        дело не в данной конкретной статье, а в тренде. Такое ощущение, что этот топик (а имено, где же взять такую команду) вне рамок всех статей о гибких методологиях в принципе :)
          0
          Суть в том, что почему то все думают, что Agile существует в условиях идеальных команд, но пердыдущие 8 лет работы по гибким методологиям дал мне понять, что Agile и его инструменты Scrum/XP/Kanban — созданы не для готовых команд, а именно как инструмент взращивания таких команд, засчет встроенных циклов обратной связи правил построения команд
        0
        + много

        Почему-то существует представление, что та или иная методология суть офигенная такая штуковина, которая одним фактом своего существования решает все проблемы.
        Методология не научит работать на совесть, не даст опыта, не принесет выгоду сама по себе. Она может спасти проект, если, допустим, из команды уходит ключевой сотрудник, но не способна родить этот самый проект и собрать для него команду.
        Следование принципу «у нас теперь agile, а значит всё зашибись и всё в шоколаде» порождает иллюзию отсутствия проблем, а это гораздо больший риск, чем то, что она призвана решать.

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

      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

      Самое читаемое