Суть идеи в том, что любой член команды может решить любую задачу из backlog.
Это где такая суть? У кого?
Если разбирать перечисленные вами пункты из scrum guide, то приведу моё понимание:
Scrum recognizes no titles for Development Team members
Фокус на том, чтобы не было фраз типа «я [такой то] и не буду делать [то-то], потому что это не моя обязанность». Если работа должна быть сделана, то она должна быть сделана. Все прикладывают максимально возможные усилия для достижения цели спринта. Опять же это не означают тупое вкалывание. Scrum требует планирование спринта, где один из вопросов на который должна ответить команда это: «How will the work needed to deliver the Increment be achieved?». Т.е. команда составляет план спринта и прикидывает как распределить свои силы на дистанции. Т.е. уже на планировании команда может увидеть, что не хватает сил по какому то направлению, и как следствие распределить эту работу. пример из другого моего комментария.
Scrum recognizes no sub-teams in the Development Team
Ну это примерно как и предыдущий пункт, не должно быть под-ролей / под-команд с личными целями. У всех фокус на достижение цели спринта.
Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.
А тут в общем то и говорится, что могут быть специализированные скилы у отдельных членов команды и они усиливают команду в целом. Что в этом и сила: берем людей разной специализации, правильно настраиваем их (взаимопомощь, обучение друг друга, фокусировка на общей цели) и получаем scrum команду.
Очень плохо, когда инкременты фиктивные. В целом можно и до MVP получать обратную связь, прототипное тестирование (бумага, картон), например. Делая автоматизирование решение, можно готовить сперва прототип с человеком внутри, который будет выполнять задачи автоматизации. Сила эмпирического процесса в том, чтобы получать обратную связь как можно раньше. Если проявлять изобретательность, то можно делать не-фиктивные инкременты, а пригодные для получение обратной связи (но например непригодные для выпуска на рынок).
Важный вопрос сколько нужно времени на создание MVP, если это полгода в вакууме, то стоит подумать об эмпиризме. Если это месяц, то делайте месячные спринты (конечно если scrum вам подходит).
Мне кажется, в стартапе вообще фреймворки не нужны (Ровно из тех причин, которые вы описываете). В стартапе ты либо делаешь то что нужно, либо стартап исчезнет. В моем опыте стартап (нас было 9 человек, я был разработчиком) — это по-настоящему эмпирический процесс, но не настолько формализованный как scrum. И, например, когда нужно было монтировать оборудование, то никто не говорил — «это не моя обязанность», мы просто шли и делали.
Тут еще вопрос что называть стартапом, ведь понятие стартапа зачастую опошлено, также как agile и scrum. Приходилось видеть, как компании с более чем 10-тилетним существованием на рынке и 1000+ сотрудников любят называть себя стартапом.
И именно для стартапов подходит компактная команда, «средне-компетентная» во всех технических аспектах (каждый член команды — full-stack)
Мне кажется грубоватое допущение. Это может быть во многих аспектах так (стартап — это же ограниченный бюджет), но скорее всего (если мы говорим о технологических стартапах) в области ключевого преимущества продукта работают настоящие спецы.
максимальное снижение лага обратной связи для возможности быстро проверять бизнес-идеи… По сути, скрам — это про стартапы, когда «лучше хуже, но раньше».
Эта схема актуальна на конкурентном рынке: либо ты запускаешь свежую бизнес-идею, либо ты позже копируешь её у конкурентов. Т.е. потребность есть не только в стартапах. Закрывать потребность можно по разному и scrum — это не единственный ответ.
Это уже именно тот момент, когда для удержания завоёванных позиций на рынке нужны более жёсткие регламенты и специализация сотрудников, когда уже пора «цементировать» выстроенные в ходе «скрамного» этапа неявные процессы в виде явных ролей, документов, регламентов и прочей ненавистной хипстерскому духу бюрократии.
Сильное утверждение, но я не до конца понимаю почему это "НУЖНО"? Понимаю, что это холиварная тема, тут в общем то копья и ломаются. Но может быть у вас есть примеры?
Отсюда и большинство негатива по отношению к скраму и расхожие слухи о его неудачных внедрениях. Да, часто его внедряют не так (и об этом, в том числе, данная статья). Но ещё чаще, как мне кажется, его внедряют совершенно не там.
Золотые слова! Очень хочется, чтобы перед внедрением scrum, те кто это делают осознали для чего они это делают? И подходит ли scrum под решение их задачи.
Не сильвербуллет, как оказалось, далеко не, но в любом случае не надо ничего абсолютизировать.
Полностью согласен. И в статье пытаюсь донести мысль, что карго-scrum больше вредит, чем приносит пользу. Первое что нужно сделать перед внедрением scrum — это понять для чего вы это делаете? какие задачи решаете? какие цели преследуете? Scrum в чистом виде требует многого от непосредственных участников и как следствие от организации. И это точно не серебряная пуля. Scrum сработает там, где это осознанный и взвешенный выбор.
Команда, любой член которой способен эффективно выполнять любую работу в команде, это команда землекопов, в крайнем случае лесорубов… Можно по 2 человека на одну специализацию держать, типа один в резерве...
Конечно же если уравнивать команду, то получим среднячков, которые решают небольшой набор задач. Приведу простой пример из WEB, допустим есть frontend и backend специалисты в команде. Собрали спринт где требуется больше backend. И есть два поведения команды:
Frontend делает свою работу, и «ждет» backend.
Backend делает архитектуру решения и куски реализации отдает frontend разработчикам, а затем уже ревьют результаты.
Во втором варианте команда более гибкая. По моему мнению нужно стремится ко второму варианту.
«Удваивать» компетенции только для резерва точно не стоит. Больше людей => нужно больше коммуникаций => эффективность ниже.
Тут нет противоречия. Scrum guide говорит о том, что команда должна быть кросс-функциональной: «Development Teams are cross-functional, with all the skills as a team necessary to create a product Increment;» Отсюда мой кейс о том, что команда должна стараться получать все необходимые компетенции для создания инкремента. Это фактически необходимое правило. А дальше уже становится важен bus factor команды: развиваем t-shaped, чтобы одни члены команды могли подстраховать других в случае чего.
НО это абсолютно не означает, что все члены должны быть одинаковыми по своим умениям и знаниям. Наоборот если команда полностью состоит MEGE-FULL-STACK специалистов, то из таких людей сложно сколотить команду, потому что они могут решать задачи в одиночку, зачем им работать командой?
Речь именно о T — специалистах: «individual who has deep knowledge and skills in a particular area of specialization, along with and the desire and ability to make connections across disciplines.»
термин «профессионал» про специализацию, а не про решение любых задач.
Но и про «решение задач» — это относится к команде целиком, а не о каждом её члене в отдельности. Конечно нужны настоящие профессионалы в своих различных областях, чтобы команде были по плечу настоящие вызовы. Вопрос в том, что станет с общекомандной функциональной мощностью в отсутствии одного из его членов: команда полностью не сможет решать определенный пласт задач, либо просто будет это делать дольше и с меньшим качеством.
Нужно аккуратно использовать вместе слова «scrum» и «назначить». Все-таки мы говорим об самоорганизации, как о ключевой характеристике scrum команды.
Лид может быть, вопрос в том какие задачи и как он решает.
О про тимлида — это очень большой вопрос. На прошедшем весной Codefest в Новосибирске был отдельный поток про это. У Жени bunopus был классный доклад про ТимЛидство — 2018.codefest.ru/lecture/1316 очень советую посмотреть.
Так же мы устраивали дисскусию на эту тему — 2018.codefest.ru/lecture/1337
Scrum guide учит нас, что сила в эмпирическом процессе (прозрачность, инспекция, адаптация.). Чтобы «объяснить» про доверие, проводите эксперимент: отмените индивидуальную оценку сотрудников снаружи команды; введите командную оценку и ответственность; дайте команде общую цель и помогите им сфокусироваться на ней. Задайте условия эксперимента — срок, критерии оценки и т.д. — это прозрачность. Проводите ежедневную синхронизацию членов команды и проведите ретроспективу по завершению эксперимента — инспекция. В случаи препятствий ищите варианты выхода — адаптация.
Главное человеку (по-идее это scrum master), который будет проводить этот эксперимент, заранее подготовиться к нему: понять для чего он это делает? куда он хочет привести команду? чему хочет её научить? Поставив цель, надо разработать план, а дальше действовать.
В целом вы правы, если нет понимания для чего внедрять Scrum и какие стоят перед ним задачи, то ничего хорошего из этого не выйдет. Чудо само по себе не случится. Карго-Scrum действительно дает больше боли, чем пользы.
Но важно понимать, что команда / кадры тут скорее всего не при чем (человеческая природа — искать состояние покоя). Нужны Агенты Изменений, который понимают, что они хотят сделать и зачем. Организация и её культура должны быть готовы к agile и тогда всё получится: можно построить из группы людей — «команду мотивированных профессионалов нацеленных на качество продукта». Но для этого нужно честно ответить себе на вопросы: «Для чего мы это делаем? Готовы ли мы меняться?».
Запустить Scrum сама по себе задача непростая, а делать это в партизанских условиях — это просто героизм. ИМХО сперва нужно, чтобы «наверху» осознали и приняли, а дальше уже народ потянется.
Отличный кейс! Странно, что PO надо заинтересовывать в продукте. Если продукт не нужен PO, то кому он вообще тогда нужен?
А в день релиза он уходит в отпуск и вырубает телефон и все мессенджеры.
Ну это просто не профессионализм независимо от позиции в компании. Детский сад. Зачем такой человек компании в принципе? Какие задачи он решает?
зато «мы успешно внедрили скрам во всех командах».
Если есть доступ к руководству, задайте прямой вопрос: «а для чего? Зачем мы внедрили Scrum?»
Из описания очень похоже, что ваш PO — это «прокси». И возможно есть настоящий PO — заинтересованный в продукте, который реально принимает решения: что делать и в какой последовательности. Возможно это сверх-занятой человек и у него просто нет времени заниматься бэклогом, тогда он может создать небольшую команду (discovery team — куда например могут входить аналитики и ui/ux специалисты), которая бы помогала ему в этом. Но важно донести до него, что наличие «прокси» с одной стороны искажает информацию в оба направления, с другой стороны коммуникации становятся дольше.
Соберитесь командой и сформулируйте свои ожидания от взаимодействия с PO. Затем позовите реального PO и озвучьте ему ваше ожидания. Совместно выработайте схему работы, где и PO не дергают неожиданно для него и команда получает нужную ей информацию.
Ну собственно я и хочу попытаться помочь в такой ситуации этой серией статей. Вторую часть про команду, готовим к публикации. И следом пойдет про Scrum Master-а
Изначально нужно исходить из проблематики: для чего внедряется scrum? И уже из ответа рассуждать об эффективности внедрения. Я тоже никогда не видел кристально чистого Scrum. Но Scrum, решающий поставленные перед ним задачи, встречается довольно часто. Дальше вопрос риторики — как называть получившийся процесс.
Что касается изначального скептицизма команды, то это абсолютно нормально. Люди не любят перемен. И чтобы они с ними смирились или даже захотели, нужно показывать в чем собственно преимущества. Это и есть работа Scrum Master-а. Дело это не простое, но увлекательное (я об этом в следующих частях буду писать). Вспоминаем теорию скрама и строим эмпирический процесс демонстрации сильных сторон SCRUM для скептически настроенной команды.
Это где такая суть? У кого?
Если разбирать перечисленные вами пункты из scrum guide, то приведу моё понимание:
Фокус на том, чтобы не было фраз типа «я [такой то] и не буду делать [то-то], потому что это не моя обязанность». Если работа должна быть сделана, то она должна быть сделана. Все прикладывают максимально возможные усилия для достижения цели спринта. Опять же это не означают тупое вкалывание. Scrum требует планирование спринта, где один из вопросов на который должна ответить команда это: «How will the work needed to deliver the Increment be achieved?». Т.е. команда составляет план спринта и прикидывает как распределить свои силы на дистанции. Т.е. уже на планировании команда может увидеть, что не хватает сил по какому то направлению, и как следствие распределить эту работу. пример из другого моего комментария.
Ну это примерно как и предыдущий пункт, не должно быть под-ролей / под-команд с личными целями. У всех фокус на достижение цели спринта.
А тут в общем то и говорится, что могут быть специализированные скилы у отдельных членов команды и они усиливают команду в целом. Что в этом и сила: берем людей разной специализации, правильно настраиваем их (взаимопомощь, обучение друг друга, фокусировка на общей цели) и получаем scrum команду.
Но все-таки хотелось бы понять, почему с зарабатыванием «нужно бетонировать»? Почему эмпирический процесс перестаёт работать?
Важный вопрос сколько нужно времени на создание MVP, если это полгода в вакууме, то стоит подумать об эмпиризме. Если это месяц, то делайте месячные спринты (конечно если scrum вам подходит).
Тут еще вопрос что называть стартапом, ведь понятие стартапа зачастую опошлено, также как agile и scrum. Приходилось видеть, как компании с более чем 10-тилетним существованием на рынке и 1000+ сотрудников любят называть себя стартапом.
Мне кажется грубоватое допущение. Это может быть во многих аспектах так (стартап — это же ограниченный бюджет), но скорее всего (если мы говорим о технологических стартапах) в области ключевого преимущества продукта работают настоящие спецы.
Эта схема актуальна на конкурентном рынке: либо ты запускаешь свежую бизнес-идею, либо ты позже копируешь её у конкурентов. Т.е. потребность есть не только в стартапах. Закрывать потребность можно по разному и scrum — это не единственный ответ.
Сильное утверждение, но я не до конца понимаю почему это "НУЖНО"? Понимаю, что это холиварная тема, тут в общем то копья и ломаются. Но может быть у вас есть примеры?
Золотые слова! Очень хочется, чтобы перед внедрением scrum, те кто это делают осознали для чего они это делают? И подходит ли scrum под решение их задачи.
Полностью согласен. И в статье пытаюсь донести мысль, что карго-scrum больше вредит, чем приносит пользу. Первое что нужно сделать перед внедрением scrum — это понять для чего вы это делаете? какие задачи решаете? какие цели преследуете? Scrum в чистом виде требует многого от непосредственных участников и как следствие от организации. И это точно не серебряная пуля. Scrum сработает там, где это осознанный и взвешенный выбор.
Конечно же если уравнивать команду, то получим среднячков, которые решают небольшой набор задач. Приведу простой пример из WEB, допустим есть frontend и backend специалисты в команде. Собрали спринт где требуется больше backend. И есть два поведения команды:
Во втором варианте команда более гибкая. По моему мнению нужно стремится ко второму варианту.
«Удваивать» компетенции только для резерва точно не стоит. Больше людей => нужно больше коммуникаций => эффективность ниже.
Действительно Agile и Scrum — это про эффективность:
Это про то, как делать так, чтобы и работа сделана и личная жизнь в приоритете.
НО это абсолютно не означает, что все члены должны быть одинаковыми по своим умениям и знаниям. Наоборот если команда полностью состоит MEGE-FULL-STACK специалистов, то из таких людей сложно сколотить команду, потому что они могут решать задачи в одиночку, зачем им работать командой?
Речь именно о T — специалистах: «individual who has deep knowledge and skills in a particular area of specialization, along with and the desire and ability to make connections across disciplines.»
Но и про «решение задач» — это относится к команде целиком, а не о каждом её члене в отдельности. Конечно нужны настоящие профессионалы в своих различных областях, чтобы команде были по плечу настоящие вызовы. Вопрос в том, что станет с общекомандной функциональной мощностью в отсутствии одного из его членов: команда полностью не сможет решать определенный пласт задач, либо просто будет это делать дольше и с меньшим качеством.
Лид может быть, вопрос в том какие задачи и как он решает.
Так же мы устраивали дисскусию на эту тему — 2018.codefest.ru/lecture/1337
Главное человеку (по-идее это scrum master), который будет проводить этот эксперимент, заранее подготовиться к нему: понять для чего он это делает? куда он хочет привести команду? чему хочет её научить? Поставив цель, надо разработать план, а дальше действовать.
Но важно понимать, что команда / кадры тут скорее всего не при чем (человеческая природа — искать состояние покоя). Нужны Агенты Изменений, который понимают, что они хотят сделать и зачем. Организация и её культура должны быть готовы к agile и тогда всё получится: можно построить из группы людей — «команду мотивированных профессионалов нацеленных на качество продукта». Но для этого нужно честно ответить себе на вопросы: «Для чего мы это делаем? Готовы ли мы меняться?».
Запустить Scrum сама по себе задача непростая, а делать это в партизанских условиях — это просто героизм. ИМХО сперва нужно, чтобы «наверху» осознали и приняли, а дальше уже народ потянется.
Ну и конечно «насадить» нельзя, но научить можно.
Ну это просто не профессионализм независимо от позиции в компании. Детский сад. Зачем такой человек компании в принципе? Какие задачи он решает?
Если есть доступ к руководству, задайте прямой вопрос: «а для чего? Зачем мы внедрили Scrum?»
Из описания очень похоже, что ваш PO — это «прокси». И возможно есть настоящий PO — заинтересованный в продукте, который реально принимает решения: что делать и в какой последовательности. Возможно это сверх-занятой человек и у него просто нет времени заниматься бэклогом, тогда он может создать небольшую команду (discovery team — куда например могут входить аналитики и ui/ux специалисты), которая бы помогала ему в этом. Но важно донести до него, что наличие «прокси» с одной стороны искажает информацию в оба направления, с другой стороны коммуникации становятся дольше.
Соберитесь командой и сформулируйте свои ожидания от взаимодействия с PO. Затем позовите реального PO и озвучьте ему ваше ожидания. Совместно выработайте схему работы, где и PO не дергают неожиданно для него и команда получает нужную ей информацию.
Что касается изначального скептицизма команды, то это абсолютно нормально. Люди не любят перемен. И чтобы они с ними смирились или даже захотели, нужно показывать в чем собственно преимущества. Это и есть работа Scrum Master-а. Дело это не простое, но увлекательное (я об этом в следующих частях буду писать). Вспоминаем теорию скрама и строим эмпирический процесс демонстрации сильных сторон SCRUM для скептически настроенной команды.