Зомби, Театр и Agile. Часть 1: Обнаружение
Эта статья родилась на Scrum Coaching Retreat в Киеве как результат работы нашей команды Zombinators. Оригинал на английском.
Постановка
Знакомьтесь, это Олег. Ему немного за тридцать, и последние четыре года он работает как независимый Agile-коуч. Ему доводилось сотрудничать как со здоровыми Agile-командами, так и помогать преодолевать трудности с производительностью и рабочей атмосферой.
Недавно он подписал контракт с ООО “Могильные Разработки”. Это софтверная компания, в которой работают 40 человек. Полгода назад руководство компании загорелось идеей внедрить Agile, и преимуществами, который он должен принести.
Своими силами в компании запустили Agile-трансформацию. Но со временем у руководства возникло впечатление, что Agile не соответствует их ожиданиям. На первый взгляд, все хорошо. Ритуалы на месте, стикеры на стенах, Беклоги регулярно прорабатываются, на Ретроспективах принимаются улучшения, которые воплощаются в жизнь. Ну почти. Некоторые команды обходят правила. Другие, наоборот, следуют предписаниям буква в букву.
Продуктивность немного выросла, но “делать в два раза больше за два раза меньшее время” не получается. Вовлеченность и мотивация сотрудников не увеличилась, а у некоторых вообще упала. Компания надеется, что Олег сможет им помочь.
Проблемы?
По опыту, Олег знает что если результаты Agile-трансформации не дают компании ожидаемых преимуществ, зачастую это происходит из-за двух дисфункций: “Agile-театр” и “Зомби-Agile”. Они возникают по разным причинам.
“Все делают Аджайл, нам тоже нужно” или “вы должны быть Аджайл”, — спускаемое сверху; соревнование за звание самой Аджальной команды компании, особенно если к этому привязаны бонусы — все это ведет к возникновению Agile-театра.
Отсутствие безопасного окружения, использование Agile в качестве оправдания за отсутствие планирования и сорванные сроки, выученная беспомощность команд в попытках изменить что-то значимое, — вирусы, порождающие Зомби-Agile.
И Театр, и Зомби могут быть спровоцированы неудачными инициативами в прошлом. “А, очередная придумка менеджмента, перебесятся” — думают сотрудники, и либо стараются переиграть систему, либо становятся бездумными исполнителями.
В оставшейся части статьи мы детально рассмотрим обе дисфункции и способы их обнаружения, вскрытия и “лечения”.
Зри в корень
Люди делают лучшее из возможного, с учетом их возможностей и знаний. Поэтому прежде чем обвинять и тыкать пальцем в виноватого, нам стоит пристально взглянуть на то, как организована их работа, помочь определить проблемы и их основные причины. “Чинить” нужно процессы, не людей.
Каждый раз при возникновении проблемы и на Ретроспективах полезно проводить Анализ корневых причин (Root Cause Analysis, RCA). Популярная техника для этого называется “5 почему”: люди собираются небольшими группами и сначала обсуждают что именно пошло не так в конкретном случае. Затем задают вопрос “почему это произошло?”. Каждую обнаруженную причину коротко обсуждают, записывают, и повторяют процесс еще несколько раз. Если пять раз задать вопрос “почему”, можно обнаружить больше полезных идей и глубоких причин, чем если это сделать один раз.
Еще один полезный инструмент — диаграмма Исикавы, она же Fishbone Diagram. Проблема записывается в “голове” рыбы”, а ее причины формируют “скелет”. Вместе с диаграммой часто используют уже упомянутые “5 почему”.
Системное мышление (Systems Thinking) поможет понять систему в целом и найти возможности к улучшению. Один из инструментов Системного мышления — подход Causal Loop Diagram (CLD): выпишите “переменные”, прямые и обратные зависимости, обсудите убеждения и задержки, зафиксируйте их на бумаге. Все вместе поможет достичь общего понимания ситуации.
Знакомьтесь: Зомби и Актеры
Вернемся к Олегу и ООО “Могильные разработки”. Он знает, что и Зомби, и Актеров можно определить по ряду признаков.
Зомби
Зомби поддерживают статус-кво, им нечего улучшать. Они уверены, что Agile им не подходит и не сработает. Точнее, то детище Франкенштейна, которое они называют “Agile”. Вроде работа ведется по-новому, но тут и там торчат “хвосты” старых практик и привычек: долгие и скучные митинги, с которыми все как бы ОК, “охота на ведьм” как способ справляться с проблемами, и так далее.
В работе Зомби используют два замысловатых фреймворка: KPI Driven Development (Разработка через показатели, KDD) и самую свежую версию Report Driven Development, (Разработка через отчетность, RDD). Они предпочитают экстремальный таймбоксинг: любые лимиты по времени игнорируются, а зачастую их и вовсе нет.
Обнаружить Зомби
Зомби не всегда заметны с первого взгляда. Но их могут выдать определенные признаки.
На Ретроспективах:
- В результате встречи не появляется никаких планов по улучшению. А если и есть, то все они вешаются на несчастного Скрам-Мастера.
- Планы по улучшению перетаскиваются из Ретроспективы в Ретроспективу, но команда их никогда не выполняет.
- Ретроспективы полны личных конфликтов и взаимных обвинений.
- Как следствие, Ретроспективы почти никогда не ориентированы на улучшение процесса.
На Планировании:
- Каждый Спринт — это маленький Waterfall, когда каждый этап посвящен отдельной части цикла разработки.
- Сверхсложный Definition of Ready (DoR), используемый в качестве контракта.
Ежедневные встречи:
- Не происходят без Скрам-Мастера.
- Больше похожи на Статус-репорт.
- На встречах команды не озвучивают возникшие проблемы и сложности.
Визуальные артефакты:
- Не существуют.
- А если и существуют, то не обновляются или устарели.
- Обновляются одним человеком (обычно это Скрам-Мастер).
Компонентные команды:
- Для каждого этапа выделяются отдельные Спринты: для разработки, тестирования, развертывания и тд.
Раскрыть Актеров
Восходящие звезды сцены, такие как джуниор Скрам-Мастер, Главный Скрам Мастер (Chief SM), Прокси Владельца Продукта (Proxy PO) и т.д. ставят галочки в чеклистах, совревнуясь кто больше “аджайл” с другими такими же актерами. Они поглощены проигрыванием своей роли, особо не заботясь о ее назначении и ценности. Они страдают от карго-культа и будут притворяться, пока у них не получится. Процесс и инструменты важнее всего, плевать на людей и их взаимодействие!
Театр начинается с вешалки
Agile-театр начинается с определенных “звоночков”:
На Ретроспективах:
- Команда выбирает улучшения из нижнего левого квадранта матрицы Влияния/Усилий (Impact/Effort Matrix). То есть те действия, которые требуют наименьшего количества усилий, и оказывают наименьшее влияние.
- Темы для Ретроспективы предопределены кем-то внешним или Скрам-Мастером, а не самой командой.
Планирование:
- Команда планирует опираясь исключительно на Скорость команды (“Velocity driven planning”).
Ежедневные встречи:
- Не происходят без Скрам-Мастера.
- Сфокусированы только задачах, о цели Спринта даже не вспоминают.
Обзор Спринта:
- 100% задач всегда “сделаны” и закрыты. Команда сосредоточена не на Доставке Ценности, а на закрытии тасков. Критерии готовности (Definition of Done, DoD) подгоняются под результат.
- Циклы обратной связи отсутствуют либо вырождены, и как следствие, бесполезны:
– Все хорошо?
– Ага.
– Ну и отлично
- Любые попытки отклониться от чеклиста пресекаются. Процесс — вот что важно.
- Команда рассказывает как они здорово поработали, но забывает продемонстрировать готовый к поставке Продукт. Или игнорирует обратную связь:
– Ваша “поделка” никуда не годится!
– Зато посмотрите сколько мы сделали Стори поинтов! Мы молодцы!
Визуальные артефакты:
- Содержат устаревшую информацию.
- Показывают что угодно, кроме реальной картины.
Каждый пункт по отдельности не означает, что перед Олегом Зомби или Актеры. Но совокупность таких признаков, которые дополняются атмосферой затхлости или наигранности в команде, позволяет понять, какую дисфункцию он наблюдает.
О том, что делать когда диагноз поставлен, идет речь в следующей части.
