Почему Agile не работает?

Автор заметки: Джон Катлер (John Cutler). Оригинал опубликован здесь.

Пару лет назад ко мне заезжал родственник (CEO страховой компании), которому успешно продали красивую идею Agile. Он поверил в нее и вскоре облажался: «Все это сплошная симуляция и обман! Мы изменили практически все в том, как мы работаем. Мы привели консультантов. Мы наняли звездных проектных менеджеров. И ничего, ни-че-го! Вообще ничего не изменилось. И никакой ответственности за результат: все, что я слышу – это отговорки и оправдания».

Не помню, что я ответил ему тогда, но я знаю, что бы я ответил сегодня. Я бы нарисовал пару картинок и даже не стал бы упоминать слово “Agile”.

Эффективность потока

Если разобрать Lead Time, можно заметить, что большая часть времени тратится на ожидание. 15-процентное соотношение времени работы (work time) к общему времени выполнения задачи (lead time) – это нормально. Лучшие достигают показателя в 40%.

В то время, как большинство команд концентрируются на сокращении времени работы (work time), секрет успеха кроется в сокращении времени ожидания (waiting time).

Источник: Hackernoon

Незапланированная работа и переключения

75% времени сотрудники теряют на незапланированную работу и переключения с одних задач на другие. Столь ужасающие факт остается в тени и, конечно же, не отражается в учетных системах, но изо дня в день изводит всех участников. Теперь представьте, что речь о “shared service”,  и команда разработчиков также занимается эксплуатацией. Незапланированные работы могут вовсе парализовать всю проектную деятельность.

Источник: Hackernoon

S, M и L

Посмотрите на время выполнения больших, средних и маленьких задач. Скорее всего, вы заметите, что во многих организациях размер задачи никак не связан со временем ее выполнения. Почему? Слишком много факторов влияет на то, как долго выполняется работа: взаимные зависимости, незапланированная работа, большое количество задач, одновременно находящихся в работе и так далее.

Источник: Hackernoon

Получение выгод

Титанические усилия мы тратим на то, чтобы снизить так называемый проектный риск (delivery risk) (своевременно и в полном объеме). Это имеет смысл, если мы занимаемся разработкой уникального продукта и заказчик платит нам по факту его предоставления. Но взглянем на услуги типа SaaS (software as a service): факт оплаты не привязан к факту завершения работ над услугой, а выгода потребления услуги для заказчика проявляется со временем. Поэтому уместнее говорить о риске неполучения выгоды (benefit risk) – результат работы не будет востребован.

Большие компании применяют agile, но не видят никаких финансовых преимуществ. Почему? Разработка идет быстрее, но это никак не связано с: а) правильными решениями по развитию продукта; б) работой по пониманию выгод заказчика.

Многие применяют agile, как показано на картинке слева. Единицы следуют тому, что показано справа. Когда компании получают убогие результаты, они пытаются впихнуть в систему еще больше работ, делая всех еще более несчастными.

Источник: Hackernoon

Неуправляемый рост сложности

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

Источник: Hackernoon

Agile

Так вот на счет Agile. Agile бесполезен до тех пор, пока не используется как катализатор постоянного совершенствования. Забудьте Scrum и SAFe, если не готовы играть в долгую. Факторы, которые замедляют работу, только частично зависят от того, «спринуете» ли вы, пишете ли user stories и готовите ли каждые две недели новые демки или нет. Рискну заявить, что все это сравнительно малозначимо с тех пор, как вы прониклись идеей инкрементального снижения риска.

Чтобы “быть agile” по-настоящему, потребуется куда больше:

  • Делать работу, которая действительно значима (с точки зрения выгод). Делать меньше.
  • Прояснить поток создания ценности.
  • Автоматизировать pipeline (DevOps).
  • Менять культуру.
  • Перестать привлекать деньги под проекты, привлекать деньги на реализацию миссии (mission-based funding)
  • Перераспределять ресурсы для управления сложностью (проводить регулярный рефакторинг).

Никакой серебряной пули. Здесь по-прежнему много работы. Опасайтесь тех, кто говорит обратное.

Share on FacebookTweet about this on TwitterShare on Google+Share on LinkedInEmail this to someone

The Phoenix Project Основы DevOps

Новый учебный курс 2017
 

Проект Феникс — DevOps на практике

Новая деловая игра от GamingWorks
 

DevOps: погружение

Новый корпоративный семинар
 

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

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Ближайшие мероприятия

Зарегистрируйтесь, чтобы получить больше полезных знаний:

НОЯ
27
Учебный курс:
Основы ITIL (очно)