Agile Assessment: что, зачем, почему? | Agile тренинги, обучение и сертификации Scrum, Kanban, DevOps в Scrum Украина
The article is displayed in the original language.

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

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

Павел Камышов
Павел Камышов
17 мар 2020

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

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

Alt Text

Соответственно, чтобы определить реальную системную проблему, нужно выйти из своего уютного мира графиков и митингов и сходить ножками к обычным сотрудникам.
Этот подход называют “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 митингов как с ключевыми людьми, так и с обычными участникам команд, чтобы получить максимально полную картину и противоположные точки зрения.
Прорисовали поток доставки ценности, структуру компании, функцию команд и ключевых людей.

Alt Text

Alt Text

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

Part 2: Assessment

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

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

Alt Text

Приоритизированные командой проблемы собраны справа в столбик
Среди них:
- нет мануалов для конечных пользователей
- нет списка задач (беклога)
- нет зон ответственности (среди ключевых людей)
- нет CI/CD
- отсутствует процесс тестирования
- многие задачи завязаны на одном человеке, то есть “bus factor” = 1

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

Alt Text

Рекомендации по итогу ассессмента:
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. Из забавного

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

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

Alt Text

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

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

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

Recommended events

Misha Glushchenko  

The Kanban System Design (Kanban Management Professional 1) lays the foundation for the Kanban method, teaching you the principles, practices, and processes. This two-day course is certified by Kanban University and has been compiled by experts and Kanban leaders, including David J. Anderson and Mike Barrows.

Alexey Krivitsky, Evgeniy Labunskiy  

An online course for Advanced professionals, about everything you need to know about backlog management. Communicate directly with trainers, with tasks for study in your team and practice!

Evgeniy Labunskiy, Pavel Kamyshov  

A two-day course on the basics of Agile and the Scrum and Kanban frameworks + 1 bonus day with offline simulation. The certification course, upon its completion, participants receive personalized certificates ICAgile Certified Professional - Agile Fundamentals (ICP), which are recognized worldwide.

Recommended articles

25 идей, как остаться эффективной командой, работая из дома

23 марта мы провели мега-вебинар на 500+ человек, посвященный поиску идей, как командам эффективно работать по ремоуту и обмену опытом. Всего получилось больше 50 идей, все они изложены: здесь

Полная видеозапись вебинара: здесь!

Смотрите и будьте продуктивны!

Agile команды теперь работают из дома, WTF?

Это произошло. Стремительно. У нас были десятилетия подготовиться. Но мы были заняты работой. Теперь самое время взять ситуацию в руки и начать вырабатывать хорошие командные привычки работы из дома.

Agile vs. home office #WfH #WTF

Мы 20 лет жарили про силу face-to-face. Времена поменялись, и теперь эти принципы уже не в моде? Или всё же даже в режиме "working from office" команды могут оставаться производительными и счастливыми? Приведу ряд конкретных советов по обустройству удалённого офиса.

We are active on social networks and want to communicate. Add to our facebook page and join our communities.

Consulting and corporate programs:
063 810-72-25 Yevhen
093 497-46-61 Kateryna
hello@scrum.ua

Public classes, events and registrations, invoices:
095 014-5900 Tetiana
backoffice@scrum.ua

On all numbers - voice, sms, viber.

©2017 - 2020 Scrum Ukraine. All rights reserved.