1. Глупыми я никого здесь не считаю.
2. Если 15-минутки идут ежедневно и в целом всё ок (все понимают для чего у них Скрам), то ненужно к ним готовиться.
3. События (обязательные встречи, если в общем) в Скрам не отменяют других встреч и прочего общения членов команды.
4. Про «клоунаду». Формат Daily Scrum может определить сама команда. Важно получить информацию по статусу движения к цели спринта и есть ли какие проблемы с этим.
В целом, если команда только начинает свой путь в Agile/Scrum, то лучше просто следовать гайду (видимо это подразумевается под «ритуалами»). Дальше, по мере того, как будет больше опыта и понимания фреймворка, всё должно стать проще. На самом деле в статье я вскользь упомянул про «сюхари» (можно посмотреть Вики) — это, на мой взгляд, как раз на данную тему.
Очень часто возникает ситуация, когда «все всё знают», сидя рядом друг с другом, а на Daily выясняется, что кто-то один мучается с проблемой, решение которой знает другой. Или же когда происходит «вброс», который приводит к существенному изменению в работе.
Судя по вашим комментариям вы очень даже в теме ;-)
Есть ещё такая штука как критерии INVEST, DOR (Definition Of Ready). Если вам интересно, то почитайте.
DOR — это то, что, например, про задачи внешнего вендора, от которых зависит ваша команда. Но фишка в том, чтобы не увлекаться DOR везде и всюду, так как перебор ведёт в неуместный Waterfall (я не против Waterfall, подчёркиваю «неуместный» в случае выбранного Agile-подхода).
«Ванильное» это и есть из первоисточника. Я использовал английскую вики, гугл тоже использует слово «facilitator» для скрам мастера в своём определении.
В принципе можно посмотреть в гайде, включая обязанности СМ для PO, DevTeam и Организации. В общем там не только фасилитация.
Скрам-мастер задуман действительно как коуч. Но по-факту в зрелой команде — именно что назначает встречи (те, что в рамках скрам-процесса) и следит за регламентом (чтобы ретро уложилось в отведённое время митинга, чтобы команда не «забыла» показать демо, чтобы не было перекоса по поинтам от спринта к спринту и готовит кучу отчетности по спринту). Поэтому в зрелых командах скрам-мастера и правда частенько выпиливают, а его обязанности взваливают на ПО или на членов команды по-очереди, что как по мне, так весьма неэффективно. Обычно «дежурный» СМ как свои функции не может выполнить нормально, так и скрам-мастера настоящего заменить полноценно не может.
В целом согласен с вами. Если уже не особо требуется команде, то пора ему подумать дальше, как расти, так как есть куда.
Вам нечем, потому что, исходя из своего опыта (очень большого кстати), это бессмысленно. Потому что начинать надо издалека, минимум, с 90-х.
Но здесь это будет потерей времени.
При первом знакомстве, на мой взгляд, неправильно хамить.
Подобное отношение, как у вас, встречал и довольно часто. Не назвал бы его высокоэффективным.
А просить, или оправдываться перед вами и не собирался, так как в данном случае это всё равно что «бисер перед...» (дальше наверное известно).
По Скрам-команде: должна быть кросс-функциональной и самоорганизующейся.
То, что вы, скорее всего, имеете в виду — это про кросс-функциональность (не следует путать со взаимозаменяемостью). То есть когда в команде присутствуют все необходимые компетенции для создания продукта от начала и до конца и, соответственно, она не зависела бы от компетенций извне.
В вашем случае необходимо договариваться и брать дизайнера в Скрам-команду, что, скорее всего, уже будет вопросом на уровне Организации и трансформации соответственно.
В Скрам-команде всего три роли: PO, SM и Development Team. Грубо говоря, «разработчик» (developer) в Scrum Team — это тот, кто непосредственно выполняет работу «руками» :-), например, кодит, тестит, организует маркетинговые компании и т.д. Короче не только о программерах идёт речь :-)
Прежде всего, спасибо за комментарий!
Цель как раз и была «вбросить», или просто, чтобы люди призадумались, что всё не просто так и не стоит «верить слухам» ;-), а многое можно почерпнуть из уже имеющихся общедоступных источников.
Я намеренно не стал растолковывать весь Скрам-гайд, а только дал «для затравочки».
Вам конкретно отвечу:
1. Цель спринта (беру из русской версии документа, хотя рекомендую пользоваться английской, как первоисточником): «Цель Спринта – это установленный для Спринта ориентир, который достигается через выполнение части Бэклога Продукта.»
2. Скрам-мастер: несет ответственность за продвижение и поддержку Скрама в соответствии с Руководством по Скраму. Он достигает этих целей, помогая всем понять теорию, практики, правила и ценности Скрама.
Скрам-мастер — это лидер-слуга для Скрам-Команды. Людям вне команды он помогает понять, что из их взаимодействий со Скрам-командой полезно, а что нет. Скрам-мастер помогает изменить эти взаимодействия так, чтобы они максимально увеличивали ценность, которую создает Скрам-команда.
3. Product Owner (Владелец Продукта): Владелец Продукта несет ответственность за достижение максимальной ценности продукта как результата работы, которую выполняет Команда Разработки. Способы достижения максимальной ценности могут различаться и зависят от самих организаций, Скрам-команд и конкретных людей.
Владелец Продукта – единственный человек, который отвечает за управление Бэклогом Продукта.
Как я уже написал в статье, одна из целей — это показать, что прежде чем давать какие-либо вольные интерпретации ролям и зонам ответственности, необходимо детально ознакомиться с первоисточником.
Что такое «ванильное определение», я не знаю но, подозреваю, что это частично то, о чём я писал: секретарь, прислуга, психолог. Вот как раз НЕТ!
В идеале СМ в части работы с командой стремиться создать из неё самоорганизующуюся команду и, опять же таки в идеале, команда должна научиться обходиться без него (без СМ).
Могу ещё много писать, но не буду :-), чтобы не написать коммент размером со статью :-)
Всегда готов пообщаться в оффлайне на эти темы!
Очередной антипаттерн в Scrum.
Daily Scrum не про то, что вы пишете.
Большинство так и пребывают в счастливом (хотя нет, скорее, в несчастном, раз так всё бесит) неведении, для чего эта встреча.
Много писать не буду, так как обычно это всё равно что "метать бисер...", скажу только, что три вопроса, которые вы привели — это про обычный, как правило бессмысленный, ежедневный отчёт. С таким же успехом туда же можно про количество "чаёв и походов в туалет" добавить.
Daily Scrum — это про статус в части движения к цели спринта. А теперь спросите вокруг, кто понял о чём это. Кстати, в Scrum Guide и про цель спринта тоже написано.
Беда в том, что множество "Scrum-команд" (именно в кавычках) понятия не имеют, что такое Scrum Guide. А если и имеют понятие, то не поняли, или поняли, но не осознали написанного.
Я ни разу ещё в своей практике не встречал такую дрим-тим, чтобы ей не нужно было ничего рассказывать, показывать, организовывать процесс, улучшаться и т.д.
Я не настаиваю на использовании именно Scrum, DSDM, XP и т.д. На мой взгляд, данные фреймворки способствуют формированию эффективного процесса работы. Они формализованы. В то, что БОЛЬШИНСТВО знает как эффективно организовать свою работу лично я не верю. Отчасти можете посмотреть на концепцию сюхари, тогда должно стать понятнее, для чего все эти "рамки".
Основная проблема организаций, которые трансформируются и идут в Agile/Scrum/… заключается в том, что либо они сами не понимают, какую проблему они решают, и как им в этом поможет та или иная методология/фреймворк. Либо они не могут это нормально донести до сотрудников. В результате, в том же Scrum получаем не "роли, события, артефакты и правила, которые их связывают", а "ритуалы", "психотерапевтические ретро", "доставку пиццы по пятницам" и т.п. (излюбленная тема про зону ответственности Scrum-мастеров).
Хорошо, когда находится человек, которому интересна эта тема, и который может попытаться донести всю глубину (а она реально большая) того, для чего весь этот Agile и Scrum. По опыту же получается бездумное служение "карго-культу" и дискредитация Agile/Scrum.
Покажу разницу (интерпретация на русском языке): "простой для понимания" vs. "трудный для совершенного овладения".
Что должен делать Скрам-мастер также написано в Scrum Guide. В первую очередь, несёт ответственность за продвижение и поддержку Scrum в соответствии со Scrum Guide.
Говорить остальным членам команды что и как делать идёт вразрез с понятием самоорганизующейся (self-organizing) команды и больше похоже на руководство детским садом, например.
"Простым" разработчикам, возможно, и незачем его понимать.
Автору спасибо за то, что поделился, как трансформация идёт в его компании.
Судя по написанному работы у вас ещё очень много и вы на пути к Scrum.
Понимаю, что бесплатный совет обычно не обладает высокой ценностью :-), но рекомендовал бы больше внимания уделить Scrum Guide'у, как основному документу про Scrum (обратите внимание на End Note).
Не соглашусь с тезисом про то, что мало где пишут про то, что нельзя совмещать роли PO и SM. На самом деле это одна из самых часто упоминаемых тем, суть которой в ярком конфликте интересов у этих двух ролей.
Можете на схожие темы погуглить: PO vs. PM, SM vs. PM и т.д. найдёте очень много интересного и полезного для себя и своих коллег.
Для всех непонимающих (обычно это касается событий в Scrum, например Daily Scrum): вы, скорее всего, не знаете и не понимаете фреймворка и его сути. Здесь я ничего никому доказывать не буду, потому что комментарий разрастётся до размера статьи и даже больше :-) Обратите лишь внимание на следующие определения в Scrum и попробуйте осознать их глубину, особенно последнего, третьего:
Scrum is:
• Lightweight
• Simple to understand
• Difficult to master
В заключение хочу сказать, что в служении "карго-культу Scrum" я замечен не был :-), и основная проблема компаний и команд в том, что они Scrum'ом называют НЕ Scrum, а что-то другое, при этом страдают ни в чём невиновные команды :-)…
В Scrum'е я немного понимаю, так как практикую его уже некоторое время и являюсь сертифицированным (Scrum.org: для знающих людей ценность сертификации на этом ресурсе должна быть понятна) специалистом .
2. Если 15-минутки идут ежедневно и в целом всё ок (все понимают для чего у них Скрам), то ненужно к ним готовиться.
3. События (обязательные встречи, если в общем) в Скрам не отменяют других встреч и прочего общения членов команды.
4. Про «клоунаду». Формат Daily Scrum может определить сама команда. Важно получить информацию по статусу движения к цели спринта и есть ли какие проблемы с этим.
В целом, если команда только начинает свой путь в Agile/Scrum, то лучше просто следовать гайду (видимо это подразумевается под «ритуалами»). Дальше, по мере того, как будет больше опыта и понимания фреймворка, всё должно стать проще. На самом деле в статье я вскользь упомянул про «сюхари» (можно посмотреть Вики) — это, на мой взгляд, как раз на данную тему.
Очень часто возникает ситуация, когда «все всё знают», сидя рядом друг с другом, а на Daily выясняется, что кто-то один мучается с проблемой, решение которой знает другой. Или же когда происходит «вброс», который приводит к существенному изменению в работе.
Есть ещё такая штука как критерии INVEST, DOR (Definition Of Ready). Если вам интересно, то почитайте.
DOR — это то, что, например, про задачи внешнего вендора, от которых зависит ваша команда. Но фишка в том, чтобы не увлекаться DOR везде и всюду, так как перебор ведёт в неуместный Waterfall (я не против Waterfall, подчёркиваю «неуместный» в случае выбранного Agile-подхода).
В принципе можно посмотреть в гайде, включая обязанности СМ для PO, DevTeam и Организации. В общем там не только фасилитация.
В целом согласен с вами. Если уже не особо требуется команде, то пора ему подумать дальше, как расти, так как есть куда.
Но здесь это будет потерей времени.
Подобное отношение, как у вас, встречал и довольно часто. Не назвал бы его высокоэффективным.
А просить, или оправдываться перед вами и не собирался, так как в данном случае это всё равно что «бисер перед...» (дальше наверное известно).
2. Если команда работает не по Скрам, СМ ей не нужен.
Вроде основные ситуации разобрали.
1. Кому не нужен?
и
2. Когда не нужен?
То, что вы, скорее всего, имеете в виду — это про кросс-функциональность (не следует путать со взаимозаменяемостью). То есть когда в команде присутствуют все необходимые компетенции для создания продукта от начала и до конца и, соответственно, она не зависела бы от компетенций извне.
В вашем случае необходимо договариваться и брать дизайнера в Скрам-команду, что, скорее всего, уже будет вопросом на уровне Организации и трансформации соответственно.
В Скрам-команде всего три роли: PO, SM и Development Team. Грубо говоря, «разработчик» (developer) в Scrum Team — это тот, кто непосредственно выполняет работу «руками» :-), например, кодит, тестит, организует маркетинговые компании и т.д. Короче не только о программерах идёт речь :-)
Цель как раз и была «вбросить», или просто, чтобы люди призадумались, что всё не просто так и не стоит «верить слухам» ;-), а многое можно почерпнуть из уже имеющихся общедоступных источников.
Я намеренно не стал растолковывать весь Скрам-гайд, а только дал «для затравочки».
Вам конкретно отвечу:
1. Цель спринта (беру из русской версии документа, хотя рекомендую пользоваться английской, как первоисточником): «Цель Спринта – это установленный для Спринта ориентир, который достигается через выполнение части Бэклога Продукта.»
2. Скрам-мастер: несет ответственность за продвижение и поддержку Скрама в соответствии с Руководством по Скраму. Он достигает этих целей, помогая всем понять теорию, практики, правила и ценности Скрама.
Скрам-мастер — это лидер-слуга для Скрам-Команды. Людям вне команды он помогает понять, что из их взаимодействий со Скрам-командой полезно, а что нет. Скрам-мастер помогает изменить эти взаимодействия так, чтобы они максимально увеличивали ценность, которую создает Скрам-команда.
3. Product Owner (Владелец Продукта): Владелец Продукта несет ответственность за достижение максимальной ценности продукта как результата работы, которую выполняет Команда Разработки. Способы достижения максимальной ценности могут различаться и зависят от самих организаций, Скрам-команд и конкретных людей.
Владелец Продукта – единственный человек, который отвечает за управление Бэклогом Продукта.
Как я уже написал в статье, одна из целей — это показать, что прежде чем давать какие-либо вольные интерпретации ролям и зонам ответственности, необходимо детально ознакомиться с первоисточником.
Что такое «ванильное определение», я не знаю но, подозреваю, что это частично то, о чём я писал: секретарь, прислуга, психолог. Вот как раз НЕТ!
В идеале СМ в части работы с командой стремиться создать из неё самоорганизующуюся команду и, опять же таки в идеале, команда должна научиться обходиться без него (без СМ).
Могу ещё много писать, но не буду :-), чтобы не написать коммент размером со статью :-)
Всегда готов пообщаться в оффлайне на эти темы!
Очередной антипаттерн в Scrum.
Daily Scrum не про то, что вы пишете.
Большинство так и пребывают в счастливом (хотя нет, скорее, в несчастном, раз так всё бесит) неведении, для чего эта встреча.
Много писать не буду, так как обычно это всё равно что "метать бисер...", скажу только, что три вопроса, которые вы привели — это про обычный, как правило бессмысленный, ежедневный отчёт. С таким же успехом туда же можно про количество "чаёв и походов в туалет" добавить.
Daily Scrum — это про статус в части движения к цели спринта. А теперь спросите вокруг, кто понял о чём это. Кстати, в Scrum Guide и про цель спринта тоже написано.
Беда в том, что множество "Scrum-команд" (именно в кавычках) понятия не имеют, что такое Scrum Guide. А если и имеют понятие, то не поняли, или поняли, но не осознали написанного.
Постараюсь ответить коротко.
Покажу разницу (интерпретация на русском языке): "простой для понимания" vs. "трудный для совершенного овладения".
Что должен делать Скрам-мастер также написано в Scrum Guide. В первую очередь, несёт ответственность за продвижение и поддержку Scrum в соответствии со Scrum Guide.
Говорить остальным членам команды что и как делать идёт вразрез с понятием самоорганизующейся (self-organizing) команды и больше похоже на руководство детским садом, например.
"Простым" разработчикам, возможно, и незачем его понимать.
Автору спасибо за то, что поделился, как трансформация идёт в его компании.
Судя по написанному работы у вас ещё очень много и вы на пути к Scrum.
Понимаю, что бесплатный совет обычно не обладает высокой ценностью :-), но рекомендовал бы больше внимания уделить Scrum Guide'у, как основному документу про Scrum (обратите внимание на End Note).
Не соглашусь с тезисом про то, что мало где пишут про то, что нельзя совмещать роли PO и SM. На самом деле это одна из самых часто упоминаемых тем, суть которой в ярком конфликте интересов у этих двух ролей.
Можете на схожие темы погуглить: PO vs. PM, SM vs. PM и т.д. найдёте очень много интересного и полезного для себя и своих коллег.
Для всех непонимающих (обычно это касается событий в Scrum, например Daily Scrum): вы, скорее всего, не знаете и не понимаете фреймворка и его сути. Здесь я ничего никому доказывать не буду, потому что комментарий разрастётся до размера статьи и даже больше :-) Обратите лишь внимание на следующие определения в Scrum и попробуйте осознать их глубину, особенно последнего, третьего:
Scrum is:
• Lightweight
• Simple to understand
• Difficult to master
В заключение хочу сказать, что в служении "карго-культу Scrum" я замечен не был :-), и основная проблема компаний и команд в том, что они Scrum'ом называют НЕ Scrum, а что-то другое, при этом страдают ни в чём невиновные команды :-)…
В Scrum'е я немного понимаю, так как практикую его уже некоторое время и являюсь сертифицированным (Scrum.org: для знающих людей ценность сертификации на этом ресурсе должна быть понятна) специалистом .