Спасибо за отклики!

На самом деле несколько провакационный вопрос был, но 53% ответивших раскусили подвох⚡️

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

Но я вот что еще заметил. Из тех 47%, кто не голосовал за вариант "Самого важного нет", всего лишь 1 человек проголосовал за Demo. Это значит, что многие либо не придают особого значения этому событию, либо не до конца осознают его силу.

Вот я лично убежден, что Demo — это самое крутое и важное мероприятие (я опускаю за скобки вариант "Самого важного нет") , потому что именно на нем команда может собрать обратную связь со своих РЕАЛЬНЫХ пользователей и SH, подвести итоги спринта, понять сколько команда заработала за предыдущий спринт и сколько потратила. Вы считаете стоимость спринта?
Итоги демо могут лечь в основу следующего спринта, скорректировать движение команды.

А вообще было бы интересно узнать почему вы выбирали тот или иной ответ. Напишите в личку @devonfekir, подискутируем :))

Уделяете ли вы время PBR? Как много и как часто?

Скрам-гайд не выделяет PBR как отдельное событие скрама, а считает его непрерывным процессом, который продолжается в течении всего спринта. Подразумевается, что команда постоянно обсуждает элементы бэклога особо не отрываясь от своей деятельности и тратит на это не более 10% своего времени.

Я знаю много команд и кейсов, где значение PBR преуменьшается или вовсе пренебрегается. Мне кажется, что происходит это из-за того, что либо PO и/или скрам-мастер считают PBR не обязательным мероприятием (ведь в гайде то оно не выделено отдельным событием и тратить время на это не нужно), либо не понимается вся суть и профит.

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

А теперь к сути и профитам. PBR помогает, особо не отвлекаясь от задач текущего спринта, по сути, готовиться к планированию следующего. Вы получаете уточненные элементы бэклога (разумеется элементы уточняются сверху вниз по бэклогу), расписанные юзерсторис, декомпозированные эпики и маленькие таски. Благодаря PBR, вы можете быстрее и точнее запланироваться в следующем спринте, иметь более понятные и оцененные задачи для команды разработки.

Поделюсь своей практикой. В силу некоторых организационных факторов и особенностей обеспечить подобный непрерывный процесс PBR на текущий момент нельзя (на самом деле, думаю, что у многих такая проблема). Поэтому мы проводим отдельную PBR встречу на 1-2 часа раз в спринт, где уточняем элементы бэклога, фокусируемся на целях, обсуждаем задачи. Подобная практика показывает себя только с самой лучшей стороны и все члены команды чувствуют пользу от этого.

​#моялюбимаярубрика

Это комбо, я щитаю😂😂😂

Что нужно, чтобы работал скрам, а продукт летел?

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

Хочу сказать, что ниже список только из критичных, на мой взгляд, параметров. Он далеко не исчерпывающий. Некий must have.

Помимо наличия самого продукта (о котором писал здесь), необходимы:

- Компетенции PO. Чертовски важная вещь. Во многом от PO зависит успешность продукта. Значит PO должен обладать достаточным уровнем знаний во всех областях, с которыми связан продукт, быть предпринимателем, знать и понимать философию скрама, управлять бэклогом. Более того, PO должен уметь распоряжаться бюджетом продукта, должен иметь достаточно власти, чтобы принимать необходимые решения. И многое-многое к этому можно еще приписать. Но концептуально, надеюсь, понятно, что это значит.

- 100% capacity. Каждый член команды должен быть на 100% занят именно этим продуктом. Только к нему он имеет отношение. Только эти задачи его касаются. Вот так вот жестко. По-другому не работает. Никогда ваш продукт не взлетит, если будет иначе. Любое минимальное отвлечение на другие задачи чревато потерей фокуса и концентрации. Я на этом уже собаку съел.

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

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

- Толковый скрам мастер. Человек, способный склеить кусочки пазлов в одну картину, обучить, научить, настроить процессы — очень важно не только для скрама, но и для продукта в целом.

Если у вас в какой-то из областей не так, то это хороший повод задуматься и поработать над этим.

Было ли у вас так, что команда не понимала зачем ей некоторые события или считала их пустой тратой времени, которое можно было бы использовать, чтобы написать пару строк кода или заняться любой другой работой?

Мне довольно часто встречались такие команды. Разумеется это были команды не совсем понимающие суть скрама и его событий. Обычно такое оттаржение происходит в самом начале пути команды. И многое здесь зависит от скрам-мастера.

Расскажу как я с этим справлялся. Скажу сразу, что в таких ситуациях я сторонник постепенного "наращивания" скрама.

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

Затем, по мере прохождения 1-2 спринтов, начинают четко вырисовываться проблемы, которые можно было бы решать за счет недостающих церемоний. Я же, как скрам-мастер, начинал подсвечивать эти проблемы, напоминал о том, что есть вот такие опции и наводящими вопросами пытался привести команду к САМОСТОЯТЕЛЬНОМУ принятию решения. Здесь важно выступить в роли коуча и дать команде самой прийти к решению. Только в этом случае команда почуствует полезность той или иной церемонии и захочет дальше так жить.

