Еще одна категория противников - люди с завышенным ЧСВ и раздутым эго. Таким людям сложно вырабатывать командные решения и принимать другую точку зрения.

#ретроспектива #фасилитация

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

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

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

#наблюдение

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

Эволюция скрам мастера: Клерк, Кукловод, Организатор, Коуч, Советник, Эксперт.

Подробнее об эволюции Скрам Мастера можно прочитать здесь:

https://blog.unusual-concepts.ru/2016/07/scrum-master-evolution/?utm_source=facebook.com&utm_medium=social&utm_campaign=chem-bolee-zrelyy-skram-master--tem-vyshe

Планирование в SAFe. Никакой джиры. Тесное общение людей друг с другом. Бизнес, Разработчики, Дизайнеры, Архитекторы - все имеют общую цель и двигаются к ней. Потрясающая энергетика.

#масштабирование #less #safe

Вдохновляющий пример компании "МТС Касса". Несколько месяцев назад ребята запустили LeSS трансформацию и уже получили первые результаты: сокращение time-to-market почти в два раза + сокращения времени обратной связи до одной недели. Кроме того, запущен активный процесс повышения кросс-функциональности (t-shaping): члены команд учатся друг у друга используя mob-programming.

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

Я бы назвал SAFe неким LeSS-but: да у нас LeSS, но не развита инженерная культура, да у нас LeSS но с кросс-функциональностью большие проблемы и.т.д.

Об опыте ребят из МТС касс можно послушать здесь: https://www.youtube.com/watch?v=Lc5g06jnoxs

#мифы #scrum
Доброе утро!

Пятничная порция мифов про Scrum:

1. Scrum Master не может выводить из команды людей.
2. Product Owner - прокси для стейкхолдеров и должен лишь собирать у них требования и транслировать их команде.
3. Обзор спринта - это демо.
4. Scrum Master должен самостоятельно устранять все препятствия, с которыми сталкивается команда.
5. Релиз функционала возможен только в конце спринта.

Краткие пояснения:

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

2. Product Owner, в идеальной ситуации, именно OWNER продукта. Он напрямую отвечает за его успех и , следовательно, должен иметь все инструменты для определения направления развития. Безусловно, он должен уважать мнение стейкхолдеров, но их мнение не должно быть определяющим. В конце концов..... можно найти других стейкхолдеров для продукта :))

3. Обзор спринта - это многокомпонентное мероприятие, в рамках которого формируется пространство диалога между пользователями, стейкхолдерами и владельцем продукта.

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

5. Основная цель Scrum - максимально быстро поставлять на рынок наиболее ценный функционал. Таким образом, если функция готова и команда не тратит большое количество времени на выливку (есть настроенный CI|CD и автотесты) - можно релизиться хоть каждый день.

#грумминг #PBR
Советы от одного из лучших экспертов по Agile в СНГ о том, как проводить PBR:

1. Сделайте груминг частью вашего процесса.
2. Выработайте понятие здорового беклога – “Definition of Ready”.
3. Заведите понятие “текущего” и “следующего” релиза, что позволит заказчику управлять объёмом работы текущего релиза.
4. Встречайтесь вживую всей командой и Владельцем Продукта как минимум раз в релиз для одноразового масштабного груминга и планирования релиза.
5. В каждом спринте выделяйте время всей команды на регулярные grooming-сессии – скажем, каждую среду c 11:00 до 12:00.
6. Во время груминга работайте с бумажным беклогом.

Подробнее: goo.gl/DUmKpq

#планирование

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

1. Видение. Какая глобальная цель у продукта? К чему мы движемся? Видение - это то, ради чего мы вообще собрали команду. Оно должно зажигать всю команду.
2. Roadmap. Стратегия развития продута. Как именно будет развиваться продукт? Это последовательность целей, которые нужно достичь, чтобы воплотить в жизнь видение.
3. Релизы. На основании видения, стратегии и состояния рынка Владелец Продукта определяет релизы продукта - масштабные изменения, которые должны удовлетворить наиболее острые потребности пользователей/клиентов.
4. Спринты. Что нам нужно сделать, чтобы продвинуться вперед к нашей глобальной цели? Какую операционную цель нам нужно достичь, чтобы реализовать стратегическую?
5. Ближайший день Каждый день на Daily Scrum мы определяем, как нам нужно адаптировать подход к работе, чтобы достичь цели спринта? Составляем план на ближайший рабочий день.

#branches #git #инженерныепрактики

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

Рассмотренные подходы:
1. Feature branches.
2. Работа с веткой Master напрямую с частыми комитами.
3. Feature toggling (feature flags).

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

https://devops.com/feature-branching-vs-feature-flags-whats-right-tool-job/

Обратите внимание на «важность» Jira и других таск трекеров.

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

#иерархия

«When there is a conflict between what the customers want and what the boss wants, the boss wins.» - Ken Blanchard, Servant Leadership in action.

#servantLeadership

Три направления работы Скрам Мастера (Лидера-Слуги) в команде:

1. Provision: следить за наличием необходимых ресурсов, формулировать глобальные цели, воодушевлять.

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

3. Presence: быть доступным для членов команды в течение рабочего дня, поддерживать в решении трудных вопросов.

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

Если у вас начинаю фигурировать такие роли, как "Chief Grand Senior Business Sponsor" и прочие - с вашей трансформацией что-то не то.

Заметки на полях...

Из разговора с менеджером средней компании с офисами в 4-х странах мира: «Мы не натягиваем процесс на людей. Мы не занимаемся скрамом ради скрама. Если нужно переключиться на другую задачу - ребята берут и делают. Мы гибкие.»

Да, гибкие...

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