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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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