Еще раз. Мысль, которую я хочу донести — не всегда нужно и полезно давать команде какое-то готовое решение, поскольку чаще всего ваше готовое решение не приживется. Гораздо важнее дать команде возможность самой прийти к решению, а вы только подтолкнете ее к нему — вот это 100% будет работать.

Тут ко мне недавно обратился человек с вопросом: мол вот все говорят о применении скрама исключительно в контексте IT, а я вот хочу понять, можно ли его применять вне IT, например в строительстве?

На самом деле очень актуальный вопрос до сих пор. Нет, не о применении скрама конкретно в строительстве. В принципе вне IT. Отвечу на него со своей колокольни :)))

Давайте обратимся к скрам гайду, где написано, что скрам предназначен для разработки комплексных продуктов (о продукте говорили уже выше 👆). То есть по факту, гайд нам говорит, что вне рамок понятия продукта — он не применим. Гайд не ставит ограничений по сферам и отрослям, в которых его можно или нельзя использовать.

Поэтому, скрам применим если:
1) У вас есть продукт (не важно какая отрасль)
2) Ваш продукт существует в условиях высокой степени неопределенности

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

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

Поэтому хочу вас призвать использовать скрам правильно и по месту :)))))

Друзья, это был последний пост в этом году.

Подведу некие итоги:

- Канал был создан 2 октября 2018 года
- За это время было опубликовано 28 постов
- Оставлено 250 реакций (без учета опросов и последнего поста)
- 9847 суммарное количество просмотров
- 249 подписчиков

Спасибо за вашу активность и любознательность! ❤️

На следующий год у меня накопилось много идей. Будет интересно.

Поздравляю всех вас с Наступающим Новым 2019 Годом! Пусть для каждого он будет гибким.

Увидимся в новом году. Stay tuned🤘

Хэй, друзья, всем привет, всех поздравляю с прошедшими праздниками!

Надеюсь все отлично отдохнули, но пора снова за работу :)))

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

Пока просто закидываю удочку, чтобы понять интерес

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

Если еще кто-то не увидел пост, то также пишите 🙂

​Вчера я снова ковырялся на всяких популярных ресурсах в поиске какого-нибудь интересного контента для своей любимой рубрики и кое-что нашел.

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

Наличие успешно выполненных Agile/Scrum проектов🤯
Вы только вдумайтесь.
В то время как многие только пытаются внедрять, пробовать, практиковать и в принципе осознать философию Agile/Scrum, где-то уже требуют наличие успешно закрытых Agile/Scrum проектов. Да как вообще подобные "проекты" могут быть закрыты?
Scrum применяется только для развития комплексных продуктов, а продукт априори не может быть закрыт (только в случае его финансовой несостоятельности). Он требует непрерывного развития.

Можно работать частично из дома🤯
Напоминаю, что это компания ищет Scrum Master. Объясните мне как скрам мастер может работать из дома🤔 Как он может наблюдать за командой из дома? Как он может понимать проблемы команды из дома? В общем не серьезно это.

Это говорит лишь об одном. Понимание Scrum в России очень поверхностное. Не везде конечно, но во многих компаниях.

Также напоминаю о митапе. Напишите в лс, я вас добавлю к чату

​Хотите узнать насколько ваша организация гибка?

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

Радар содержит 4 домена:

- Клиент — позволяет оценить клиенториентированность комании
- Связи — позволяет оценить уровень внутренних и внешних взаимодествий
- Рабочие процессы — позволяет оценить ваши сложившиеся рабочие процессы
- Майндсет — позволяет оценить уровень культуры и сознания внутри вашей компании

В целом оценка business agility по миру составляет 4.9 из 10, что соответствует примерно "только-только поднимается с колен". А на картинке изображение радара средней мировой гибкости. Можно будет потом сопоставить ваши результаты с мировыми.

Ну и что потом с этим делать? Мы сами провели такую оценку. К слову, оценка топов и скрам мастеров отличалась. Увидели где мы проседаем и куда нужно двигаться. На основании этого имеем план действий.

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

Помните я недавно звал всех питерских на первый митап?

Так вот, на этой неделе он у нас состоялся🎂
Нас было немного, 5 человек, но было очень интересно.

Мы познакомились и поделились опытом друг с другом. Рассказали о своих практиках работы, об организации скрама в командах и в приницпе о там как устроен agile в компаниях.

Договорились, что обязательно будем проводить подобные встречи и в будущем, но уже в более обширном составе и ином формате.

Если хотите поучаствовать в следующем митапе (в СПб), присоединяйтесь к нашей группе 👉 https://t.me/joinchat/Ct4sARZplABPF9FGFLVmWQ

P.S. отдельный респект @tolstostrun за помощь в организации

Многие из вас наверняка сталкивались с давлением со стороны организации, SH, PO, руководителей. Якобы вы работаете плохо, медленно, делаете не то, не приносите ожидаемого результата или приносите, но мало. А результат, такая штука, которая нужна прямо здесь и сейчас.

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

В таких ситуациях любое давление извне должно фильтроваться/перевариваться самим PO и находить отражение в бэклоге (ведь это инструмент PO) в виде приоритетов и новых задач, но ни в коем случае не спускаться на команду. И уже исходя из обновленнго бэклога, команда продолжает работать без потери эффектинвости, мотивации, скорости и доверия. В этом заключается сила PO в том числе.