Agile Assessment: что, зачем, почему? | Scrum Україна - тренінги, навчання та сертифікації Agile, Scrum, Large-Scale Scrum
 
Стаття відображається оригінальною мовою.

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

Рекомендовані заходи

тренінг
Олексій Кривицький  

Це офіційний інтенсивний сертифікаційний клас Scrum Alliance. Курс читає Олексій Кривицький – Certified Scrum Trainer, розробник, скрам-майстер та практикуючий agile-коуч з 2008 року.

тренінг
Олексій Кривицький  

Це офіційний інтенсивний сертифікаційний клас Scrum Alliance. Курс читає Олексій Кривицький – Certified Scrum Trainer, розробник, скрам-майстер та практикуючий agile-коуч з 2008 року.

тренінг
Дмитро Незабитовський  

Дводенний курс з основ Agile, Scrum фреймворку та Kanban-методу. Курс сертифікаційний, після закінчення учасники отримують іменні сертифікати ICAgile Certified Professional (ICP): Scrum & Kanban.

Рекомендовані статті

Скільки коштують ваші зустрічі? Та як не втрачати гроші.

Зустрічі у компаніях, які займаються розробкою програмного забезпечення, часто визнаються найважливішою складовою успішного продукту (чи проєкту). Однак, їх вартість і вплив на бізнес часто залишаються недооціненими. Проведення зустрічей вимагає великих витрат часу і ресурсів, і саме тому …

Top 5 питань про Agile Retrospectives

Я проводжу ретроспективи досить часто, близько сотні на рік, а почав уперше це робити майже 10 років тому. У цій статті я хочу відповісти на Top 5 із питань про Ретроспективи, які найчастіше задають учасники тренінгів та Agile-ком'юніті.

Чому коучинговий підхід актуальний у бізнесі?

Однією з основних функцій сучасного менеджера лідера є розкриття потенціалу кожного учасника команди для досягнення максимальної ефективності та реалізації цілей. Scrum Masters, Product Owners, Facilitators та інші лідери й керівники можуть використовувати коучинговий підхід для підвищення …

Ми активні в соціальних мережах і хочемо спілкуватися. Додавайтеся на нашу сторінку в facebook та приєднуйтесь до наших спільнот.

З приводу тренінгів, реєстрацій, рахунків:
+380993383636
@scrum_ukraine
hello@scrum.ua

Із питань корпоративних програм:
+380993383636
hello@scrum.ua

©2017 - 2024 Scrum Ukraine. Всі права захищені.

Політика конфіденційності