Как продать Agile? Часть 2 – Как продать тем, кто знает что есть Agile

Они строго говоря тоже делятся на 2 части:

  1. те, кто действительно знают, что такое agile;
  2. те, кто слышали про agile, и хотят попробовать.

Продажа вторым ничуть не отличается от продажи тем, кто никогда не имел дела с agile – просто происходит легче, так как Заказчик “предрасположен”. Работать с первыми – несравненно сложнее. Итак, как действует agile-Заказчик, который покупает agile-проект? К чему быть готовыми? И зачем он это делает?

  1. Он потребует чтоб ему представили команду. Причем прямо в ее рабочем месте. При этом он будет смотреть, насколько место обжито командой – то есть на самом ли деле “они работают вместе уже 2 года” или их посадили вместе вчера? Зачем ему это надо – он хочет сработанную команду, с минимальной вероятностью конфликтов. Причем скорее всего потребует зафиксировать состав членов команды в контракте. Замесы типа “у нас вся компания – одна команда, кого не поставь – все будут отлично работать!” не пройдут. Квалифицированный agile-Заказчик всегда покупает именно команду. Почему – см. ниже.
  2. Он предложит сделать притирочный workshop. Ну там знаете – шарики понадувать, кубики покидать, но все это в режиме реального scrum, пусть и со спринтами по 15 минут. Смотреть при этом он будет на владение терминологей, предупредительность к Заказчику, соблюдений рекомендованных практик. Зачем ему это надо? Проверить, насколько команда умеет работать по agile – имеет поставленный процесс или читала книжку и сейчас вырабатывает соглашения.
  3. Он захочет увидеть среду continuous integration и какой-то предыдущий проект команды. Потому что даже следы двухнедельной деятельности команды очень трудно эмулировать. И из артефактов станет понятно, насколько толковый тестер, как аккуратно оформляются чейнджсеты и коммиты, и вообще как люди работают вместе. Зачем ему это надо? Увидеть, насколько технически зрелой является среда, в которой работает команда. Это дает некоторые основания считать, что будет качественное решение.
  4. Он затеет peer codearchitecture review предыдущегоодного из проектов команды. Причем среди peers обязательно будет Архитектор Заказчика. Зачем ему это надо? И тут как дважды два станет понятна вероятность получения качественного решения.
  5. Он попросит посмотреть burnout charts предыдущих проектовспринтов. И конечно же будет искать ненормальные прекращения спринта, недовыполненные обещания и задавать вопрос “почему?”. Зачем ему это надо – понять, с какой скоростью работает команда, и насколько она аккуратно делает оценки и выполняет обещания.
  6. И только после этого он затеет тестовый спринт. Причем скорее всего честно вас предупредит – “кроме вас тут еще 4 команды делают тестовый спринт, и вот по результатам выступлений мы выберем лучшую, которой и отдадим проект”. Зачем ему это? Чтобы не только выбрать самую производительную команду, но и задать высокий темп бега с самого старта дистанции.

Итого. Если вы в своей sales-презентации заявили, что “our team is capable to deliver true agile” – будьте готовы к изложенным выше моментам. Если вы не готовы подтвердить декларацию опытной командой – лучше сразу честно сказать, что мы обучение прошли, но команда вместе не работала.

В следующей части я расскажу как продавать agile тем, кто не имеет о нем представления.

Tags: ,

Post Author

This post was written by who has written 29 posts on Agile.by.

  • magnet

    Спасибо за статьи!
    Жаль что так и нет продолжения.
    Интересно было бы узнать о :
    1. О том как продать Agile тем кто не имеет о нем представления – сомневаются что “это все будет работат”

    2. Немного не по теме – как “продать” agile внутри фирмы

    • http://thetorch.ru/ Денис Петелин

      Привет.
      Да как-то особо резонанса не вызвало – вот и не собрался дальше писать 🙂
      Но раз надо – могу собраться.

  • http://www.idea2site.com Алекс Гольцман

    Решать конечно тебе, но было бы интересно.

    У тебя есть опыть “продажи” agile в нутри команды? фирмы?