Когда аджайл не работает

Ловушка для бизнеса. Шесть случаев, когда Agile бесполезен и опасен

Agile methodology, что в переводе значит «гибкая методология», — тренд среди программистов и разработчиков. Но принципы agile популярны во всех сферах бизнеса, ведь идея agile — в гибкости, способности адаптироваться под текущую ситуацию и корректировать сроки и отношение к продукту в зависимости от изменений. Пожалуй, это самый адекватный подход для российского бизнеса именно сейчас, в условиях нестабильности и невозможности долгосрочного планирования. Вот только на самом деле agile вовсе не универсален. Так в каких случаях этот метод не для вас?

1. Стоимость переделки очень высокая

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

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

2. Все по инструкции

Agile — путь инноваций и экспериментов. Иногда возможности для этого просто нет. Если у вас call-центр, в котором алгоритм действий оператора отлажен и жестко задан прописанным алгоритмом, то здесь в Agile нет необходимости. В данном случае конечный продукт — быстрое решение оператором проблемы позвонившего клиента — определяется четким следованием инструкции. И никаких отклонений от описанного алгоритма не допускается.

Однако, прописанный алгоритм ответов оператора покрывает не все случаи, по которым может звонить человек, почти всегда процентов 10% приходятся на непредвиденные «инциденты» — случаи, которые в алгоритме оператора не предусмотрены. Допустим, в колл-центр по обслуживанию 1С позвонит человек с просьбой о помощи — за ним гонятся и угрожают его жизни, а у него в телефоне был номер call-центра, и он его набрал в панике. Как должен поступить оператор, учитывая, что этот разговор — настоящий стресс для обоих? В алгоритме такого случая нет. Так вот, улучшать этот алгоритм, включая в него отработку непредвиденных «инцидентов» как раз можно итеративно — по Agile.

3. «Команда» из одного-двух человек

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

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

4. Нет четкого понимания, что и зачем мы делаем

Если у вас нет требований и видения продукта — хотя бы на уровне понимания вашего сегмента пользователей, их потребностей и ценностного предложения — то зачем вам Agile? Мы можем научиться делать быстро, увлекать сотрудников идеей, поставлять продукт на рынок, но если мы не попадем в пользователя, то у нас ничего не купят. По этому поводу вспоминается высказывание Сенеки (IV в. до н.э.): «Когда корабль не знает, в какой порт направляется, ни один ветер не будет для него попутным».

Например, в одном из банков решили сделать систему автоматизированного документооборота с регулирующими органами. Заложили большой бюджет, набрали команду разработки. Но разработчики за месяц успели реализовать маленькую, минимально жизнеспособную версию этой системы, а у менеджеров были масштабные планы на дальнейшую разработку. Наняли Agile-коучей, чтобы наладить рабочий процесс и сделать все быстро. Но первое же планирование работ с командой на ближайший месяц показало, что исходные продуктовые посылки никто не подумал проверить. Оказалось, что весь «поток» составлял 2-3 документа в неделю. После анализа оказалось, что дешевле нанять специального человека, который бы вел этот небольшой документооборот, используя ту небольшую систему, которую успели сделать разработчики, и больше ничего разрабатывать не потребуется. В данном случае все кончилось хорошо, но представьте, какие ненужные убытки и какой бесполезный продукт появился бы, если бы вовремя не проанализировали — а какова реальная бизнес-потребность в данном продукте?

5. Ваш ключевой подрядчик не умеет и не хочет работать по Agile

Определенная (а часто и главная) часть работ делается подрядчиком. Внутренние процессы подрядчика становятся ключевыми для нас, и как бы мы ни хотели снизить Time To Market (время выхода первой версии продукта на рынок), стать более гибкими, лучше реагировать на обратную связь от пользователя, пока мы не имеем влияния на то, как именно подрядчик работает — ничего не сдвинется с мертвой точки. Например, подрядчик отказывается вносить срочные изменения, потому что техническое задание утверждено и подписано на год вперед и ваши доработки он сможет внести только в следующем году за дополнительную плату.

Что делать? Наладить оперативный контакт с подрядчиком, в каком-то смысле перетянуть его на свою сторону. Например, переходить на аренду команды разработки и оплату времени работы этой команды (time & material), а чтобы команда делала именно то, что нужно — выделить со своей стороны продуктового менеджера к подрядчику, чтобы тот напрямую доносил видение продукта команде и осуществлял приемку. Вариантов организации масса. Но все они должны быть направлены на максимально тесное, прозрачное и оперативное взаимодействие с разработчиками подрядчика. Только после этого можно двигаться в сторону Agile.

