Спасибо за активность, друзья!

Благодаря вашим ответам четко оформилась картинка контингетна. Могу точно сказать, что контент будет полезен и интересен всем.
___________________________________

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

Примерно год назад у нас в компании только началась Agile трансформация. Мы были молоды в этом плане, зеленые, неопытные. С нами работали внешние коучи. Примерно тогда мы узнали о существовании иного подхода к реализации проектов, помимо классического проектного — продуктовый, для которого очень хорошо подходит скрам.

Это было в некотором смысле открытие. Мы очень захотели приметь его, поскольку данный подход является неотъемлемой частью трансформации. Ну и особо не разобравшись в понятии "продукт", мы взяли и натянули его на большинство наших проектов. Вместе со скрамом. То есть просто проект переименовали в продукт, а PM в PO. И всем по скрам-мастеру в добавок с барского плеча.

Но ведь проект не равно продукт, а PM не равно PO. Совсем разные сущности. Это было нашей ошибкой, которую мы осознали спустя год. Год, за который мы могли бы привнести больше качественных и культурных изменений в компании. Заработать и/или потртратить больше/меньше денег. Доставить больше ценности клиенту. И много чего еще. Эта ошибка явилась следствием как раз неверной трактовки понятия и нежаланием капнуть глубже, расширить угол обзора.

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

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

P.S. Я понимаю, что этот кейс оставляет много вопросов, поэтому и считаю его не своевременным, но будем есть слона по кускам и переодически возвращаться к этому кейсу. Все же его цель — показать, что необходимо очень внимательно относиться к новому и шире смотреть на вещи. Уверен, что далее я отвечу на большинство вопросов.

Сегодня у меня с коллегой завязался спор на тему того кто выбирает скрам-мастера в команду: DevTeam, PO или же DevTeam+PO.

Я глубоко убежден, что выбирать скрам-мастера должна исключительно DevTeam, а мой коллега твердит, что DevTeam+PO.

Поясню. Дело в том, что механизм выбора скрам-мастера толком нигде не описан: ни в скрам-гайде, ни в каких-либо статьях на просторах сети. Поэтому мнений множет быть достаточно. Но многие, наверняка, слышали ни раз, что скрам-мастера выбирает команда. А какая команда никто не уточняет. Но ведь в скраме есть два понятия команды: скрам команда, куда входят PO, Scrum Master и DevTeam, и команда разработки (DevTeam).

В моем восполенном воображении скрам-мастера должна выбирать именно DevTeam. Потому что скрам-мастер бОльшую часть своего времени работает именно с ней, так как именно DevTeam поставляет инкремент и от ее эффективности будет зависеть скорость и качество. PO лишь транслирует свое видение и задает вектор движения для DevTeam, понимает что клиенту нужно именно сейчас и передает это в работу. PO должен доверять своей команде разработке и ее выбору.

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

Может быть я очень идеализирую.

А как считаете вы?

Друзья, мне также интересно узнать как вы оцениваете свои знания об Agile/Scrum по шкале от 1 до 55, где 55 - уровень Герман Греф, а 1 - новичок. Уделите 5 секунд времени :)
anonymous poll

21 – 23
👍👍👍👍👍👍👍 37%

34 – 13
👍👍👍👍 21%

8 – 11
👍👍👍 17%

1 – 8
👍👍 13%

3 – 6
👍👍 10%

55 – 2
👍 3%

👥 63 people voted so far.

​Сегодня проводил игру GetKanban для одной из команд, поскольку ребятам необходимо было разобраться в принципах Kanban. И после игры я попросил ребят поделиться своими мыслями, инсайтами. В общем дать любую обратную свзяь.

Один из членов команды сказал: "Любое событие влияет на скорость команды". Речь разумеется шла о событиях, которые происходили в игре. Но ведь если подумать шире, то действительно так и есть. Абсолютно любое событие, которое происходит внутри команды и во внешней окружающей ее среде — может повлиять на скорость. Как положительно, так и отрицательно.

Проблема только в том, что не всегда мы можем знать об этом событии. И не всегда можем понимать, что что-то произошло. Помочь выявить проблему могут графики скорости и эффективности команды (velocity, burndown, cycle time, CFD и др.). Важно только вовремя заметить ее. Это задача скрам-мастера.

Если график сигнализирует нам о проблеме, то докапаться до сути не составит большого труда.

Итого абсолютного большинства не образовалось и мир раскололся на 2 половины :)))))))))))
Значит вопрос очень спорный

Особенно удивило, что за PO голоса тоже были.

Тут хотелось бы пояснить тогда. Не правильно, когда PO единолично выбирает SM. Все-таки PO — это 1 человек, а команда — много. SM не только с PO будет взаимодействовать и не для него лично строить процесс.

Чем отличается PM от PO?

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

В случае проекта это:
- Время. Проект имеет рамки. Четкое начало и понятный, измеримый конец. Обычно рамки зафиксированны в договоре.
- Деньги. Конкретная сумма денег, требуемая на реализацию задач в зафиксированных временных рамках, также фиксируемая в договоре (спойлер: обычно денег нужно больше).
- Скоуп. Все окружение проекта, включая его предметную часть, договорную, внешние и внутренние факторы.
- Качество. В конечном итоге все замыкается на качестве. Заказчик должен получить то, чего он хотел. Не всегда это так, конечно. Часто заказчик получает совсем не то, что он хотел из-за абсолютно непрозрачного процесса.

Этим безобразием управляет PM.

