​Вот такой веселый постер висит у нас в офисе, который напоминает кем скрам-мастер является, а кем нет. Картинки легче воспринимаются, чем слова.

Добавляйтесь в чат о проектном менеджменте, тут обсуждаться насущные темы, все по делу. Находим решения вместе.
https://t.me/joinchat/EuUO5g6eDqLcvk4ZPu3nLg

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

Scrum также имеет ДНК. Разумеется оно намного проще, чем человеческое и состоит всего из 3х элементов. При неполноценности или отсутствии хотя бы одного из них, мы имеем неполноценный, храмой или, как часто любят говорить, адаптированный (знакомо?) скрам. Ну или в противном случае и вовсе его отсутствие.

Так вот. 3 элемента:

- Эмпиризм
- Самоорганизация
- Ценности Scrum

О самоорганизации ничего нового не расскажу, думаю, и так понятно что это, много где об этом говорится.

О ценностях скрама я уже писал выше, а вот эмпиризм прокомментирую.

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

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

- Прозрачности
- Инспекции
- Адаптации

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

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

Снова моя любимая рубрика "Вакансия дня"

Production manager
- Помощь PO в формировании backlog перед планированием спринта
- Проведение ежедневных stand-up встреч
- Проведение ретроспектив после завершения спринта
- Обнаружение проблем, которые могут привести к закрытию целей спринта
- Устранение блокеров, озвученных командой

По описанию очень похоже на Scrum Master, но вот почему это названо Production manager ума приложить не могу😂

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

У меня есть показательный кейс на эту тему. Расскажу о нем позже.

Слушайте, я тут подумал, что я как-то совсем не представился и не рассказал о себе. Гораздо приятнее читать человека, о котором ты хоть что-то знаешь :)

Меня зовут Максим. Сейчас я работаю скрам-мастером в одной из крупнейших компаний в России. Офис находится в СПб. Я работаю не только с командами, но и с организацией. У нас есть своя отдельная команда, которая занимается Agile трансформацией компании и развитием business agility.

Я посещал тренинги и конференции по Agile и Scrum. Проходил сертификацию PSMI. Читал много полезной тематической литературы.

В целом, у меня около 1,5 лет чистого опыта в качестве скрам-мастера. До этого, около года работал Project manager в одном из digital-агенств СПб.

Я открыт к диалогу, и хотел бы также узнать что-то вас. Так что не стесняйтесь писать и задавать вопросы :)

Первое что интересно мне узнать, какая аудитория здесь собралась:
anonymous poll

Project manager – 27
👍👍👍👍👍👍👍 28%

Scrum master – 27
👍👍👍👍👍👍👍 28%

Специалист (любой) – 26
👍👍👍👍👍👍👍 27%

Top manager – 9
👍👍 9%

Product Owner – 6
👍👍 6%

Product manager – 2
👍 2%

👥 97 people voted so far.

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

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

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

Примерно год назад у нас в компании только началась 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 часа раз в спринт, где уточняем элементы бэклога, фокусируемся на целях, обсуждаем задачи. Подобная практика показывает себя только с самой лучшей стороны и все члены команды чувствуют пользу от этого.

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

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