Agile Assessment: что, зачем, почему?

Или "7 раз отмерь, 1 раз отрежь"

Часто к нам обращаются клиенты с запросом провести Scrum тренинг для того, чтобы “все заработало как надо, по Скраму”.

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

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

Поэтому любое вовлечение мы начинаем с определения проблемы, с проработки реального запроса. И вот тут становится интересно, так как СЕО компаний часто поляризованы вокруг двух крайностей, от “Я без понятия как работает компания, я просто туда кидаю запрос, и через месяц-два либо получаю результат, либо нет (чаще второе)” до “Конечно, я четко знаю какие у нас где проблемы, и понимаю какие реальные боли у моих подчиненных, лучше них самих”.

Согласно же исследованиям ТОП менеджмент компаний видит только около 4% происходящего в компании.

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

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

Этот подход называют “Management by wandering around”

Поэтому чаще всего наше вовлечение в компанию мы начинаем с этапа “Agile assessment”. Хотя, по сути, это аудит трех вещей: людей, информации и способа обмена этой информацией. Плюс понимание общей цели (видения развития продукта).

Итак, реальный кейс:

К нам пришел директор небольшой ИТ компании с запросом: “компания совершенно непрозрачна, сроки постоянно сдвигаются, менеджеры не справляются. Давайте попробуем внедрить Скрам?”.

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

Как выглядело предложение с нашей стороны:

Part 1: Processes Diagnostics

Анализ процессов вместе с лидерами вашей компании. В формате 1-1 встреч мы обсудим контекст в котором работают менеджеры и лидеры компании, как они понимают свои цели, с какими вызовами/сложностями они сталкиваются, какие способы решения проблем применяли и какие получились результаты.

Part 2: Assessment

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

Part 3: Review of Assessment results with management and key people

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

Это предложение было принято руководством и наша работа закипела

Part 1: Processes Diagnostics

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

Прорисовали поток доставки ценности, структуру компании, функцию команд и ключевых людей.

Когда начали разбираться, как работает текущий “Скрам” - поняли, что из Скрама там только формальные спринты и “демо” (именно в кавычках). А по факту не было не только Sprint Backlog, но и Product Backlog в принципе.

А еще участники команд не понимали толком, кто у них ПО, его функцию вроде как должны были выполнять менеджеры, но не делали этого. Более того, команды абсолютно не понимали, что делает и за что отвечает один из менеджеров(как и он сам).

Part 2: Assessment

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

Что выяснили:

Приоритизированные командой проблемы собраны справа в столбик

Среди них:

- нет мануалов для конечных пользователей

- нет списка задач (беклога)

- нет зон ответственности (среди ключевых людей)

- нет CI/CD

- отсутствует процесс тестирования

- многие задачи завязаны на одном человеке, то есть “bus factor” = 1

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

Тикеты приоритизировались вместе с руководством:

Рекомендации по итогу ассессмента:

1. Построить понятный и прозрачный поток доставки ценности.

2. Выделить внутреннего Продакт Овнера, который будет отвечать за приоритизацию задач и развитие продукта. Создать Product Roadmap.

3. Четко определить, что является продуктом компании.

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

5. Для ПМов провести сессию определения кто за что отвечает. Создать RASCI матрицу.

6. Начать регулярно проводить ретроспективы со всеми участниками процесса. Каждую ретроспективу заканчивать четким списком Action Items, с ответственным лицом и дедлайном.

7. Чтобы избежать некачественных запросов от бизнеса - договориться о Definition of Ready. Перед началом выполнения задачи выделять некоторое время для изучения задачи, чтобы можно было дать качественную оценку.Это увеличит не только качество сделанной работы, но и предсказуемость системы.

8. Включить в Definition of Done пункт про тестирование. Рассмотреть вариант найма QA в команду.

9. Создать прямой канал коммуникации между саппортами/клиентом и командами разработки. Это сократит цикл обратной связи и уменьшит количество ошибок в разработке.

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

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

Так как, на момент консультирования, текущие проекты 90% были реализованы, решили новые инициативы внедрить уже в новых проектах.

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

Путь в тысячу миль начинается с первого шага (с)

P.S. Из забавного

Часто о неформальной культуре в компании можно сказать по обстановке в офисе.

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

Например, у клиента шикарный офис на первом этаже, а в нем новенькая переговорка с выходом во внутренний дворик.

Но проблема в том, что в переговорке дверь во двор закрыта на ключ.Ключи у секретаря.Но за ними ходить неудобно, поэтому люди ходят во дворик через окно :)

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

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

P.P.S

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