Scrum внедрили, а циклы обратной связи забыли

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

Scrum — это не просто набор встреч. Это живой процесс, где ключевую роль играют регулярная обратная связь и адаптация планов. Живой бэклог, постоянные эксперименты, анализ данных — вот что отличает настоящую Scrum-команду.

Самое главное в Scrum — это цикл инспекции и адаптации. Вы можете забыть про все встречи, если ваш эмпирический процесс не работает.

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

Мы регулярно проводим диагностику работы в Scrum для компаний и выстраиваем эффективный процесс.

Виды сопротивлений изменениям.
Как преодолеть и двигаться вперед?

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

Теория ограничений выделяет шесть основных слоев сопротивления.

Понимание каждого из них помогает нам лучше управлять изменениями и минимизировать конфликты:

1. Несогласие с существованием проблемы
Фразы вроде: «Нет проблем», «Мы всегда так делали».
Здесь важно показать, почему существующее положение вещей не работает и как это мешает достижению целей.

2. Несогласие с направлением решения проблемы
Примеры: «Эту проблему не решить», «Такова специфика нашего бизнеса». Здесь фокусируемся на демонстрации успешных кейсов и адаптации решений под конкретный контекст компании.

3. Недоверие к предложенному решению
Часто слышим: «Это не решает нашу проблему». Чтобы преодолеть это, важно обеспечить тестирование и демонстрацию результатов на пилотных проектах.

4. Негативные последствия от решения
Классическое «да, но…». Задача на этом этапе — проработать риски и минимизировать возможные негативные эффекты, показывая преимущества.

5. Препятствия, которые кажутся непреодолимыми
«Мы не можем это сделать, потому что…». Необходимо выявить реальные барьеры и предложить пути их преодоления: от обучения до реструктуризации процессов.

6. Невербализованные страхи и психологические барьеры
Часто скрыты и трудно выявляемы. Здесь важно создать среду доверия и открытого общения, показать людям, что они являются частью изменений, а не их жертвами.

Движители дисгармонии в организации.

Есть довольно стандартные факторы которые препятствуют достижению компаний поставленных целей. Это:

1. Многие люди не знают (т.е. не могут четко сформулировать), что они делают важного для организации.

2. Многие люди в организации не знают, что из того, чем заняты их коллеги, является важным для организации или хотя бы каков их вклад в достижение цели.

3. Организационные конфликты. Люди работают в условиях конфликтов, которые вызваны конфликтующими политиками или назначением ресурсов.

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

5. Индивидуальные конфликты. Разрывы между полномочиями и ответственностью.

А теперь представьте что если мы начнём чинить эти факторы, то насколько улучшиться перформанс и результативность компании. Все чисто про людей.

Вакансия - Release Train Engineer / SAFe coach

Друзья, готов порекомендовать компанию, которая проводит трансформацию своего управления на SAFe.
Нужно будет запустить АРТы и выстроить эффективные процессы в них.
Если есть интерес и опыт, приходи в лс с резюме @agileguru

Встраиваем непрерывный процесс ИБ в разработку

Одна из ключевых проблем задержки релизов - это несоответствие продукта требованиям безопасности. Часто новые функции продукта блокируются перед релизом и команда сталкивается с большим количеством доработок и конфликтам с ИБ

Хорошие Agile-команды применяют подход DevSecOps, делая учет и проверку требований безопасности постоянными и непрерывными.
Процесс написания кода и его проверки с точки зрения ИБ должен быть непрерывно встроен в разработку.

Вот некоторые принципы которые точно помогут улучшить ситуацию:

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

- Постоянный анализ кода. Внедрите автоматический анализ на соответствие требованиям безопасности на всех этапах разработки.

- Раннее выявление проблем. Чем раньше найдены уязвимости, тем дешевле и проще их устранить. Регулярно запускайте сканеры безопасности и включайте их проверку в Definition of Done

- Доступ к инструментам ИБ. Дайте команде возможность самостоятельно запускать сканеры безопасности или сделайте специалиста по ИБ доступным для оперативной помощи. Убедитесь что налажен регулярный мониторинг к которому есть доступ у разработки.

- Интеграция проверок в CI/CD. Автоматизируйте проверки безопасности, чтобы они стали частью CI/CD конвейера, минимизируя ручной труд.

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

Важно помнить что разработка и проверка ИБ - это не разные этапы разработки, а непрерывный процесс

🔍 Как провести качественную диагностику команды и процессов

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

1. Go See — "Иди и посмотри". Сформируйте собственное экспертное мнение. Оцените продукт, процессы разработки, прозрачность работы команды и эффективность взаимодействия между участниками.
2. 360-опрос — Спросите команду и стейкхолдеров, что у них вызывает сложности. Это поможет выявить проблемы, которые могли бы остаться незамеченными.
3. Метрики поставки — Соберите данные по скорости, результативности и качеству работы. Эти метрики дадут объективную картину того, насколько эффективно команда достигает своих целей.
4. Опросы — Проведите отдельные опросы для двух групп: команды и стейкхолдеров. Спросите их, что мешает им работать лучше, и сравните полученные данные.
5. Командная сессия — Организуйте встречу команды и заказчиков для совместного разбора выявленных проблем. Это важный шаг для построения общего понимания и поиска решений.
6. STATIK — Проведите анализ системы с помощью метода STATIK, чтобы понять, как она работает, и выявить узкие места или возможности для улучшений.

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

Run, Change, Disrupt. Как управлять различными видами деятельности в организации

Одной из ключевых концепций для понимания и управления потоком работ компании или отдельной команды является разделение проектов и задач на три типа: Run, Change и Disrupt. Давайте разберемся, что это значит:

🔹 Run – Это задачи, которые поддерживают текущие операции на плаву. Они помогают бизнесу продолжать функционировать стабильно и эффективно. Например, регулярное обслуживание, устранение багов или поддержка существующих продуктов. Цель здесь – минимизировать риски и обеспечить стабильность.

🔹 Change – Это улучшения того, что у нас уже есть. Сюда входят задачи по внедрению новых функций, адаптации к изменениям требований рынка или улучшению процессов.
Основная идея – делать наш продукт или услугу лучше и более востребованными.

🔹 Disrupt – А вот здесь мы говорим о радикальных изменениях, которые могут полностью изменить правила игры. Инновации, эксперименты с новыми технологиями, запуск принципиально новых продуктов – это рискованно, но потенциально может принести огромную выгоду.

💡 Зачем нужно такое деление?
Такое разделение помогает правильно расставить приоритеты и сбалансировать ресурсы команд. Например, без задач Run бизнес может столкнуться с критическими сбоями, но фокус только на поддержке без Change приведет к стагнации. А если забыть про Disrupt, то можно упустить возможности для масштабного роста и потерять конкурентное преимущество.

Как использовать эту концепцию?
1. Используйте ее при балансировке портфеля проектов ваших инициатив
2. Распределяйте задачи внутри конкретного продукта по этим направлениям.
3. Всегда оставляйте на run активности 20-30% времени при планировании change и disrupt активностей. Часто этим пренебрегают.

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