Почему не работает Аджайл — замеченные антипатерны и невзлеталки

Действительно, все команды счастливы по разному, но огорчены одинаково — не взлетело. Почему? Почему Аджайл продолжает невзлетать несмотря на конференции, тренинги, преобладании в проектах умных и опытных людей? Почему  «Аджайлом у нас даже и не пахнет» — как выразился один мой печальный умудренный очередным падением коллега?

Это самый страшный смертный грех аджайлоподобных: подражать и надеяться, что все обязательно получиться. Печальное замеченное в поведении людей (даже очень умных): пытаться воспроизвести то, что видится, но не задумываться, что послужило причиной.

Уже на слуху культ Карго. Многие, в том числе и я, сравнивали Аджайл/Скрам и этот интересный феномен.  Это такое мифическое чувство, что произнеся имя божества на команду нахлынет манна небесная, производительность и сходимость барн даун чарта.

Не хлынет. Не сойдется. Итерации вырождаются в двухнедельные промежутки времени. Скрам вырождается в Скрамно. И пахнет совсем не Аджайлом.

Воспроизвести дизайн офисов Гугла, не означает что ваща компания по духу и инновационности позволит на рынке IPO стать эффективнее, чем лоток для продажи Шаурмы.

И что печально — у таких лотков процесс поставки продукта клиенту лучше отработан, чем у средних софтверных компаний.

Терминологические Спекуляции

Проект менеджеры имеют желание ставить даты, и не имеют привычки спрашивать у команды достижимость таких дат. До сих пор есть люди, которые полагают, что девять женщин пренепременно родят за один месяц упитанного и здорового малыша. Ожидание успеха перекрывает адекватность реальности. Проекты у таких менеджеров просто обречены на «успех».

— У вас же эффективно внедренный Аджайл — вы справитесь!

А в глазах команды читается:  «Мы не говорим жопа, мы говорим challenge«.

Для приезжающего высокого менеджмента Директор небольшого ИТ департамента  создал презентацию о работе нового приложения. Директор указал скорость обработки запросов — что-то порядка 100 000 операций в секунду. На демонстрации презентации своей команде   (предварительно, перед тем как показать начальству) он получил вопрос. Один из разработчиков поднял руку и заметил:
— Но система не держит и половины указанной нагрузки.
— Вы не понимаете! — Воскликнул Директор — главное верить, что она может это делать! Главное в этом не сомневаться!

Главное верить, что как корабль назовешь, так он и поплывет, а то и поскачет.

И таких тоже набирается команда. Люди предпочитают получать удовольствие, жертвуя работой.  Скучная работа появляется, и — исчезает. Исчезает из поля зрения, потому что ее никто не делает.

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

Или работа отыгрывается инцидентом у клиента, потому что суппорт команда не смогла воспроизвести процедуру выкатывания в прод новую версию, потому что процедура не закончена или некоректна, а топ-перформер релиз-менеджер ушел в отпуск. И телефон на Бали не берет…

Скучно — не всегда означает не нужно. И уж тем более не означает — не важно.  Работа все равно появиться, когда нибудь, может быть не скоро, может быть не у вас, но появиться. И вот так положившись на авось и обозвав это более профессиональным «я принял риски» прокрастинируется неинтересное: «У нас Аджайл — у нас все построено на общении (читай настроении) и быстрой поставке».

Поставка быстрая, да только от случая к случаю.

Культура Героев

Мне часто приходится сталкиваться с коллегами, которые в среднем за свою карьеру проработали в одной и той же компании два, максимум — три года. У таких ребят может быть внушительный суммарный объем опыта, но каждые два года они меняют работу. Это ни хорошо и ни плохо. Это реалии ИТ рынка и правила +20 к окладу. Плохо другое. Плохо когда человек имеет опыт работы только в определенных типах проектов, например — в стартапах.