6. Руководство не доверяет своим людям и не готово предоставить им свободу действий

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

Мы работали с владельцем компании по производству торгового оборудования, кассовых аппаратов, датчиков. Он жаловался, что на предприятии слишком долгий цикл разработки, и их начали уже обгонять конкуренты. В итоге выяснилось, что директор замкнул все решения на себя, постоянно меняет задачи, а менеджмент практически «парализован». Источником проблем был он сам.

В заключение хочется напомнить, что Agile — это не методология и не алгоритм, а четыре ценности:

• Люди и их взаимодействие важнее, чем процессы и инструменты;
• Готовый продукт важнее, чем исчерпывающая документация;
• Взаимодействие с заказчиком важнее, чем уточнение условий контракта;
• Готовность к изменениям важнее, чем следование первоначальному плану.

Опираясь на эти ценности, вы станете более гибкими, а ваш продукт быстрее завоюет рынок.

Источник

Почему Agile не работает и что с этим делать

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

Гибкие методологии не новы, не оригинальны и испробованы многими компаниями. И некоторые из них (как, например, американская компания-поставщих BI-решений для железных дорог Railinc) признают, что agile — лучшее, что могло с ними произойти. Правда, их энтузиазм разделяют не все. Крис Йорк (Chris York), тестировщик и разработчик с пятнадцатилетним опытом, утверждает, что ни разу в своей жизни не видел, чтобы гибкие методологии работали так, как надо.

Что значит, не работают?

По данным исследования VersionOne, 98% компаний считают свои agile-проекты успешными. Однако всего 7% респондентов сказали, что внедрение agile помогло компании лучше адаптироваться на рынке, и только 11% опрошенных заявили, что достигли высокого уровня компетентности внутри организации благодаря agile. Остальные 82% говорят, что всё ещё не достигли желаемого уровня «гибкости». Возможно, эти компании что-то делают не так, попробуем разобраться, что именно.

1. Общение — не самоцель

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

Многие компании осознали важность личного общения: IBM переместила удалённых сотрудников в офис, чтобы получить максимум от командной работы. Кроме IBM удалённых сотрудников «превращают в офисных» компании Reddit, Aetna, Bank of America и Best Buy. Диана Герсон (Diane Gherson) старший вице-президент по кадровой политике IBM говорит, что причина изменений состоит в том, что при этом подходе можно развивать «непрерывный процесс генерации инноваций».

Хуан Эмилио Инзауррага (Juan Emilio Inzaurraga), менеджер проектов компании Hexacta, также подчеркивает важность общения в agile-командах. Компания практикует ежедневные встречи/звонки с участием заказчика, и, по словам Хуана, это помогает ему определять прогресс команды, возможные узкие места и недостатки продукта. С другой стороны, встречи помогают разработчикам сконцентрироваться на текущей задаче, а новичкам и неопытным членам команды — лучше понять задачу и определить способы её выполнения.

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

Разумеется, если ситуация преподносится руководством именно так, энтузиазма у сотрудников новые подходы не вызовут. Более того, команда будет демотивирована — кто-то просто не сможет быстро перестроить режим работы, а кто-то будет открыто заявлять что раньше было лучше. Стив Берчук (Steve Berczuk), ведущий инженер и скрам-мастер в Fitbit, подчеркивает — в некоторых компаниях внедрение agile конфликтует с ранее принятыми политиками по найму удаленных работников.

Увлечение личными встречами тоже имеет свои негативные последствия. Например, опытный разработчик и резидент Quora Оливер Долан (Oliver Dolan) подсчитал, что на ежедневные встречи уходит 2640 минут или 44 часа за 1 спринт. Это не так уж и мало. Пользователи Hacker News также приводят множество аргументов против этих встреч: встречи убивают мотивацию, отвлекают, раздражают разработчиков, о чём также упоминает Джон Парселл (John Purcell), создатель образовательного проекта CaveOfProgramming.

Все эти опасения — не повод «отменять agile». Вопрос в том, насколько удачно компания сможет адаптировать гибкую методологию под себя. Например, другой резидент Quora, Патриция Оковицка (Patrycja Okowicka), разработчик с двенадцатилетним стажем, говорит, что в ее scrum-команде встречи занимают только 15% времени, остальные 85% — чистая работа. При таком подходе волноваться о том, что вся работа превращается в совещания, не приходится.

И несмотря на уверенность одного из создателей Agile Manifesto Роберта Мартина (Robert Martin) в том, что для достижения результата разработчикам нужно находиться буквально «в одной комнате», примеры того, как распределенные команды успешно внедрили agile, тоже существуют. Например, Джейми Болстер (Jamie Bolster), генеральный директор MentorMate, успешно управлял командой разработчиков, которые работали удалённо, с помощью agile. А Сандип Джоши (Sandeep Joshi), разработчик Microsoft, предлагает конкретные действия для грамотного управления удалённой командой.