В случае продукта это:
- Время. Продукт не имеет окончательного срока, он не ограничен в своем развитии.
- Деньги. Невозможно запланировать деньги на весь продукт, потому что он не имеет конечной временной границы.
- Скоуп. Все то же самое, что и в проекте.
- Качество. Качество также имеет весомое значение, но из-за постоянного взаимодействия с конечными пользователями и SH, качество намного предсказуемее и выше, чем в проекте.
- Бизнес-ценность. Продукт концентрируется на доставленной ценности своему пользователю и приобретенной выгоде для бизнеса, о чем забыто в проекте. Там важнее сроки и потраченные деньги.

Этим всем управляет PO.

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

Скрам очень хорошо применим для настоящих продуктов.

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

Сегодня, хотел бы обратить внимание на опрос об оценке знаний Agile/Scrum. Судя по его результатам примерно 39% ответивших оценивают свои знания как не очень высокие. Поэтому, думаю, что будет полезно рассказать о модели Cynefin.

Эту модель придумал Дейв Сноуден. Он всю жизнь занимается исследованием различных систем, накоплением и управлением знаниями. И вот, накопив определенный пласт, Дейв разработал модель, где поделил наш мир на 4 области. Каждая из четырех областей Cynefin соответствует определенному способу восприятия и понимания проблемы или ситуации — от того, к какой области мы отнесем проблему, будет зависеть стратегия нашего мышления — как мы будем воспринимать ситуацию и какие выводы делать.

1. Первая область — область очевидных систем. Здесь находятся, что называется — лучшие практики. В этой области есть 1 очевидное решение, которое 100% позволит добиться результата. Из точки А в точку В можно прийти одним путем. Например, лучший способ собрать стол из Икеи — воспользоваться инструкцией. Другого изобретать не требуется.

2. Вторая область — область сложных систем. Здесь живет симейство хороших практик. Эта область характерна вариативностью выбора решения. К примеру, из точки А в точку B можно прийти тремя разными путями, но каждый из них будет верен и мы будем знать о существовании этих решений. Построить башню из лего можно разными способами, но при любом из них мы получим башню.

3. Третья область — область запутанных систем. Здесь живут возникающие практики. В запутанных системах существует большое количесвто переменных или факторов и еще больше причинно-следственных связей между ними, но не о всех мы можем знать. Такая солянка не позволяет использовать анализ или классификацию. Поэтому мы вынужденны идти маленькими шажками и постоянно анализировать результат.

4. Четвертая область — область хаоса. Здесь появляются совершенно новые практики. Эта область характерна совершенно неявными причинно-следственными связями и их приходится искать самим быстрыми действиями и немедленной реакцией на свои действия. Обычно именно в этой области рождаются инновации.

По середине — неопределенность. В эту область выгружаются все аспекты проблемы, согласие по которым между участниками не достигнуто.

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

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

Как понять "продукт у меня или нет"?

Самым первым признаком, которым должен обладать продукт — четкая обособленная бизнес-модель. Продукт — это в первую очередь бизнес, который имеет определенную модель доходов и расходов (p&l). Например, основным продуктом и источником дохода мебельной фабрики является продажа мебели. Весь ресурс и инфраструктура, которая стоит за созданием конечного изделия — имеет право называться продуктом. Но если фабрика решает дополнительно предоставлять услуги по сборке мебели (не обязательно своей), то по сути она запускает новый продукт, который генерит иную прибыль, и за конечным продуктом — собранной мебелью, будет стоять иной ресурс, иные бизнес-процессы и иная инфраструктура.
В большинстве случаев многие уверены, что они развивают продукт (к примеру, какую-нибудь ERP систему), но на самом деле этот "продукт" является либо лишь частью бизнес-модели, либо сервисом, который не направлен на внешнего клиента. Иными словами, он не приносит нам денег. Здесь всегда нужно смотреть шире.

Второй признак — продукт имеет внешнего клиента. Именно он [клиент] и приносит деньги вашему продукту, на которые он [продукт] существует.

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

Недавно начал работать с новой командой, с которой в прошлую пятницу мы прошли первый спринт, а в понедельник у нас случилось демо и ретроспектива.

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

Так вот, к чему это я. На первом ретро команды я задал вопрос "А что вам понравилось в прошедшем спринте?".

Я услышал просто два потрясающих ответа, которые наверно каждый скрам-мастер мечтает услышать от своей команды:

- PO сказал, что ему понравился "результат". И здесь он скорее всего имел в виду все, не только инкремент
- Один из разрабов сказал, что ему понравился "фокус" — одна из ценностей скрама, мощь которой он ощутил на себе в полной мере. Он пояснил, что до этого он жил в какой-то постоянной расфокусировке и раздрайве, всего делал по чуть-чуть, но не доделывал до конца, а в последние 2 недели у него был четкий фокус на задачах, которые он успешно и дотащаил до конца.

И это всего лишь один спринт прошел! А сегодня на дейли PO еще раз сказал, что он просто в восторге от происходящего.

В общем я очень рад, а вам наглядный результат, который способен дать скрам.

А как вы думаете, какое самое важное событие в Scrum?
anonymous poll

Самого важного нет – 34
👍👍👍👍👍👍👍 48%

Retrospective – 14
👍👍👍 20%

PBR (Grooming) – 6
👍 8%

Daily Meeting – 5
👍 7%

Sprint planning – 5
👍 7%

Sprint review – 4
👍 6%

Demo – 3
👍 4%

👥 71 people voted so far.

Оставьте побольше голосов, интересно ваше мнение :)))

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

На самом деле несколько провакационный вопрос был, но 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 в России очень поверхностное. Не везде конечно, но во многих компаниях.