Львиная доля стартапов начинаются с культуры героев. Это когда сон для слабаков, когда мы 100% кроссфункциональная команда (и жнец и швец и дудец), и когда любой запрос от клиента становится ASAP. Проекты, окультуренные аджайлом задают дальнейшее соответствующее мышление и поведение своей команде. У  ребят из таких проектов существует ненасытная потребность быть вечно занятым делами. Им неприятна сама мысль, что все вдруг станет простым, ясным — они просто привыкли, что всегда сложно. И их, в свою очередь, сложно заставить привыкнуть к стабильному процессу воспроизведения ожидаемого результата. Вместо стабилизации процесса — такие люди любят стабилизировать процесс набора героев.

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

И культура героев ставит очередной памятник очередному проекту.

Невовлеченность

Пришли мыши к мудрой сове попросить совета, 
как им избежать участи быть съеденными обнаглевшими котами. 
Сова говорит им: «Станьте ежиками. 
Если вы будете колючими, вас никто не съест!» 
Обалдевшие от восторга мыши побежали домой, 
там опомнились и снова вернулись к сове. 
«Сова, расскажи — а как нам стать ежиками?» 
А Сова им в ответ: «Мое дело — стратегия!». 

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

Тест менеджер перечисляет риски, исходя из которых не то что итерация закончится не вовремя, а релиз не будет поставлен до конца года. Проект менеджер (продукт говнер) спрашивает: «Зачем ты мне это говоришь?»
TM: Ну ты же менеджер проекта…
PO: Да, но меня волнует только то, чтобы вы выпустили продукт в срок!

Ты виноват лишь в том, что хочется мне кушать…

Пассивность

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

Члены команды не самововлекаются, а самодистанцируются. И это начало конца — они аморфируются. Аморфная масса поглощает следующих. И затем даже у самых про-активных рождается вопрос: Зачем мне что-то делать, если никто кроме меня не пытается что-то улучшить? — это самый страшный вопрос. Это уже почти конец.

Проактивный член команды идет к лайн менеджеру советоваться. И не дай бог услышать от менеджера ответиз разряда: Ты же сеньорный человек\ты все должен понимать\ты должен уметь самомотивироваться\должен мотивировать других«. После таких слов, где то в душе специалиста умирает последний маленький пушистый котик. Человек идет самомотивироваться на hh.ru. И вот это — конец.

Пассивность душит проекты медленно, но верно.

Процессная порнография

There are good practices in context, but there are no best practices

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

Желание попробовать все сейчас и сразу — в первой же итерации или во второй, получить готовый результат, а если не получилось повторить, и еще и еще раз,  вызывает разные эмоции: от восторга до депрессии.  Изменить культуру, заставить того парня и его отражение изменить свое мнение — «как же все это просто изменить за одну итерацию!»

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

К сожалению для практикующих процессолюбов  — практики имеют уровень зрелости.

Канбан доску нельзя внедрять, пока не стабилизировался процесс приоритезации и не устоялись двунедельные итерации, например.

Или до тех пор пока вы не научитесь поставлять  предсказуемые стабильные версии приложения, не стоит задумываться о постоянных приемочных тестированиях у пользователей.

Или пока вы действительно не научитесь определять, что входит в последний билд и так называемые Definition Of Done для разработки, то сложно отслеживать ежедневный статус тестирования, поскольку статус в джире Ready for Testing может подразумевать, что еще неделю тестировщики не смогут начать тестирование, потому что нужно готовить тестовый стенд.

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

Надеюсь также, что ни у кого не отложилось в голове, что список полный. Паттернов и антипаттернов в ИТ хватает с лихвой. Мне очень нравятся 3 основные (по моей скромной версии практикующего менеджера) книги которые рассказывают о всевозможных оттенках серого в ИТ: Lesson Learned in Software Testing, Зомбированные шаблонами и Joel on Software. Для поклонников гибкого пути имеет смысл их перечитывать, чтобы не утонуть в горизонте безответственности и самолюбования (а потом самобичевания и самоистязания)

Удачного опыта и взлета. С первого и даже со второго раза.  В конце концов — все в наших руках. И проблема не в том, что мы совершаем ошибки, а в том, что мы их повторяем.