2. Менеджер vs Надзиратель

Энтони Мерсино (Anthony Mersino), основатель тренинговой компании Vitality Chicago и автор книги «Agile Project Management: A Nuts and Bolts Guide to Sucess», утверждает, что менеджеров в agile вообще не должно быть. А Стив Деннинг (Steve Denning), автор шести книг о бизнесе и блога в Forbes, говорит, что «менеджмент» и agile — два разных мира. Предполагается, что члены команды могут сами организовать рабочий процесс и мотивировать себя.

К сожалению, многие реальные участники рабочего процесса считают такой подход, мягко говоря, оторванным от реальности. Патрик Харрингтон (Patrick Harrington), один из основателей и главный аналитик данных компании Paysa, подчёркивает, что опытные разработчики не нуждаются в постоянном надзоре, они уже достаточно взрослые и мотивируются KPI. Проблема в том, что менеджера обычно привыкли видеть «надсмотрщиком над разработчиками», в то время как в действительности (в особенности в agile-командах) его роль должна быть совершенно иной.

В сообществах вроде Hacker News [1, 2] разработчики отмечают, что «идеальный PM» должен быть на стороне команды, помогать каждому ее участнику разобраться в целях и задачах проекта, по возможности устранять мешающие факторы вроде нехватки ресурсов и (самое главное) защищать интересы и время разработчиков, а также ограждать команду от слишком частых совещаний и прочей энтропии. Такой подход позволит программистам работать слаженно и быстро реагировать на требования клиента — а это именно то, к чему стремятся agile-команды.

3. Agile-принципы != KPI

Agile — это набор принципов, а не самоцель — именно поэтому важно разделять подходы к работе и ее результаты. То, что команда следует принципам agile, влияет на скорость выполнения задач, но не всегда ускорение можно предсказать и замерить «на старте».

Один из участников этого треда на Hacker News проводит аналогию с футболом. В футбольной команде все игроки четко понимают цель, обладают навыками, чтобы её достичь. Каждый из них знает, как общаться с товарищами по команде так, чтобы они выполняли свои задачи, и каждый готов проявлять инициативу в сложившейся ситуации на поле. Никто не дышит футболистам в спину со словами: «Нужно забить гол через 15 минут и 48 секунд после начала матча и не минутой позже, даже если это невозможно». Такая команда работает слаженно и обычно достигает цели, и это именно то, что пытаются донести agile-методологии.

Следование принципам agile положительно влияет на эффективность работы, но (само по себе) не является показателем эффективности: выполнение формальных «ритуалов agile» не приблизит команду к достижению KPI. Более того, и показатели, по которым измеряется качество работы, с введением agile имеет смысл пересмотреть: если ваша команда должна незамедлительно реагировать на новые вводные, быстро адаптироваться к меняющейся ситуации, могут ли при этом оставаться неизменными KPI и подходы к их оценке? Этот вопрос, в частности, поднимает Джим Хайсмит (Jim Highsmith) в книге Agile Project Management.

Иногда такой «гибкий» пересмотр KPI «на ходу» требует немало смелости. Кстати, именно смелость сказать, что что-то в проекте идет не по заранее спланированному сценарию, как одну из важнейших качеств agile-лидера, выделяет Гари Поллис (Gary Pollice), практикующий профессор информатики и один из авторов книги «Разработка программных проектов. На основе Rational Unified Process (RUP)».

4. «Неформальный» agile

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

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

С другой стороны, нет необходимости и в «дословном копировании» всех нюансов того или иного подхода — особенно если вы не понимаете, что именно они дают вашему проекту. В конце концов, у всех методологий есть свои плюсы и минусы. Поэтому вместо междоусобных войн вроде: Lean vs Agile или Kanban vs Scrum, полезнее будет посмотреть на общие черты различных методологий, объединить самые выгодные для конкретной команды и проекта и внедрить их.

Один из успешных примеров — команда разработчиков RentaTeam. Они изменили принципы общения в команде и подстроили agile-методологии под свою команду и проект. Так agile обрёл смысл для сотрудников, а продуктивность разработчиков возросла на 30%.

По мнению Грега Йоргенсена (Greg Jorgensen), «типичного программиста» с сорокалетним опытом работы, увлечённая команда профессионалов, которая не зависит от решений сверху, понимает цели и требования и знает, как их достичь — вот, что сделает проект успешным. Методологии и инструменты — это прекрасно, но главное — это люди.

Источник