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

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

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

Вполне может быть, что ваши программисты ненавидят Agile только потому, что вы заставляете их делать это неправильно. Но также возможно, что вы делаете это правильно, и ваша команда в целом не любит эту идею. В этом случае остается только подождать, пока он вырастет в команде, или заменить команду.

Люди, использующие Agile, решают, над чем им работать, имеют право голоса в отношении внешнего вида и функций продукта и получают значительный контроль над проектом в целом. Возможно, стоит рассказать об этом своим сотрудникам.
Имейте в виду, что Agile был задуман как подход к программированию… самими программистами
- а не руководителями проектов.
Может быть, тогда , что основное различие между Agile в том виде, в каком они были разработаны, и Agile, которые использовались в последнее время, заключается в том, что они стали больше областью управления проектами, а не программистами? Если так, то единственное решение - забрать его обратно у ПМ!

Понимая причины, по которым некоторые не в восторге от Agile, есть один способ взглянуть на Agile, который приводит к провалу большинства аргументов: это примета времени.
Факты таковы, что что угодно метод, который вы выберете, в наши дни он по-прежнему будет учитывать постоянно меняющийся потребительский спрос и, таким образом, следовать потребности заинтересованных сторон в итеративном контроле результатов вашей работы.
Другими словами - как бы вы ни хотели позвонить вы будете выполнять некоторую форму гибкой разработки.

И еще: естественно, что несчастная сторона любой истории кричит громче. Вы не представляете, сколько разработчиков считают Agile рабочим методом и не видят в нем ничего, что могло бы вызвать гнев. Но всегда есть что сказать недовольным, не так ли?
Итак: попробуйте, настройте (да, Agile Manifesto упоминает только несколько ключевых рекомендаций, ни в одном из которых не упоминается Scrum, спринты или в частности, ежедневные стендапы) и только потом решайте, на какой стороне забора вы находитесь. Спасибо!

Первоначально написано для Канбан-инструмента Блог.