Еще раз о том, как выглядит долгосрочное и среднесрочное планирование в Scrum. Над видением продукта могут находится более верхнеуровневые цели компании.

Из архива 🙂

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

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

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

Привет!

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

Придерживаясь ценностей Scrum (а именно - Открытости), хочу сообщить, что в начале Июня я ушел с прежнего места работы и теперь обучаюсь на магистерской программе в Национальном Университете Сингапура (NUS).

В канале я продолжу делиться материалами связанными с Agile, Scrum, организационным дизайном, однако “практики” будет сильно меньше (по крайней мере в ближайший год).

P.S.: если у вас есть вопросы по релокации в Сингапур, а также о жизни  здесь - пишите в ЛС (@vasiliizorin)

Также хочу поделиться списком интересных каналов, которые ведут настоящие профессионалы:

@inteamwetrust_rus - канал Алексея Пикулева о доверии внутри организаций и команд. Настоящий кладезь полезных инструментов.

@myscrum - дневник Сергея Господчикова, Скрам Мастера в компании МТС-касса. Сергей делится своими наблюдениями о процессе работы продуктовой группы с использованием фреймворка LeSS.

@agile_coach_notes - канал Анастасии Бутовой-Никишиной о нелегкой работе Agile коуча с большим количеством практик, чек листов и инструментов для работы с командой и организацией.

@tw0_percent - канал Сергея Артюхова с интересными материалами об Agile, Scrum, коучинге, саморазвитии…

@kanban_ru - канал, для тех, кто хочет “познать” kanban.

Хозяйке на заметку

Decentralized Autonomous Organization (DAO) - следующий шаг в развитии самоуправляемых организаций.

DAO - это набор инструкций, формирующий порядок взаимодействия между акторами. Актор - это любой человек, каким-либо образом участвующий в жизни компании.

Под инструкциями понимаются:
- Правила распределения прибыли
- Правила найма/увольнения/пересмотра заработной платы/назначения на определнные роли.
- Правила принятия решений и правила измения уже принятых инструкций и др.

Все перечисленные процессы легко представить в формате алгоритма и реализовать в рамках определенной платформы (например DAOstack).

Вы можете спросить, чем DAO отличается от простой автоматизации процессов?

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

За что люблю работу Скрам Мастера, дак это за бесконечное многообразие задач, эмоций, идей и контекстов.

А как выглядела ваша самая необычная/упоротая ретроспектива?

Поделитесь, мне очень интересно, насколько далеко могут зайти Скрам Мастера 😂 (@vasiliizorin)

Большинство отечественных IT компаний очень сильно тормозит в развитии неумение тратить деньги. Вместо этого они тратят кучу времени и сил на поиски способов сэкономить. В результате:

- одни пилят "на коленке" простенький CRM чтобы не покупать готовое решение;
- другие строят отделы ручного тестирования с кучей народу вместо найма пары грамотных людей, способных выработать здравую автоматизацию тестирования;
- третьи строят процессы "по интуиции" вместо того чтобы обратиться за компетентной помощью;
- четвёртые не могут несколько месяцев выпускать быстро новые фичи, потому что не выходит нанять классных разработчиков на зарплату -$500 от хорошей рыночной;
- у пятых нет CTO и его работу приходится делать CEO, который и так перегружен, но нанять человека "дорого";
- ну и я молчу про орехи и фрукты в офисе, вкусный кофе, соки и молоко...

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

#трансформация #кейс

На днях была возможность пообщаться с топ менеджером (COO) одного крупного (50 тыc. Сотрудников) и очень-очень старого (>140 лет) банка.

Вот некоторые цитаты и мысли из этого разговора:

- “Я 25 лет в банковской сфере и я впервые слышу все эти должности. Scrum Master, Product Owner…. Честно говоря я даже не стал разбираться.”

⁃ “В целом мне все равно, как сотрудники будут выполнять задачи. Главное чтобы они были выполнены и желательно в установленные сроки. А Agile/Waterfall - ваш выбор”

⁃ “Agile should not make you fragile” (Аджайл не должен делать вас хрупкими)

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

⁃ Если у вас нет “лицензии” на осуществление изменений с самого верха - трансформация обречена на провал.

В общем и целом, везде одни и те же проблемы и примерно одно и то же восприятие Agile трансформации со стороны ТОПов.

Похоже мы стали забывать, как выглядит настоящий сертифицированный Скрам Мастер.

Всем привет! Пришло время выйти из академической спячки (я наконец-то защитил свою диссертацию по организационному дизайну (результатами поделюсь позже)!

Для начала предлагаю освежить в памяти базовые концепции фреймворка Scrum и заодно протестировать новый функционал Telegram (проведение квизов). Я буду публиковать вопросы о Scrum (ценности, события, артефакты, кейсы) и ровно через сутки - комментарий к вопросу, поясняющий почему тот или иной ответ правильный.

И так, первый вопрос:

На сегодня все. Развернутые коммментарии к вопросам опубликую завтра 🙂

#dailyScrum

И так, правильный ответ на этот вопрос можно найти в Scrum Guide: “Скрам-мастер следит, чтобы встреча Команды Разработки состоялась, но за проведение Ежедневного Скрама (Daily Scrum) отвечает сама команда. Скрам-мастер обучает Команду Разработки проводить Ежедневный Скрам (Daily Scrum) за 15 минут или быстрее”

Да, в течении первых 2-3 спринтов Скрам Мастеру необходимо присутствовать на Daily Scrum, поскольку ему важно важно быть рядом и отвечать на возникающие вопросы (а в самом начале они точно будут). Более того, первые 3-4 дня Скрам Мастер может фасилитировать Daily Scum, чтобы обозначить рамки для Команды Разработки… Однако затягивать с такой “фасилитацией” опасно и важно как можно скорее “отпустить” команду, чтобы она сама выработала эффективный формат взаимодействия.

После 3-4 спринтов Скрам Мастер может не присутствовать Daily Scrum, но ему необходимо время от времени посещать это событие в роли наблюдателя, для того чтобы убедиться, что встреча проходит эффективно и не сформировались антипаттерны.

#sprintBacklog

Это один из самых распространенных мифов о Scrum. Вносить изменения в Sprint Backlog можно, но только в том случае, если это не угрожает Цели Спринта. Корректировать Sprint Backlog может ТОЛЬКО Команда Разработки после обсуждения с Владельцем Продукта.

Более подробно об этом можно прочитать здесь: https://medium.com/the-liberators/myth-the-sprint-backlog-cant-change-during-the-sprint-e1a10f735c67